Re: 303 +1, WSDL -1

On Jul 13, 2007, at 12:20 AM, Mark Wilkinson wrote:


>>> What worries me about the 303 solution (other than that we are  
>>> not using it for
>>> it's primary purpose [1]) is that the redirection can only be to  
>>> a *single* resource, specified in the Location header.
>
>> On Thu, 12 Jul 2007 03:57:34 -0700, Jonathan Rees  
>> <jonathan.rees@gmail.com> wrote:
>> If this is an important functionality then it can be provided in a
>> variety of ways - a mere matter of programming. LSID resolver happens
>> to be the only way that comes ready made. But the functionality
>> doesn't need to be tied to the use of LSIDs.
>
> If there is an alternative solution that provides the same  
> functionality, and that can be applied universally to all existing  
> URIs (URLs), then I'm all for it!  To be honest, this is my  
> *primary* objection to moving to a URL solution vs an LSID  
> solution... if you can solve that problem, then I am *almost* in  
> the URL camp.

Here is an alternative:

Problem statement:

Enable third parties to register the fact that they have additional  
statements to provide about something that a URI denotes, in such a  
way as to make it easy for anyone to discover this fact. Do this in a  
way which requires minimal coordination (ideally none) between the  
minter of the original URI, the provider of the additional  
statements, and the consumer of all the statements.

Solution:

For a given URI http://a.b/c/d/e, construct a new URI  http:// 
purl.org/about/a.b/c/d/e

Configure the purl server so that http://purl.org/provide-about/a.b/c/ 
d/e redirects to something akin to a structured wiki page or a REST  
service (let us assume for the moment that whoever currently provides  
the LSID WSDL that contains this information currently is the  
provider of this service).

This page may be edited (manually or programmatically) to include a  
description (suitable for a machine to understand) of how to access  
the resource and what sort of resource it is, and perhaps some  
additional useful information (what predicates does the resource  
provide). This information rendered as RDF using a standard  
vocabulary and saved.

Configure the purl server so that http://purl.org/about/a.b/c/d/e  
retrieves the RDF that was constructed (or a 404 if there is none).  
Semantic web agents then interpret this RDF and go fetch what they  
want or need.

We all agree that 303s redirect to a human readable html document,  
that this document uses a REL link to an RDF document that says what  
the provider wishes to say and that the RDF also states that http:// 
purl.org/about/a.b/c/d/e may have more information. (suitable  
shortcuts are provided to make bulk retrievals more efficient - we've  
already discussed such mechanisms)

This can be done now, with effort analogous to what is being done  
with LSIDS. Let me point out some obvious advantages: 1) No  
requirement to use web services (though web services *could* be  
described as ways of accessing further statements using this scheme)  
2) Requires *less* manual intervention than is currently required to  
maintain the WSDL. 3) Re-uses purl, which is based on HTTP, which  
everyone knows how to use already 4) Makes clear that the description  
of these additional resources for statements are to be in RDF, and  
requires that one advertises what to expect if you go to the resource  
(will you get an RDF document, a SPARQL endpoint, a Web service set  
of methods?)

---

With a bit more effort expended on extending the purl server code we  
can get some more leverage - we enhance it so that retrieving http:// 
purl.org/about/a.b/c/d/e actually merges the RDF result of retrieving  
each of http://purl.org/about*/a.b/
http://purl.org/about*/a.b/c
http://purl.org/about*/a.b/c/d
http://purl.org/about/a.b/c/d/e

Where the about* top level domain indicates that the information  
about covers all URIs that start with the indicated path.

In this way different providers can note that they have additional  
statements about URIs located in varying amounts of namespace.

With some coordination among us, we could even decide to dedicate a  
server to hosting the whole mess of this information (I don't expect  
that it needs too large a resource) so as to make the service more  
efficient in answering queried, and making it easy to provide, to  
whoever wishes, a snapshot that they can host themselves.

---

May I now count you among those *almost* in the URL camp? ;-)

-Alan

Received on Saturday, 14 July 2007 03:19:49 UTC