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 <[email protected]> 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: [email protected] > <mailto:[email protected]> > URL: http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl> > >> On Sep 10, 2018, at 5:06 PM, Mark Fichtner <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>>: >> 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 <[email protected] >> <mailto:[email protected]>> on behalf of Detlev Balzer >> <[email protected] <mailto:[email protected]>> >> Date: Tuesday, September 4, 2018 at 12:11 PM >> To: "[email protected] <mailto:[email protected]>" >> <[email protected] <mailto:[email protected]>> >> 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 <[email protected] >> <mailto:[email protected]>> on behalf of Martin Doerr >> <[email protected] <mailto:[email protected]>> >> >> *Date: *Saturday, September 1, 2018 at 7:41 AM >> >> *To: *crm-sig <[email protected] <mailto:[email protected]>> >> >> *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: [email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> | >> >> | >> >> 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 >> >> [email protected] <mailto:[email protected]> >> 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 >> >> [email protected] <mailto:[email protected]> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> <http://lists.ics.forth.gr/mailman/listinfo/crm-sig> >> >> >> >> _______________________________________________ >> Crm-sig mailing list >> [email protected] <mailto:[email protected]> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> <http://lists.ics.forth.gr/mailman/listinfo/crm-sig> >> >> >> _______________________________________________ >> Crm-sig mailing list >> [email protected] <mailto:[email protected]> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
