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

Richard Light richard at light.demon.co.uk
Wed Sep 12 09:56:30 EEST 2018

On 11/09/2018 20:02, Martin Doerr wrote:
> Dear All,
> Firstly, apologies, the RDF was wrong, it was intended to be P1 is
> superproperty of rdfs:label.
I'm not sure that this is something we need to state at all, and I worry
that - if it is included in our RDFS Schema - it may bring unwanted
side-effects.  Isn't this saying that any instance of rdfs:label is to
be treated as an instance of P1?  Bear in mind that CRM data may
co-exist in triple stores in company with other RDF data, which may well
use rdfs:label for its own purposes.  This assertion that 'all
rdfs:labels are P1 relationships' would then be applied to this other
data as well.  This might well result in incorrect/spurious results when
SPARQL queries are applied to the data.

In general, I suggest that we are ok to define sub-classes/properties of
standard RDFS types, but we shouldn't define super-classes/properties of
them.  (I would welcome comments on the validity of this suggestion from
someone who understands RDF better than me.)

> Semantically, the range of rdfs:label, when used, is ontologically an
> Appellation in the sense of the CRM.
Agreed (see my reply from yesterday).  The conclusion I draw from this
is that we can validly say:

E1 rdfs:label "string value" is a shortcut for the path 'E1 CRM Entity'
'P1 is identified by' 'E41 Appellation' ...

in exactly the same spirit as the similarly-worded note which we find in
the definition of P1 itself. (Obviously, by using this shortcut, we lose
the information that this string value is an Appellation, but that's the
nature of short-cuts.)

> I agree with George, that all RDF nodes should have a human readable
> label. They name the thing, even if it is a technical node.
> I would find it confusing to say, labels are not to be queried, only
> to be read, and the "real" names must have a URI,
> regardless weather I have more to say about it.
> I am really not a fan of punning, we definitely forbid it in the CRM.
> The point with Appellations is that some, the simple ones, can
> directly be represented in the machine, or be outside. The solution to
> assign a URI in all cases, and then a value or label, does not make
> the world easier. It is extremely bad performance. We talk here about
> implementation, not about ontology.
> You get simply a useless explosion of the graph for a purpose of
> theoretic purity.
Agreed. What we need to do is to propose a simple way of expressing
simple Appellations in RDF.  That is why my shortcut definition above
ends with '...': I don't think we have yet decided how to do this.

I've just been looking over the draft document we are trying to write,
and it currently says that a fully-worked-out path will use 'P3 has note
-> E62 string' to express the value of an E41 Appellation.  This (i.e.
the suggestion to use P3) comes from the definition of the superclass
E90 Symbolic Object.  A comment in our draft RDF document questions
whether this is sufficiently precise, since P3 is simply "a container
for all informal descriptions about an object that have not been
expressed in terms of CRM constructs".  I suggest that we need either to
use rdfs:value to hold the string value, or (better) to define a
CRM-specific subproperty of rdfs:value and use that.  (This subproperty
could be part of the published CRM, or it could just form part of the
'RDF implementation' guidelines.)  I don't think that we should use
rdfs:label here.

I don't think we should concern ourselves with URLs in our RDF guidance
document.  Any implementer of our RDF solutions can choose to assign a
URL to represent any node in the structure, but it won't change the
logic of the resulting RDF, or how it responds to SPARQL queries.

> Those claiming confusing should be more precise. Has someone looked at
> query benchmarks? Has someone looked at graphical representations of
> RDF graphs. Do they really look better?
> So either we either ignore the issue, and write queries that collect
> names either via P1, URI and a value/label, or via a label, because
> this is where names appear in RDF, we make no punning, but our queries
> implement exactly this meaning. So, we are not better, but do as if we
> wouldn't know.
> Or, we describe the fact by punning, have one superproperty for all
> cases, which we can query, and stop thereby the discussion if labels
> are allowed or not, and how they relate to appellations. The punning
> comes in, because the range of the superproperty must comprise the
> ranges of the subproperties. We can play a bit more, make the punning
> with a superproperty of P1, and have both P1 and rdfs:label
> subproperties of it, if this is preferred.
> The solution I describe is just a logical representation of the
> situation, not creating a different situation. It just says that names
> can be complex objects or simple literals.
As I said yesterday, I don't see how any punning strategy can make
differently-structured RDF equivalent for the purposes of querying.
Therefore, I think we will have to accept that if we allow more than one
way of representing a given statement in CRM RDF, we will have to
construct queries which look explicitly for each of the possible patterns.

> The problem is, that the RDF literals do have meaning beyond being
> symbol sequences.
Insofar as they have such meaning, I would argue that we define it (i.e.
that meaning) by the CRM context in which we place the string/literal
value.  I think there is a danger that we could over-think this problem.

> The punning does not introduce the problem. With or without, the
> queries have to cope with names in either form.
> This holds similarly for space primitives and large geometry files,
> for short texts and equivalent files etc.
> Opinions?
> Best
> Martin

*Richard Light*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180912/bcbf0ce3/attachment-0001.html>

More information about the Crm-sig mailing list