W3C home > Mailing lists > Public > semantic-web@w3.org > March 2005

Re: SemWeb Non-Starter -- Distributed URI Discovery

From: Benjamin Nowack <bnowack@appmosphere.com>
Date: Wed, 23 Mar 2005 09:56:45 +0100
To: Stephen Rhoads <rhoadsnyc@mac.com>
Cc: semantic-web@w3.org
Message-ID: <PM-EH.20050323095645.C8164.2.1D@192.168.27.2>

On 22.03.2005 18:18:22, Stephen Rhoads wrote:
>
[...]
>
>So, with that settled, let’s restate the problem:
>
>At present, there is no formal, generalized mechanism whereby a Web Agent,
>upon discovery of a URI, and lacking knowledge about that URI, can query the
>Originator of the URI in order to obtain an RDF description of the URI.
True, unfortunately. I was hoping the SWBPD WG (or DAWG) would address
this issue but I'm not sure if they're going to.

>Further, if we're going to empower the SemWeb to take off the way the Web did,
>it's got to be simple enough for people with limited technical ability to
>grasp and partake.  That's why I’m beginning to see the benefits of the
>document-centric hash approach.  Any 'ol Cat with a text editor and a copy of
>"RDF for Dummies" can toss some RDF statements into a file.  The base of the
>document plus fragID serves as a URI for each resource defined within *and*
>gives a Web Agent that may discover a reference to the URI a good hint at
>where to find an RDF description of the URI ... in the document.
>
>Or maybe all we need is some sort of convention akin to “index.html” or
>“robots.txt”.  Toss your RDF statements into a file named “index.rdf” at the
>root of your domain so that others can easily and reliably discover
>information about the URIs of which you are the Originator.
these are two of the various approaches you can find in the mailing
list's archives. the problem is not to find an approach which covers
a certain use case, the problem is to find an efficient approach that
covers most (or the whole set) of use cases out there and which allows
the implementation of a standard way/process to get from a URI to a
resource description.
some comments re your proposals:
- the "URI without hash = RDF file" approach works for hashy URIs
  only, it doesn't allow you to provide rdf descriptions of non-rdf
  web resources (documents, html pages, media files, etc.), so
  you'd need a different mechanism to describe resources with
  non-hash URIs (which surely exist on any server).
- the "index.rdf" approach simply doesn't "scale", it'd have to
  describe all the resources matching the root's URI in one file.

Sorry for not being more encouraging, but I don't think there
is a super-easy solution to the problem of resource description
discovery. you either need an agreed-on non-GET method to
retrieve a resource's description ( la URIQA's MGET), some
HTTP response headers which tell an agent where to find the
RDF, or a standard interface URL to query some service for
a description of a resource's URI. Each approach requires
a certain amount of server-side programming/tweaking.

regards,
benjamin

--
Benjamin Nowack

Kruppstr. 100
45145 Essen, Germany
http://www.bnode.org/
Received on Wednesday, 23 March 2005 09:00:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:45 UTC