Hi Adrian:
Thank you! Your interpretation may be closer to the intended usage than my initial take. I'm going to examine this further and make some suggestions, but I might be missing something very obvious, and if so, I welcome enlightenment from the BIBFRAME community!
The supplementary instructions at
http://www.loc.gov/bibframe/docs/pdf/bf2-identifiers-march2017.pdf state "Along with the identifier value itself, the identifier type must be conveyed" and that where there is no specific BIBFRAME class for the identifier, and there is no external class for the identifier, a bf:source must be supplied. All three examples show an identifier with an rdf:value of a string literal, but without an example of a URI, it's unclear if the intention was for all identifier values to be string literals.
Rebecca Younes noted on this list back on 2016-06-22 in the (long!) "rdf:value" thread: "The range of rdf:value is rdfs:Resource, so the object can be any type of resource: a URI resource, a blank node, or a literal." In a linked data context, I think that forcing a URI
to be represented as a literal (with a blank node as a bonus), instead
of as the URI it is, is an anti-pattern.
However, even if we accept that the value of rdf:value can be a URI resource rather than a literal, we still need to specify the identifier type. We've already established that there is no existing BIBFRAME identifier class for URI. So that currently takes us to option #2 or #3 in the document.
Option #2 is using an external class for the identifier. RDF and RDF Schema don't seem to define a
class for URI/IRI, perhaps because URIs are so core to RDF / linked data that they just exist and are used directly to identify
things.
A popular external vocabulary that does specify a type of URI as a literal is
http://schema.org/URL. I say "as a literal" because it is a subclass of
http://schema.org/Text, but
schema.org tends to err on the side of being permissive to encourage structured markup of any kind. Indeed, some of the examples in the
schema.org documentation for schema:URL lead to generating either URIs or literals depending on which serialization (RDFa or JSON-LD) you choose.
If we're not comfortable with adopting
http://schema.org/URL or some other external class, then we're down to #3 -- basically what you suggested, plus a bf:source [ ] statement, with an uncontrolled string value identifying URI (oh the irony!):
A few suggestions coming out of this:
1. Given that the identifier type must be conveyed, and URI will
hopefully be a very common identifier type in the linked data
environment we're aiming for, BIBFRAME should either define a bf:URI
subclass of bf:Identifier OR document the recommendation of a common
external class (something like
http://schema.org/URL, although that might not be the best choice).
2. If BIBFRAME wants strings for identifiers, then per Simon Spero's recommendation in the same 2016-06-22 thread, consider declaring a pair of new properties that replace rdf:value and rdfs:label with more specific ranges -- Simon suggested bf:text and bf:res -- and replace throughout the examples/documentation. That will reduce ambiguity.
Best,
Dan
