Hi David, *sigh*. I said recently that I would rather chew my arm off than re-engage with http-range-14. Apparently I have very little self control.
On Mar 25, 2012, at 11:54, David Booth wrote: > Jeni, Ian, Leigh, Nick, Hugh, Steve, Masahide, Gregg, Niklas, Jerry, > Dave, Bill, Andy, John, Ben, Damian, Thomas, Ed Summers and Davy, > > I have drafted what I think may represent a middle ground change > proposal and I am wondering if something along this line would also meet > your concerns: > http://www.w3.org/wiki/UriDefinitionDiscoveryProtocol > > Highlights of this proposal: > - It enables a URI owner to unambiguously convey any URI definition to > an interested client. +1 to this. I have long been a fan of unambiguous definition. The summary argument against is Leigh Dodd's "show what is actually broken" approach and the summary argument for is my "we need to invent new ways to associate RDF with other Web resources in a discoverable manner to allow for 'follow-your-nose' across islands of Linked Data." > - It does not constrain whether or how a client will use that or any > other URI definition, as that is the client's business. Yes, +1 of course. > - It retains the existing httpRange-14 rule. No real argument here, I suppose. > - It also permits the use of an HTTP 200 response with RDF content as a > means of conveying a URI definition. +1. I quite like the registration of the "isDefinedBy" relation as a complement to POWDER's "describedby", although I'd probably name it in the same way for consistency ("definedby"). > - It provides guidelines for avoiding confusion and inconsistencies, > while acknowledging the burden those guidelines place on URI owners. This is no different to the current Web and allows people to play fast and loose with the standards if they need or choose to. Overall, that is a feature not a bug. > - It encourages URI owners to publish URI definitions even if those URI > definitions are not perfect. It also allows non-URI owners to publish conflicting or complementary definitions and for them to refer by URI to each others definitions. That's good. > > It also includes numerous other clarifications. A note regarding hash URIs: It seems to me that the major use for hash URIs is to provide links into monolithic human-oriented documentation. That made sense on the early Web and still works today. Your proposal would allow existing users of hash URIs to provide a separate machine-oriented "isDefinedBy" relation URI. That would make a nice (and useful) bridge toward addressing hash URI deployments without breaking them. It is also worth noting that hash URI users could easily navigate bi-directionally between human- and machine-oriented content using this approach, thereby taking the sting out of the use of hash URIs: Once a machine-oriented definition URI has been found once, it could be cached and used subsequently. In other words, this proposal (ever so slightly extended to be more clear regarding the caching guidance for the "isDefinedBy" relation) could be used to get around the existing cacheless nature of the 303 response. > > Would something along these lines also meet your concerns? After giving this proposal a provisional "thumbs up", I still doubt whether the TAG (after more than a decade arguing about this and finally satisfying http-range-14 via a minimal patch) will be able to come to consensus on a major change. Good luck :) Regards, Dave -- David Wood, Ph.D. 3 Round Stones http://3roundstones.com
