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

Richard Light richard at light.demon.co.uk
Tue Sep 11 19:39:16 EEST 2018


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

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

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,


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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180911/ba251dfc/attachment-0001.html>

More information about the Crm-sig mailing list