- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 12 Feb 2008 10:47:44 -0600
- To: ext Richard Cyganiak <richard@cyganiak.de>
- Cc: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org" <www-tag@w3.org>, Graham Klyne <GK@ninebynine.org>, Jonathan Borden <jonathan@openhealth.org>
On Feb 6, 2008, at 10:30, ext Richard Cyganiak wrote: > > Stuart, > > There's also the > > Link: site.rdf;rel=meta > > pattern, which seems more or less the same as Resource-Description > (except that AFAIK it is intended for use on information resources > only). > > Personally I'm uneasy about cramming too much semantics into the > transport layer. I think HTTP is about efficiently moving > representations of resources back and forth over the network. It is > not about describing the nature of resources or their > relationships. That's what representations are for. I don't see how > Resource-Type, Resource-Description and similar headers improve > HTTP's ability to efficiently exchange representations. > > Your argument seems to be that 303 redirects are too weak; that the > redirect doesn't imply anything more than “try-over-there”. I would > like to know why more than this weak implication is necessary on > the transport layer. Strong “aboutness” and similar relationships > can be expressed, if necessary, in a representation made available > at the redirection target URI. > > ... > > Regarding the Resource-PropertyValue header, I propose to > generalize it into a Subject-Predicate-Object header. We could > build the Semantic Web using only HTTP HEAD. I also propose new > HTTP verbs HEADPOST, HEADPUT and HEADDELETE to modify all those new > HTTP headers. > Something like http://sw.nokia.com/uriqa/URIQA.html ??? We've been using this approach successfully for years at Nokia... FWIW. Patrick > Best, > Richard > > > On 6 Feb 2008, at 13:11, Williams, Stuart (HP Labs, Bristol) wrote: > >> >> I wanted to resurface an idea that I can trace back to being >> 'buried' deep in a email message from Jonathan Borden [1] when the >> httpRange-14 permathread was in it's infancy (there may have been >> earlier incarnations of similar a idea). Jonathan's email is on a >> different topic and appears at the end rather of the message: >> >> The Idea: >> --------- >> <quote> >> I generally agree. "Site" is one type of resource, perhaps its >> special >> enough to get its own HTTP header (?) but why not just (example HTTP >> response headers): >> >> Resource-Type: http://example.org/siteOntology#Site >> Resource-Description: http://example.org/site.rdf >> >> would solve this problem, as well as [httpRange-14] in a general >> fashion. >> </quote> >> >> Discussion: >> ----------- >> At the time the idea passed by uncommented upon - probably unnoticed. >> >> I came across the idea when the mime of a "Resource-Description" >> header struck me, did a Google search because I couldn't believe >> it would not have been though of before and found Jonathan's >> message. This was at a time when the httpRange-14 resolution would >> have been regarded as an uneasy peace - in need of some time to >> settle rather than being distrubed... howvever time has moved >> on... and I think it is appropriate to resurface Jonathan's buried >> idea. >> >> I think this would address the problem of: " >> >> Given a reference to a thing (IR or nonIR... generically a >> thing, anything) >> how do I (or my agent) find out *about* what that thing is.?" >> >> >> A Resource-Description: header on a 200 or 303 response would >> explicitly refer you to a resource that the authority deploying a >> URI for the original thing regards as descriptive of it (extended >> metadata if you like that you'd be hard pressed to fit in existing >> headers and which itself is *not* a awww:representation of the >> referenced thing). >> >> This is stronger than the "303 'try-over-there <Location:>' >> 'hint'" because the intention of the Resource-Description: is (or >> would be) clear. >> >> Following a Resource-Description: reference that fails to yield a >> description of the referenced thing create a detectable error or >> 'conformance violation'. That will need some careful definition >> because IMO it would be wrong to restrict the media type of >> (representations of) such descriptions. So, an error of this kind >> could only be sanctioned if no descriptive representation obtained >> at all, or when it has a media-type that the retrieving agent >> 'understands' and it contains no description of the original subject. >> >> In addition the narrative definition these header could be >> augmented with (RDF) assertions that use of the header licenses >> eg: >> Given a request with a request URI of <?u> (referring to >> resource ?u) AND >> >> a corresponding 2xx or 3xx response carrying one or more >> headers >> of the form "Resource-Description: <? >> d>" AND >> >> ?d does infact describe ? >> u THEN >> >> ?u :hasDescription ?d . >> >> And probably some other rules for asserting error situations. >> Also, there probably needs to be more consideration of precidence >> rules with respect to the <?u>'s taken from request lines agains <? >> u>'s taken from Content-Location: headers - maybe assertions >> should be applied using both URI. >> >> Jonathan's "Resource-Type:" header is interesting as well, but I >> think less crucial. >> >> Varations >> ---------- >> A slight variant of Jonathan's proposal based on a suggestion from >> a colleague >> >> Resource-PropertyValue: <?propertyURI> <?propertyValue> >> >> where ?propertyValue is either another URI or a simple literal >> value (more depth thought required - but http/mime header >> character constraints apply). >> >> This header would allow an derived RDF assertion of: >> >> ?u ?propertyURI ?propertyValue . >> >> A property could then be define to signify :hasDescription >> property above or rdf:type (expanded as a URI) could be used >> similar effect to Jonathan's Resource-Type: header. >> >> >> Any way... I think that the bones of a proposal are clear. Three >> possible RDF header definitions required: >> >> Resource-Description: >> Resource-Type: >> Resource-PropertyValue: >> >> Worth Doing? >> ------------ >> So... does the idea of legs... or will it die on the spike? >> >> Is anyone already engaged in trying to do something similar in >> spirit? One well thoughout and supported approach is going to be >> better than a multipicity of diverse but similarly intentioned >> approaches each attracting their own communities. >> >> I guess I'd be willing to carry the ball *if* there were enough >> feedback that it is a ball worth carrying. >> >> If so... what does it take to make it happen? >> >> Community buy-in, an internet-draft, experimental implemention and >> in the long run, HTTP header registrations in the IANA registry [1]? >> >> How long could that take? Hmmm... >> >> Stuart >> -- >> [1] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0006 >> [2] http://www.rfc-editor.org/rfc/rfc3864.txt >> [3] http://www.iana.org/assignments/message-headers/message-header- >> index.html >> >> (Tracker, this is ISSUE-57) >> >> >> >> > >
Received on Tuesday, 12 February 2008 16:55:35 UTC