Dear Richard,
I basically agree with your comments. Specifically however, I indeed
wanted to say that the official definition of rdfs:label makes it
exactly a subproperty of P1 (or shortcut of it) in any correct use of
RDFS. If we want to mix RDFS models, we should have an opinion about
their compatibility. Otherwise, we would have to regard them as
alternative that cannot be compared with the CRM.
I am not happy with adding rdfs:label to instances of Appellation,
because this would mean it is a name for a name and not the name. I
would sympathize with George using rdfs:value, if it had the respective
semantics.
What we need, to my opinion, is a property of Symbolic Object we may
call it "has symbolic content" or "has symbolic content inline" or
anything better, which defines that the symbolic content *is identical
to* the Literal, *abstracted *to the "level of symbolic specificity"
that the Literal implies and that conforms to the identity condition of
the Symbolic Object, i.e., characters of a certain script, or whatever.
That would make the meaning of the "value" unambiguous.
We may need add another property, such as "is contained in" or so
pointing to a URL actually holding an instance of its content, again
abstracted to the "level of symbolic specificity" that the file instance
implies and that conforms to the identity condition of the Symbolic Object.
Whereas the shortcut interpretation is attractive, it is not exactly the
same. Using a shortcut, we say that the intermediate node is of
different, independent nature from the terminal node. Here, we do not
say "Appellation" is related to something called "Literal". We say "this
Appellation IS itself what is in this Literal". That may or may not be a
reason to reject this interpretation.
We also have to distinguish Appellations and other Symbolic Objects
which have multiple symbolic forms, i.e. spelling variants, versions
etc., from those *being one* symbolic form. The rdfs:value has no means
to express that. I believe we need yet another property "has symbolic
content variant". In that case, the URI is necessary, to my opinion.
I think the polymorphism we describe here, well studied in
object-oriented languages, is in the nature of Appellations. The problem
for me is, that the the respective KR models have NOT THOUGHT of the
case that such polymorphisms can occurr. Nevertheless, RDFS is tolerant
enough to accept the Superproperty statement, but not to create a class
which is either URI or *inline expanded* object.
This polymorphism occurs EXCLUSIVELY for Symbolic Objects with symbol
sets a certain machine supports. Another reason not to use rdfs:value,
because it does not give credit to the fact that only Symbolic Objects
can have such a "value".
I agree that we may over-think the point. As I mentioned, the
superproperty statement I propose has no other effect than that I can
get E41's and labels back by querying P1 only.
Opinions?
Best,
Martin
On 9/12/2018 9:56 AM, Richard Light wrote:
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.
Richard
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*
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: 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 |
--------------------------------------------------------------
