W3C home > Mailing lists > Public > semantic-web@w3.org > December 2012

Re: Well Behaved RDF - Taming Blank Nodes, etc.

From: David Booth <david@dbooth.org>
Date: Wed, 19 Dec 2012 18:44:38 -0500
To: Henry Story <henry.story@bblfish.net>
Cc: Lee Feigenbaum <lee@thefigtrees.net>, Steve Harris <steve.harris@garlik.com>, Pat Hayes <phayes@ihmc.us>, semantic-web <semantic-web@w3.org>
Message-ID: <1355960678.2229.51902.camel@dbooth-laptop>
On Wed, 2012-12-19 at 22:02 +0100, Henry Story wrote:
[ . . . ]
> It would take a lot more careful development you are right to find the correct 
> language to describe the differences. But I think there are distinctions here
> that one should make
> - bnodes: these don't have a rich sense
> - #uris: These have what is close to an analytic definition: you dereference
> the associated document to find its meaning.

I think what you might be getting at is that a particular bnode in an
RDF graph cannot have an associated definition beyond whatever was
otherwise stated or implied by that graph.  Whereas a URI can have a URI
definition that is not an explicit part of the graph, but is nonetheless
intended to constrain the interpretations of that graph, as described in
the proposed standard RDF process for determining resource identity
though I used the term "URI declaration" instead of "URI definition" in
that paper.  I agree.

>   Here one needs to look at David Lewis' "Convention" where he shows that one
> can save the notion of analyticity from Quine's attacks. Also Gareth Evans
> has a notion of a delta definition, that gives a minimal identifying definition.
> In both cases I need to do more reading on this.
>   I just hinting that the pragmatics of the Web and the definition of URIs
> gives us something akin to what philosophers were thinking of as analytic
> definitions. These also work by description btw, it is just that the meaning
> of a #URI is defined by the owner of the URI space. In order to define it 
> usually he will use terms from other vocabularies, often not his
> own, so usually he can't stabilise his meaning without a larger community. But he can
> pin it, if you will.

Yes, to get the full effect of the definition the ontological closure
must be obtained:

>  BNodes clearly make that impossible.  A Bnode in a description is not
> something anyone can own. If I want to copy a statement about an
> object I need to capture a larger part of the graph, the identifying
> part for that bnode.  Bnodes can only be identified by description,
> since there is no way for the bnode to stabilise over time.
> With a URI you can have a term stabilise over time in use - in
> software for example that might not update itself quickly for core
> terms available, such that the initial description can disappear and
> the URI still function. Natural languages are like that: 
> words stabilise without an quick access to their definitions. 

Yes, that is possible, but I think we need to be very careful about how
we expect that to occur, in order to facilitate the goal of the semantic
web, which is machine processing.  That situation is what I have been
calling "community expropriation" of the URI:
The problem is that when the community expropriates a URI -- i.e., when
the URI owner's definition should no longer used -- then there is no
longer a simple algorithmic way to locate the correct URI definition.
This is precisely why I proposed that in such cases, the URI should be
deprecated in favor of a new one that can be located by dereferencing
the URI.  Otherwise, the number of URIs whose definitions are needed,
but cannot be located by a simple algorithm, would continually grow,
unbounded, which would not work so well.

To be blunt, although the continual community evolution of a word's
definition is what happens with natural language, that would *not* be a
good architecture for the Semantic Web.

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Wednesday, 19 December 2012 23:45:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:31 UTC