Re: URI resolver was Re: RDDL and XML Schemas Proposed Recommendation

[Michael Mealling <michael@bailey.dscga.com>]

On Sun, Mar 25, 2001 at 09:45:36AM -0500, Jonathan Borden wrote:
> Michael Mealling wrote:
> > On Sun, Mar 25, 2001 at 02:33:38PM +1000, Justin Couch wrote:
> > > Jonathan Borden wrote:
> > > > Things like RDF allow you to make statements "about" resources without
> > > > needing to resolve the URI.
> > >
> > > Well that is an invalid statement. It is easy to prove it to be false
> > > because you may say something and then have the resolver tell you it is
> > > completely different.
> 
> as i said. per RFC 2396 when you resolve a URI you get back an entity not a
> resource. you are conflating resource and entity. 

Oh lordy be carefull here. RFC 2396 defines the term Resource. Are you
using its definition or something else? Its kind of buried in the
semantics but RFC 2396 defines a Resource as something that is bound
to a URI.

> this is a common
> misconception. Using RDF you can make statements about URIs that cannot be
> disproven by resolving the URI -- indeed there is no guarentee nor even
> intention that a URI _can_ be resolved.

RDF can do this, sure. But URIs don't know or care about RDF. RDF
is simply one of a multitude of applications that use URIs. Each
application uses them differently. In RDF's case it uses URIs to make
some interesting and complex statements about URIs but that doesn't
mean that URIs then inhereit those statements. 

Also, you may be using the term 'resolve' in a much more constrained sense 
than Justin is.  IMHO, any time you find out some information about a URI 
then you have just done the act of resolution. When I look in my local cache in 
my web browser that is resolution. When my entity resolver looks
in its local catalog, that is resolution. True, many URIs were designed
in a way that makes authoritative, global resolution impossible (the OID
URN namespace I defined in RFC 3061 for example). But that doesn't mean
that resolution in general is not possible...

> That is, these can only strictly be limited to a
> > > collection of hints until an authorative answer is given by actually
> > > resolving a resource. For example, that URN above, your RDF says that it
> > > is a comic book. If you resolved it you would find it is a technical
> > > book about Java network programming.
> 
> Suppose this RDF is published by Amazon. And if I resolved this URN via
> Amazon I assume a book would arrive at my doorstep. _I would return the
> book_. If Amazon were to disagree I would call my Visa company and complain.
> If I got nowhere I would call the FBI, my lawyer etc.

It depends on what the RDF said. In this case what is authoritative
is Amazon's promise to send you said book. Amazon isn't authoritative
for the ISBN number, they're authoriative for the transaction you are
currently in. If they screwed up the ISBN urn in the RDF then yes, they
screwed up. But its no the fault of the URI....

> Your concept of authority is interesting but I don't accept it.

Authority for what? The ISBN organizatin is the _only_ entity that
can truly know what ISBN number goes with what book since they're
the ones that assigned it. If Amazon screws up their internal
inventory list then is it the ISBN agency that made the mistake? No,
its the mistake of Amazon for not checking with the authoritative
agency....

> > And this is an important point. The URI Resolution application finds
> > _authoritative_ information about the URI and/or its Resource.
> 
> Authoritative per _whom_?

Authoritative for the entity that has change control over the portion
of the namespace in question. Anything else is just someone's opinion.
Just because we may not be using the same definition of authoritative
doesn't mean either one is invalid. Mine is predicated on identifier
assignment. I take it that yours is predicated on the trust model
of the transaction in question. Both are useful....

> If
> > you want to find information that is simply someone elses opinion about
> > the URI then that is what a few of us are calling Contextualization.
> > Its the resolution and/or use of metadata about a URI within some
> > non-authoritative context. But that is a different story....
> >
> > > > The resource that a URI identifies is distinct
> > > > from the "entity" that the URI may resolve to from time to
> > time (the entity
> > > > is not guarenteed to be constant e.g. a stock price --very
> > unfortunately
> > > > these days).
> 
> > >If the URI resolves to an instantaneous stock
> > > price, then find a better resolver.
> 
> huh? this is how the web works.
> 
> why should I confuse "http://example.org/stockprice?symbol=INTC
> 
> with "data:text/plain,$5.0" ?
> 
> The resource the first URI identifies is  "the stock price of Intel", the
> resource the second URI identifies is "$5.0" ... at one point in time these
> URIs resolved to the same entity.

And this is the problem. You didn't bind that first URI to its resource
so you can't make that statement authoritatively (unless you're 
running example.org and I don't think you are). I'm no going to trust
your statement that http://example.org/stockprice?symbol=INTC is
an abstract container object of data:text/plain,$5.0. The only
one I'm going to trust OUTSIDE OF ANY OTHER TRUST RELATIONSHIP is
the one that example.org makes.

> > Yep. Its the old story of does the URI identify the thing in the box
> > or the box itself. The answer is that you should have three URIs: one
> > for the box, one for whatever is currently in the box. and possibly
> > several for the thing that is the contents. If your URI identifies
> > an abstract thing that can change its representation then you have
> > to deal with that in your application or pick a different URI.
> >
> 
> Certainly you can have a "data:" URI that need not be resolved to ascertain
> what its 'contents' are. And so you can easily represent the 'contents of
> the box' rather than the box to use your terminology. But those are two
> different URIs. Or many different URIs depending on what you want to do.

Au contrare. The data URI scheme defines the resolution process (as do
all URI schemes). Its resolution process is to look inside the URI string
itself for its Resource. What we are talking about here are concepts
that trancend any particular scheme. What are the concepts that exist 
for ALL URI schemes in ALL situations? Basing our assumption on those, 
what infrastructure level services can I create that allow me to 
ask complex and possibly application specific questions about URIs in
general when I'm not the one that bound the URI to its Resource.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com