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 <rsander...@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-boun...@ics.forth.gr> on behalf of Detlev Balzer
> <d...@balilabs.de>
> *Date: *Tuesday, September 4, 2018 at 12:11 PM
> *To: *"crm-sig@ics.forth.gr" <crm-sig@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” and the
> resource that has the URI 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” and the
> resource that has the URI http://example.museum.org/data/1 as its
> identifier.
>
>
>
> Rob
>
>
>
>
>
> *From: *Crm-sig <crm-sig-boun...@ics.forth.gr> on behalf of Martin Doerr <
> mar...@ics.forth.gr>
>
> *Date: *Saturday, September 1, 2018 at 7:41 AM
>
> *To: *crm-sig <Crm-sig@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 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>
>
> 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>
>
> 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>
>
> 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>
>
> 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>/>
>
> </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/>
>
> 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>
>
>
>
> select * where { crm:P1_is_identified_by rdfs:range ?range}
>
>
>
> *result: *
>
> *range*
>
> http://www.cidoc-crm.org/cidoc-crm/E41_Appellation
>
> 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> .
>
> @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> .
>
> @prefix 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>
>
> 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>
>
> rdfs:label "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>
>
> 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/>
>
> 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>
>
> select * where
>
> { <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
>
> 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/>
>
> 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>
>
> select ?identifier
>
> where {
>
> {<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> 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>/>*
>
> </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
>
>
>
> 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: mar...@ics.forth.gr <
> mailto:mar...@ics.forth.gr <mar...@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 |
>
> --------------------------------------------------------------
>
> _______________________________________________
>
> Crm-sig mailing list
>
> Crm-sig@ics.forth.gr
>
> 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@ics.forth.gr
>
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
