-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I very much object to crafting new non-http URI schemes, please let me
elaborate:
Am 18.07.2014 22:17, schrieb Denenberg, Ray:
[...]
> While there are no subspaces common to:
>
> ‘info:’
http://info-uri.info/registry/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc) and
>
> ‘urn:’ (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml)
>
> There is quite a body of literature that claims that this or that
> identifier, in the ‘info’ table, but not in the ‘urn’ table, is expressible as a
> URN. These include sici, doi, and hdl, and perhaps others. I am assuming that
> the rule here would be to express these as ‘info:’ URIs, and never as URNs.
>
>
>
> No URI form
>
> I am hoping that there is unanimous consensus that an identifier whose
> scheme is not listed in the URN registry should never be expressed as a URN.
Historically, "URN" (uniform resource *name*) was a concept constrasting to
"URL" (uniform resource *locator*). For instance the OAI-identifier
specification <
http://www.openarchives.org/OAI/2.0/guidelines-oai-identifier.htm > (dated 2002,
document last revised 2006) has to be interpreted from that background:
"oai-identifiers are Uniform Resource Names (URNs) in the sense of RFC1737; they
are resource identifiers and not resource locators (URLs)."
% --
Current usage of "URN" however is based on RFC 2141, i.e. URIs within the
"urn:" prefix scheme, and RFC261 outlining registration and namespace
procedures (superseded by RFC3406).
Accordingly, IANA maintains two lists of prefixes in the sense of a registry:
1. Uniform Resource Identifier (URI) Schemes
(< http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml >,
since long almost completely unrelated to the "Service Name and Transport
Protocol Port Number Registry") grouped in
a) Permanent URI schemes like "gopher", "info", "http", "mailto", "z39.50r"
and "urn"
b) Provisional URI Schemes like "cvs", "secondlife", "svn", "webcal"
c) Historical URI schmees like "fax", "wais", "z39.50"
"urn" stands out here since it is the only prefix whose namespace is
also administered as an IANA registry:
2. Uniform Resource Names (URN) Namespaces
(< http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml >)
lists "Formal URN namespaces" /within/ the urn: prefix system like
"urn:isbn", "urn:issn", "urn:nbn", or "urn:ietf", "urn:iso", and probably
a couple more of the schemes listed there are highly relevant to us.
Many of "our" common schemes "ark", "hdl", "oai" or "doi" are not mentioned in
any of the two registries. Therefore the "info" registry remains important,
listing ( <
http://info-uri.info/registry/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc >):
info:ark/
info:doi/
info:hdl/
info:sici/
(and also some "common" database identifiers like "lc", "lccn", "oclcnum",
"bnf" ...)
still no "oai". However the "info:ofi" scheme for the OpenURL framework
allows to map *any* syntactically correct (but otherwise privately crafted)
URI into the IANA uri delegation scheme by prefixing it with
"info:ofi/nam:info:" ;-)
The OAI identifier standard proposes "oai:" URIs as elegant means to
transform DNS based namespace prefixing into URNs (as they call them,
we'd say URIs). Although there is no internet police preventing any
community from using convenience URI schemes not registered with IANA
these IMHO should be generally avoided for Bibframe purposes.
% --
In 2010 the info registry officially declared itself closed for the
registration of new schemes, cf. the "Notice" < http://info-uri.info/ >.
The argument was/is, that current Linked Data activities stress the utility
of web actionable (dereferenciable) URIs and the http: scheme together with
DNS provided namespace delegation provides a much more flexible and
lightweight mechanism than centralized registries of URI schemes and
sub-schemes, especially since the usually do not have resolution
mechanisms and even if they have the standard tools (browsers and so
on) do not know about them.
And indeed we see web friendly, official, canonical and persistent
identifiers emerge, like
http://catalogue.bnf.fr/ark:/12148/cb12284219c
http://www.idref.fr/03167142X/id
http://id.loc.gov/authorities/names/n82141174
http://lccn.loc.gov/n82141174
http://d-nb.info/gnd/117712582
(of which only the last is declared as "the official URI in Linked Data
sense" of the resource by the maintaining agency. The others are mere
"common convenience wrappers" for the string identification numbers
established by broad usage within several communities.
% --
Although there are "good" URIs (persistently dereferenciable) but not
better or "best" ones. Whoever is making statements about a resource
does so by assigning an URI to it and formulating his assertions
with that URI in subject position. Our previous discussion has shown
that nothing is gained by recommending to always use private URIs
(within a namespace controlled by the agent formulating the statements)
but it likewise has shown that there is no univerally canonical URI
all statements could (or should) converge to. [<
https://en.wikipedia.org/wiki/Uniform_resource_identifier#History > reports that
the "U" in URI
stood for "Universal" in RFC1738 (actually RFC1630 used as reference there)
and was changed to "Uniform" in RFC 2396]
Our traditional identifiers however usually make claims for universality
(and sadly lack uniformity as we have seen), at least for the community
they are created for.
The GND number "117712582" as expressed in http://d-nb.info/gnd/117712582
is /published/ as an identifier together with the promise of a
major institution to reserve this number (and URI) eternally to
the resource currently described by the content you can fetch by
resolving the URL or looking up the number in the Web database.
Second and third parties refering to these numbers and/or URIs /implicitly/
claim identity of their respective resources, regardless wether they
use the published URI syntactically as subject URI of their statements
or a privately crafted.
bf:identifiers provide a mechanism to model this usage even in case
of string-only identifiers (or /only/ in this case), but admittedly
they introduce a degree of indirection one would like to avoid.
However
< http://d-nb.info/gnd/117712582 > bf:type bf:person.
does not express the fact that this person is known to the GND
authority file and has a certain identifier there.
I have to combine it with the statements at
< http://d-nb.info/117712582/about/rdf >, namely
< http://d-nb.info/gnd/117712582 > gndo:gndIdentifier "117712582".
But for that I need deeper knowledge of the gndo vocablulary typically
beyond my average reasoning capabilities (gndo:gndIdentifier serves
the same purpose as bf:identifierValue only the identifierScheme
is implicit).
The more practical problem however is the lack of uniformity in
real world identifiers: "n82141174" is a semi-official variant of
the "real" identifier "n 82141174 " as noted in Field 010$a of
< http://id.loc.gov/authorities/names/n82141174.marcxml.xml >.
Thus I too see the need for providing prospective bibframe users
with guidance when it comes to canonicalization of identifiers
occuring in common identification systems.
However I would propose to do this *not* by means of the URN or info
URI schemes, but rather by a space of http URIs within some
"bibframe" namespace. With that I could state:
<http://d-nb.info/gnd/117712582> bf:type bf:person;
bf:identifier <http://bibframe.org/registry/GND/117712582>.
and resolving <http://bibframe.org/registry/GND/117712582>
could provide me with additional statements like
<http://bibframe.org/registry/GND/117712582> a bf:Identifier;
bf:identifierRegisteredScheme <http://bibframe.org/registry/GND>
bf:identifierValue "117712582";
bf:commonURI <http://d-nb.info/gnd/117712582>.
>
and <http://bibframe.org/registry/GND> would be a "registration"
document describing the "GND" authority file and give hints about
common forms of identifiers, their usage and especially what
forms of URIs or URLs using these identifiers are commonly
known (in the GND example there is not much to tell but to
report the fact that these http-URIs actually already are intended
to serve all purposes and demands in linked data contexts).
NOT resolving <http://bibframe.org/registry/GND/117712582> (or
not even making the correponding statement) would still have
the advantage of <http://d-nb.info/gnd/117712582> being a
common way of denoting the resouce and give a high probability
that my statements can "coincidentally" be merged with statements
from other parties.
In the /absence/ of any community practice for crafting URLs or
URNs from identifiers (which usually evolves rather straightforward
as soon there are resolvable URLs related to the numbers)
the hypothetical bibframe registry could provide a second
namespace as kind of cristallization point for URIs:
<http://bibframe.org/registry/ISIL> would be a "registration"
document describing "ISIL", give hints about common forms
of identifiers and their usage /and/ it would document that
a prefix "http://bibframe.org/aux/ISIL/" has been reserved
for crafting "good" URIs.
[German wikipedia states that the ISIL system has applied for
registration within the info URI registry but considering that the
registry is closed I don't see that ever happen. Also ISILs are
defined by ISO 15511 but to my knowledge this does not imply that
a registry for that standard automatically can extend the official
urn:iso space with its identifers.]
Therefore I am encouraged to formulate:
<http://bibframe.org/aux/ISIL/DE-Bo413> bf:type bf:Agent
and have advantages from that alone. Optionally I can amend this
by
bf:identifier <http://bibframe.org/registry/ISIL/DE-Bo413>
which would provide me with additional statements about that
"DE-Bo413" /is/ an ISIL, where to find data associated with
it in the ISIL system and so on.
Note that the registry and the aux namespace would never be
implemented as real RDF stores, they are (for each of the
individual registered schemes) mere "resolvers", providing
programmatically derived reformulations and transformations
of identifiers according to the facts and knowledge about
those kinds of identifiers collected in the registration
process and expressed in the "registration document" mentioned
above.
viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iJwEAQECAAYFAlPKhKEACgkQYhMlmJ6W47MXxwQAm4ujXh2JTyu3CURWDLl2eDQ9
TK9+blwZ2rGgfuXgVntyxUp+UPGk8iOwi5/VSHvLMYNvEuLb2ARMWyVlcvX0Nig/
yjsuZYCJxR88PmZfMnhztTS0xGX4p66ayqjBdQ4lf5Rr+WrjWQv6fBpI8lKkhvC4
uBHBfzcoMQKp3IhDTSg=
=RL3s
-----END PGP SIGNATURE-----
