Hi, Ray. Can we assume that this solution is being offered for all of the identifiers in the vocabulary? [1]

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.

Here's a stab at two different examples, mostly copied from your example. The first has no URN, the second has an http IRI:

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


<> a bf:Instance ;

      bf:identifier   <> .


a                                                                              bf:IdentifierDescriptor ;

                bf:identifierScheme                                       <> ;

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

LCCN permalink:

<> a bf:Instance ;

      bf:identifier   <> .


a                                                                              bf:IdentifierDescriptor ;

                bf:identifierScheme                                       <> ;

                bf:identifierValue                                            "" ; //or 010 format?

           bf:uriFormOfIdentifier                   “”.

Is this how you think these identifiers would be represented?

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:


<> a bf:Instance ;

      bf:identifier   <> .


a                                                                              bf:IdentifierDescriptor ;

                bf:identifierScheme                                       <> ;

                bf:identifierValue                                            "9780099483793" ;

                bf:uriFormOfIdentifier                                  “urn:isbn: 9780099483793”.



·         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.




bf:Identifier becomes bf:IdentifierDescriptor

Part of the confusion has been that people see


  <>   a                     bf:Identifier ;


and conclude that 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 ""  


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 and the identifier is “1234” ‘


So for Rob’s example:

                bf:identifierScheme                                       <> ;

                bf:identifierValue                                            "1234" ;

                bf:uriFormOfIdentifier                                  “”.


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




Comments welcome!










Karen Coyle
[log in to unmask]
m: 1-510-435-8234
skype: kcoylenet