W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2005

RE: SemWeb Non-Starter -- Distributed URI Discovery

From: Dave Viner <dviner@apache.org>
Date: Fri, 1 Apr 2005 13:36:22 -0800
To: <www-rdf-interest@w3.org>
Message-ID: <263A1F717ECDED40AA969F98D1CF122E063EDA04@penxng.smca.yahoo.com>

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


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

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

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.



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

> 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

But if the query side is enough then presumably (as you suggest) the
solution may well lie in the SPARQL protocol.


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


Received on Friday, 1 April 2005 21:36:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:55 UTC