W3C home > Mailing lists > Public > www-rdf-logic@w3.org > August 2001

QNames, semantics, serialization

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Thu, 30 Aug 2001 13:39:57 -0400 (EDT)
Message-Id: <200108301739.f7UHdvK05388@pantheon-po04.its.yale.edu>
To: www-rdf-logic@w3.org

   [Patrick Stickler]
   I think I follow what you are saying here. Though for me, I like to
   differentiate clearly between the (formal) semantics of RDF and the 
   (informal?) semantics attached to a given ontology. The RDF semantics
   is concerned with things such as statements, predicates, subjects,
   objects, axioms, etc. and how other ontologies are defined in terms of 
   that semantics; i.e. RDF is a semantics for defining labeled graphs,
   right? (just as XML provides a semantics for defining labeled trees).

I've heard people say this, but I find it puzzling.  One could say
that C defines a semantics for defining abstract-syntax trees.  E.g.,
'(' means, "Treat the precedence of the operator to the right as
higher than the precedence of the operator to the left."  So 
a * ( b + c ) can be given a "meaning" as a recipe for building the
       / \
      a   +
         / \
	b   c

But this is overkill.  Syntax is so well understood that there's
rarely a need to think about the "semantics" of tokens in this sense.
If someone said that the tree-building scheme sketched above was all
there was to say about the semantics of C, he would be taken aside and
told about unsigned characters, the sense in which '+' denotes
something close to addition, exactly what happens when you evaluate
f(++x, g(x)), and so forth.

Similarly, it seems to me that there is nothing useful to say about
RDF at the syntactic level.  Its expressions are labeled graphs of a
certain sort, and it's no harder to spell out what counts as a legal
RDF graph than it is to spell out what counts as a legal C program.
The interesting semantics comes in when you ask what entities the
graph is talking about, and what it's saying about them.

   My understanding has always been that non-RDF semantics which is 
   associated with (represented by) the terms in a given ontology (i.e. the 
   "real world" concepts that those terms represent) is irrelevant to the 
   core machinery (i.e. semantics) of RDF proper. But the issue of maintaining 
   integrity (uniqueness) of terms is crucial to the proper operation of 
   that machinery.

   So it doesn't matter whether a term 'mother' actually represents the
   concept "MOTHER" or "FAVORITE BEVERAGE BRAND", per se, but ideally it
   should not accidentally and untentionally represent both. Note the
   words 'accidentally' and 'unintentionally', i.e. it's not that someone
   is incorrectly asserting they are the same, but that noone asserts
   that they are the same but they end up being treated the same because
   they end up with the same identity in RDF space. That is the
   whole gist of my issue with the QName to URI syntax mapping.

   It has become clear from these discussions, though, that although the
   risk of such collisions is still real with the present mapping function
   employed by RDF, I see now that the chances of it occurring are much
   smaller than originally thought, and also any collisions would happen
   (presumably) within the URI space of the same authority, and hence there
   is a reasonable way to address the risk; namely, document in the standard
   that there *is* such a (remote) risk and that specific practices should
   be followed to avoid it.

I believe I am echoing Pat Hayes when I say that I don't understand
why it is considered desirable, let alone essential, let alone
*possible*, that there be only one name for each object.  What on
earth could guarantee such a thing?  Lasers in space that destroy any
computer found to have a nonofficial URI for an object?

I don't mean here to allude to the "uncontrollable anarchy" that
supposedly reigns on the WWW.  It seems to me that it will be
commonplace for a person or object to have multiple URIs corresponding
to different roles.  The tax collectors might have a URI for me, and
my employer might have another; why should one be favored?  (Do I
really *want* the government and several large corporations to have
the same identifier for me?  The supposed advantage is that it will it
easier for them to trade information about me; I'm happy for them, but
I think it's too damned easy for them to trade information about me

   >    Secondly, I was referring mostly to semantics associated 
   > with ontologies
   >    and identified by both URIs in the graph and QNames in 
   > serializations,
   >    and not the semantics of RDF itself -- which I see as yet a third
   >    layer/level
   >    of semantics that is disjunct from either URI Scheme 
   > semantics or specific
   >    ontological semantics. 
   > You've lost me here.  I suspect the problem lies in the phrase
   > "semantics associated with ontologies," which sounds like it's
   > infected with the confusion I described above.

   Acutely infected ;-)

   I'll try again in my admitedly corse layman's terms -- I meant the 
   semantics that is associated with (represented by) globally unique 
   identifiers, which take one of two forms: (1) QNames in XML (if 
   identifying predicate resources), and (2) URIs in RDF Graphs. Such
   semantics is separate from (and irrelevant to) the specific semantics
   of RDF -- though the terms representing that non-RDF semantics are 
   themselves within the scope of RDF semantics as they participate in 
   statements defined and manipulated using RDF semantics. Or is that 
   even more unclear? ;-)

I think I understood it.  I think I even agree with it.

   What I meant was that the semantics of the URI Scheme is "hidden" in
   RDF-land such that the "things a URI denotes" within an RDF graph
   is totally disjunct from any interpretation, analysis, parsing, or
   dereferencing of that URI according to the URI Scheme. Insofar as
   RDF is concerned, it's not a URI, it's just a unique string. Right?

I am really not competent to comment on this issue.  My impression is
that XML namespaces are basically the same idea.  You use a string
that looks like it points somewhere on the Web, but you never follow
the apparent pointer (even if you could, which you usually can't).
The string is there just to serve as a disambiguating prefix.
Meanwhile, all this machinery is supposed to be a new kind of name
that sticks to its denotation more tenaciously than any name
previously known to mankind.  This just doesn't add up, as far as I
can see.

                                             -- Drew McDermott
Received on Thursday, 30 August 2001 13:39:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:40 GMT