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