Re: The Case For Redirection

From: pat hayes <phayes@ihmc.us>
Subject: Re: The Case For Redirection
Date: Thu, 25 Sep 2003 23:32:13 -0500

[...]

> >>  > It seems to me that you can already do all this.  Use a URI reference with
> >>  > a fragment identifier as the name.  The web page and the RDF/XML content
> >>  > (and maybe OWL content (and maybe FOL content (and ...))) can all live at
> >>  > the URI address.  The query answering system could also live there, I
> >>  > guess.
> >>  >
> >>  > So you have
> >>  >
> >>  >	http://sandro.org/foaf#sandro		for the name
> >>  >	http://sandro.org/foaf.html		for the human readable page
> >>  >	http://sandro.org/foaf.rdf		for the RDF/XML content
> >>  >	(http://sandro.org/foaf.owl		for the OWL content)
> >>  >	http://sandor.org/foaf#sandro?...	for other purposes
> >>  >
> >>  > All, except the last, would be accessible via
> >>  > http://sandro.org/foaf#sandro.  The last, I think, needs extra parameters,
> >>  > and thus can't be just http://sandro.org/foaf#sandro. 
> >>  >
> >>  > This has the advantage that related names can share URIs.
> >>
> >>  With the right view of content negotiation, this might work.  But I'm
> >>  not sure it's possible.  This brings up the issue of what
> >>  "representation" means in HTTP, since content negotiation allows
> >>  selecting one representation from among many, according to its
> >>  media-type (aka MIME type, aka content type).
> >
> >Sure.  Sounds good to me.  You write an RDF-only tool and get RDF content.
> >I write an OWL tool and get OWL content.  Netscape writes a web browser and
> >gets HTML content.
> 
> I agree this picture makes short-term pragmatic 
> sense. What bothers me about it is that the 
> RDF/OWL kind of distinction doesn't seem anything 
> like a media type distinction. Maybe Im being 
> overly fussy, but to subsume semantic depth under 
> media type feels like a hack, and I am sure that 
> if we do this then it will come back to bite us 
> fairly soon.  And we can do it in a cleaner way 
> by using our own technology, see below.

I don't see that there is any problem here.  Why shouldn't the difference
between an RDF document and on OWL document that attempt to represent the
same intuitive notions be just like the difference between a GIF document
and a JPEG document that attempt to represent the same picture?

> >>  If you tried to fetch <http://sandro.org/foaf#sandro> (which would be
> >>  truncated to <http://sandro.org/foaf> before going out) with "Accept:
> >>  text/html" you would presumably get back a representation of
> >>  http://sandro.org/foaf.html (that is, you would receive a
> >>  serialization of a hypertext doument) and would probably think your
> >>  original URI identified an anchor in that document.
> >
> >Sounds fine to me.  If I have a tool that wants to display HTML then URI
> >references with fragment identifiers should be somehow related to HTML
> >anchors.
> >
> >>  If you tried to fetch the same URI with "Accept: application/rdf+xml"
> >>  you would presumably get back a representation of
> >>  http://sandro.org/foaf.rdf (that is, you would receive a serialization
> >>  of an RDF graph) and would probably think your original URI identified
> >>  an instance of foaf:Person.
> >
> >Again this sounds great to me.  If I have a tool that prefers RDF then this
> >seems to be just what the doctor ordered - URI references with fragment
> >identifiers are names, and it is possible to get information related to
> >that name by accessing an RDF document at the URI that is the URI reference
> >with the fragment identifier stripped off.
> 
> You are assuming that we will be using the same 
> kind of tools we have now, and browsing and SW 
> inference have nothing to do with one another. 
> But surely we can hope for a future superBrowser 
> which can use SW markup in some way to provide a 
> more useful browsing experience. I have always 
> assumed that we should be thinking about ways of 
> including SW markup *inside* web pages, linked to 
> the current visible HTML content. 

Sounds nice.  Propose a content type that allows this.  Browsers and RDF
tools alike could employ these sorts of document, after suitable upgrades
of course.

> Then the 
> conflation of HTML-# with RDF-# seems like a 
> problem.  Like, if I can refer to a document, why 
> can't I refer to a place in a document? Or to the 
> anchor at that place in the document? I should be 
> able to refer to anything, and it might be very 
> useful to have an SW ontology which is about HTML 
> documents.

I don't see anything wrong with having a theory of HTML documents in RDF.
This theory would provide denotations for certain URI references, tied to
implementation using World Wide Web protocols.  If you have a URI reference
that has been determined to denote an HTML document or a portion of an HTML
document then the above situation would seem to still work.  The URI
reference still has a denotation, which is a document or document section.
Browsers can still use the URI reference as before.  Semantic Web tools can
still use the URI reference as before, including accessing relevant
information by retrieving a Semantic Web document at the related location.

Where this does begin to break down is if you want to be able to access
Semantic Web documents in a similar fashion, because there is no easy way
to extend this to have Semantic Web documents that relate to other Semantic
Web documents in the same way that Semantic Web documents relate to HTML
documents.   Some (new) redirect mechanism would be needed to handle this
case, but I don't think that it is needed right now.

[...]

> >I agree that using redirection gets some of the same benefits.  I just
> >worry about the problems of uniformly using URI references without fragment
> >identifiers as names.  What happens if there is a document at that URI?
> >Is the URI reference then required to denote that document?
> 
> Better say not, given what you find at the URIs 
> already out there, eg the RDF, RDFS and XSD 
> no-frag URIs.  But why do we need to specify what 
> they *denote* at all? 

Well at some stage of the game we would like to be able to have a Semantic
Web theory of World Wide Web documents.  I think that at this stage we need
to be able to specify that a particular URI reference denotes a particular
document, just as the typed literal "3"^^xsd:integer denotes the integer 3.

> What they *fetch* is one 
> thing, what they denote can be another. I don't 
> see any reason to impose general conditions on 
> denotation in this case.  If we have to say 
> something, it would make more sense to say that 
> IF there is a document at that URI which asserts 
> that they denote something, THEN that is what 
> they denote: ie what the document says, not the 
> document. That is, they SHOULD denote something 
> that makes that document true.  We don't have to 
> go into details about what kind of 'true' that 
> is.  That has the merit of making a rough kind of 
> semantic sense and also covering the actual 
> examples which are out there, eg XSD asserts that 
> 'XSD' denotes a namespace.

I don't follow this at all.

> It occurs to me that this all follows from a 
> simple principle: an URI should not Web-retrieve 
> anything that is SW-false of itself.  So if A 
> fetches a document which says that A denotes, 
> say, a certain namespace, then it has to denote 
> that namespace. Again, never mind for now about 
> HOW it says that.

I think that this is incredibly prone to problems.  This seems to be the
``Use Implies Consent'' notion in another guise. If the meaning of any URI
in the Semantic Web is inextricably tied up with a document that can be
fetched at that URI, then I would argue that Lucent should not use any URIs
that are not controlled by Lucent or organizations that Lucent trusts.
This would make it very hard for Lucent to communicate with its suppliers
or customers, many of which do not belong to this select group.

[...]

peter

Received on Friday, 26 September 2003 08:27:43 UTC