[Crm-sig] RDFS, XML and more

Robert Sanderson azaroth42 at gmail.com
Thu Sep 9 17:46:48 EEST 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!

Rob


On Thu, Sep 9, 2021 at 6:45 AM Mark Fichtner <m.fichtner at wiss-ki.eu> wrote:

> 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.
>
> Best
>
> Mark
>
> Am Di., 7. Sept. 2021 um 12:45 Uhr schrieb Pavlos Fafalios via Crm-sig <
> crm-sig at ics.forth.gr>:
>
>> 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/
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210909/949c4553/attachment-0001.html>


More information about the Crm-sig mailing list