[Crm-sig] RDFS, XML and more

Pavlos Fafalios fafalios at ics.forth.gr
Tue Sep 7 13:35:42 EEST 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 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.


> 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).

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210907/e5a55989/attachment.html>


More information about the Crm-sig mailing list