Re: please review issue-57 document draft before Tuesday telcon

On Wed, 2011-03-16 at 07:52 -0400, Jonathan Rees wrote:
> I guess my question is: Under "take it at face value," many URIs are
> supposed to be taken to refer to WS(u). So, under what set of
> circumstances, if any, will an automaton be able to detect that URI is
> supposed to refer to IR(u)?

I like the way you're putting this -- that the criterion is to enable an
automaton to make the detection -- but I think the way you've stated it
reflects too strong an RDF bias.  The vast majority of URIs on the web
-- easily 99%+ -- arguably refer to IR(u), not WS(u), so I think it
would make more sense to state the goal with the opposite default:
[[
Under "take it at face value," many URIs are
supposed to be taken to refer to IR(u).  So, under what set of
circumstances, if any, will an automaton be able to detect that URI u is
supposed to refer to WS(u)?
]]

But I think the bigger problem occurs if you implicitly assume that
IR(u) is not the same as WS(u).  In other words, the definition of :IR
MUST NOT say that it is disjoint with anything.  (And lest anyone
complain that if :IR is not disjoint with anything, then we have said
nothing useful about :IR, I will remind them that IsProvable(P) is not
the same as !IsProvable(!P).  Knowing that something has been "tagged"
as an :IR may indeed be useful to some applications.)

I think a way to state the chimera case 
http://www.w3.org/2001/tag/awwsw/issue57/latest/#id35999
is to say that an HTTP GET of u returning a 200 status implies:

 <u> a :IR ; log:uri "u" .       # Assertion set gh

Let's call this set of assertions "gh" (graph implied by the HTTP
response).  

Then, if the document retrieved from u happens to be interpretable as
RDF, that RDF might further say something like:

 <u> a :Toucan .                 # Assertion set gd

Let's call this set of assertions "gd" (graph expressed in the URI
declaration, or "account").

But is :IR owl:disjointWith :Toucan?  Not necessarily.  But suppose
someone else supplies another set of assertions "ga" (graph of ancillary
statements):

 :IR owl:disjointWith :Toucan .  # Assertion set ga

Now an RDF consumer that chooses to merge graphs gh, gd and ga will
obviously have a problem, because the result will be self-contradictory.
It will either need to forgo some of these assertions, or it will need
to split the identity of <u>.
http://dbooth.org/2007/splitting/ 

On the other hand a different RDF consumer may happily choose to merge
only graphs gh and gd, thus allowing <u> to (ambiguously) denote
something that is both an :IR and a :Toucan in the merged graph.

Furthermore, a third RDF consumer may happily choose to merge only
graphs gh and ga, thus viewing <u> as only an :IR.

This brings us into the whole question of which assertions *should* be
used in what circumstances, i.e., what should these graphs contain,
which of them should be merged by whom under what circumstances, and
what should be done if there are contradictions?

There are several questions:

1. Precisely what assertions should be included in gh, the graph implied
by the HTTP 200 response?  The n3 rules at
http://www.w3.org/wiki/AwwswDboothsRules
were intended as a first crack toward nailing this down.

2. What responsibilities does a URI owner have in minting a new URI,
configuring his/her server, and hosting a URI declaration (or
"account")?  Many people have talked about this, including the "Cool
URIs for the semantic web" document:
http://www.w3.org/TR/cooluris/
and my papers on URI declarations:
http://dbooth.org/2007/uri-decl/ 
and "The URI Lifecycle in Semantic Web Architecture":
http://dbooth.org/2009/lifecycle/

3. If a URI owner does host a URI declaration (or "account"), what
assertions should it include or avoid?  For example, if gh asserts that
<u> is an :IR, should the URI declaration (or "account") include a
disjointness assertion like "<u> owl:disjointWith :Toucan" if <u> is
*only* intended to denote a toucan?  This has mostly been only vaguely
addressed in the past, however my paper on "The URI Lifecycle in
Semantic Web Architecture"
http://dbooth.org/2009/lifecycle/
does propose that the URI declaration (or "account") should not contain
any assertions that would cause the transitive closure of URI
declarations (i.e., the ontological closure) to be contradictory.

4. What should be the RDF statement author's responsibilities, in
writing a graph of statements involving <u>, to help ensure that the
intended "meaning" of <u> will be understood by an RDF consumer?  The
URI Lifecycle paper also proposed an answer to this question.
http://dbooth.org/2009/lifecycle/

5. What process and graphs should the RDF consumer use, in attempting to
determine the referent of a URI?  The URI Lifecycle paper proposes an
(initial) answer to this
http://dbooth.org/2009/lifecycle/
and the paper on "Resource Identity and Semantic Extensions: Making
Sense of Ambiguity"
http://dbooth.org/2010/ambiguity/paper.html
goes into much more detail on the proposed process or algorithm.

All of these questions need more work before we can hope to reach
community consensus, but we do at least have some starting points.



-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Friday, 18 March 2011 16:07:23 UTC