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
<[EMAIL PROTECTED]> 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
