RE: URI for abstract concepts (domain, host, origin, site, etc.)

On Thu, 2009-07-02 at 09:49 -0700, Eran Hammer-Lahav wrote:
> But this approach means a parser cannot figure out the meaning of a
> URI without a GET. 

No, the GET can be optimized away if the parser is aware of this
convention, as described here:
http://thing-described-by.org/#optimizing
This is comparable to a parser being aware of the "tdb:" scheme.

> How would a parser know that a document about such a URI is really
> about something else (the subject of the URI) and not the resource the
> URI itself is identifying?
> 
> For this to work, I need to hardcode http://t-d-b.org into every
> parser to have a specialized meaning.

No, parsers that do not know about this "http://t-d-b.org?" prefix can
dereference the URI if they wish, whereupon they will be 303-redirected
to the descriptive document, in accordance with:
http://www.w3.org/TR/cooluris/
http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039

On the other hand, parsers that *do* know about this prefix can skip the
initial HTTP request and go directly to the descriptive document.  In
comparison with a "tdb:" URI, the result would be the same for parsers
that know about the special "tdb:" or "http://t-d-b.org?" prefix.  But
parsers that do not know about the "tdb:" would be out of luck, whereas
parsers that do not know about the "http://t-d-b.org?" prefix may still
be able to find the descriptive document by dereferencing the URI.

David Booth

> 
> EHL
> 
> > -----Original Message-----
> > From: David Booth [mailto:david@dbooth.org]
> > Sent: Wednesday, July 01, 2009 7:08 AM
> > To: Larry Masinter
> > Cc: 'Jonathan Rees'; ashok.malhotra@oracle.com; Eran Hammer-Lahav;
> > apps-discuss@ietf.org; www-tag@w3.org; 'URI'
> > Subject: RE: URI for abstract concepts (domain, host, origin, site,
> > etc.)
> > 
> > Larry,
> > 
> > On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote:
> > > I'm thinking about revising
> > >  http://larry.masinter.net/duri.html
> > >
> > > to:
> > > (1) to get rid of "duri" and just stick with "tdb"
> > >   (because there isn't much use for duri at all)
> > > (2) make it a URI scheme rather than a URN namespace
> > > (3) make the date optional, for cases where the time of
> > >   binding resource to representation (and of interpretation
> > >   of that representation to an 'abstract concept')
> > >
> > > So the simplest form would be
> > >
> > > tdb:http://larry.masinter.net
> > 
> > That makes it remarkably similar to
> > http://t-d-b.org?http://larry.masinter.net
> > 
> > but the t-d-b.org URI has the advantage that it doesn't require a new
> > URI scheme, and it *might* be dereferenceable by a browser.  In fact,
> > at
> > the moment it *is* dereferenceable.
> > 
> > >
> > > which would neatly allow using descriptions of
> > > abstract concepts to identify the abstract concept.
> > 
> > That sounds like what the "http://t-d-b.org?" prefix does.
> > 
> > > (Syntactically, the date can be left out without
> > > ambiguity.)
> > >
> > > Would this be helpful, at least for illustrative purposes?
> > 
> > I think the goal is reasonable, but as explained in
> > http://dbooth.org/2006/urn2http/
> > I don't think a new URI scheme is necessary to achieve it.  Similar
> > things can be done with http URIs, with greater benefit.
> > 
> > >
> > > I think there are other means for distinguishing
> > > between the representation of a  description and
> > > the thing described, but this would at least
> > > add a well-known method that isn't tied to
> > > any particular protocol, linking method, resolution
> > > method, etc.
> > 
> > Right, but "http:" URIs do not necessarily need to be resolved using
> > HTTP, nor do they necessarily need to be resolved at all.  At worst
> > they
> > can be treated as opaque strings, but at best they *might* be
> > dereferenceable to useful information.  A URI prefix like
> > "http://t-d-b.org?" can become "well known" just as "tdb:" can.  This
> > is
> > a social issue, independent of whether a new scheme is defined.
> > 
> > 
> > --
> > David Booth, Ph.D.
> > Cleveland Clinic (contractor)
> > 
> > Opinions expressed herein are those of the author and do not
> > necessarily
> > reflect those of Cleveland Clinic.
> 
> 
> 
> 
-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Received on Monday, 6 July 2009 03:09:25 UTC