Do LSIDs Need to Resolve?

farmpaintlickInternet και Εφαρμογές Web

21 Οκτ 2013 (πριν από 4 χρόνια και 19 μέρες)

88 εμφανίσεις

Do LSIDs Need to Resolve?

Joel Sachs

jsachs@cs.umbc.edu

No


To review …


There are many flavours of Uniform Resource
Uniform Resource Identifier (URI).




One of the principles of Linked Data is that all
resources be identified by HTTP URIs. This way,
they will resolve in a browser.



But …


Linked Data is changing what it means for a URI to
resolve


Moving from a page
-
centric notion of resolution to
a resource
-
centric notion of resolution.


For example …


If you put
http://dbpedia.org/resource/Coffea

into a
standard web browser, it will simply list all the triples stored
at the address
http://dbpedia.org/page/Coffea
.





But if you put the same URI into a Linked Data browser,
the browser doesn’t only list all triples served by
http://dbpedia.org/data/Coffea
. Rather, it will list all triples
it is aware of (i.e. that are in its cache) that are about the
resource
http://dbpedia.org/resource/Coffea
.

In other words …




the URI resolves not to the address, but to all known
information about the resource.


What if dbpedia (the server) goes down?

http://dbpedia.org/resource/Coffea

will no longer resolve in
a standard web browser.


But, assuming that other servers have made assertions about
dbpedia:Coffea
, the URI
can

still "resolve" in a linked data
browser, in the sense described above.

How does this apply to Life Science
Identifiers (lsids)?




urn:lsid:ncbi.nlm.nih.gov:601077

LSIDs are URIs, so …


We can make assertions about them using rdf.




Therefore, they can resolve in rdf browsers, provided the
browser
s are aware of the assertions that have been made
about them.




And there are many services (Google, Swoogle, Sindice,
etc.) that can bring these assertions to the attention of the
Linked Data browser.

So just as Google makes everything
actionable …


So LSIDs can join the Linked Data cloud as is,
without having to be transformed into http URIs via
http lsid resolvers.



Not only this, but the inventor of the lsid doesn't even
need to implement a resolution protocol, since
standard http architecture (search engines, rdf
browsers) will take care of the resolution.

Advantages …


1. It eases the burden of creation.




Currently, to introduce an LSID, you must either



i) provide a mechanism for resolution (traditional);

ii) implement linked data
-

style content negotiation
(modern); or

iii) depend on the largesse of others to do i or ii for you

2. It eases the burden of curation


If your server disappears tomorrow, so will all your
LSIDs. But if we consider the LSID to be just a name,
instead of a name plus an address, then we can
continue talking about the names even after the
addresses no longer function.

3. It is more satisfying to my sensibilities


Currently, a linked data URL does double duty. It
serves as both the name of something and its
"official" address. Don’t you find this odd?

Conclusion


We may be able to allow LSIDs to continue to exist as names just the
way they are.


And the only guidance we’d need to provide is


i. Create names that look like:

lsid:YourOrganization:xyz


ii. Say things about them on web/semantic web pages.


iii. Ping Google and Swoogle to make sure that everyone knows about
those web pages.

Caveat


Linked data browsers don’t behave exactly as I
described them.


(But we can make them if we try.)

Wild idea …


or just dumb?