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

Nicola Carboni nicola.carboni at map.cnrs.fr
Tue Sep 11 01:53:23 EEST 2018


Dear all, 
>> 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.
>> 

While punning could be a solution, I have to admit it not my favourite either.

In our daily practice, for encoding appellation strings we defined as best practice[1]:

Approach 1)  E1 → P1 is identified by → E41 Appellation → rdfs:Label → rdfs:Literal

The modelling above allow us the possibility to add further statements about the Appellation. Nevertheless, I have to admit that there has been cases where using rdfs:label on the entity (without using the appellation) was very much desired, because it would easier to display, and it would not create extra unnecessary triples (which could be a problem in big datasets).

We are, for now, sticking with the modelling above, which seems to be the most comprehensive and able to accomodate the most diverse needs. 
If I would vote, I would suggest Approach 1 as standard practice and the deprecation of the approaches 2 and 3 below:

Approach 2) E1 → P1 is identified by → E41 Appellation → P3 has note → rdfs:Literal
and
Approach 3) E1 → P1 is identified by → E41 Appellation → rdf:value → rdfs:Literal


If I may suggest, specification should also need be discussed for the preferred appellation, which does not have a corresponding property in CRM. Personally, we define each of the strings of a name as different appellation (unless they are transliteration) and specify the preferred one using P2 has type (more details here [2]).

Best, 

Nicola


[1] https://docs.cordh.net/modelling/#modelling-the-appellation <https://docs.cordh.net/modelling/#modelling-the-appellation>
[2] https://docs.cordh.net/modelling/#preferred-appellations-identifiers <https://docs.cordh.net/modelling/#preferred-appellations-identifiers>



--
Nicola Carboni,
Semantic Architect
Swiss Art Research Infrastructure 
University of Zurich 
Post Box 23 
Ramistrasse 71 
8006 Zurich 
Switzerland




> On 10 Sep 2018, at 21:20, George Bruseker <bruseker at ics.forth.gr> wrote:
> 
> 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 <mailto:bruseker at ics.forth.gr>
> URL: http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl>
> 
>> On Sep 10, 2018, at 5:06 PM, Mark Fichtner <m.fichtner at wiss-ki.eu <mailto: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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180911/f269f6c5/attachment-0001.html>


More information about the Crm-sig mailing list