RE: Proposed AWWW erratum on "information resources" [was Re: Fwd: Splitting vs. Interpreting]

> LSIDs and XRIs are the main two that come to mind.  Here's
> an example of a claim that "LSIDs are independent of any particular
> transport protocol":
> http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006Jul/0173.html

I think the claim of being "independent of any particular
transport protocol" is a little confused, but the concerns
about using http: make sense to me.  Really it's a matter
of "being independent of other people's resolution mechanisms,
and instead dependent on ours".

> My objection to these proposals is that there is no *need* to define new
> schemes for LSIDs or XRIs: http URIs can do the same thing, and
> therefore should be used instead.

I disagree that they "can do" the "same thing". I think that
they are showing that they value some properties that you
think are insignificant.

> I think the main reason for proposals like an LSID or XRI scheme has
> been a misconception about how http URIs can be used.  The essential
> misconception is that http URIs *must* be resolved using the HTTP
> protocol. The owner of a URI such as http://filbert.example/foo could
> define an alternate protocol -- the filbert protocol -- for resolving
> URIs that begin with "http://filbert.example/",

A world in which that is true is very "Humpty Dumpty", where words
mean whatever the utterer of the word intends it to mean. I don't
think that's a reasonable architecture, and -- wearing a Web
Architect hat, would vote against such a design, as leading to
poor interoperability. How can a receiver of 
"http://filbert.example/yes" *know*, reliably, that filbert
has defined an alternate protocol?   

Protocols and protocol elements like URIs need a stable definition
so that receivers of communications can know, without telepathy
or infinite wisdom, what the communication is intended to mean.
URIs are "uniform" resource identifiers in that they carry along
the indication of intended resolution.


> just as the owner of a
> "filbert:" scheme could define the filbert protocol for resolving URIs
> that begin with "filbert:".  

The design of the URI system, as I understood it through the
more than 15 years of shepherding the documents through the
IETF standards process -- has been that the registered scheme
is a reliable indicator of the protocol. For
"http://filbert.example/yes" to mean something other than
"use the HTTP protocol", it would require an incompatible
change to the "http" URI scheme definition which is not
justified at all.

> The point is that the ability to do this is
> due to the fact that http://filbert.example/foo, in *addition* to being
> an http URI (and thus associated with the HTTP protocol), is also a
> *name* that can be associated with *any* protocol. 

I'm sure that you can also use http://filbert.example/foo 
as a design on a T-shirt or in in a pagan ritual, but
it doesn't mean that it is therefore also a fashion statement
or one of the many name of a diety unsuitable for uttering
aloud. 

We're discussing the standardized use of URIs within network
protocols. The fact that I can design a system which uses URIs
for some other purpose doesn't detract from there being value
in having a standardize meaning.

>  The association of the name to a protocol is by external
>  convention. 

The purpose of writing standards is to write down the conventions
so that those who agree to use a protocol can infer all of
the conventions without some out-of-band transmission of what
the protocol elements mean. A design which relies on out-of-band
communication (external convention) is a bad network design.

>  It can be
> accomplished by publishing a document proclaiming that URIs beginning
> with "filbert:" should follow certain syntactic conventions and can
> resolved using the filbert protocol 

There is a convention for publication established in the URI
specification and URI registry. Proclaiming such a thing in
a document in the third drawer of your file cabinet in your
basement isn't sufficient.

> or it can be accomplished by
> publishing a document proclaiming that URIs beginning with
> "http://filbert.example/" should follow certain syntactic conventions
> and can be resolved using the filbert protocol.

But there are already existing documents, long published,
read, absorbed, and implemented, which already define what
URIs beginning with "http:" mean and how to process them.
Proposals for a new system which has severe interoperability
difficulties as a replacement for one which is functioning
should be rejected.

> Perhaps one difference in viewpoint is that I believe that if http URIs
> can be used, they *should* be used, rather than creating a new scheme.

This seems much too dogmatic to me. I believe systems should
be designed in a way that improves reliability and interoperability,
and that design choices are complex, those making them should
be informed of the costs and benefits of those design choices,
and that interoperability, extensibility and reliability
are important elements of design which often get short shrift.

> I.e., the proponent of a new scheme should bear the burden of proving
> that a new scheme is needed

They have some burden to show that there is value, yes.
>  -- that the http *scheme* (not protocol) is
> inadequate -- rather than the other way around. 

Well, the scheme currently implies the protocol and I think
proposals that it shouldn't -- well, the ones I've seen
have been poorly thought out.

>  Again, the reason why I
> think the default should be this way is to prevent fragmentation in the
> URI space.

I'm not sure what "URI space" is to be fragmented. I don't
think calling everyone "Bob" is a good idea, Bob Larry Masinter,
Bob David Booth, etc. 

I think systems should be designed so they work effectively
and reliably, and that reuse and simplicity are important
but secondary goals.

>   Sure, one can say that the marketplace will choose which
> schemes will win out -- and indeed it will -- but that won't prevent
> unnecessary churn along the way, which could be avoided by discouraging
> unnecessary new schemes.

I certainly would discourage unnecessary new schemes, but
I'm more willing to accept rationales for why some new schemes
may seem "necessary" to their proponents.

> Rather than jumping directly to a new URI scheme, I think it would be
> better to initially use an http URI prefix (such as
> http://filbert.example/ ),

well, if that works for them, then it's a good indication their
scheme isn't "necessary".

>  and only consider creating a new scheme
> *after* widespread implementation support for that prefix has been
> observed, i.e., *after* software implementations widely use the filbert
> protocol to resolve URIs that start with http://filbert.example/ .
 
Well, if prefixes are sufficient (as they seem to be with doi, for
example) then you've supplied evidence that a new scheme isn't
necessary.

> Anyway, I don't know if this explanation has helped.  I do wish we could
> have an opportunity to chat in person sometime.  :)

Writing this up is useful, too.  I'm not sure I'm getting through
about the design space, and I'd like to hone my written arguments.

David Booth



On Wed, 2009-07-29 at 07:55 -0700, Larry Masinter wrote:
> > HTTP protocol *may* be useful in conjunction with it.  This is
> > additional value that other URIs that are designed to be "protocol
> > independent" do not have.  
> 
> I don't understand this at all. What URIs are "protocol
> independent"? Every URI scheme I can think of has a "protocol"
> because how else can you define it? 
> 
> > There is nothing intrinsic to a URI or a URI scheme that makes a URI
> > function only as a name or as a locator (or both). That function
> > depends on how it is *used* -- not on the URI itself. 
> 
> I agree with that
> 
> >  A URI that was
> > intended primarily as a locator can still be used as a name,
> 
> Sure, "can be used". Separate question about how well it works.
> 
> >  and a URI
> > that was intended primarily as a name can be used as a locator if a
> > protocol becomes associated with it.  All that's needed is a way to
> > resolve it.  
> 
> I don't know how to "associate a protocol" with a URI without
> redefining the URI scheme, which seems generally like a bad idea.
> Yes, you need a way to resolve it.
> 
> > The fact that an http URI can be readily used as a locator does not
> > *reduce* its value as a name. 
> 
> XXX has a value. Knowing something about XXX doesn't increase 
> or reduce its value.
> 
> >  It's potential use as a locator is in *addition* to its use as a name.  
> 
> Now I've lost your point here.
> 
> Larry
> --
> http://larry.masinter.net
> 
> 
> 
> 
> 
> 
-- 
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 Saturday, 1 August 2009 07:23:59 UTC