ebu
Inverse Properties: existing, new, renamed, corrected, obsolete
I checked all properties for being defined as inverse or requiring to be defined so. Here's the list of proposals. Comments are welcome.
1) define existing properties as inverse
isTrackPartOf <> hasTrackPart (forward property)
2) define new properties as inverse
isAffiliatedTo <> hasAffiliation (new forward property! would point from Organisation to Affiliation) isAnimatedBy <> animates (new forward property!) isAnnotationFor <> hasAnnotation (new forward property!) isApprovedBy <> grantsApproval (new forward property!) isCommissionedBy <> commissions (new forward property!) isDefinedBy <> defines (new forward property!) isEmbodiedBy <> hasEmbodyingArtefact (new forward property!) isEpisodeOf <> hasEpisode (new forward property!) isExtractOf <> hasExtract (new forward property!) isIssuedBy <> hasIssuer (new forward property!) isMasterOf <> hasMaster (new forward property!) isOrderedBy <> hasJob (new forward property!) isOwnedBy <> owns (new forward property!) isPlayedBy <> plays (new forward property!) isPortrayedBy <> portrays (new forward property!) isReferencedBy <> references (new forward property!) hasAuthor <> isAuthorOf (new!)
3) rename existing properties and define new properties as inverse
isRelatedAgent (instead of isAgent) <> hasRelatedAgent (new forward property!) hasAnimalGroom (instead of isAnimalGroom) <> isAnimalGroomFor (new forward property!) isUsedBy (instead of isRegisteredAs <> uses (new forward property!) isOfferedBy (instead of isReleasedBy <> offers (new forward property!) isPublishedBy (instead of isScheduledOn <> publishes (forward property) isProductOf (instead of isSeriesOf) <> hasProduct (new forward property)
4) corrections to existing inverse properties
isMediaFragment <> hasMediaFragment (the domain of hasMediaFragment must be from Media Resource, not from EditorialObject) isPartOf <> hasPart (the domain for "isPartOf" must be EditorialSegment or Work, not EditorialObject)
5) obsolete properties ?
isChildOf <> hasChild (instead of hasParent <> isParentOf ! remove isParentOf and hasParent?) isAnnotatedMediaResource <> hasMediaResourceAnnotation (probably not neccessary! better use isAnnotationFor <> hasAnnotation) isMemberOfPublicationPlan (probably obsolete?)
Agree with your proposal.
Should we consider additional inverse properties like ?
hasAudience <> ec:isAudienceOf hasContributor <> isContributorOf
Consider using anonymous inverse properties instead of named ones where possible. OWL allows referring to inverse properties without explicitly naming them, which can reduce clutter
Advantages of defining and naming inverse properties
Explicitness: Named inverses make it clear how two entities are related in both directions. Ease of querying: Users can refer directly to the inverse name in queries without having to construct it manually.
Disadvantages
Ontology complexity: Adding named inverses for every property can add unnecessary complexity. Performance impact: Named inverses can increase computation time and storage requirements, especially if not all are actively used.
Mixed approach
A mixed approach, where inverse properties are named only when explicitly needed or frequently queried, is a compromise. This approach ensures that the ontology remains lean while still effectively supporting common use cases.
Criteria for naming inverse properties
Query frequency: If the inverse relationship is frequently used in queries, it should be named. Semantic Clarity: If the inverse name adds significant clarity to the structure or use of the ontology, it should be defined. Avoidance of redundancy: Avoid naming inverses that are rarely used or that add no value over their forward counterparts.
Ref https://www.semanticarts.com/wp-content/uploads/2018/10/QuantumEntanglementInverseProps041516MFUnewtemplate.pdf
He will consider systematically adding the inverse properties - it has become good practice. We will review the ebucoreplus to identify other potential inverse properties. For example hasAudience <> isAudienceOf hasContributor <> isContributorOf
Sections 1 and 2 are correct and most of them will be helpful when querying the graph.
In section 3 I have to take a closer look at “is scheduled on” renaming. I think this relation is used for or was meant to be used to connect a publication event to a certain publication plan. I will check on my computer later.
Offer versus release? This is a kind of synonym. One can say that a publisher offers some content, but in the music business, they still reference this as a release. (In the days of LP or CD the physical content carriers were distributed to the store and then released on a certain release date from when you were able to buy the record) If we do a renaming, perhaps the other term should be mentioned in the description.
Section 4 is probably OK.
Section 5 i have to check the last line covering the relation to the publication plan.
isPublishedBy (instead of isScheduledOn <> publishes (forward property) The Object property might be ok, but it is a danger that people think this references a publisher, ex: "The book was published by Nature."
isMemberOfPublicationPlan (probably obsolete?) This one points to a publication plan that is part of another publication plan. If we delete it, we can use parent/child instead, but we must update the class restrictions accordingly.
He will consider systematically adding the inverse properties - it has become good practice. We will review the ebucoreplus to identify other potential inverse properties. For example hasAudience <> isAudienceOf hasContributor <> isContributorOf
EditorialCommittee: We should not add these two.
- isAudienceOf might lead to 1:many (millions?) links, that could impede DB performance. (-> complexity criteria)
- isContributorOf will not link a Person to all EditorialObjects, because the class Involvement is in between. It would not help and ist useless here.
However, we should consider the criteria mentioned above by @aro-max when deciding about inverse properties.
After the discussion in the Editorial Committee, I re-checked the list and applied the "Mixed Approach". As the result, here's the list of changes to apply:
1) define existing properties as inverse
isTrackPartOf <> hasTrackPart (forward property)
2) define new properties as inverse
hasAffiliation <> isAffiliationFor (new property! will point from Affiliation to Person) isAnimatedBy <> animates (new forward property!) isAnnotationFor <> hasAnnotation (new forward property!) isApprovedBy: already renamed to hasApprover <> grantsApproval (new forward property!) isCommissionedBy: rename to hasCommissioningContract <> commissions (new forward property!) isDefinedBy <> defines (new forward property!) isEmbodiedBy <> hasEmbodyingArtefact (new forward property!) isEpisodeOf <> hasEpisode (new forward property!) CANCELLED: isExtractOf <> hasExtract (new forward property!) CANCELLED: isIssuedBy <> hasIssuer (new forward property!) isMasterOf <> hasMaster (new forward property!) isOrderedBy <> hasJob (new forward property!) isOwnedBy <> owns (new forward property!) isPlayedBy <> plays (new forward property!) isPortrayedBy <> portrays (new forward property!) isReferencedBy <> references (new forward property!) hasAuthor <> isAuthorOf (new!) hasRegistration <> hasRegisteredConsumer
3) rename existing properties and define new properties as inverse
hasAffiliationTarget (instead of isAffiliatedTo) but no inverse property needed isRelatedAgent (instead of isAgent) <> hasRelatedAgent (new forward property!) hasAnimalGroom (instead of isAnimalGroom) <> isAnimalGroomFor (new forward property!) CANCELLED: isUsedBy (instead of isRegisteredAs <> uses (new forward property!) CANCELLED: isOfferedBy (instead of isReleasedBy <> offers (new forward property!) hasPublication (insead of isPublishedBy) <> publishes (existing forward property) isProductOf (instead of isSeriesOf, change domain to EditorialObject, not only Series) <> hasProduct (new forward property, also pointing to EditorialObject)
4) corrections to existing inverse properties
isMediaFragment <> hasMediaFragment (the domain of hasMediaFragment must be from Media Resource, not from EditorialObject) isPartOf <> hasPart (the domain for "isPartOf" must be EditorialSegment or Work, not EditorialObject)
5) obsolete properties
remove hasParent <> isParentOf . Use isChildOf <> hasChild instead remove isAnnotatedMediaResource <> hasMediaResourceAnnotation (not neccessary!). Use isAnnotationFor <> hasAnnotation instead replace isMemberOfPublicationPlan by isMemberOf remove offers (from each of PublicationPlatform, PublicationChannel or PublicationService to PublicationEvent: channel, platform and service are master data objects that should not know at all of all their uses.)
This issue was resolved by the commits in the following pull requests: #382 #383 #385