[Crm-sig] RDFS, XML and more
thomas.francart at sparna.fr
Wed Sep 8 11:53:02 EEST 2021
Le mar. 7 sept. 2021 à 12:43, Pavlos Fafalios via Crm-sig <
crm-sig at 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 at gmail.com>
>> Miel, all,
>> 4 issues below:
>> (1) There is a 7.1.1 compatible JSON-LD context at:
>> The description for how the JSON keys are derived from the ontology is:
>> 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.
>> <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
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" />
>> 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">
>> <rdfs:subPropertyOf rdf:resource="P1_is_identified_by" />
>> 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
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.
> Thanks again!
> Best regards,
>> Thanks for your hard work on this!
>> On Wed, Sep 1, 2021 at 8:44 AM Miel Vander Sande via Crm-sig <
>> crm-sig at ics.forth.gr> wrote:
>>> 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
>>> Op wo 1 sep. 2021 om 10:19 schreef Pavlos Fafalios via Crm-sig <
>>> crm-sig at ics.forth.gr>:
>>>> 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
>>>> 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
>>>> Best regards,
>>>> Dr. Pavlos Fafalios
>>>> Postdoctoral research fellow
>>>> Project ReKnow <https://reknow.ics.forth.gr/> (MSCA Individual
>>>> Centre for Cultural Informatics / Information Systems Laboratory
>>>> Institute of Computer Science (ICS)
>>>> Foundation for Research and Technology (FORTH)
>>>> Visiting Lecturer
>>>> Department of Management Science & Technology (MST),
>>>> Hellenic Mediterranean University (HMU)
>>>> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
>>>> Email: fafalios at ics.forth.gr
>>>> Tel: +30-2810-391619
>>>> Web: http://users.ics.forth.gr/~fafalios/
>>>> Crm-sig mailing list
>>>> Crm-sig at ics.forth.gr
>>> Crm-sig mailing list
>>> Crm-sig at ics.forth.gr
>> Rob Sanderson
>> Director for Cultural Heritage Metadata
>> Yale University
> Dr. Pavlos Fafalios
> Postdoctoral research fellow
> Project ReKnow <https://reknow.ics.forth.gr/> (MSCA Individual Fellowship
> Centre for Cultural Informatics / Information Systems Laboratory
> Institute of Computer Science (ICS)
> Foundation for Research and Technology (FORTH)
> Visiting Lecturer
> Department of Management Science & Technology (MST),
> Hellenic Mediterranean University (HMU)
> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
> Email: fafalios at ics.forth.gr
> Tel: +30-2810-391619
> Web: http://users.ics.forth.gr/~fafalios/
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
blog : blog.sparna.fr, site : sparna.fr, linkedin :
tel : +33 (0)184.108.40.206.97, skype : francartthomas
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Crm-sig