Simplifying subclasses under EditorialObject.

[tormodv]

EditorialObject is one of Ebucoreplus's main building blocks. Therefore, it is natural that we have a few variants of the class with additional properties. Among the subclasses, we also have some variants that do not provide any new properties; they are merely a change of name or clarification of their function. We can express this with an instance of skos:concept instead. I propose that we remove the classes that don't provide any additional properties.

[JuergenGrupp]

Thank you @tormodv for this proposal! Our goal is to specify EBUCorePlus-subclasses only if they introduce additional (object or data) properties.

Before I remove the above mentioned subclasses of "EditorialWork", I would like to clarify how we alternatively model this classification by using "skos:Concept",

If I understand correctly, the current way of using "skos:Concept" in the model is to add a subclass of "skos:Concept" as the classification scheme root. The naming convention is to add "Type" or "Code" to the name of the class whose individuals are classified, eg. "IdentifierType", "CountryCode" (some exceptions like "Format" apply). Then the classifying terms are used as subclasses and may create a hierarchical list of concepts. Like in this example:

• skos:Concept
  • IdentifierType
    • AnimalBreedCode
    • CountryCode
    • CityCode
    • ...

Applying this rule to the proposed classes would lead to a hierarchy like this:

• skos:Concept
  • ...
  • ItemType
    • SportsItem
    • BreakingNewsItem
    • Review
  • ProgrammeType
    • AudioContent
    • RadioProgramme
    • TVProgramme
  • EditorialExtraType
    • Bonus
    • BehindTheScenes
    • MakingOf
    • ...

I see the following advantages:

• enables simple maintenance directly in the model
• allows for adding organization-specific concepts to a list or even replacing the list completely

Question 1:
Is this the intended and right way to model classification schemes in EBUCorePlus? Even if we do not use skos:ConceptScheme?

Question 2:
I would not remove the class "EditorialExtra" as proposed by Tormod, because this subclass introduces the property "hasProgramme" as a specific reference to another "EditorialWork". Do you agree?

Question 3: For the same reason I would not remove "Reminder". It introduces a specific reference to another "Promotion". But I would move it to become a subclass of "Promotion", which introduces a reference to a "CampaignPackage". Do you agree?

[JuergenGrupp]

We decided in the Editorial Committee today:

• keep EditorialExtra as a class
• re-check the classes and don't remove them, if they add properties
• Reminder class should also be kept and made a subclass of Promotion
• skos:concept should only be used as placeholders for real controlled vocabularies that in turn might be defined as skos:concepts that may point to a skos:conceptScheme. So we should not add all possible values here.