Rolifying the n-ary Relation classes

[florenceclavaud]

I'm afraid the following will be long and quite technical.

For now, in RiC-O, we have a system of n-ary Relation classes (48 classes) that correspond to RiC-O binary object properties and can be used whenever you want to say something about a relation (add a description, a certainty, a date, a place, to it, for example, not to mention that you can assign a IRI to it). Instances of these Relation classes are thus full contextual, historical entities. This also enables to connect to each other more than two other entities, which is much closer to real facts in the archival world (see for example rico:AgentOriginationRelation, or rico:LeadershipRelation).

For each of these n-ary relations, there at therefore at least 4 object properties. For example, as concerns the LeadershipRelation, you have:

• ‘leadershipRelationHasSource’, used to connect the LeadershipRelation to a Person;
• ‘leadershipRelationHasTarget’, used to connect the LeadershipRelation to a Group;
• the two inverse properties of these properties, that can be used to connect the Person and the Group to the LeadershipRelation.

This results in a significant number of object properties (for now, 168 ones in RiC-O 0.2).

In addition to this, in order to explicitly relate the Relation classes to the binary object properties of which they are a full representation, RiC-O uses the OWL 2 property chain axiom feature (see https://www.w3.org/TR/2012/REC-owl2-new-features-20121211/#F8:_Property_Chain_Inclusion), in order to say for example, that the object property rico:isOrWasLeaderOf is the shortcut for the more complex path that involves the Person, the LeadershipRelation and the Group. See also, about this, https://www.ica.org/standards/RiC/RiC-O_v0-2.html#fromRiCCM-to-RiCO.

Semantically and technically speaking, this results in a good formal definition. And it allows a reasoner that would know OWL 2-RL to infer, if an instance of the LeadershipRelation exists, the shortcut to which it is bound.

Everything there works very well. At the ANF we already are making an extensive use of the n-ary relations in our datasets (one of the reasons being that we have about 16000 authority records in EAC-CPF, which contain a lot of descriptions of relations between agents and provenance relations, with dates and textual details). See the ‘agents/producteurs’ subfolder in the https://github.com/ArchivesNationalesFR/Referentiels. And we have already used the inferred properties as inferred ones.

The problem with this is that all this results in a huge amount of declarations in RiC-O, which is difficult to maintain, particularly the resulting system of object properties.

The 48 n-ary Relation classes should undoubtdely be kept, and even enriched maybe. As said they are already necessary, even when you just start from 'legacy' metadta, e.g. XML/EAC-CPF files. They should be more and more useful if institutions and projects move to higher quality metadata; this, at least until another better method is specified, one of the candidates being OWL Star - well we'll see.

Same for the property chain axioms and the shortcuts. In particular, the shortcuts / binary object properties are a direct, full, simple, transposition (and extension) of RiC-CM, that all implementations are using and will extensively use. This is the core of RiC.

Fortunately, we can drastically simplify the system of object properties related to the Relation classes (as a reminder, there are exactly 168 object properties of the kind in RiC-O 0.2, out of 423 object properties, which is 40 %).

In order to do this, we can rolify the relation classes. You can find a good reference about this method there: https://stackoverflow.com/questions/16989042/owl-2-rolification/16990106#16990106.

So, the idea is:

• to keep only 6 generic object properties out of 168, in order to connect any rico;Thing to any rico:Relation (‘relationHasSource’, ‘relationHasTarget’, ‘thingIsSourceOfRelation’, ‘thingIsTargetOfRelation’, and their 2 symmetric super-properties);
• to create, for each Relation class, one new object property only (instead of 4) that would be defined as a reflexive one and would have the concerned Relation class as domain and as range;
• to adjust the formal definition of each Relation class, in order to say that it is the equivalent of the group of entities that have the new reflexive object property pointing to themselves;
• to adjust the definition of the shortcuts consequently.

BTW, many thanks to @tfrancart who gave me this advice and explained the solution to me.

Doing this, we could roughly divide by three the number of object properties associated with Relation classes. We could reduce the total number of RiC-O object properties by a quarter (we would get a total of about 310 properties instead of 423, considering RiC-0 0.2). Doing this, we would keep the same semantics for the Relations, the same level of accuracy as concerns their formal specification, and the same inference possibilities.

We already have discussed the topic within the RiC-O development team, and I know the persons who have reacted agree with this proposal.
Also, I already have tested the idea, and it works.
Unless somebody strongly opposes this idea there, I would like to work on that ASAP, i.e. tomorrow. Though I am thinking of doing it quite automatically, I will need several hours. Also, this is quite urgent, since after that, we still have other quite 'big' issues to address for RiC-0 1.0, among which this general one: #45.

[williamsonrichard]

Cool to discuss this! To summarise, the idea as I understand it is as follows. One introduces an object property ReflexiveLeadershipRelation

and then asserts

LeadershipRelation EquivalentTo ReflexiveLeadershipRelation some Self

as well as the following.

thingIsSourceOfRelation o ReflexiveLeadershipRelation o relationHasTarget subPropertyOf isOrWasLeader

This is a neat trick!

A disadvantage with the proposed approach is that one cannot explicitly express what class the source or target of a leadership relation should have. It does follow logically from that the second and third assertions above (the ones involving EquivalentTo and composition), so one doesn't really lose anything ultimately in OWL Full, but from the point of view of automatically generating documentation for instance, to guide how people should use the relations, the result may be somewhat less clear than today; and if one is using an OWL DL reasoner for example, one does lose something, because OWL DL, if I am not mistaken, will not be able to understand the final assertion.

And of course there is the disadvantage that the proposed approach is considerably more abstract, which likely will make it more difficult to understand: there is no way really to 'hide' the abstraction from the user.

Naturally, one has to weigh up whether these disadvantages outweigh the streamlining and greater elegance that you describe!

Aesthetically, though I understand how it does the job in practise here, something about the second assertion (the one involving EquivalentTo) also troubles me. I think it may partly be that the semantics seem incomplete: what does A ReflexiveLeadershipRelation B mean for example, when A is not B?

[florenceclavaud]

Hi @williamsonrichard

my two first cents (I do hope I have understood your reactions well and I am clear - I will check the answers below later on).

Cool to discuss this! To summarise, the idea as I understand it is as follows. One introduces an object property ReflexiveLeadershipRelation

and then asserts

LeadershipRelation EquivalentTo ReflexiveLeadershipRelation some Self

as well as the following.

thingIsSourceOfRelation o ReflexiveLeadershipRelation o relationHasTarget subPropertyOf isOrWasLeaderOf

Yes exactly.

This is a neat trick!
A disadvantage with the proposed approach is that one cannot explicitly express what class the source or target of a leadership relation should have. It does follow logically from that the second and third assertions above (the ones involving EquivalentTo and composition), so one doesn't really lose anything ultimately in OWL Full, but from the point of view of automatically generating documentation for instance, to guide how people should use the relations, the result may be somewhat less clear than today; and if one is using an OWL DL reasoner for example, one does lose something, because OWL DL, if I am not mistaken, will not be able to understand the final assertion.

In fact you keep the Relation class just as it was defined before (except that you add a equivalentClass property; and replace the 4 specific object properties previously defined by the 4 generic ones).
You can still say, for example, that a LeadershipRelation class has source at least one person and has target at least one group.

As concerns the reflexive object property, it can be defined as shown below, with a domain and a range (everything there is a test, which works; but I have added things to RiC-O instead of changing them):

About inferencing: you can infer the shortcut using OWL-RL, just like with RiC-O 0.2, provided that you have in your data explicited the fact that the instance of the relation class has this reflexive object property, like in the example below.

And of course there is the disadvantage that the proposed approach is considerably more abstract, which likely will make it more difficult to understand: there is no way really to 'hide' the abstraction from the user.

Well I am not sure the end user would really see the difference. When you want to use such Relation classes, even if you stick to RiC-O 0.2, you must in the end configure a query interface that can use property paths so that you can go through this intermediate Relation node, or use the inferred shortcut (note that of course, nothing prevents you from having this shortcut in your 'explicit' data). And also find a way to display the n-ary relation (if needed).

Now I agree that the pattern is more abstract and more technical, but IMHO it is worth doing, since again it will make the ontology much easier to maintain - I have already spent hours creating and updating the system of Relation object properties, and honestly it is really complex.
And RiC-O would remain something not so difficult to understand for somebody who would have skills in semantic technologies and OWL. Less complex than other models.

[williamsonrichard]

Hi @florenceclavaud, thank you very much for the replies! I should say that of course you must feel free to go ahead with what you feel is best, I have not really explored it enough to have a firm opinion either way, I am just offering a few points for reflection in case they are useful and have not already occurred to you :-).

You can still say, for example, that a LeadershipRelation class has source at least one person and has target at least one group.

Good point, thank you! This does not of course exclude also saying, for some LeadershipRelation individual L that 'L relationHasSource X' where X is any rico:Thing, without getting any immediate contradiction if one asserts that X is not a rico:Person (I will elaborate a bit more below on what I mean by 'immediate contradiction'), so I still think that the situation is not quite the same as/as explicit as before; but it is a good point that saying that LeadershipRelation is a subclass of 'relationHasSource some rico:Person' or similar does help with regard to indicating to the user what is intended.

As concerns the reflexive object property, it can be defined as shown below, with a domain and a range

This part I had understood, but thank you for the confirmation!

you can infer the shortcut using OWL-RL, just like with RiC-O 0.2

Thank you for the example! I had actually understood this too, apologies if my point was unclear: what I meant to say is that in OWL-DL (not -RL), which many reasoners use, one can immediately infer a contradiction if, for a LeadershipRelation L, one says L rico:leadershipRelationHasSource X and also that X is not a rico:Person, without having to use inference and composition of properties, which typically OWL-DL is not able to handle. One can certainly take a decision that this is not so very important, but it is at least a change from before.

Well I am not sure the end user would really see the difference

You could be right here, I agree that for a user who is concerned with creating data by means of relation classes, they could probably ignore and never have a need for the reflexivity aspect. Whether one can ignore it if one is working with the data by means of SPARQL or similar is more unclear to me, for instance, but you might be right here too. And for those who work without relation classes, one can ignore it. Where I think one cannot ignore it is if one is just trying to understand the ontology and how to use it, and trying to understand the way in which relation classes and the simple object properties interact, but this can probably be ameliorated to a significant degree by good documentation/supporting materials.

Regarding the 'aesthetic' point with which I ended my first comment, by the way, I think one can take it a bit further:

thingIsSourceOfRelation o ReflexiveLeadershipRelation o relationHasTarget subPropertyOf isOrWasLeaderOf

is also rather unfathomable if one uses A ReflexiveLeadershipRelation B where A is not B!

But what you write here...

since again it will make the ontology much easier to maintain - I have already spent hours creating and updating the system of Relation object properties, and honestly it is really complex.

is of course a very important point, which I have a lot of sympathy for :-)!

[florenceclavaud]

I agree with all your comments above I think. In other words, yes this pattern has its drawbacks.

And in the end, yes we will need good documentation.

As concerns A ReflexiveLeadershipRelation B where A is not B, I had not thought of this I must say...
Well, I know this is not a fully satisfactory answer, but just like about SKOS, when you learn that you should not use skos:narrower for an indirect relation, only to 'direct hierarchical link between two SKOS concepts' (https://www.w3.org/TR/skos-reference/#semantic-relations) we could at least say in the documentation : this property it not to be used in other situations than the reflexive case.

We also could release some SHACL rules along with RiC-O (in the future ;-)). It would at least help I think to handle some of the cases you quote.

[florenceclavaud]

I have begun to work on this, and in fact I already have written a script that does everything needed :-).

But of course I have found a few tricky cases in the input RiC-O 0.2 file, that need to be fixed, and I would also like to complete the shortcuts already present in RiC-O 0.2 so that everything works well.
Also, this is linked to the issue #39.

So, nothing in the branch for now; I will come back to this in about 2 weeks.

[williamsonrichard]

Great!

we could at least say in the documentation : this property it not to be used in other situations than the reflexive case.

Absolutely, this sounds like a good idea!

We also could release some SHACL rules along with RiC-O (in the future ;-)). It would at least help I think to handle some of the cases you quote.

Sounds good!

[florenceclavaud]

The classes are now rolified, and the PR merged (see #83). This has implied:

• that 48 new, reflexive, object properties, named with '_role' as a suffix, have been created
• that the specs of the 48 n-ary preexisting relation classes have been modified
• that the chain property axioms of the corresponding shortcuts have also been modified
• that 166 object properties have been deleted
  I also have added a OrganicOrFnuctionalProvenanceRelation class, superclass of ActivityDocumentationRelation and of OrganicProvenanceRelation (which was AgentOriginationRelation), and created or renamed the needed shortcuts.
  I am closing this issue.

[VladimirAlexiev]

@florenceclavaud asked:

support for RiC-O rolification in GraphDB?
Having support for these rolification properties in GraphDB will enable us, among other things, to utilize property paths for traversing these relations in SPARQL or to leverage the property chain axioms of RiC-O for generating shortcuts.

Hi! Can you elaborate the question: what is the problem?

Rolification Uses propertyChainAxiom and hasSelf

"Rolification" means adding a self-loop on relation instances (eg leadershipRelation_role below), so it can be used in PCA:

rico:isOrWasLeader owl:propertyChainAxiom
  (rico:thingIsSourceOfRelation rico:leadershipRelation_role rico:relationHasTarget).

GraphDB supports PCA.
However, there is a problem with inferring leadershipRelation_role, which is defined like this:

rico:LeadershipRelation a owl:Class;
  owl:equivalentClass [a owl:Restriction;
    owl:onProperty rico:leadershipRelation_role;
    owl:hasSelf true].

According to the OWL2 Profiles spec, hasSelf is part only of OWL2 EL. It's explicitly excluded from OWL 2 QL and it's not mentioned in the description or grammar of OWL2 RL.
GraphDB supports OWL2 QL and RL but not EL.
We may be able to add some partial support for hasSelf, but I think there's a better way.

First let's explore the complexity of PCA.

Complexity of propertyChainAxiom

The handling of multiplace (arbitrary length) PCA is a bit complex since it involves unrolling the list that holds the PCA.
If you look in the Builtin rules (on Windows: c:\Users\<user>\AppData\Local\GraphDB Desktop\app\configs\rules\builtin_owl2-rl-optimized.pie) or the documentation https://graphdb.ontotext.com/documentation/10.5/reasoning.html#entailment-rules, you'll find PCA rules like this:

Id: prp_spo2_1
    p <owl:propertyChainAxiom> pc
    start pc last                   [Context <onto:_checkChain>]
    ----------------------------
    start p last
        
Id: prp_spo2_2
    pc <rdf:first> p
    pc <rdf:rest> t                 [Constraint t != <rdf:nil>]
    start p next
    next t last                     [Context <onto:_checkChain>]
    ----------------------------
    start pc last                   [Context <onto:_checkChain>]

Id: prp_spo2_3
    pc <rdf:first> p
    pc <rdf:rest> <rdf:nil>
    start p last
    ----------------------------
    start pc last                   [Context <onto:_checkChain>]

Here is a worked example how this reasoning works for a 2-place chain, and it's quite a mind twister:

Axiom: assume a chain P of two properties P1,P2:
  P   <owl:propertyChainAxiom> PC
  PC  <rdf:first>              P1
  PC  <rdf:rest>               PC'
  PC' <rdf:first>              P2
  PC' <rdf:rest>               <rdf:nil>

prp_spo2_3: pc=PC', p=P2
  start' P2  last'
  ----------------
  start' PC' last' [Context <onto:_checkChain>]

prp_spo2_2: next=start', t=PC', last=last', pc=PC, p=P1
  start P1 start'
  --------------
  start PC last'   [Context <onto:_checkChain>]

Branch1: prp_spo2_1: start=start, pc=PC, last=last', p=P
  -------------
  start P last'

Overall:
  start  P1 start'
  start' P2 last'
  ---------------
  start  P last'

Branch2: prp_spo2_2: next=start, t=PC, last=last': no match

Optimized 3-place PCA

If most of our chains are 3-place, we can write an optimized rule:

id: propChain3place
  P   <owl:propertyChainAxiom> PC1
  PC1 <rdf:first>              P1
  PC1 <rdf:rest>               PC2
  PC2 <rdf:first>              P2
  PC2 <rdf:rest>               PC3
  PC3 <rdf:first>              P3
  PC3 <rdf:rest>               <rdf:nil>
  a1  P1                       a2
  a2  P2                       a3
  a3  P3                       a4
  --------------------------------
  a1  P                        a4                  

It takes just one step and doesn't infer intermediate relations in the hidden context <onto:_checkChain>.
It's not only simpler, but also quite more efficient.

Using Qualification Instead of Rolification

The Linked Data Patterns book documents a Qualified Relation pattern
that is widely used in the PROV-O ontology.
Similarly to RiCO, PROV uses a whole lot of direct relation properties (called "unqualified") and their corresponding relation classes (called "qualified").
Eg Example 6 and Example 7 illustrate this duality.

PROV uses a simple way to associate the qualified relation to the direct property, eg:

prov:Generation prov:unqualifiedForm prov:wasGeneratedBy .

RiCO can use the same mechanism:

rico:LeadershipRelation prov:unqualifiedForm rico:isOrWasLeader.

This is better than rico:leadershipRelation_role because:

• It doesn't create a parasitic self-link on every relation node
• It expresses the association between the relation node and the direct property in a simpler way.

Using a Custom Rule

While OWL class constructs are extensive, its property constructs are quite limited.
The report https://rawgit2.com/VladimirAlexiev/my/master/pubs/extending-owl2/index.html
(mentioned in https://graphdb.ontotext.com/documentation/10.5/rules-optimisations.html)
introduces the use of custom axiomatic constructs and rules as one of the ways to optimize inference.

Assuming RiCO adds prov:unqualifiedForm axioms, we can use this rule:

id: rico_qualifiedRel_to_unqualifiedRel
  a1  <rico:thingIsSourceOfRelation> a2
  a2  <rico:relationHasTarget>       a3
  a2  <rdf:type>                     cls
  cls <prov:unqualifiedForm>         rel
  --------------------------------------
  a1  rel                            a3

It is much simpler and faster than the PCA plus hasSelf form!

Inferring Qualification from Rolification

However, we don't need to change RiCO axioms to obtain the benefits of this simpler rule.
We can write another rule to convert existing PCA + hasSelf axioms to unqualifiedForm:

id: rico_Rolification_to_Qualification
  cls   <owl:equivalentClass>    restr
  restr <owl:onProperty>         self
  restr <owl:hasSelf>            "true"^^xsd:boolean
  rel   <owl:propertyChainAxiom> PC1
  PC1   <rdf:first>              <rico:thingIsSourceOfRelation>
  PC1   <rdf:rest>               PC2
  PC2   <rdf:first>              self
  PC2   <rdf:rest>               PC3
  PC3   <rdf:first>              <rico:relationHasTarget>
  PC3   <rdf:rest>               <rdf:nil>
  --------------------------------------
  cls   <prov:unqualifiedForm>   rel

Here cls is the relation class, self is its reflexive "role" link, and rel is the direct property.

rico_Rolification_to_Qualification implements "partial evaluation" of the PCA + hasSelf rules and convert them to a much simpler axiom.
It runs only a few times because it involves only axiomatic triples (T-Box).

rico_qualifiedRel_to_unqualifiedRel runs a lot more times because it operates on instance data (A-Box).
Together, the two rules implement the RiCO shortcuts in a faster and simpler way.

[tfrancart]

Hi @VladimirAlexiev

Hi! Can you elaborate the question: what is the problem?

The problem is not with the support of PCA I think. The problem is with the support of the owl:hasSelf operator in GraphDB to express rolification predicates, that would then be used in PCA.

   <owl:Class rdf:about="https://www.ica.org/standards/RiC/ontology#AgentToAgentRelation">
      <owl:equivalentClass>
         <owl:Restriction>
            <owl:onProperty
               rdf:resource="https://www.ica.org/standards/RiC/ontology#agentToAgentRelation_role"/>
            <owl:hasSelf rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</owl:hasSelf>
         </owl:Restriction>
      </owl:equivalentClass>

We had a discussion with Yan Bodain who confirmed us this was not supported in GraphDB.

[VladimirAlexiev]

I got it! Indeed, GraphDB supports OWL2 QL and RL but not EL.

In the OWL2 Profiles spec, hasSelf is part only of OWL2 EL. It's explicitly excluded from OWL 2 QL and it's not mentioned in the description or grammar of OWL2 RL.

But as outlined above, with GraphDB you don't need this self-loop to infer the shortcuts.
I was mistaken that the self-loop is on relation types, I now realize they are on each relation instance node.
I'll try to rewrite my big comment above to reflect this reality.

[tfrancart]

But as outlined above, with GraphDB you don't need this self-loop to infer the shortcuts.
I was mistaken that the self-loop is on relation types, I now realize they are on each relation instance node.
I'll try to rewrite my big comment above to reflect this reality.

Thank you, I think detailled information on how to implement this inference in GraphDB would be very very welcome !

[VladimirAlexiev]

Hi @tfrancart and @florenceclavaud!
I edited my long comment and I think it's correct now.

Rather than Rolification, I propose to use the Qualification pattern that's widely used in PROV.
It is a much simpler way to express the link between relation class and direct (shortcut) prop:
rico:LeadershipRelation prov:unqualifiedForm rico:isOrWasLeader.

• I show a rule that converts PCA+hasSelf axioms to unqualifiedForm axioms (rico_Rolification_to_Qualification),
• and a simple rule to implement shortcut derivation (rico_qualifiedRel_to_unqualifiedRel)

Now that I think about it, there may be one unimplemented aspect: inverse direct props.

• Above I implement Person-isOrWasLeader->Group based on this definition:

rico:isOrWasLeader owl:propertyChainAxiom
  (rico:thingIsSourceOfRelation rico:leadershipRelation_role rico:relationHasTarget)

• If there is a (presumed) inverse Group-hasOrHadLeader->Person, it can be implemented with simple owl:inverseOf reasoning (which GraphDB supports)
• A more complex way is to use this (presumed) definition:

rico:hasOrHadLeader owl:propertyChainAxiom
  (rico:thingIsTargetOfRelation rico:leadershipRelation_role rico:relationHasSource)

• And split up unqualifiedForm into two, eg:

rico:LeadershipRelation
  rico:shortcutSourceToTarget rico:isOrWasLeader;
  rico:shortcutTargetToSource rico:hasOrHadLeader.

• and then split the 2 rules into 4 to cover both directions

Actually I like this splitting up because it makes more explicit which are the shortcuts in both directions.
Else one is connected directly to the relation class but the other is only connected indirectly:

rico:LeadershipRelation prov:unqualifiedForm rico:isOrWasLeader.
rico:isOrWasLeader owl:inverseOf rico:hasOrHadLeader.

[florenceclavaud]

Thanks a lot @VladimirAlexiev

I think I understand what you mean, and of course the patterns defined by PROV-O are to be taken into account - besides we already had in mind to articulate RiC-O and PROV-O.

I learned a lot about OWL and semantic modeling and I am still learning; so I am not as agile with OWL as you, and my first thought may be wrong... but I suspect this solution, though elegant, PROV-O based, and allowing to avoid the reflexive properties, would imply that we move to more object properties than we have now in RiC-O 1.0 for handling the 48 Relation classes. While we had chosen to rolify in order to get something more compact and simpler to maintain than in RiC-O 0.2.
So I would say we have to think of it more.
Anyway, meanwhile, it remains possible, using RiC-O 1.0 as it is, to import or to infer the reflexive properties from instances of the Relation classes, than to infer the unqualified properties/shortcuts using the PCA.

[VladimirAlexiev]

would imply that we move to more object properties than we have now

No. For each Relation you have 1-2 shortcut props, eg:
rico:LeadershipRelation: rico:isOrWasLeader, rico:hasOrHadLeader.

The rule rico_qualifiedRel_to_unqualifiedRel uses the generic links rico:thingIsSourceOfRelation, rico:relationHasTarget to infer the specific shortcut rel. That rel is selected as the prov:unqualifiedForm of the cls, which is the type of the middle node a2.

than to infer the unqualified properties/shortcuts using the PCA.

The rule rico_Rolification_to_Qualification uses the existing PCA+hasSelf axioms at the T-Box (axiom level), i.e. fires only a few times. PCA is normally used at the A-Box (instance level) but we examine it at the axiom level to infer new axioms like rico:LeadershipRelation prov:unqualifiedForm rico:isOrWasLeader.

The benefit is that the complex PCA rules fire only a few times. Then for each relation instance, the simpler rule rico_qualifiedRel_to_unqualifiedRel fires.

[tfrancart]

Hi @VladimirAlexiev

Using Qualification Instead of Rolification

This solution implies that specific properties, holding the semantic of the relation itself, are kept in the ontology. Since relations in RiC-O are N-ary, and birectional, this implies declaring 4 specific predicates (xxxHasTarget / isTargetOfxxx / xxxhasSource / isSourceOfxxx) for each 48 Relation class in the ontology. This makes a lot of properties to maintain, hence the choice of the rolification pattern.

Using a Custom Rule

Relying on the type of the relation in the inference rule is excellent; however we can't express that in pure OWL I think ?

Inferring Qualification from Rolification

yes as you outline in your latest comment we need 2 shortcut relations, one in both direction. So we would need something like rico:shortcutSourceToTarget + rico:shortcutTargetToSource

[VladimirAlexiev]

@tfrancart We don't need 4*48 relations!
The rule rico_qualifiedRel_to_unqualifiedRel uses the universal (generic) props thingIsSourceOfRelation, relationHasTarget to infer the variable prop rel (which is specific per Relation).

Rolification infers this:
a1 rico:thingIsSourceOfRelation a2. a2 rico:leadershipRelation_role a2. a2 rico:relationHasTarget a3 -> a1 rico:isOrWasLeader a3

My rule ("unqualification") infers this:
a1 rico:thingIsSourceOfRelation a2. a2 a rico:LeadershipRelation. a2 rico:relationHasTarget a3 -> a1 rico:isOrWasLeader a3

As you see, the inference is very similar, but my rule is simpler, and doesn't require the redundant self-link for each relation instance (since those already have rdf:type link to the relation class).

we need 2 shortcut relations, one in both direction

@tfrancart and @florenceclavaud, if you like my approach, should I write up the full ruleset?
(Mind you, none of this is tested, but I'm pretty sure it's correct)

we can't express that in pure OWL I think ?

Correct. But

• this approach is used in PROV (which is widely used),
• we can derive the needed "qualification" axioms from your existing PCA+hasSelf

rico:LeadershipRelation
  rico:shortcutSourceToTarget rico:isOrWasLeader;
  rico:shortcutTargetToSource rico:hasOrHadLeader.

So repositories that want to be strict OWL can use PCA+hasSelf, whereas repositories that allow custom rules can enjoy the simplicity and better efficiency of Unqualification.

[florenceclavaud]

Hi @VladimirAlexiev and @tfrancart, I had in fact come to the same conclusion for now; thank you for the suggestion, for confirming that OWL cannot express this, for everything.

Back to the ontology, which is one of my main concerns here, I like the idea of adding a rico:shortcutSourceToTarget and rico:shortcutTargetToSource (probably as subproperties of prov:unqualifiedForm) to each of the Relation classes, since as you said they would clearly document the link between the Relation and the shortcut(s). We also have some non oriented relations there, where prov:unqualifiedForm would be enough.

IMHO also, we will not get rid of the inverse shortcut object properties (like PROV-O does), for at least two reasons:

• the ontology transposes a conceptual model where most of these shortcuts are specified as binary relations, and where the inverse relations are also defined
• we need to provide users (I mean implementers, working in or for many cultural heritage institutions hopefully) with a complete domain ontology, that helps to build infrastructures and create data that can be interconnected to each other; defining inverse properties can help avoid which could be chaos in such a specific, domain, distributed world of data.

So, I will soon create a new issue so that the RiC-O team within EGAD can discuss this. The milestone will be RiC-O 1.0.2 (not just now).

Meanwhile I have explained the current state of RiC-O Relations there, and also added a warning about owl:hasSelf and inferencing the shortcuts.

As concerns the ruleset, @VladimirAlexiev, you mean rulesets for GraphDB (sorry for the naive question)? I think this can be written using SPARQL update too?

[VladimirAlexiev]

@florenceclavaud Yes, I mean GraphDB custom rules. These are the code blocks with ----- (where the conclusion is below the line).

It's easy to do this with SPARQL, but the question is:

• How often will you run the SPARQL? After every little insert? Daily? Monthly?
• If additional rules depend on the inferred direct relations, you need to run those rules too.

[florenceclavaud]

Hi @VladimirAlexiev, sorry for reacting so late

@florenceclavaud Yes, I mean GraphDB custom rules. These are the code blocks with ----- (where the conclusion is below the line).

It's easy to do this with SPARQL, but the question is:

* How often will you run the SPARQL? After every little insert? Daily? Monthly?

Well, not monthly; every three or six months maybe from now.

Anyway, I would be glad if you can write at least a partial ruleset. I can do the rest building on your lines (there are 48 n-ary relations, designed using exactly the same pattern so I can go further), and then easily test the whole.
Anyway, this ruleset would work for us or any GraphDB user only (I suppose), so I think I will also write at least the equivalent SPARQL update code for one of this GraphDB custom rules, and release it.

* If additional rules depend on the inferred direct relations, you need to run those rules too.