RDFS Implementation and related issues

Posted by Pavlos Fafalios on 1/9/2021

Dear all,

The "Resources" page of the CIDOC-CRM website (http://www.cidoc-crm.org/versions-of-the-cidoc-crm) has been recently updated to include:

- An RDFS implementation (not yet approved by SIG) of the last official version of CIDOC-CRM (7.1.1). The link points to a gitlab web page which also includes the policies adopted for generating the RDFS file.
- An XML file for each version of CIDOC-CRM, including the classes and properties of the corresponding version.
- An HTML page for each version of CIDOC-CRM, containing declarations for all classes and properties (facilitating navigation to the classes and properties of each version).
- An HTML page for each version of CIDOC-CRM, containing translations and versioning information of all classes and properties.

We (at FORTH) believe that the above will facilitate the adoption of CIDOC-CRM.

We will start gathering comments about errors, improvements, etc., so please do not hesitate to provide your critical feedback.

All the above will be presented and discussed during the next CIDOC-CRM meeting.

Posted by Miel Vander Sande on 1/9/2021

Thanks to all involved for this contribution. This is indeed an important step towards adoption.

I was wondering: is a SHACL profile and a JSON-LD context being considered?

Posted by Robert Sanderson on 1/9/2021

Miel, all,

4 issues below:

(1) There is a 7.1.1 compatible JSON-LD context at:  https://linked.art/ns/v1/linked-art.json 
The description for how the JSON keys are derived from the ontology is: https://linked.art/api/1.0/json-ld/#context-design 
Comments welcome and happy to contribute it to the SIG, and make only a secondary linked art context for the profile specific features!

(2) A second request from me ... it would be great to have owl:inverseOf between each of the property pairs in the ontology.

e.g.

  <rdf:Property rdf:about="P1i_identifies">
    <rdfs:label xml:lang="en">identifies</rdfs:label>
    <rdfs:label xml:lang="de">bezeichnet</rdfs:label>
    <rdfs:label xml:lang="el">είναι αναγνωριστικό</rdfs:label>
    <rdfs:label xml:lang="fr">identifie</rdfs:label>
    <rdfs:label xml:lang="pt">identifica</rdfs:label>
    <rdfs:label xml:lang="ru">идентифицирует</rdfs:label>
    <rdfs:label xml:lang="zh">标识</rdfs:label>
    <rdfs:domain rdf:resource="E41_Appellation" />
    <rdfs:range rdf:resource="E1_CRM_Entity" />
    <owl:inverseOf rdf:resource="P1_is_identified_by" />
  </rdf:Property>

And (3) a minor typo:

  <rdfs:Class rdf:about="E41_E33_Linguistic_Appellation">
    <rdfs:label xml:lang="en">Linguistic Appellation</rdfs:label>
    <rdfs:subClassOf rdf:resource="E41_Appellation" />
    <rdfs:subClassOf rdf:resource="E33_Linguistic_Object" />
  </rdfs:Class>

It was agreed that this was going to be E33_E41 to keep the numbers in order, and to coincidentally correspond to the two parts of the label (E33 -> linguistic, E41-> appellation)
Great if this could be fixed.

And (4) a concern. I don't think that it is good practice to make assertions about other ontologies' predicates:
Line 1176 asserts:

  <rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#label"&gt;
    <rdfs:subPropertyOf rdf:resource="P1_is_identified_by" />
  </rdf:Property>

So this means that all of the objects of instances of rdfs:label are, due to the range of P1_is_identified_by, suddenly instances of E41_Appellation.
A system that does even basic inferencing will produce very different results, by assigning E41_Appellation as another class for all of the literals which are the object of rdfs:label.

This doesn't affect me, because while inferencing is a good idea in practice in some domains with very tightly controlled data and precisely applied ontologies and vocabularies, I have yet to see any benefit at all from it in ours.

Might I suggest as a compromise instead having this assertion published, but in a different rdfs file? That would make it more noticeable to people who might otherwise have no clue why their system was misbehaving all of a sudden, and also make it easier for it to be omitted from processing if it was not useful in practice. Then we're still making the assertion in an official, public capacity, but we're also giving agency to our users as to whether they want to use it.

Thanks for your hard work on this!

Posted by Alexander Huber on 2/9/2021

Dear Pavlos,

This is fabulous news, thanks to all involved!  One question: is there a timeline for bringing the compatible models in line with this release, particularly LRMoo, CRMinf, and CRMdig?

Thanks! 

Posted by Pavlos on 7/9/2021

Dear Miel, 

Thank you for your comments. 

Having a JSON-LD serialization seems useful, given the increasing adoption of this encoding format. We can start considering its implementation once the RDFS is approved by CRM SIG. 

About SHACL: do you mean using SHACL for schema validation, or for defining constraints/requirements over crm-compliant RDF graphs? I guess the latter. This is interesting as well, but it also requires careful design and thinking/discussions on what types of constraints to consider and define.  

Posted by Pavlos on 7/9/2021

Dear Alexander,

Yes. As far as I know, the plan is to review and update all models based on 7.1.1 (by the corresponding working groups). 
Then, we plan to also provide an RDFS implementation for these models (whose generation has been automated to a great extent; we just need to check if specific policies need to be considered). 

Posted by Pavlos on 7/9/2021

Dear Robert,

Thank you for your comments and feedback. Some answers inline:

On Wed, Sep 1, 2021 at 4:40 PM Robert Sanderson <azaroth42@gmail.com> wrote:

    Miel, all,

    4 issues below:

    (1) There is a 7.1.1 compatible JSON-LD context at:  https://linked.art/ns/v1/linked-art.json&nbsp;
    The description for how the JSON keys are derived from the ontology is: https://linked.art/api/1.0/json-ld/#context-design&nbsp;
    Comments welcome and happy to contribute it to the SIG, and make only a secondary linked art context for the profile specific features!

Please see my reply to Miel. 
 

    (2) A second request from me ... it would be great to have owl:inverseOf between each of the property pairs in the ontology.

    e.g.

      <rdf:Property rdf:about="P1i_identifies">
        <rdfs:label xml:lang="en">identifies</rdfs:label>
        <rdfs:label xml:lang="de">bezeichnet</rdfs:label>
        <rdfs:label xml:lang="el">είναι αναγνωριστικό</rdfs:label>
        <rdfs:label xml:lang="fr">identifie</rdfs:label>
        <rdfs:label xml:lang="pt">identifica</rdfs:label>
        <rdfs:label xml:lang="ru">идентифицирует</rdfs:label>
        <rdfs:label xml:lang="zh">标识</rdfs:label>
        <rdfs:domain rdf:resource="E41_Appellation" />
        <rdfs:range rdf:resource="E1_CRM_Entity" />
        <owl:inverseOf rdf:resource="P1_is_identified_by" />
      </rdf:Property>

Our intention was to provide a 'pure' RDFS implementation, since one of our next steps is to provide a rich OWL implementation (and also automate its production, as we do for RDFS). 
Nevertheless, including this OWL property does not seem to cause any problem and allows for at least some basic reasoning. Not sure if it is better to provide it as a separate module/file, or just enrich the existing file. 
 

    And (3) a minor typo:

      <rdfs:Class rdf:about="E41_E33_Linguistic_Appellation">
        <rdfs:label xml:lang="en">Linguistic Appellation</rdfs:label>
        <rdfs:subClassOf rdf:resource="E41_Appellation" />
        <rdfs:subClassOf rdf:resource="E33_Linguistic_Object" />
      </rdfs:Class>

    It was agreed that this was going to be E33_E41 to keep the numbers in order, and to coincidentally correspond to the two parts of the label (E33 -> linguistic, E41-> appellation)
    Great if this could be fixed.

Thanks for spotting, we will fix it. 
 

    And (4) a concern. I don't think that it is good practice to make assertions about other ontologies' predicates:
    Line 1176 asserts:

      <rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#label"&gt;
        <rdfs:subPropertyOf rdf:resource="P1_is_identified_by" />
      </rdf:Property>

    So this means that all of the objects of instances of rdfs:label are, due to the range of P1_is_identified_by, suddenly instances of E41_Appellation.
    A system that does even basic inferencing will produce very different results, by assigning E41_Appellation as another class for all of the literals which are the object of rdfs:label.

    This doesn't affect me, because while inferencing is a good idea in practice in some domains with very tightly controlled data and precisely applied ontologies and vocabularies, I have yet to see any benefit at all from it in ours.

    Might I suggest as a compromise instead having this assertion published, but in a different rdfs file? That would make it more noticeable to people who might otherwise have no clue why their system was misbehaving all of a sudden, and also make it easier for it to be omitted from processing if it was not useful in practice. Then we're still making the assertion in an official, public capacity, but we're also giving agency to our users as to whether they want to use it.

The reason for making this assertion is the fact that rdfs:label has been widely used for providing names/appellations (without making use of "P1 is identified by"). However, all these labels are (semantically) appellations of the corresponding resources. So, using this subproperty declaration, a system can use P1 together with an inference rule for retrieving both names expressed using rdfs:label and instances of E41 (or appellations that are in URL/URI form --a more complex case). 

It's not very clear to me why some systems will start misbehaving. Could you please provide an example of such misbehaviour and the platform of reference? The only case I can imagine (but I might be wrong!) is when a system uses P1 together with an inference rule for retrieving appellations, but for some reason it does not want to get back values of rdfs:label, although these are appellations (but again here SPARQL offers constructs that can be used to distinguish between the different types of appellations).

Posted by Miel Vander Sande on 8/9/2021

Hi Pavlos,

Op di 7 sep. 2021 om 09:38 schreef Pavlos Fafalios <fafalios@ics.forth.gr>:

    Dear Miel, 

    Thank you for your comments. 

    Having a JSON-LD serialization seems useful, given the increasing adoption of this encoding format. We can start considering its implementation once the RDFS is approved by CRM SIG. 

When done right, it can make complex models like CIDOC-CRM look a lot less scary. I think the goal should not be a complete implementation of CIDOC-CRM in a single context, but rather lead to an entry-level format that can be expanded when necessary (json-ld allows you to do this). I'm working on similar examples for PREMIS OWL.

    About SHACL: do you mean using SHACL for schema validation, or for defining constraints/requirements over crm-compliant RDF graphs? I guess the latter. This is interesting as well, but it also requires careful design and thinking/discussions on what types of constraints to consider and define.  

same here. I think both are very useful, but the latter can provide an easy to adopt, entry-level view on CIDOC-CRM. In any case, you cannot capture an open ontology in a single SHACL schema; they will always be one or more constraint views aimed at implementation and easy adoption. 

In fact, this is what we have done in Belgium with the OSLO programme by defining a consensus-driven application profile of cidoc-crm. You can find JSON-LD and SHACL implementations at the bottom of this page: https://data.vlaanderen.be/doc/applicatieprofiel/cultureel-erfgoed-even…

Posted by Thomas Francart on 8/9/2021

Hello

Le mar. 7 sept. 2021 à 12:43, Pavlos Fafalios via Crm-sig <crm-sig@ics.forth.gr> a écrit :

    Dear Robert,

    Thank you for your comments and feedback. Some answers inline:

    On Wed, Sep 1, 2021 at 4:40 PM Robert Sanderson <azaroth42@gmail.com> wrote:

        Miel, all,

        4 issues below:

        (1) There is a 7.1.1 compatible JSON-LD context at:  https://linked.art/ns/v1/linked-art.json&nbsp;
        The description for how the JSON keys are derived from the ontology is: https://linked.art/api/1.0/json-ld/#context-design&nbsp;
        Comments welcome and happy to contribute it to the SIG, and make only a secondary linked art context for the profile specific features!

    Please see my reply to Miel. 
     

        (2) A second request from me ... it would be great to have owl:inverseOf between each of the property pairs in the ontology.

        e.g.

          <rdf:Property rdf:about="P1i_identifies">
            <rdfs:label xml:lang="en">identifies</rdfs:label>
            <rdfs:label xml:lang="de">bezeichnet</rdfs:label>
            <rdfs:label xml:lang="el">είναι αναγνωριστικό</rdfs:label>
            <rdfs:label xml:lang="fr">identifie</rdfs:label>
            <rdfs:label xml:lang="pt">identifica</rdfs:label>
            <rdfs:label xml:lang="ru">идентифицирует</rdfs:label>
            <rdfs:label xml:lang="zh">标识</rdfs:label>
            <rdfs:domain rdf:resource="E41_Appellation" />
            <rdfs:range rdf:resource="E1_CRM_Entity" />
            <owl:inverseOf rdf:resource="P1_is_identified_by" />
          </rdf:Property>

    Our intention was to provide a 'pure' RDFS implementation, since one of our next steps is to provide a rich OWL implementation (and also automate its production, as we do for RDFS). 
    Nevertheless, including this OWL property does not seem to cause any problem and allows for at least some basic reasoning. Not sure if it is better to provide it as a separate module/file, or just enrich the existing file. 

I would also find it very useful to have the inverseOf declarations directly in this file. It cannot harm and would be indeed very useful for some simple reasoning use-cases in triplestore.
 

        And (3) a minor typo:

          <rdfs:Class rdf:about="E41_E33_Linguistic_Appellation">
            <rdfs:label xml:lang="en">Linguistic Appellation</rdfs:label>
            <rdfs:subClassOf rdf:resource="E41_Appellation" />
            <rdfs:subClassOf rdf:resource="E33_Linguistic_Object" />
          </rdfs:Class>

        It was agreed that this was going to be E33_E41 to keep the numbers in order, and to coincidentally correspond to the two parts of the label (E33 -> linguistic, E41-> appellation)
        Great if this could be fixed.

    Thanks for spotting, we will fix it. 
     

        And (4) a concern. I don't think that it is good practice to make assertions about other ontologies' predicates:
        Line 1176 asserts:

          <rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#label"&gt;
            <rdfs:subPropertyOf rdf:resource="P1_is_identified_by" />
          </rdf:Property>

        So this means that all of the objects of instances of rdfs:label are, due to the range of P1_is_identified_by, suddenly instances of E41_Appellation.
        A system that does even basic inferencing will produce very different results, by assigning E41_Appellation as another class for all of the literals which are the object of rdfs:label.

        This doesn't affect me, because while inferencing is a good idea in practice in some domains with very tightly controlled data and precisely applied ontologies and vocabularies, I have yet to see any benefit at all from it in ours.

        Might I suggest as a compromise instead having this assertion published, but in a different rdfs file? That would make it more noticeable to people who might otherwise have no clue why their system was misbehaving all of a sudden, and also make it easier for it to be omitted from processing if it was not useful in practice. Then we're still making the assertion in an official, public capacity, but we're also giving agency to our users as to whether they want to use it.

    The reason for making this assertion is the fact that rdfs:label has been widely used for providing names/appellations (without making use of "P1 is identified by"). However, all these labels are (semantically) appellations of the corresponding resources. So, using this subproperty declaration, a system can use P1 together with an inference rule for retrieving both names expressed using rdfs:label and instances of E41 (or appellations that are in URL/URI form --a more complex case). 

    It's not very clear to me why some systems will start misbehaving. Could you please provide an example of such misbehaviour and the platform of reference? The only case I can imagine (but I might be wrong!) is when a system uses P1 together with an inference rule for retrieving appellations, but for some reason it does not want to get back values of rdfs:label, although these are appellations (but again here SPARQL offers constructs that can be used to distinguish between the different types of appellations). 

While not incorrect, I also think this could cause confusion; the use-case I have in mind would be a triplestore loaded with both CIDOC-CRM data combined with data from other ontologies using rdfs:bale, where all of the sudden these entities would get a P1_is_identified_by.
I suggest that these "alignments" with other ontologies (we could think about skos:note <-> P3 has note, E21 Person <-> foaf:Person, etc.) be separated in another file (or other files), so that users have a choice on using them or not, depending on the ontologies they use and the level of interoperability they want to have.

Posted by Robert Sanderson on 8/9/2021

Dear Miel, all,

On Wed, Sep 8, 2021 at 4:11 AM Miel Vander Sande via Crm-sig <crm-sig@ics.forth.gr> wrote:

    Op di 7 sep. 2021 om 09:38 schreef Pavlos Fafalios <fafalios@ics.forth.gr>:

        Having a JSON-LD serialization seems useful, given the increasing adoption of this encoding format. We can start considering its implementation once the RDFS is approved by CRM SIG. 

    When done right, it can make complex models like CIDOC-CRM look a lot less scary. I think the goal should not be a complete implementation of CIDOC-CRM in a single context, but rather lead to an entry-level format that can be expanded when necessary (json-ld allows you to do this). I'm working on similar examples for PREMIS OWL.

I agree that a well crafted context can greatly improve usability of the ontology in modern software frameworks. This has been demonstrated very clearly in different domains since the standardization of JSON-LD 1.0 in 2014. I'm very happy to put as much effort as needed into this.

However, I disagree about the goal. I feel that the SIG should provide a context that covers the same set of classes and predicates as in the RDFS. Composing multiple contexts together with no overlap would be extremely error-prone, with little way to detect those errors. For Linked Art, we started with two contexts ... the terms that we recommend from CRM in the profile, and the second was all the other terms. If you wanted to stick with just Linked Art, you imported one. If you wanted to use anything extra, you also imported the rest. And even that level of composition was highly frustrating for implementation, as you needed to know all of the terms used in the document in order to know whether you should use one or both. The easy solution was to always use both... defeating the purpose of splitting them.

And the errors are difficult to detect because if a key in JSON-LD doesn't match an entry in an included context, it is silently ignored. So data would just disappear, and you had to go hunting through other people's documents (the contexts) to figure out why.

By sticking to the same divisions as the RDFS files (e.g. one context for base, one for sci, one for geo, etc) it would be straightforward to manage from a publishing and consumption perspective at the ontology level, rather than at an application profile level.

Posted by Miel Vander Sande   on 9/9/2021

Hi Robert,

That makes a lot of sense. If you were to only support a subset, you'd need to accompagny it with a SHACL profile to indicate what shape the context offers and to make sure that things don't go missing. Although in practice, this might indeed create chaos rather than prevent it.

Posted by Frank Fichtner on 9/9/2021

Dear Pavlos,

to my knowledge up to now the ecrm is the official OWL-implementation of the CIDOC CRM. Automation of the process seems to be a good idea, however in the last years we could provide many feedback while we were implementing cidoc crm (style/writing mistakes but also logical inconsistencies etc.). We are currently working on 7.1.1 but are not completely done yet. I think we should not mix owl and rdfs on the rdfs-level because that simply would make the rdfs-file obsolete. If we do that we could just use OWL because it is rdfs anyway.

Posted by Robert Sanderson on 9/9/2021

Hi Mark,

Could you expand a little about "OWL is RDFS anyway"? The advantage of the current RDFS file is that it's easy to understand and process as XML without a full semantic stack. Once decorated with all of the owl details, it becomes more complex. Apart from owl:inverseOf and perhaps owl:ObjectProperty vs owl:DataProperty, is there anything else that would be added? Cardinality? Definition of shortcuts using axioms / rules?

I'm curious also as to your thoughts on the rdfs:label / P1_identifies issue?

Many thanks!

Posted by Francesco Beretta on 9/9/2021

Dear Rob, all,
>> I'm curious also as to your thoughts on the rdfs:label / P1_identifies issue?

À propos: there is a question that has been on my mind for some time, perhaps you can give me some insights.

The P1 is identified by (identifies) property has E41 Appellation as range. This class is subclass of Symbolic Object and Legal Object, therefore a E77 Persistent Item and not a E62 String which is a E59 Primitive Value.

Therefore an instance of E41 Appellation — rdfs:label —> '[label]', right ? So it crm:P1 cannot be equivalent to rdfs:label?

E1 Entity —rdfs:label—> rdfs:Literal  would appear to be a shortcut of:

E1 Entity —P1 is identified by—> E41 Appellation —rdfs:label—> '[label]'

My question(s):

1. is this correct ?
2. is there any way in OWL-DL or any other formal language to express the notion of shortcut or path, with a start and an end class, and the whole path inbetween ?

<There was unfortunately a copy-paste issue in my email.>
Le 09.09.21 à 17:35, Francesco Beretta a écrit :
> The P1 is identified by (identifies) property has E41 Appellation as range. This class is subclass of Symbolic Object and Legal Object, therefore a E77 Persistent Item and not a E62 String which is a E59 Primitive Value.
>
> Therefore an instance of E41 Appellation — rdfs:label —> '[label]', right ? So it crm:P1 cannot be equivalent to rdfs:label?

I mean:

An instance of E41 can have this property:
E41 Appellation — rdfs:label —> '[label]', right ?

So the crm:P1 property cannot be equivalent to rdfs:label, right?

Posted by Thomas Francart on 9/9/2021

Le jeu. 9 sept. 2021 à 17:51, Francesco Beretta via Crm-sig <crm-sig@ics.forth.gr> a écrit :

    Dear Rob, all,
    >> I'm curious also as to your thoughts on the rdfs:label / P1_identifies issue?

    À propos: there is a question that has been on my mind for some time, perhaps you can give me some insights.

    The P1 is identified by (identifies) property has E41 Appellation as range. This class is subclass of Symbolic Object and Legal Object, therefore a E77 Persistent Item and not a E62 String which is a E59 Primitive Value.

    Therefore an instance of E41 Appellation — rdfs:label —> '[label]', right ? So it crm:P1 cannot be equivalent to rdfs:label?

    E1 Entity —rdfs:label—> rdfs:Literal  would appear to be a shortcut of:

    E1 Entity —P1 is identified by—> E41 Appellation —rdfs:label—> '[label]'

    My question(s):

    1. is this correct ?
    2. is there any way in OWL-DL or any other formal language to express the notion of shortcut or path, with a start and an end class, and the whole path inbetween ?

Indeed, this is OWL2 Property Chains : https://www.w3.org/TR/owl2-primer/#Property_Chains

Posted by Martin on 9/9/2021

Dear Francesco,

This is a complex issue, which has been discussed in length in 2018 and basically was spelled out in the implementation guidelines for RDFS by Richrad Light and me.

All these questions you pose have been taken into account carefully. The text may need improvements, but I'd kindly ask all CRM-SIG members having respective questions to read it carefully and give us feedback.

Let me explain just a bit here from the side of logic, which is tricky and not the usual reasoning we apply within the CRM:

A superproperty is not equivalent to a subproperty. A superproperty is only implied by a subproperty.
 
 Therefore: Once E41 Appellation has no necessary property, an instance of E41 Appellation without having a property of its own does not violate the range of the superproperty. Its just a poor case.

(But it is completely true that rdfs:label is without properties. From the time of RDFS 1.1 on, which recommends the use of xsd values in literals, there are hidden properties in the label, such as the language tags.)

This statement does also strictly not hold: "This class is subclass of Symbolic Object and Legal Object, therefore a E77 Persistent Item and not a E62 String which is a E59 Primitive Value",

because a) there is no axiom in CRM saying that Persistent Item and E62 String are disjoint.
                b) There is no declaration in the RDFS implementation that rdf:Literal equals E62 Sting or
                        E59 Primitive Value.

Obviously, RDFS makes rich use of Literal, packing stuff like WKT geometric values  into them, which are used in geo-enabled triple stores.

With the superproperty declaration, we say that whowever uses rdfs:label refers to a name (E41 Appellation). Unfortunately, RDFS does not allow us smarter things to do, but this gives the right answers to queries.

Posted by Mark Fichtner on 9/9/2021

Dear all,

I am speaking from OWL-point of view and agree with most of the other writers. 
Concerning the P1-issue:
- rdfs:label has rdfs:Literal as range
- P1 in OWL typically is an object property and not a datatype property. It has E41 as a range and E41 is not in the E59 primitive value subtree. Its subclasses are via multiple inheritance, but it does not hold for E41 itself.
- If you declare rdfs:label a subproperty of P1 you are changing in fact the definition of rdfs:label and the definition of E41. This means you simply change the data on nearly the whole world without even having a glance at a single dataset. This is not only a worst-practice but would lead to massive inconsistencies when it comes to reasoning with OWL. I don't want to tell you what you should do in rdf - because rdf is more flexible here. But it does not seem logical to me. Ontology alignment is a difficult task.
I  understand that it might be helpful in some scenarios. But I think it would confusing if the official CIDOC CRM RDF file would do ontology integration that way. Furthermore RDF is just one implementation of CIDOC CRM and typically when it comes to implementation only primitive datatypes are replaced by the implementation - not object properties.

In the Erlangen CRM we use:
- owl:Class for the classes,
- we have some owl:Restrictions (74)
- owl:ObjectProperty for the object properties
- owl:DatatypeProperty for the datatypes
- owl:inverseOf for the inverses
If I didn't miss anything, thats all. See http://erlangen-crm.org/200717/

So the difference between OWL and RDF variant won't be big after adding owl:inverse and if you start using owl in your ontology definition it is pretty straight forward to use OWL completely anyway ;-)

We had a long discussion on shortcuts - I think the conclusion was we hardly have shortcuts in CIDOC CRM that could be used as Property chains as the implications are not strong enough. Martin probably can add some in here. 

Posted by Robert Sanderson on 9/9/2021

Dear all,

I am speaking from OWL-point of view and agree with most of the other writers. 
Concerning the P1-issue:
- rdfs:label has rdfs:Literal as range
- P1 in OWL typically is an object property and not a datatype property. It has E41 as a range and E41 is not in the E59 primitive value subtree. Its subclasses are via multiple inheritance, but it does not hold for E41 itself.
- If you declare rdfs:label a subproperty of P1 you are changing in fact the definition of rdfs:label and the definition of E41. This means you simply change the data on nearly the whole world without even having a glance at a single dataset. This is not only a worst-practice but would lead to massive inconsistencies when it comes to reasoning with OWL. I don't want to tell you what you should do in rdf - because rdf is more flexible here. But it does not seem logical to me. Ontology alignment is a difficult task.
I  understand that it might be helpful in some scenarios. But I think it would confusing if the official CIDOC CRM RDF file would do ontology integration that way. Furthermore RDF is just one implementation of CIDOC CRM and typically when it comes to implementation only primitive datatypes are replaced by the implementation - not object properties.

In the Erlangen CRM we use:
- owl:Class for the classes,
- we have some owl:Restrictions (74)
- owl:ObjectProperty for the object properties
- owl:DatatypeProperty for the datatypes
- owl:inverseOf for the inverses
If I didn't miss anything, thats all. See http://erlangen-crm.org/200717/

So the difference between OWL and RDF variant won't be big after adding owl:inverse and if you start using owl in your ontology definition it is pretty straight forward to use OWL completely anyway ;-)

We had a long discussion on shortcuts - I think the conclusion was we hardly have shortcuts in CIDOC CRM that could be used as Property chains as the implications are not strong enough. Martin probably can add some in here. 

--------------------------

from rdflib import ConjunctiveGraph

from owlrl import RDFSClosure

g = ConjunctiveGraph()

g.parse("Downloads/minimal_schema.rdfs.xml", format="xml")

rdfs_sems = RDFSClosure.RDFS_Semantics(g, axioms=True, daxioms=True, rdfs=True)

rdfs_sems.closure()

out = rdfs_sems.graph.serialize(format="ttl")

print(out.decode('utf-8'))

 ...

"fish"@en a crm:E1_CRM_Entity,

        crm:E41_Appellation,

        crm:E90_Symbolic_Object,

        rdfs:Literal,

        rdfs:Resource .

-------------------------------

As expected, it entails the nonsense that the literal "fish"@en is an E1, E41, E90, etc. which is garbage caused by this pollution in the ontology, as literals cannot be the subject of triples.

Hope that helps explain my unease!

Posted by Martin on 9/9/2021

Dear Robert, Mark,

Of course this is not elegant schema design. Unease is accepted, but what are the alternatives??

On 9/9/2021 10:30 PM, Robert Sanderson wrote:
>
>
>
> As expected, it entails the nonsense that the literal "fish"@en is an E1, E41, E90, etc. which is garbage caused by this pollution in the ontology, as literals cannot be the subject of triples.
This is, in my eyes, not nonsense, but simply reality. The literal "fish" is used as a name. Hence it is ontologically an E41. Following the definition of E90, "fish"@en is also symbolic object, regardless whether one distinguishes data objects and literals. Note, that the definitions of the CRM are ontological, not syntactic in the first place.

This is a classical problem of data integration, and why formal ontologies were invented. Literature in the 1980ties discussed that classes can be hidden in boolean values, strings, or be explicit tables. There is an arbitrary decision of applications to name things via labels, or via classes in RDF/OWL. SKOS exclusively names things via labels.

So, if one makes a knowledge base that commits to the CRM, I would like to have a query that returns all names in the whole world I can reach, regardless what encoding variant and KR paradigm is used. Otherwise, SKOS names will not be appellations.

Alternatively, we close our eyes, and hard code in data entry and query that "fish" is used as Appellation, but just don't write it down.

@en actually is equivalent to "has language" etc. With these hidden properties RDFS itself violates the separation of Literals and data objects.  It opens up a whole world of user-defined data objects within Literals, with no logical connection to the data objects. This is nothing than a bad later patch to a problem not initially anticipated. How are these compatible with OWL reasoners?

There is no elegant solution to providing an ontology that describes a reality based on FOL to fitting it exactly with Schema languages.

At least, this is how I perceive this problem, having seen enough knowledge representation languages and information integration literature from the eighties and implementations from the nineties on.

For me, the question is completely practical: We have a CRM compatible KB, a real platform. What is the simplest form that I get all names in the KB back?  I have not seen a whole "RDF" world that my statement label IsA P1 would turn upside down. Do you have one?
 

Posted by Martin on 9/9/2021

Sorry, I just forgot:

Of course we can provide guidelines and S/W how to query all names etc. We can hardly forbid CRM users to put appellations into rdfs:label.

So, how do this problem solved in OWL? Those of you opposing to the superproperty hack, how do you solve the query question? 

Posted by Robert on 10/9/2021

Thanks Martin :)

As Francesco asked and Thomas answered, I would also recommend a property chain axiom that says:

If: x rdfs:label y 
then: x P1_is_identified_by z ; z a E41_Appellation , P190_has_symbolic_content y .

I quickly defer to those who do OWL more often than I, but I think it's as easy as:

    rdfs:label owl:propertyChainAxiom (crm:P1_is_identified_by, crm:P190_has_symbolic_content) .

Posted by Pavlos Fafalios on 10/9/2021

Dear all, 

Thank you for the interesting discussion. A notice that might be important: 

In 'OWL Full', which was designed to allow flexibility and preserve compatibility with RDFS: "object properties and datatype properties are not disjoint" and "datatype properties are effectively a subclass of object properties", see: 

https://www.w3.org/TR/owl-ref/#OWLFull   (not sure if there is a change on this in OWL 2) 

On the downside, as also described in the above link, the OWL Full features means that one loses some guarantees that OWL DL and OWL Lite can provide for reasoning systems. 

So, we can have an RDFS implementation that includes the superproperty hack (and which seems compatible with OWL Full, allowing for some basic reasoning). And then focus on having an OWL DL implementation (Mark's effort) which is more strict, provides guarantees and will be useful for advanced reasoning engines (this implementation can include the property chain axiom). 

Posted by Martin on 10/9/2021

Dear All,

I'd also like to point you to a subtle distinction which is very important for us:

Mark correctly states:

If you declare rdfs:label a subproperty of P1 you are changing in fact the definition of rdfs:label and the definition of E41. This means you simply change the data on nearly the whole world without even having a glance at a single dataset.

This is the mathematical, model-theoretic point of view about what a definition is.

In contrast, we commit to Nicola Guarinos formulation, that the logical declarations of a formal ontology are an approximation of a conceptualization (rather than being it), trying to minimize "unintended models".

Therefore, there exist textual definitions for all constructs of formal ontologies, in order to render the intended models. This is the ontological (philosophical, cognitive) point of view of what a definition is.

The CRM states for E41 Appellation:
This class comprises signs, either meaningful or not, or arrangements of signs following a specific syntax, that are used or can be used to refer to and identify a specific instance of some class or category within a certain context.

 RDFS 1.1 states for rdfs:label:
rdfs:label is an instance of rdf:Property that may be used to provide a human-readable version of a resource's name.

According to that, E41 constitutes a generalization of all adequate uses of rdfs:label, and indeed is intended to be so for all possible worlds. Methodologically, for CRM-SIG, the intended meaning has priority over preserving the formal definition in the sense Mark mentioned. This principle is also behind the formulation of the "conservative extension" in the CRM introduction.

Further, I want to express our particular gratitude to Mark Fichtner for creating the OWL implementations of the CRM and his careful semantic checking, which has been helping us a lot. When I mentioned automatic generation, I rather spoke about a utility making work easier, not a mechanism replacing manual scrutiny.

Finally, I would like to confirm, that no more constructs of this kind are intended, that it is not intended to introduce a new practice of this kind (please do not generalize and panick! and that indeed the rdfs:label problem and identifiers play an exceptional role in the ontology - schema transition.