Re: URL +1, LSID -1

On Thu, 12 Jul 2007 03:57:34 -0700, Jonathan Rees  
<jonathan.rees@gmail.com> 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

Received on Friday, 13 July 2007 04:20:28 UTC