[Crm-sig] RDFS, XML and more

Francesco Beretta francesco.beretta at cnrs.fr
Thu Sep 9 18:35:05 EEST 2021


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 ?

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 
> <mailto: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 <mailto: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 <mailto: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
>             <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
>             <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
>             <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
>             <mailto: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
>                 <mailto: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
>                     <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
>                     <mailto:fafalios at ics.forth.gr>
>                     Tel: +30-2810-391619
>                     Web: http://users.ics.forth.gr/~fafalios/
>                     <http://users.ics.forth.gr/~fafalios/>
>                     _______________________________________________
>                     Crm-sig mailing list
>                     Crm-sig at ics.forth.gr <mailto:Crm-sig at ics.forth.gr>
>                     http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>                     <http://lists.ics.forth.gr/mailman/listinfo/crm-sig>
>
>                 _______________________________________________
>                 Crm-sig mailing list
>                 Crm-sig at ics.forth.gr <mailto:Crm-sig at ics.forth.gr>
>                 http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>                 <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 <mailto:fafalios at ics.forth.gr>
>         Tel: +30-2810-391619
>         Web: http://users.ics.forth.gr/~fafalios/
>         <http://users.ics.forth.gr/~fafalios/>
>         _______________________________________________
>         Crm-sig mailing list
>         Crm-sig at ics.forth.gr <mailto:Crm-sig at ics.forth.gr>
>         http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>         <http://lists.ics.forth.gr/mailman/listinfo/crm-sig>
>
>
>
> -- 
> Rob Sanderson
> Director for Cultural Heritage Metadata
> Yale University
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210909/61b979a0/attachment-0001.html>


More information about the Crm-sig mailing list