[Crm-sig] RDFS, XML and more

Thomas Francart thomas.francart at sparna.fr
Wed Sep 8 11:53:02 EEST 2021


Hello

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>
> 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
>> 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!
>>
>
> 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">
>>     <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.

Best Regards
Thomas



>
> Thanks again!
>
> Best regards,
> Pavlos
>
>
>>
>> Thanks for your hard work on this!
>>
>> Rob
>>
>>
>>
>>
>>
>>
>>
>> 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
>>> considered?
>>>
>>> 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
>>>> 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.
>>>>
>>>> Best regards,
>>>> Pavlos
>>>>
>>>> --
>>>> 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)
>>>>    and
>>>> 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
>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>>>
>>> _______________________________________________
>>> Crm-sig mailing list
>>> Crm-sig at ics.forth.gr
>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>>
>>
>>
>> --
>> 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)
>    and
> 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
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>


-- 

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210908/4dc6d313/attachment-0001.html>


More information about the Crm-sig mailing list