Initial question 3: How to deal with subjects not listed?

Archived Page.

This page related to stage 1 of the project, which concluded in September 2014.

Dealing with subjects that don’t have an associated dedicated term is one of the issues that can affect the structure of the new subject coding scheme. Read through the issue and the solutions, and let us know what you think the solution should be, and why.

The issue

However comprehensive a coding scheme is, it is likely that there will be courses, modules or research areas that are not covered. The NSCS will need to find a way to deal with such instances.

Solution 3a. classify at the broader term

inheritance

Broader term classification

In 3a, a broader term covers a wide area of narrower or more specialised terms, some of which have been listed, but we assume that there may be many more that haven’t been listed yet. If someone discovers such an unlisted narrower term, then it can be properly covered by the broader term, even if that means a loss of some detailed meaning.

Pros:

  • covers all instances
  • consistent and predictable
  • simple

Cons:

  • implies loss of meaning

Solution 3b. explicit “subject x not otherwise classified” code

In 3b, special ‘miscellaneous’ codes are dotted around the hierarchy to catch new or unanticipated terms.

notElsewhere

A “not elsewhere classified” code

Pros:

  • familiar

Cons:

  • redundant, because it requires a very large number of “x not elsewhere classified” terms that do not add any useful meaning and tend to be overused by classifiers.
  • tempting to use as a shortcut, leading to inconsistency

Solution 3c. make your own code

In 4c, institutions can create their own codes to cover new terms. These new terms can either be left local, or registered at a HEDIIP registry for such terms or both. It is also conceivable that popular registered external codes will become part of a future NSCS.

A new subject added in its own namespace

A new subject added in its own namespace

Pros:

  • covers all instances
  • no loss of meaning
  • flexible
  • agile
  • provides a natural basis for future NSCS development

Cons:

  • may not be supported well by all systems
  • risk of fragmentation through duplication (local term means the same as a NSCS term)
  • will need governance and technical infrastructure

More initial questions on the Design page

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s