Re: URI resolver was Re: RDDL and XML Schemas Proposed Recommendation
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@n...
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format