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
>
>
>