[Crm-sig] RDFS, XML and more

Thomas Francart thomas.francart at sparna.fr
Thu Sep 9 19:19:49 EEST 2021


Le jeu. 9 sept. 2021 à 17:51, Francesco Beretta via Crm-sig <
crm-sig at 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)
> <https://ontome.net/property/1/namespace/1> 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

Thomas


>
> All the best
> Francesco
>
>
>
>
>
> Le 09.09.21 à 16:46, Robert Sanderson via Crm-sig a écrit :
>
>
> 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
>
> _______________________________________________
> Crm-sig mailing listCrm-sig at ics.forth.grhttp://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
>


-- 

*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/20210909/df4da8cc/attachment-0001.html>


More information about the Crm-sig mailing list