On Thu, 12 Jul 2007 03:57:34 -0700, Jonathan Rees
<[EMAIL PROTECTED]> 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.
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.
...though I do think that the fact that LSID resolution is "grounded" in
WSDL is also a huge advantage... through WSDL we can resolve using a GET
if that is what the provider intends (as per most of our use-cases), or
using something more complex if necessary. As Matthias points out in his
(beautiful!) post late today, the vast majority of our current Web
information doesn't come from explicitly named resources, but rather from
some form of analytical/lookup interface. Sure, we can provide REST-like
URIs for some of our data, but there is a large component that is going to
come from an analytical service. In fact, there are a large number of
resources out there that are, in fact, provided by "REST-like" URLs, with
a "?id=foo" after the domain and path information. Certainly for these
cases there is no additional programming required once the LSID resolver
is set-up - no more work than what will be required to give them "pure"
URLs. And if the interface is more complex, then the WSDL handles that.
I'd like to be able to use the same framework to interact with Web
Services on the Semantic Web as I do to interact with explicitly named
URIs (in fact, having Web Services identified by LSIDs is something I
already have grant funding to pursue, so regardless of the decisions of
the HCLS working group, I will continue to pursue that!). Again, I see
this as a potental limitation with a pure-URL solution. I'm not an
advocate of an LSID-only solution (unless you get me tipsy, when I start
to say what I really think! ;-) ) but I do think that the LSID resolution
protocol was exquisitely well thought-out, and solves a subset of problems
that we are bound to be faced with if we pursue a URL-only solution!
As I've said before, I think that LSIDs solve a *very specific subset*
of
problems that don't seem to be raised very often in the discussions on
this list because they aren't "typical" situations... at the moment!
I'm willing to believe this. I think I'm close to having a short list
of the features that LSID users like, and I think we can reproduce
most or all of them inside the http: URI scheme. But I would really
like to hear from you and other LSID users which features they find
essential.
I noticed that a lot of LSID-believers came out of the woodwork today!
I'm quite relieved that I am not a lone voice in the wilderness :-)
Hopefully we can all provide you with the specific use-cases that have
pushed us into using LSIDs rather than URLs... because quite honestly, if
I could have used a URL instead of an LSID, I would never have put myself
through the pain during the early days of LSID code development! ;-) (no
offense intended to Ben S. and his colleagues! it's been a fun ride!)
I would also like to see an LSID HOWTO for consumers of LSIDs. Perhaps
this exists already. But right now, if I get an LSID in some email, I
haven't a clue how to track down an LSID resolver that knows about it
(although via google I learned that sourceforge might be a good place
to start).
The reference to "best practices" that came across the list earlier (I
believe it came from Michel Dumontier) is a good start. I agree with Ben
Good, though, that I need to get off my arse and post the code for a
"generic" LSID authority server and a "generic" LSID metadata/data
resolver. Client-side, it's only really two lines of code in the most
simplistic case, so that's pretty trivial, but server-side it seems that
the documentation is sadly lacking! It isn't really that hard! Certainly
no harder than a simple CGI... which, as Matthias points out, is how
*most* ID's are resolved right now!
Is anyone willing to write my grant proposals so that I have time to do
this ;-)
M
