Subclasses of EditorialWork for "Extra" content

[JuergenGrupp]

"Extra" content like trailers, bonus material, outtakes and making-of is represented as subclasses of EditorialWork. But there are more cases to be covered: interviews, behind the scenes, raw footage. I propose to add these as subclasses to EditorialWork. The hierarchy then would look like this:

If we want to avoid subclassing for each type of "extra" content, we could introduce a class "extra (content)" and represent the types with a specific skos:concept in the property objectType. A list would be easier to maintain but coding might be more complicated (SPARQL-queries, case distinctions, etc). Please feedback your opinion on this.

[alessandraboellaW2T05]

Hello JuergenGrupp, in our ontology (broadcasting media company) based on the ebu ontology we chose to use a single class and represent the types with a list, so I second this approach.

[JuergenGrupp]

Hello JuergenGrupp, in our ontology (broadcasting media company) based on the ebu ontology we chose to use a single class and represent the types with a list, so I second this approach.

Hello @alessandraboellaW2T05, thank you for your comment!

Just to make sure that I understood correctly: You have a class similar to EditorialObject and create related "classes" only by adding a type from a list. You don't use any subclassing for that. Is that correct? Or do you have a class similar to "Extra Content" as a subclass to EditorialObject (or similar) and create related classes from "Extra Content" that by adding a type from a list?

Thank you for clarification!

[tormodv]

All the potential sub-classes of "extra" will probably have the same set of properties, therefore the objectType attribute referring a skos:Consept instance will probably cover what you need and will be more flexible, and can be more detailed, adapted to the needs of each broadcaster.

[JuergenGrupp]

Thank you for your comments, @alessandraboellaW2T05 and @tormodv !

We have discussed the pros and cons of the two approaches in the editorial committee: subclassing vs skos:Concept. Depending on the use case, the circumstances of the implementation and the knowledge of participating developers, you can choose one or the other. It is perfectly ok to use a skos:Concept (property "objectType") and to NOT use the EditorialObject or EditorialWork or EditorialExtra subclasses.

In fact, I do that in my own implementation project, because in my specific use case the type of an individual EditorialObject is quite likely to change over time, so it is simpler to implement it with skos:Concept for the time being. (I might review this decision in the course of the project, though.)

The Editorial Committee also considered that in the world of semantics all information is represented as triples, so the difference of subclassing vs skos:Concept is really not so huge: An individual resource is assigned a class with the "rdfs:type" property. Or it can be assigned a skos:Concept with the "objectType" property. The results are also very similar when you map the triples of this individual in a serialized format like JSON. Only when you cast the serialized format into an object of your object oriented programming language, you'll have to implement the correct conditions. Still, the code will look very similar either way.

However, for the purpose of creating a specification, we think subclassing is more expressive. It can express with exact statements which subclasses have which additional properties (e.g., "hasSeason" is only available to a subset of the classes in the hierarchy). Otherwise, those business rules would need to be expressed in another form (e.g., SHACL-rules). The specification would become less compact and require additional techniques.

So, the shortly following pull request will contain a new subclass of EditorialWork with the name EditorialExtra. And EditorialExtra will be the superclass for Trailer, Bonus, Outtakes, MakingOf, Interviews, BehindTheScenes and raw Footage. If this list needs to be amended, please comment or file a new issue.

[JuergenGrupp]

After discussion in the Editorial Committee: Interview is removed from the Subclasses of EditorialExtra. Footage will stay but remember to call it "Stock Footage", when talking about material, that is not yet edited.