What is the appropriate syntax to refine EPUB identifiers in order to declare that they follow the scheme of a URI?
In EPUB 2, `identifier` elements could be refined with a `scheme` attribute. The EPUB 2 spec was lax on [what is a valid scheme](http://www.idpf.org/epub/20/spec/OPF_2.0.1_draft.htm#Section2.2.10), and so Project Gutemberg uses URIs as identifiers for their EPUB 2 files.
<dc:identifier id="id" opf:scheme="URI">http://www.gutenberg.org/ebooks/46426</dc:identifier>
In EPUB 3, instead, identifiers are refined with a `meta` element, so it is that element the one carrying the `scheme` attribute.
<dc:identifier id="pub-id">urn:doi:10.1016/j.iheduc.2008.03.001</dc:identifier>
<meta refines="#pub-id" property="identifier-type" scheme="onix:codelist5">06</meta>
The EPUB 3 spec, though, is more specific about [what can constitute a scheme](http://www.idpf.org/epub/301/spec/epub-publications.html#attrdef-meta-sc...) stating that it's value must be a `property`. The spec defines "[The property Data Type](http://www.idpf.org/epub/301/spec/epub-publications.html#sec-property-da...)" as "a compact means of expressing an IRI", and explains how to create an IRI out of it. Ultimately, it declares that "The resulting IRI must be valid to [RFC3987]".
So, how does one map Project Gutemberg's way of using an URI as identifiers to the EPUB 3 syntax? ONIX Code List 5 does not provide an value associated to URI. Of course there is value `01` for "proprietary" but I was looking for a more explicit way, one to declare, specifically, that the identifier is an URI.
Subscribe to IDPF feed
Follow IDPF
Actually, there's no requirement that you use a controlled list value or define a scheme. If you do use a value from a controlled list, then you should identify where it comes from, but even that isn't a hard requirement (emphasis mine):
So there's nothing technically wrong with porting an EPUB 2 "URI" value to:
That said, the LOC has a list of identifier types now that includes "uri". If I remember right, this list was under development, or a future addition, during the original 3.0 revision. But long story short, you could do:
(The "marc:" prefix is maybe a bit too specific for my taste here, but the CURIE resolves to the LOC identifier vocabulary. The original two LOC vocab use cases were for MARC lists, hence the prefix name.)
Anyway, hope this helps.