JuergenGrupp
commented
3 months ago Here's an update to the ideas presented above:
I have added a few examples for new subclasses of Contract like Subscription, Licensing and Purchase. This led to the idea of renaming "ProductionOrder" to "Order", because the concept of an order is much broader and fits better with the other subclasses. Another reason for the new proposal is the smaller number of properties, if labels like "isAppliedIn" and its inverse "applies" are used. And we can avoid redundancies ("ProductionJob" "usesProductionDevice" "ProductionDevice"). So here is the proposal V2 for the modelling:
Some thoughts on this:
- hasSubject can point to other classes, too.
- hasParty is a super-property of hasContributor.
- Properties pointing to Involvement are better named "hasContribution" than "hasContributor".
- properties pointing to Agent are better named "hasContributor" than "hasAgent". Exception: "Contract hasParty Agent" is more generic and can remain.
Comments are appreciated.
ProductionOrder is currently a subclass of Thing. It's intention is to represent the agreement of (at least) two parties to conduct a ProductionJob for some piece(s) of content, represented as EditorialObject(s). Therefore the attributes of class Contract fit perfectly for all ProductionOrders and this makes it a nice fit as a subclass. Also, Contract has some object properties to link it with ProductionJob, ProductionDevice and EditorialObject. These properties are too specific for the generic class contract, but fit better with ProductionOrder.
Contract also covers agreements for the publication of content. This should be represented in a new subclass of Contract, eg. PublishingContract, that links to Rights and a PublicationPlan (consisting of PublicationEvents) or a PublicationPattern. PublishingContract should be added.