- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Mon, 4 Apr 2005 08:39:45 +0300
- To: <dviner@apache.org>
- Cc: <www-rdf-interest@w3.org>
On Apr 2, 2005, at 00:36, ext Dave Viner wrote: > > [I earlier sent this message to semantic-web@w3.org... but this seems > to be > the list which is continuing the discussion] > > I got to thinking about Danny Ayer's comments: > > "The other approach that springs to mind, not as far as I'm aware > standardized or particularly deployed (but I'm sure some folks will be > using it) is to use a special query, maybe: > > http://example.org/food/blah?about# > > to get the lowdown on http://example.org/food/blah > > It would be relatively straightforward to implement, e.g. get Apache > to redirect to a query on a triplestore." > > This is an interesting solution. I definitely agree that it would > restrict > the URI creator/originator's freedom. However, what if we just used > another > feature of HTTP to handle this? I'm thinking of the Accept HTTP > header. > Here's a snippet from the rfc > (http://www.w3.org/Protocols/rfc2068/rfc2068) > > " > The Accept request-header field can be used to specify certain media > types which are acceptable for the response. Accept headers can be > used to indicate that the request is specifically limited to a small > set of desired types, as in the case of a request for an in-line > image. > " > > I think it should be feasible to issue this sort of request: > > GET /food/blah HTTP/1.1 > Host: example.com > Accept: application/rdf+xml Not to just jump in and jump out calously, but this has been explored quite a bit for quite some time and content negotiation is simply not the correct mechanism for this. C.f. the FAQ section of http://swdev.nokia.com/uriqa/URIQA.html ... Patrick > > In theory, this should return /food/blah *only* in rdf+xml. This > request > should return different results than a "regular" http/html request: > > GET /food/blah HTTP/1.1 > Host: example.com > Accept: text/html, */* > > > I know that many servers don't respect the Accept: header, but it sure > seems > like it is designed to supply different types of media for identical > URLs. > > Thoughts? > > dave > > > -----Original Message----- > From: Danny Ayers [mailto:danny.ayers@gmail.com] > Sent: Saturday, March 19, 2005 3:22 AM > To: Stephen Rhoads > Cc: semantic-web@w3.org; www-rdf-interest@w3.org > Subject: Re: SemWeb Non-Starter -- Distributed URI Discovery > > > > On Fri, 18 Mar 2005 17:49:39 -0500, Stephen Rhoads <rhoadsnyc@mac.com> > wrote: > >> As far as I can tell, there is no formal, generalized mechanism to > reliably query the owner of a URI in order to obtain an RDF > Description of > that URI. And this is a serious impediment to the Semantic Web. > > Yep, and arguably it extends beyond just query - > >> From URIQA [1]: > [[ > As the Semantic Web emerges and the behavior of automated software > becomes increasingly directed by explicit knowledge about resources, > gathered from disparate sources, the need for a standardized means of > sharing authoritative knowledge about a given resource, based solely > on the URI denoting that resource, becomes critical to achieving a > fully open, global, scalable, and ubiquitous Semantic Web. > ]] > > I agree this is an important point, as the Web* is built on HTTP+URIs > and the Semantic Web seems so far only to have got to URIs. > > There have been efforts such as RDDL [2] to cover the query/GET side > in a manner that would be suitable for both the current Web and the > Semantic Web. As Joshua suggests, it's probably a bit late to earmark > slashes or hashes for the purpose. But is the query side enough? > > I'm personally not comfortable with URIQA's approach, addition of new > HTTP verbs - it's a nice technical solution, but I'd worry about > deployment. But maybe we do need something you could loosely describe > as the RDF Protocol for description-oriented actions (covering the > ASK, TELL kind of agent language, as expressed in HTTP as GET, PUT > etc). > > But if the query side is enough then presumably (as you suggest) the > solution may well lie in the SPARQL protocol. > > Cheers, > Danny. > > *Ok, as danbri has been saying on the Atom list, the "Web" as we know > it can be characterized in other ways, and isn't necessarily > HTTP-specific. But as the primary protocol at this point in time, it > should probably be taken into consideration... > > [1] http://sw.nokia.com/uriqa/URIQA.html > [2] http://www.rddl.org/ > > -- > > http://dannyayers.com > > >
Received on Monday, 4 April 2005 05:40:59 UTC