Classification properties and (subject) resource types (e.g. occupationType, industryType, instructionalProgramType)

[philbarker]

Some classification properties are used with resource types other than the type for which the scheme referenced is as classification. The definition of these properties does not make this usage explicit.

Examples:

• ceterms:instructionalProgramType is not always used on an instructional program
• ceterms:occupationType is not always used on an occupation
• ceterms:industryType is not always used on an industry

For further discussion about this usage see comments at the end of issue #730

The definitions for these properties follows the pattern

Type of industry; select from an existing enumeration of such types such as the SIC, NAICS, and ISIC classifications.

I suggest

Indicates the type of [industry|occupation|instructional program] for which a resource is relevant; select from an existing enumeration of such types such as the ABC DEFG HIJ classifications.

The definition for ceterms:audienceType and ceterms:audienceLevelType, ceterms:assessmentDeliveryType , ceterms:learningDeliveryType already follow roughly similar patterns, e.g. "The type of audience for which the resource is applicable, intended, or useful; select from an existing enumeration of such types."

Other ___Type properties have domains that align with what the relevant classification scheme covers, e.g. learningMethodType has domain LearningOpportunityProfile

[siuc-nate]

Mirroring my post from #730, minus the last line since this is no longer in the context of the october release:

The definition may benefit from some work, but the usage isn't all that different from how we use other properties that point to concepts in a scheme:

• industryType references the classification of industry applicable/relevant to the thing being described; it is not saying "this credential/etc is a 611692 Automobile driving schools"
• occupationType references the classification of occupation applicable/relevant to the thing being described; it is not saying "this credential/etc is a 39-5011 Barbers" (with the possible exception of its use by ceterms:Occupation, where a soft-subclassing interpretation is more reasonable, but it's still technically just a classification)
• audienceType references the classification of audience applicable/relevant to the credential/etc being described; it is not saying "this credential/etc is a Former Military"
• creditUnitType/creditLevelType reference the classification of unit/level of credit applicable/relevant to the course/etc being described; it is not saying "this course/etc is a Degree Credit" (with the possible exception of its use by ceterms:ValueProfile, where a soft-subclassing interpretation is more reasonable, but it's still technically just a classification)

In essence, the lack of any actual verb in all of our _____Type properties makes the verb implicit based on the context (ie based on what is doing the pointing) - meaning that this interpretation follows suit with the rest of CTDL:

• instructionalProgramType references the classification of instructional program applicable/relevant to the credential/etc being described; it is not saying the credential/etc is a 14.0803 Structural Engineering (with the possible exception of its use by ceterms:LearningProgram, where a soft-subclassing interpretation is more reasonable, but it's still technically just a classification)

We use some variation of "type of x; select from an existing enumeration of such types" with a lot of our ____Type properties, so while the definition for instructionalProgramType seems odd in a vacuum, it isn't all that strange when you look at it in the context of the rest of CTDL. That terseness is probably also intentional, since it gives you greater flexibility when interpreting the implicit verb of the property itself. There is some value in that fuzziness.

I guess what I'm saying is: let's not update the definition for instructionalProgramType in a vacuum; let's figure out some logic for doing so that also applies, minimally, to instructionalProgramType, industryType, and occupationType (and ideally to all of our ____Type properties).

[philbarker]

Thanks for copying that over Nate.

I think that my first post for this issue takes into account the points you raise. Unless I missed some, it is only the three ___Type properties that I mention as examples that are used in the way you describe (to point to classification scheme for a different type of resource in order to indicate some relevance) but don't have definitions that make that usage clear. The others either say so in the definition or are only used for types to which the classification applies.

We live with what we have, but going forward we are in a better position to avoid this type of use. For example if we now wanted a property to indicate that something was somehow relevant to some occupation we could point to an object of type ceterms:Occupation -- just as we did with ceasn:substantiatingOccupation.

[siuc-nate]

This one is probably still worth thinking about, but it hasn't come up in a few years, so I'm archiving it for now.