Many object property names are not according to semantic naming conventions and guidelines

[JuergenGrupp]

About a quarter of the object properties are not following conventions or best practices for semantic modelling. The use of naming elements like "is", "has" and "of" is not consistent across the ontology. Some forward properties should rather be named in active voice and deserve inverse properties in passive voice. This is due to historical evolution, especially the merge of CCDM and EBUCore into EBUCorePlus and the use of class restrictions instead of the specification of domain and range. Some examples for current names and their improvements:

• current: "objectType skos:Concept" , better: "hasObjectType skos:Concept"
• current: "hasChild" and "hasParent", better "hasChild" and "isChildOf"
• current: "dubbedTo MediaResource", better "hasDub MediaResource"
• current: "isDubbedFrom MediaResource, better "isDubOf MediaResource"
• current: "clonedTo MediaResource", better "hasClone"
• current: "isClonedFrom MediaResource", better "isCloneOf"
• current: "accountingTo Account", better "accountsTo Account"

The proposal here is to adopt the best practices of semantic naming and change their names. This will result in a non-backward-compatible version of the ontology and hence some effort for adapting software and interfaces. But it will foster easy understanding and consistent use of the ontology in the long run.

The correction effort can be combined with issue #286 : labelling inconsistencies for object properties.

[aro-max]

I propose to list the heuristic rules and review them before applying the changes. as a starting point, some rules for renaming properties.

Prefix with "has" for possessive relationships:

• Use "has" to denote ownership or containment.
• Example: "VersionType" should be "hasVersionType"

Prefix with "is" for state or existential relationships:

• Use "is" for properties that indicate a state, condition, or existential relationship
• Example: "ApprovedBy" should be rephrased as "isApprovedBy"

Use of "of" for Inverse Relationships:

• Rename properties to include "of" when defining inverse relationships, making them passive
• Example: "ChildOf" as opposed to "hasParent"

Active vs. Passive Voice:

• Apply active voice for forward relationships and passive voice for inverse relationships
• Example: "Controls" can have an inverse property "isControlledBy"

Unify verb tenses and forms:

• Maintain tense consistency across properties.
• Example: "applyTo" should be "appliesTo".
• Ensure properties that imply action use a verb that clearly states the action.
• Example: "dubbedTo" should be "hasDubbedVersion" or "dubsTo".

Specificity in Relationships:

• Use specific relational phrase that accurately describe the interaction between entities.
• Example: "memberOf" can be detailed further into "isMemberOf"

[JuergenGrupp]

Editorial Committee agreed on these rules on April 22. There will be a minimized number of exception to the rules.

[aro-max]

We will share the exceptions for documentation/explanation purpose.