Re: reference needed

> It looks like I'm going to have to do a certain amount of background 
> reading before I can have a real understanding of all the issues here, 
> but looking at http://esw.w3.org/topic/SlashURI, I have a question. It 
> looks like this discussion is 'browser-centric," but what if we're using 
> an inferencing engine to reason about RDF statements? Would the engine 
> treat all occurrences of SlashURIs as referring to the thing itself, or 
> would it have to try to access each SlashURI and check what comes back, 
> perhaps performing different kinds of inferencing depending on whether 
> the response is a "302 found" redirect or not?

I think the RDF Model Theory is very clear that URIs (aka URIRefs)
function in RDF just like constant symbols in classical logic.  No
dereferencing is involved in knowing that each URI acts (within an
interpretation) as a name for something in the domain of discourse.

The question in this whole area is how you integrate the browser
experience with this RDF logical formalism.  That is, RDF tells me
that "http://www.w3.org/Consortium/" is a constant symbol that denotes
something in each interpretation, ....  But how do we reconcile that
with our experience of using that string as a web address which we can
use to view a maintained document about the W3C?  Should we think of
that string as denoting the W3C?  As denoting the currently served
contents?  As denoting the abstraction of a document which is
maintained over time?  As denoting a server which offers some content
in response to each HTTP request?   

I tried to sketch this out in "When Browsable And Unambiguous Collide"
[1] but I recognize that may be fairly unreadable.

Let's see if I can understand your question:

> but what if we're using 
> an inferencing engine to reason about RDF statements? Would the engine 
> treat all occurrences of SlashURIs as referring to the thing itself,

All URIs in RDF refer to things themselves.  Those things themselves
might be web pages.

> or 
> would it have to try to access each SlashURI and check what comes back, 
> perhaps performing different kinds of inferencing depending on whether 
> the response is a "302 found" redirect or not?

Inferencing using RDF simple entailment, or the RDFS or OWL vocabulary
entailements (ignoring owl:imports) don't really have anything to do
with the web.  Perhaps someday we'll have an RDF "retrieval-based
entailment, which would say:
   
    To learn more about the thing named by http://foo, do a web
    retrieval operation on http://foo and see what you get.

But of course that's way too fuzzy for machines (and logicians).  So
we don't have it defined yet.

The key point for now is to not get ourselves into a bind.  If we
start to use some URI as a name for a person and as a web address
for a page about the person, we're likely to get into the kind of bind
you pointed out in your first message.

So for now, the main idea is HashURI [2], which recommends that you
use URIs with a "#" in them for RDF names.  This mostly works okay.
Some people don't like it, so an alternative is SlashURI [3], where
you use a "303 See Other" redirect from URIs for non-web-page things
to related authoritative web-page things.

So if you want to prototype "retrieval-based entailment" inference,
you can try fetching content from each URI and see what you get.  (cwm
has some code to play with this.)  If a fetch on http://foo gets you a
page with no redirect, then *I think* that tells you http://foo
denotes some kind of a web page / document / information-providing
agent.  But exactly what it denotes depends on which ontology of
the web you're using, I guess.  There might be useful ontologies of
the web where http://foo could still denote a person or chair while
still exhibiting that behavior, but I'm skeptical.

Sorry for not giving you the simple yes/no answer you probably
wanted.  :-)

      -- sandro

[1] http://esw.w3.org/topic/WhenBrowsableAndUnambiguousCollide
[2] http://esw.w3.org/topic/HashURI
[3] http://esw.w3.org/topic/SlashURI

Received on Wednesday, 4 June 2003 15:12:54 UTC