Do LSIDs Need to Resolve? Joel Sachs

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 into a standard web browser, it will simply list all the triples stored at the address But if you put the same URI into a Linked Data browser, the browser doesn’t only list all triples served by Rather, it will list all triples it is aware of (i.e. that are in its cache) that are about the resource

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? 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 browsers 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?