RE: URI for abstract concepts (domain, host, origin, site, etc.)
David Booth <david <at> dbooth.org>
2009-07-06 03:08:07 GMT
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:
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:
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.
> > -----Original Message-----
> > From: David Booth [mailto:david <at> dbooth.org]
> > Sent: Wednesday, July 01, 2009 7:08 AM
> > To: Larry Masinter
> > Cc: 'Jonathan Rees'; ashok.malhotra <at> oracle.com; Eran Hammer-Lahav;
> > apps-discuss <at> ietf.org; www-tag <at> 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.