W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > April 2005

Re: [BioPAX-discuss] LSID Best practices...

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Fri, 8 Apr 2005 12:27:18 -0400
Message-ID: <1112977638.4256b0e64bc29@webmail.musc.edu>
To: Sean Martin <sjmm@us.ibm.com>
Cc: public-semweb-lifesci@w3.org

> Unless I have completely misunderstood Gary's orginal question as stated 
> above, I disagree. There is a standard [1] for dereferencing any LSID and 
> retrieving its associated data and metadata documents. This is part of the 

I agree with SM here but felt for EJ as well.  Since URN, which LSID is, is
itself a logical name, but eventrally we need to get down to retrieve it so we
always wonder how.  IMHO, it is the same reason why EN asks TBL about
concatenating URI and URN.  

It boils down to the question how we can make using LSID less technical demanding.

For example, if I read an article talking about a gene "URN:LSID:x:y:z" and want
to further explore it, what should I do now?  The current solution of LSID is
through a client software that implemented specified services.  To make it fully
works, we need a bunch of registries running around, to retrive where the
resolution service is and then ...  All these are well thought but the
complexity will scare off most ones from trying LSID. 

One thing I think LSID can do is to offer a "convention".  For instance,
given a LSID of "URN:LSID:x:y:z", a user could expect to go to a web page of the
following convention: "http://" + x + "/lsid", where a user can enter the LSID
to retrieve  data or meta data through interactively.  Similarly, web services
URI can also be conventionally specified.  I think in this way, we can at make
using LSID much easier than it is.

With this convention, we can promote the usage of LSID since a lot of user will
feel comfortable developing web pages and databases.  For more advanced users,
they can gradually add web services, then registering it to some discvoery
service etc.

Received on Friday, 8 April 2005 16:27:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:23 UTC