[Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label

George Bruseker bruseker at ics.forth.gr
Mon Sep 10 22:20:14 EEST 2018


Dear all,

I am a fan of the traditional solution:

1) E1 -> p1 -> E41 

here the encoding all the way down to a value would be rdfs:value VALUE because we want to track the actual string used to represent the name (separate from the URI of the name)

We use this solution whenever we want to name something about which we care for the name (much of the time)

2) rdfs:label Value

This should be used on all nodes to give a human readable label. This is often enough if we don’t study the names used.

Best,

George

------------------------------------------------------
Dr. George Bruseker
R & D Engineer

Centre for Cultural Informatics
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)
Science and Technology Park of Crete
Vassilika Vouton, P.O.Box 1385, GR-711 10 Heraklion, Crete, Greece

Tel.: +30 2810 391619   Fax: +30 2810 391638   E-mail: bruseker at ics.forth.gr
URL: http://www.ics.forth.gr/isl

> On Sep 10, 2018, at 5:06 PM, Mark Fichtner <m.fichtner at wiss-ki.eu> wrote:
> 
> Dear all,
> 
> the main question for me is: Is the use of rdf:label in this case really the intended way by the CIDOC CRM? In fact P1 currently has a valid range and E41 is a valid class and not a primitive datatype. Why should we substitute this?
> 
> I agree with Martin that we should integrate old data that has a different model and therefore the proposal and the work is very nice to see. However I think we should have exactly one best practice. At the GNM we typically have regular instances of E41, which in my eyes follows the CIDOC CRM better, so I would love to see this in the best practice.
> 
> Best,
> 
> Mark Fichtner
> 
> 2018-09-04 21:29 GMT+02:00 Robert Sanderson <RSanderson at getty.edu <mailto:RSanderson at getty.edu>>:
> Hi Detlev,
> 
>  
> 
> Apologies, I meant that the pattern makes it more complicated to understand, as opposed to it being ambiguous in the data (which would be much worse!). More difficult for a human rather than for the machine :)
> 
>  
> 
> For example, in JSON-LD, it would result in
> 
>  
> 
> {
> 
>   “P1_is_identified_by”: [
> 
>       “uri-as-string”,
> 
>       {
> 
>          “@id”: “uri-as-identifier”
> 
>       }
> 
>   ]
> 
> }
> 
>  
> 
> Which then makes developers cross, as there are mixed data types in the array, and the current specification doesn’t allow the string to be expressed in an object with only @value as a key.
> 
>  
> 
> Currently that would be the simpler compaction of:
> 
>  
> 
> {
> 
>   “P1_is_identified_by: [
> 
>       “uri-as-identifier”
> 
>   ]
> 
> }
> 
>  
> 
> Because P1 can only ever have a resource as its object.
> 
>  
> 
> Or (if you don’t care for the singleton array), the simplest possible form:
> 
>  
> 
> {
> 
>   “P1_is_identified_by”: “uri-as-identifier”
> 
> }
> 
>  
> 
> Rob
> 
>  
> 
> From: Crm-sig <crm-sig-bounces at ics.forth.gr <mailto:crm-sig-bounces at ics.forth.gr>> on behalf of Detlev Balzer <db at balilabs.de <mailto:db at balilabs.de>>
> Date: Tuesday, September 4, 2018 at 12:11 PM
> To: "crm-sig at ics.forth.gr <mailto:crm-sig at ics.forth.gr>" <crm-sig at ics.forth.gr <mailto:crm-sig at ics.forth.gr>>
> Subject: Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label
> 
>  
> 
> Am 04.09.2018 um 19:19 schrieb Robert Sanderson:
> 
> In particular, it makes it difficult in several serializations to distinguish between the string “http://example.museum.org/data/1 <http://example.museum.org/data/1>” and the resource that has the URI http://example.museum.org/data/1 <http://example.museum.org/data/1> as its identifier.
> 
>  
> 
> Which ones do you mean? All the serializations I've seen make clear syntactic distinctions between literals and URIs.
> 
>  
> 
> While I agree that "punning" is bad practice, I don't see why it should confuse RDF software tools.
> 
>  
> 
> Detlev
> 
>  
> 
>  
> 
> Am 04.09.2018 um 19:19 schrieb Robert Sanderson:
> 
>   
> 
> Dear all,
> 
>   
> 
> Please no!  This is called “punning” (when the same property can be have both literals and resources as its range) and is widely recognized as a bad practice in RDF.
> 
>   
> 
> In particular, it makes it difficult in several serializations to distinguish between the string “http://example.museum.org/data/1 <http://example.museum.org/data/1>” and the resource that has the URI http://example.museum.org/data/1 <http://example.museum.org/data/1> as its identifier.
> 
>   
> 
> Rob
> 
>   
> 
>   
> 
> *From: *Crm-sig <crm-sig-bounces at ics.forth.gr <mailto:crm-sig-bounces at ics.forth.gr>> on behalf of Martin Doerr <martin at ics.forth.gr <mailto:martin at ics.forth.gr>>
> 
> *Date: *Saturday, September 1, 2018 at 7:41 AM
> 
> *To: *crm-sig <Crm-sig at ics.forth.gr <mailto:Crm-sig at ics.forth.gr>>
> 
> *Subject: *[Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label
> 
>   
> 
> Dear All,
> 
> Obviously, there are two ways in RDF to express what the CRM regards as an Appellation: Either using a URI, instance of E41, and then another property specifying in whatever way the symbolic content (I am not concerned with this here), *OR *using rdfs:label, which has exactly the meaning of some forms of Appellation that can be expressed exhaustively as literal.
> 
> Interesting enough, there seems to be no existing validation method, that would exclude any instance of xsd Datatype to be used as range of rdfs:label.
> 
> We have made therefor the following tests with Virtuoso, if P1 can have two ranges, Literal and E41, and if SPARQL gives the expected answers, it does:
> 
> *1.**      **Dualism of Appellations*
> 
> The purpose of this is to provide an *RDF based technical solution* for representing and querying a property which can be at the same time Data and Object type regardless of the fact that it violates the respective constraints or rules.
> 
> Practically we can have three options of representing appellations. By taking the example of Alexander the Great with supposed URI: http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great> we can do the following:
> 
> 1)      Use the “P1 is identified by” property and an instance of E41 Appellation class:
> 
>   
> 
> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>>
> 
> crm:P1_is_identified_by
> 
> <http://example.com/appellation/alexander_the_great <http://example.com/appellation/alexander_the_great>> <http://example.com/appellation/alexander_the_great <http://example.com/appellation/alexander_the_great>> .
> 
>   
> 
> <http://example.com/appellation/alexander_the_great <http://example.com/appellation/alexander_the_great>> <http://example.com/appellation/alexander_the_great <http://example.com/appellation/alexander_the_great>>
> 
> rdfs:label
> 
> "Alexander the Great" .
> 
>   
> 
> 2)      Use directly the rdfs:label:
> 
> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>>
> 
> rdfs:label
> 
> "Alexander the Great" .
> 
>   
> 
> 3)      Use the “P1 is identified by” property as a data property (violating the rdfs definitions):
> 
> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>>
> 
> crm:P1_is_identified_by
> 
> "Alexander the Great" .
> 
>   
> 
> Based on these examples the following steps were followed to test the practical application of such cases to a triple store. *Virtuoso triple store* was used for the following examples.
> 
> 1.       The cidoc_crm.rdfs was altered to include the following:
> 
> <rdf:Property rdf:about="P1_is_identified_by">
> 
>                                   <rdfs:label xml:lang="en">is identified by</rdfs:label>
> 
>                                  <rdfs:domain rdf:resource="E1_CRM_Entity"/>
> 
>                                  <rdfs:range rdf:resource="E41_Appellation"/>
> 
> </rdf:Property>
> 
> <rdf:Property rdf:about="P1_is_identified_by">
> 
> <rdfs:label xml:lang="en">is identified by</rdfs:label>
> 
>                                  <rdfs:domain rdf:resource="E1_CRM_Entity"/>
> 
>                                  <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal <http://www.w3.org/2000/01/rdf-schema#Literal>" <http://www.w3.org/2000/01/rdf-schema#Literal>/ <http://www.w3.org/2000/01/rdf-schema#Literal%3E/>>
> 
> </rdf:Property>
> 
> * *
> 
> So,  an is identified property was added to the initial schema but with rdfs:Literal as a range.
> 
>   
> 
> 2.       The cidoc crm schema was uploaded in virtuoso and the following query (give me the range of P1_is_identified_property) was executed to be sure that the changes have been applied:
> 
>   
> 
> prefix crm: <http://www.cidoc-crm.org/cidoc-crm/ <http://www.cidoc-crm.org/cidoc-crm/>> <http://www.cidoc-crm.org/cidoc-crm/ <http://www.cidoc-crm.org/cidoc-crm/>>
> 
> prefix rdfs: <http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema>> <http://www.w3.org/2000/01/rdf-schema <http://www.w3.org/2000/01/rdf-schema>>
> 
>   
> 
> select * where { crm:P1_is_identified_by rdfs:range ?range}
> 
>   
> 
> *result: *
> 
> *range*
> 
> http://www.cidoc-crm.org/cidoc-crm/E41_Appellation <http://www.cidoc-crm.org/cidoc-crm/E41_Appellation>
> http://www.w3.org/2000/01/rdf-schema#Literal <http://www.w3.org/2000/01/rdf-schema#Literal>
>   
> 
> So, it is confirmed that the two ranges have been added. I repeat at this point that Virtuoso *does not apply* any semantic validation. The purpose of this test is to prove that this exercise is possible even though conceptually it may not be correct.
> 
>   
> 
> 3.       The ttl data that was presented previously has been added in virtuoso:
> 
>   
> 
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema>> <http://www.w3.org/2000/01/rdf-schema <http://www.w3.org/2000/01/rdf-schema>> .
> 
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns>> <http://www.w3.org/1999/02/22-rdf-syntax-ns <http://www.w3.org/1999/02/22-rdf-syntax-ns>> .
> 
> @prefix crm: <http://www.cidoc-crm.org/cidoc-crm/ <http://www.cidoc-crm.org/cidoc-crm/>> <http://www.cidoc-crm.org/cidoc-crm/ <http://www.cidoc-crm.org/cidoc-crm/>> .
> 
>   
> 
> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>>
> 
> crm:P1_is_identified_by <http://example.com/appellation/alexander_the_great <http://example.com/appellation/alexander_the_great>> <http://example.com/appellation/alexander_the_great <http://example.com/appellation/alexander_the_great>> .
> 
>   
> 
> <http://example.com/appellation/alexander_the_great <http://example.com/appellation/alexander_the_great>> <http://example.com/appellation/alexander_the_great <http://example.com/appellation/alexander_the_great>>
> 
> rdfs:label  "Alexander the Great" .
> 
>   
> 
> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>>
> 
> rdfs:label  "Alexander the Great" .
> 
>   
> 
> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>>
> 
> crm:P1_is_identified_by  "Alexander the Great" .
> 
>   
> 
> 4.       A query to return all the “identifiers” of alexander the great using the is identified property was applied:
> 
> prefix crm: <http://www.cidoc-crm.org/cidoc-crm/ <http://www.cidoc-crm.org/cidoc-crm/>> <http://www.cidoc-crm.org/cidoc-crm/ <http://www.cidoc-crm.org/cidoc-crm/>>
> 
> prefix rdfs: <http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema>> <http://www.w3.org/2000/01/rdf-schema <http://www.w3.org/2000/01/rdf-schema>>
> 
> select * where
> 
> { <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>>  crm:P1_is_identified_by ?identifier }
> 
> *result: *
> 
> *identifier*
> 
> http://example.com/appellation/alexander_the_great <http://example.com/appellation/alexander_the_great>
> Alexander the Great
> 
>   
> 
> So, it is obvious that with the same query both the literal and the uri values are returned.
> 
> A version of the above query to return also the appellation’s label (but not the uri) is the following:
> 
> prefix crm: <http://www.cidoc-crm.org/cidoc-crm/ <http://www.cidoc-crm.org/cidoc-crm/>> <http://www.cidoc-crm.org/cidoc-crm/ <http://www.cidoc-crm.org/cidoc-crm/>>
> 
> prefix rdfs: <http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema>> <http://www.w3.org/2000/01/rdf-schema <http://www.w3.org/2000/01/rdf-schema>>
> 
> select ?identifier
> 
> where {
> 
> {<http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>>  crm:P1_is_identified_by ?identifier }
> 
> UNION
> 
> {<http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>> <http://example.com/person/alexander_the_great <http://example.com/person/alexander_the_great>>  crm:P1_is_identified_by ?identifier_uri .
> 
> ?identifier_uri  rdfs:label ?identifier }
> 
> FILTER (!isURI(?identifier))
> 
> }
> 
> *With the following result :*
> 
> *I**dentifier*
> 
> Alexander the Great
> 
> Alexander the Great
> 
>   
> 
> The next question is, if P1 can be declared superproperty of rdfs:label, so that the query for P1 returns everything CRM regards as Appellation. It works:
> 
> It was tested by altering the cidoc-crm rdfs file, importing it in virtuoso and asking for the subproperties of rdfs:label as follows:
> 
> <rdf:Property rdf:about="P1_is_identified_by">
> 
>      <rdfs:label xml:lang="en">is identified by</rdfs:label>
> 
>      <rdfs:label xml:lang="ru">идентифицируется посредством</rdfs:label>
> 
>      <rdfs:label xml:lang="fr">est identifiée par</rdfs:label>
> 
>      <rdfs:label xml:lang="pt">é identificado por</rdfs:label>
> 
>      <rdfs:domain rdf:resource="E1_CRM_Entity"/>
> 
>       <rdfs:range rdf:resource="E41_Appellation"/>
> 
> *     <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#label <http://www.w3.org/2000/01/rdf-schema#label>" <http://www.w3.org/2000/01/rdf-schema#label>/>* <http://www.w3.org/2000/01/rdf-schema#label%3E/%3E*>
> </rdf:Property>
> 
> Query (Give me all the subproperties of rdfs:label) :
> 
> select * where {
> 
> ?p rdfs:subPropertyOf rdfs:label
> 
> }
> 
> Result from Virtuoso:
> 
> p:
> 
> http://www.cidoc-crm.org/cidoc-crm/P1_is_identified_by <http://www.cidoc-crm.org/cidoc-crm/P1_is_identified_by>
>   
> 
> I propose this method for the RDFS implementation of the CRM: two ranges for P1, namely E41 and rdf:Literal, and P1 superproperty of rdfs:label.
> 
> Best,
> 
>   
> 
> Martin
> 
> --
> 
> --------------------------------------------------------------
> 
>   Dr. Martin Doerr              |  Vox:+30(2810)391625        |
> 
>   Research Director             |  Fax:+30(2810)391638        |
> 
>                                 |  Email: martin at ics.forth.gr <mailto:martin at ics.forth.gr> <mailto:martin at ics.forth.gr <mailto:martin at ics.forth.gr>> |
> 
>                                                               |        
> 
>                 Center for Cultural Informatics               |
> 
>                 Information Systems Laboratory                |
> 
>                  Institute of Computer Science                |
> 
>     Foundation for Research and Technology - Hellas (FORTH)   |
> 
>                                                               |
> 
>                 N.Plastira 100, Vassilika Vouton,             |
> 
>                  GR70013 Heraklion,Crete,Greece               |
> 
>                                                               |
> 
>               Web-site: http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl>           |
> 
> --------------------------------------------------------------
> 
> _______________________________________________
> 
> 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>
>  
> 
> --
> 
> Detlev Balzer, Mecklenburger Landstr. 5, D-23570 Lübeck
> 
> Tel (+49/0)4502-8896495, Mobil (+49)0173-6231233
> 
> PGP Fingerprint B5F3 6467 0615 1EB4 B602 8E41 DE70 8D59 0A8B BBD7
> 
> _______________________________________________
> 
> 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>
> 
> 
> _______________________________________________
> 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/20180910/ebabf52d/attachment-0001.html>


More information about the Crm-sig mailing list