Hi, Apologies for being so quiet on this front.
I'm puzzled by Martin's final declaration test: it says the intention is to see if P1 can be a /superproperty /of rdfs:label, yet the declaration (and consequent SPARQL query) asserts/tests that it is a /subproperty /of rdfs:label: > 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 suspect that in practice this distinction doesn't particularly matter (though it does make my brain hurt :-)). Presumably the thinking is that when you search for P1 relationships you will get all the rdfs:label shortcuts as well? (And not the other way round ...?) Anyway, my point is that a single SPARQL expression cannot pick up both fully-expressed P1's with an E41 on the end, and 'short cut' P1's with rdfs:label. This is because the shape of the RDF is different in the two cases. So you're going to have to query for both variant patterns explicitly, and declaring P1 as a sub- or super-property of rdfs:label isn't going to save you any time or effort. Doing so might lead to unwanted consequences, especially if CRM data forms part of a larger RDF resource. As regards your proposed short-cuts (and bearing in mind that P1 is already a short-cut), I don't have strong views on which approach to take. I think that your experiments with Virtuoso demonstrate the 'open world' nature of the RDFS framework; it allows multiple alternative possibilities. If we look at the definition of rdfs:label, it says it represents "a human-readable version of a resource's /name/" (my italics). As such, it is certainly semantically close to our P1 property, whose range is an E41 Appellation. So that might be an argument for your second option: using rdfs:label at the point where P1 would otherwise occur. Like George, I originally liked the idea of using rdfs:value to represent values (!), but on re-reading their definitions I now tend to agree with Martin that rdfs:label is a closer fit, semantically, for our purposes. rdfs:value may still be useful for representing more complex values (e.g. those involving values and units), and we may want to consider deriving some useful CRM-specific subproperties of rdfs:value. But that's a discussion for another day ... Best wishes, Richard On 10/09/2018 20:20, George Bruseker 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 > -- *Richard Light*
