Hello,

Comments in-line.

On 5.8.2014 3:26, Karen Coyle wrote:
[log in to unmask]" type="cite"> Hi, Ray. Can we assume that this solution is being offered for all of the identifiers in the id.loc.gov vocabulary? [1]

[log in to unmask]" type="cite">
If so, I think it would be good to see a few more examples. There are identifiers with defined URNs (like ISBN), some with no URN, and some with http IRIs.

Registering a URN namespace for an identifier is a simple process, especially because IETF does not require that URNs must be actionable (resolvable).

On the other hand, I have occasionally seen example URNs using namespace IDs which have not been formally registered. Although it is likely that NID "LCCN" will be given to Library of Congress Control Number if and when namespace registration is made, examples like urn:lccn:<lccn> should be avoided until the NID registration for LCCN has been completed.  

[log in to unmask]" type="cite">
Here's a stab at two different examples, mostly copied from your example. The first has no URN, the second has an http IRI:

#1
MARC:
027 ##$aFYHU/PF/2--80/12+MAGN

BIBFRAME:

<http://example.com/xyz/book1> a bf:Instance ;

      bf:identifier   <http://example.com/xyz/identifiers/book1/identifier1> .

  <http://example.com/xyz/identifiers/book1/identifier1>

a                                                                              bf:IdentifierDescriptor ;

                bf:identifierScheme                                       <http://id.loc.gov/vocabulary/identifiers/strn> ;

                bf:identifierValue                                            "FYHU/PF/2--80/12+MAGN" .


#2
LCCN permalink: http://lccn.loc.gov/65026236


<http://example.com/xyz/book1> a bf:Instance ;

      bf:identifier   <http://example.com/xyz/identifiers/book1/identifier1> .

  <http://example.com/xyz/identifiers/book1/identifier1>

a                                                                              bf:IdentifierDescriptor ;

                bf:identifierScheme                                       <http://id.loc.gov/vocabulary/identifiers/lccn> ;

                bf:identifierValue                                            "http://lccn.loc.gov/65026236" ; //or 010 format?

           bf:uriFormOfIdentifier                   “http://lccn.loc.gov/65026236”.



Is this how you think these identifiers would be represented?

IMO it would be more logical to have bf:identifierValue "65026236" since that is the LCCN. Actionable version of the identifier (LCCN permalink) belongs to bf:uriFormOfIdentifier (or bf:urlFormOfIdentifier; see below).


[log in to unmask]" type="cite">
Thanks,
kc
[1] http://id.loc.gov/vocabulary/identifiers
 
On 8/4/14, 1:28 PM, Denenberg, Ray wrote:
[log in to unmask]" type="cite">

Discussion about identifiers has been interesting and valuable, and here at LC we are trying to capture the essence of the discussion. As part of that process,  we have a proposal for consideration, for a slightly different modeling of bf:Identifier.

 

Let’s say I have an identifier – an isbn – for an Instance.   I propose to represent it like this:

 

<http://example.com/xyz/book1> a bf:Instance ;

      bf:identifier   <http://example.com/xyz/identifiers/book1/identifier1> .

  <http://example.com/xyz/identifiers/book1/identifier1>

a                                                                              bf:IdentifierDescriptor ;

                bf:identifierScheme                                       <http://id.loc.gov/vocabulary/identifiers/isbn> ;

                bf:identifierValue                                            "9780099483793" ;

                bf:uriFormOfIdentifier                                  “urn:isbn: 9780099483793”.


This encoding has two identifiers (ISBN and URN) under single bf:identifierScheme. There is no place for actionable (URL) versions of the URN. bf:urlFormOfIdentifier could be used for this purpose. uriFormOfIdentifier is not an ideal name since according to URI Generic Syntax (RFC 3986) URNs are also URIs.

In this encoding:

a                                                                              bf:IdentifierDescriptor ;

                bf:identifierScheme                                       <http://id.loc.gov/vocabulary/identifiers/isbn> ;

                    bf:identifierValue                                           "9789515100535" ;

                bf:identifierScheme                                       <http://id.loc.gov/vocabulary/identifiers/urn> ; 
                     bf:identifierValue                                         “urn:isbn: 9789515100535”;

                     bf:urlFormOfIdentifier                                  “http://urn.fi/URN:ISBN:978-951-51-0053-5”.


each identifier is specified by its own identifierScheme. Actionable forms of the URN (there can be more than one since there can be 1-n resolvers) are also clearly indicated.

Once the global URN resolver discovery system is established, URNs should no longer need bf:urlFormOfIdentifier.  IMO that would be an ideal situation since URLs are volatile and we should try to avoid using them in bibliographic records (if we rely on URNs and other PIDs instead, URLs can be "hidden" in resolvers in which the URN - URL linking can be centrally managed). Alas, there are no immediate plans to implement global URN resolver discovery system and for the time being it is necessary to attach the URL of the resolver to URNs when they are expressed in actionable form.

The encoding above can be extended to e.g.:

a                                                                              bf:IdentifierDescriptor ;

                bf:identifierScheme                                       <http://id.loc.gov/vocabulary/identifiers/isbn> ;

                    bf:identifierValue                                            "9789515100535" ;

                bf:identifierScheme                                       <http://id.loc.gov/vocabulary/identifiers/urn> ; 
                     bf:identifierValue                                           “urn:isbn: 9789515100535”;

                     bf:urlFormOfIdentifier                                  “http://urn.fi/URN:ISBN:978-951-51-0053-5”;

                bf:identifierScheme                        <http://id.loc.gov/vocabulary/identifiers/doi> ; 

                     bf:identifierValue                                            “10.978.95151/00535”.

                     bf:urlFormOfIdentifier                                   “http://dx.doi.org/10.97895151/00535”.


Even if a book has just one ISBN, it may have several PIDs based on the ISBN. These PIDs may provide different resolution services and facilitate links to different systems (Handle to an institutional repository, URN to the national library's legal deposit system, DOI to the publisher's book shop, etc.).

In the future it will (most likely) be possible to use URI fragments and queries with URNs. ARKs, Handles and DOIs are already using URI query for various purposes. This should be taken into account in encoding, although it is not certain that URNs and other PIDs with fragments and/or queries will be used in cataloguing.

One of the issues we've been talking about in the IETF URNBIS working group is whether URI query and fragment have a role in identification. According to URI Generic Syntax they do, but that leads to problems which we try to avoid in URN syntax by saying that URI fragment and query are not part of the URN namespace specific string and therefore do not identify anything.  

If we follow the letter of RFC 3986, it  would be OK to use encoding

                bf:identifierScheme                                       <http://id.loc.gov/vocabulary/identifiers/urn> ; 
                     bf:identifierValue                                           “urn:isbn: 9789515100535”;

                bf:identifierValue                             “urn:isbn: 9789515100535#chapter2”.

to identify a book and its second chapter, and

                bf:identifierScheme                                       <http://id.loc.gov/vocabulary/identifiers/urn> ; 
                     bf:identifierValue                                           “urn:isbn: 9789515100535”;

                bf:identifierValue                             “urn:isbn: 9789515100535?s=URC”.

could be used to identify a book and a bibliographic record describing the book. I may not be the only person who sees all sorts of problems with this approach.

However, if URI fragment and query do not identify anything, encoding can be changed into:

              bf:identifierValue                                           “urn:isbn: 9789515100535”;

                     bf:urlFormOfIdentifier                                  “http://urn.fi/URN:ISBN:978-951-51-0053-5”;

                bf:urlFormOfIdentifier                      “http://urn.fi/URN:ISBN:978-951-51-0053-5#chapter2”.

in which we have just one identifier (URN), but two URLs which provide different functionalities.

Fragments are not sent to HTTP servers (or URN resolvers) by web browsers and other clients; they use fragments to go to the indicated location within the identified document once it has been fetched (provided that the mime type of the document supports fragment usage). 

URN + query could be encoded in the same way. Unlike fragment, query is sent to the resolver, which converts it into whatever is appropriate. For instance, if the user wants metadata about the resource, URN + query can be converted into an SRU search with the identifier as the search term. 

Juha
 
[log in to unmask]" type="cite">
[log in to unmask]" type="cite">

 

Summary:

·         bf:Identifier becomes bf:IdentifierDescriptor.

·         bf:identifierScheme  becomes a resource (not a literal).

·         bf:uriFormOfIdentifier  is introduced.

 

A couple notes:

·         Note the use of property bf:identifier, not bf:isbn. Included as part of this proposal is to abolish all of the bf:indentifier subproperties – bf:isbn, bf:issn, etc. (as we have already agreed to abolish bf:uri).

·         Note also that this representation violates the tentative agreement that we would always represent a bf:Identifier (changed to bf:IdentifierDescriptor in this proposal)  as a blank node.  I think the reasoning behind that no longer applies, with this proposal.

 

Discussion

 

bf:Identifier becomes bf:IdentifierDescriptor

Part of the confusion has been that people see

 

  <http://example.com/xyz/identifiers/book1/identifier1>   a                     bf:Identifier ;

 

and conclude that http://example.com/xyz/identifiers/book1/identifier1 is an identifier. And justifiably so, but they get confused:

·         Some mistakenly think that it is an identifier for the resource (book1) when really it is an RDF identifier, for the resource bf:Identifier.

·         Some say “it’s an identifier for an identifier  (i.e. the bf:Identifier) which is an un-necessary layer of indirection”.

 

but if you portray bf:Identifier as an “identifier description” rather than an identifier, then there is less confusion, and the way to do that would be to change its name from bf:Identifier to bf:IdentifierDescriptor.

 

 

bf:identifierScheme  becomes a resource (not a literal)

Thomas Berger proposed this in one of his  messages, and it seemed well-reasoned.

 

 

bf:uriFormOfIdentifier  introduced

In the debate about what form the identifier should take - string or URI --  and if URI what does that imply (must it resolve?) – I believe (correct me if I’m wrong) the consensus is to  supply:

(1)    the raw string identifier,

(2)    the scheme that it is supplied  in,  and

(3)    what it looks like when turned into a URI (if it can be turned into a URI) – supplied as a string, not a resource.

And the user can choose which one to use, the combination raw string plus scheme, or the URI.   We don’t say that this URI is an identifier for the resource, and we don’t say it isn’t; we simply say, here is the URI form for this identifier.

 

In the example above the URI is a URN, however any URI scheme could apply, urn:, info:, http:, etc. 

 

Yes, even http:      ……

 

In one of Rob’s messages he gave the example:

 

bf:identifierValue "http://linked-data.stanford.edu/titles/books/1234"  

 

Which I tried to make sense of (which in turn led to the above proposal) and I asked, can you separate that into an identifier  scheme and a value within that scheme and Rob’s response was  ‘The scheme is http://linked-data.stanford.edu/titles/books/ and the identifier is “1234” ‘

 

So for Rob’s example:

                bf:identifierScheme                                       <http://linked-data.stanford.edu/titles/books/> ;

                bf:identifierValue                                            "1234" ;

                bf:uriFormOfIdentifier                                  “http://linked-data.stanford.edu/titles/books/1234”.

 

So, there is no real reason to exclude http URIs when used in this manner.

 

 

 

Comments welcome!

 

Ray

 

 

 

 

 

 

 


-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet


-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University
 Tel. +358 9 191 44293
 Mobile +358 50 3827678