- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Fri, 8 Apr 2005 12:27:18 -0400
- 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. Xiaoshu
Received on Friday, 8 April 2005 16:27:26 UTC