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