In practice there are a number of systems for persistent identifiers, such as the Handle System, Purls, Uniform Resource Name (URN), Archival Resource Keys (ARK), and Extensible Resource Identifier (XRI). There is a good overview by Juha Hakala How do you best combine these identifiers with "cool" linked data URIs? Can you take these URI prefixes as canonical for the persistent identifiers systems mentioned above?:

 info:hdl/  or  info:doi/
 xri://  or any of  http(s)://xri.*/

At least Purl and XRI could made compatible with cool URIs, but for Purl you would need to hack the resolver at purl.org. My question is not about which system is better and whether to use other identifiers but HTTP-URIs at all, but about what to do if you already have these other identifiers and their infrastructure. You could create a HTTP proxy but Handle and Purl already have their resolver infrastructure. I'd be interested in solutions where people actually use a non-HTTP-URI-infrastructure system combined with a Linked Data environment. Can you avoid adding owl:sameAs to each of your resource identifiers?

asked 08 Mar '11, 14:38

Jakob's gravatar image

accept rate: 10%

I had a project where we had a dataset in a SPARQL store. It consisted entirely of tag: URIs. We used Pubby and its URI rewriting capability to put a linked data site in front of the endpoint. It rewrote the tag:domain.com,200X: part of each URI to http://otherdomain.com/mydataset/ and made those URIs dereferenceable.

permanent link

answered 08 Mar '11, 15:49

cygri's gravatar image

cygri ♦
accept rate: 34%

Thanks for the example. For tag: URIs you can simply create a proxy linked data site in front. But for established persistent identifier systems there already are proxies, such as http://purl.org, http://dx.doi.org, and http://hdl.handle.net/. Its also common practise to install your of link resolver, but I have not seen any combination with linked data yet.

(09 Mar '11, 10:47) Jakob Jakob's gravatar image

You can, for instance, relate each identifier by utilizing specific sub properties of dcterms:identifier, i.e., for each identifier type you have to create a separate sub property, e.g., ex:doi.

permanent link

answered 08 Mar '11, 14:53

zazi's gravatar image

accept rate: 13%

This may helps to display the identifier as literal string, but if there already is an URI form if the identifier this adds no information, so what's the benefit?

(09 Mar '11, 10:43) Jakob Jakob's gravatar image

The Virtuoso Sponger Middleware enables the development of Custom Resolvers for naming schemes (e.g., URNs) associated with protocols beyond HTTP, including DOI, OAI & LSID.

Virtuoso has an owl:sameAs inference rule, so you can have co-referents in Virtuoso that have URIs based on different schemes. When said context is enabled you end up with a union of all data that is accessible to SPARQL or exposable at an Address associated with any of the co-Referents entity names references (URI based Names). See owl:sameAs inference tutorial also.

permanent link

answered 09 Mar '11, 23:41

hwilliams's gravatar image

accept rate: 18%

Is 'DEFINE input:same-as "yes"' a standard construct or a Virtuoso extension? Can you point me to an example where Virtuoso is used in practice with a custom resolver for other kinds of persistent identifiers (DOI, Handle, Purl, ARK...)?

(10 Mar '11, 08:50) Jakob Jakob's gravatar image
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 08 Mar '11, 14:38

question was seen: 3,258 times

last updated: 09 Mar '11, 23:41