W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > July 2007

Re: URL +1, LSID -1

From: Marc-Alexandre Nolin <lotus@ieee.org>
Date: Fri, 13 Jul 2007 21:13:08 -0400
Message-ID: <d6a9bb0d0707131813n5e151439k337cdbe8b380f181@mail.gmail.com>
To: "Ricardo Pereira" <ricardo@tdwg.org>
Cc: public-semweb-lifesci <public-semweb-lifesci@w3.org>

>From my point of view, this is a 2 sides problems: identification and resolving

We need to clearly and as long as possible identify biological concept
to reference them in the long run. For this, LSID seem to offers
something more stable than the HTTP URI. But let me cite the page Cool
URIs don't change http://www.w3.org/Provider/Style/URI at the section
"I didn't think URLs have to be persistent - that was URNs"

----> This is the probably one of the worst side-effects of the URN
discussions. Some seem to think that because there is research about
namespaces which will be more persistent, that they can be as lax
about dangling links as they like as "URNs will fix all that". If you
are one of these folks, then allow me to disillusion you.

Most URN schemes I have seen look something like an authority ID
followed by either a date and a string you choose, or just a string
you choose. This looks very like an HTTP URI. In other words, if you
think your organization will be capable of creating URNs which will
last, then prove it by doing it now and using them for your HTTP URIs.
There is nothing about HTTP which makes your URIs unstable. It is your
organization. Make a database which maps document URN to current
filename, and let the web server use that to actually retrieve files.

If you have gotten to this point, then unless you have the time and
money and contacts to get some software design done, then you might
claim the next excuse:

--------
I don't know who is the author of this, but it seem pretty right to
me. In the article "Globally distributed object identification for
biological knowledgebases" about LSID at
http://bib.oxfordjournals.org/cgi/content/abstract/5/1/59 they say on
page 62 : "Once assigned, an LSID is permanent and is never
reassigned." Who can guaranty me this? Who can prove me that it is
more true for LSID than it is for HTTP URI?

For the resolving part. If I want to resolve the URI and getting
something useful in answer, the HTTP URI is the answer because it work
right now, see TBL Tabulator.

Resolving system exist for LSID, I know, I've one myself and this
thread is fill with link to LSID resolver. But why should I rely on
something "over the DNS" to do the DNS job? Who can tell me the LSID
resolvers I use won't just go away tomorrow? next year? In five year?
In ten year? I'm no futurologist, but I'm pretty sure DNS will still
work by then. If you're telling me you can set up your own LSID
resolver to resolve your own concept in the possibility that the
resolver I use go away, I can answer you that you can also set up you
own urlrewrite file in a matter of minute to redirect you wherever you
want using a REST-like interface and no exotic resolution scheme like
LSID. All it would take would be for people to share the urlrewrite
file in question.

I like what Alan proposed in the beginning of this thread. It's a
REST-like interface very easy to implement even for little lab we not
a big budget to publish ther data. No content negociation, no WSDL to
implement, no web server hack to answer 303 to redirect, no specific
client to built to ask for diferent mime type in the request, no #
that will give you a whole group of document instead of only a
document, no nothing, just a plain URL with what I want in it.

http://[domaine name]/[what I offer]/[namespace]:[id].[version]

http://purl.uniprot.org/rdf/uniprot:p19367.1 <---- only an example,
didn't test if it is a real one
http://purl.uniprot.org/html/uniprot:p19367.1
etc...

In fact it is really near from an united version HTTP URI and LSID.

LSID = urn:lsid:Authority:AuthorityNamespace:ObjectID:RevisionNumber
HTTP URI = We don't have a standard yet, but could be http://[domaine
name]/[what I offer]/[namespace]:[id].[version]

So a mixed up could be http://[domaine name]/[what I
offer]/Authority:AuthorityNamespace:ObjectID.RevisionNumber

Stripping the URN:LSID because it don't give any more meaning.

This is easily programable with a urlrewrite files or if you're really
on a low budget, a directory tree with static files in them.

On another though, maybe not completely related to the current
discussion... but not far. Where are heading URI in other domain. We
are in health care and life sciences, but what about economic (stock,
trading, etc) domain, engeneering (chemical, physic, etc) domain,
juridic, politic domain? How will they build their URI? We are not
alone in the Semantic Web community. LSID is for LIFE SCIENCE
identificator, not every identificator. So what happen when an
engeneering document refers to an URI in Life sciences. Answer: all
his documents connect together but when it come to the life science
"bubble" of identifier, nothing resolve unless you go throw some kind
of resolver you're not aware of because you're not even in life
sciences! Aren't you affraid of having an identification that will put
life science in some kind of ghetto? Yes LSID identify, but the extra
layer to resolve them is the bummer.

See you next monday for the F2F, I will be on the phone.

Marc-Alexandre

P.S.: Sorry for my bad english. It's not my native language.


2007/7/12, Ricardo Pereira <ricardo@tdwg.org>:
>
>    Someone raised the question of whether the LSID Browser for Firefox
> looks up DNS SRV records during the resolution protocol. In functional
> terms, the answer is YES, it does.
>
>    The cause of confusion is that the browser uses a web service
> somewhere else (at http://lsid.tdwg.org as of version 1.0.1) to do the
> lookup. That's because the Mozilla JavaScript toolkit doesn't provide
> SRV record lookup. Yes, it is a hack, but nevertheless it makes the
> client resolve LSIDs according to the specification.
>
>    You can disable that lookup by unchecking a box in the LSID Browser
> configuration. In that case, the browser will try to look up the
> authority using regular DNS A records (that "only in code" fallback
> mechanism that someone else mentioned in this thread). You can also
> configure the browser to provide your own local mapping between
> authority identifications to authority host.
>
>    I hope this clarifies the issue.
>
>    Cheers,
>
> Ricardo
>
>
> Mark Wilkinson wrote:
> > On Thu, 12 Jul 2007 06:30:37 -0700, Roderic Page
> > <r.page@bio.gla.ac.uk> wrote:
> >
> >
> >> The
> >> initial step is looking up the authority server in the DNS. The
> >> FireFox client doesn't seem to do this,
> >
> > I stand corrected :-)
> >
> > M
> >
> >
> > ----
> > Mark Wilkinson
> > Assistant Professor, Dept. Medical Genetics
> > University of British Columbia
> > PI Bioinformatics
> > iCAPTURE Centre, St. Paul's Hospital
> > Tel:  604 682 2344 x62129
> > Fax:  604 806 9274
> >
> > ***CONFIDENTIALITY NOTICE***
> > This electronic message is intended only for the use of the addressee
> > and may contain information that is privileged and confidential.  Any
> > dissemination, distribution or copying of this communication by
> > unauthorized individuals is strictly prohibited. If you have received
> > this communication in error, please notify the sender immediately by
> > reply e-mail and delete the original and all copies from your system.
> >
> >
>
>
>
>
Received on Saturday, 14 July 2007 01:13:15 UTC

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