Hi Ray, all,

To clarify, this is *in addition to* the ability to just owl:sameAs the URI identifier directly with the resource?  And the use case is that there's *other* information that is desirable to express about the provenance of the identifier, such as the organization that minted it?
If so, it would be good to show those properties as well.

For example:

<http://ld.stanford.edu/books/1> a bf:Work ;
  owl:sameAs <urn:isbn:123456789X> ;
  bf:identifier [ a bf:IdentifierDescription ;
      bf:scheme <http://id.loc.gov/isbn> ;
      bf:value "123456789X" ;
      bf:assigner <bowker.com> ;
      bf:uriFormOfIdentifier "urn:isbn:123456789X" ]




On Mon, Aug 4, 2014 at 1:28 PM, Denenberg, Ray <[log in to unmask]> wrote:

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


a                                                                              bf:IdentifierDescriptor ;

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

                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


  <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!










Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305