Inverse property

[Sylvain Loiseau]

Dear all,

I'm aware that an RDF ontology is a descriptive model rather than a data-entry model, and that its purpose is to describe the meaning of relationships. From that perspective, nothing in the ontology should distinguish between hasOrHadParticipant and isOrWasParticipantIn, since they are strictly symmetric.

However, from a user's perspective, we need to choose one property and use it consistently. This seems preferable to systematically encoding both properties, and also better than using one or the other inconsistently.

What solution do you have for indicating, within the ontology, which relationship should be preferred for data entry? In particular, is there any informal hint in order to select one property, that could be used automatically by an App, such as the "I" suffix of inverse property in CIDOC ?

Best,

Sylvain

[Florence Clavaud]

Dear Sylvain,

Using the OWL vocabulary, in RiC-O most relations between entities (object properties) may either be symmetric (which means that they can be used in both directions; so for instance, if ThingA rico:isRelatedTo ThingB, as rico:isRelatedTo is formally defined as being a symmetric property, then thingB rico:isrelatedTo ThingA), or have an inverse property (for instance, rico:hasOrHadParticipant is formally defined as the inverse property of rico:isOrWasParticipantIn, which means that if EventE rico:hasOrHadParticipant ThingA, then ThingA rico:isOrWasParticipantIn EventE, and vice-versa.)

On this topic see (among other resources) this section of OWL 2 Primer: https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Property_Characteristics

This is why, theoretically speaking, is you use RiC-O, no object property should be “preferred” rather than the inverse one for data entry. Now, of course, depending on the perspective you have, and on your project, you may decide, when you produce data, to focus for example either on records or on agents, which may have consequences on what you explicitly state. If your focus is on agents, you may consider creating statements that connect agents to other kinds of entities, so for example use rico:performsOrPerformed or rico:isAuthorOf rather than rico:isOrWasPerformedBy or rico:hasAuthor (which are the inverse properties, and connect activities or records to agents). Anyway, if you store the triples you have produced in a triplestore (knowledge graph database), along with RiC-O and the other ontologies you possibly use, the inference engine which this database includes should most often be able to infer the statements that use the inverse properties from the ones you have specified (and many other statements, from the hierarchies of properties or classes for example). The way inferred statements are managed depends on graph databases. But all these statements (be they explicit or inferred by the inference engine) can actually be queried just the same using SPARQL. So, based on a consistent OWL ontology, such logical inference enables the end user to navigate or query the graph from any entry point using any direction.
And even if you do not know what the inverse property is for some given property (or do not want to use this inverse property), you could, in a SPARQL query, use an inverse property path, like this: 

# Look for persons and events, where persons are connected to events using the inverse property of rico:hasOrHadParticipant

PREFIX rico: https://www.ica.org/standards/RiC/ontology#

SELECT ?person ?event

WHERE

{?person ^rico:hasOrHadParticipant ?event .}

 This query is equivalent to the following one:

SELECT ?person ?event
WHERE

{?person rico:isOrWasParticipantIn ?event .}

 

Note that of course, when you produce your data, you can also decide to produce statements in both directions.

By the way, when we developed RiC-O, we chose not to use, for their components (be they classes or properties) identifiers (names) which would include numbers like '058' or '058i'. We preferred to develop something a bit simpler to maintain, and that any human being knowing English could understand quite easily, whatever component is used. We nevertheless follow some naming conventions (I will not elaborate on this here).
However, when the RiC-O component directly transposes an entity, attribute or relation defined in RiC-CM (which is not always the case), you can find the correspondence to this RiC-CM component, and the identifier of the RiC-CM component, in a specific annotation property. 
So, for example, you have the following line in RiC-O, in the specification of rico:hasOrHadParticipant:

<rico:RiCCMCorrespondingComponent xml:lang="en">RiC-R058 ('has or had participant' relation)</rico:RiCCMCorrespondingComponent>

You will also find in RiC-O textual definitions of inverse object properties like the following one (from the specification of rico:isOrWasParticipantIn):

<rdfs:comment xml:lang="en">Inverse of 'has or had participant' object property.</rdfs:comment>

This is not at all to say that the rico:hasOrHadParticipant inverse property should be preferred (again, in an OWL ontology and in RiC-O datasets, this would not make sense). It’s just that, so far, we have lacked the time to do better.

I hope this helps,

Florence Clavaud
Chair of ICA/EGAD, lead of RiC-O development team