* Identifiers
We do believe that identifiers in BIBFRAME could benefit from more thinking. As such, we feel that Rob’s section on identifiers may be trying to grapple with several different issues, all of which are about identifiers but each of which should be treated separately. These issues are likely legitimate, but we need to sort them out.

We do want to note, bf:identifierValue expects a string literal, and Rob’s examples appear to treat it as a resource identifier.  This is a fairly fundamental misinterpretation that needs to be cleared up before we can begin to sort out the other issues.

This wasn't my interpretation. The documentation is very good about when a literal or a resource is expected as the range of a predicate, kudos on that!

Let me start by saying I completely understand and agree with the existence of bf:Identifier.  It is important to be able to capture *non-URI* identifiers for resources, especially in such a way as to record qualifiers, assigners and schemes/namespaces that they might fit into.

* Point 1: Identifier Unnecessary for URIs

It's when the identifier is a URI that things become problematic.  If there is a resource that has an identifier which is a URI, then in RDF that URI is the identifier for the resource.

Thus:
  _:bnode1 a bf:Instance ;
     bf:uri _:bnode2 .
  _:bnode2 a bf:Identifier ;
     bf:identifierValue "http://www.example.com/books/book1" .

Is really saying, at least to me:
  <http://www.example.com/books/book1> a bf:Instance .

The first reads as: "There is a resource without an identifier, an Instance, and it has an identifier that's a URI." Clearly, this is syntactically possible to say, but is self-contradictory.

Or am I mistaken? If I am, then I think there needs to be some very thorough documentation about the difference between the Bibframe notion of an identifier and the RDF/Linked Data notion of an identifier.

* Point 2:  Identifier Must be a Blank Node

The key point here is that bf:Identifier must always be a blank node.  Why am I saying this?

If the bf:Identifier gets given its own identifier, then there are some very strange semantics going on. Consider the following:

  _:LotR a bf:Instance ;

      bf:uri _:id .

  _:id a bf:Identifier ;

      bf:identifierValue "some string identifier here" .

No problem, right? There's an Instance which has a string associated with it, which identifies the Instance. Right! All is good.

Now consider:

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

      bf:identifierValue "some string identifier here" .

Now it becomes very odd. This asserts that there is some resource, (identifiers/book1) which has an identifierValue. But it's not really that resource's identifier, it's the Instance's identifierValue that we want to assert other information about (like the assigner, qualifier, etc)

It would be solved by being clear that bf:Identifier is only to be used for identifiers of the resource that are not URIs, AND that the construction must be a blank node.

* Point 3:  Identifier Collision for URIs

In the situation where there's a uri associated with an Instance, such as:

  _:bnode1 a bf:Instance ;
     bf:uri _:bnode2 .
  _:bnode2 a bf:Identifier ;
     bf:identifierValue "http://www.example.com/books/book1" .

It seems like the Identifier should be identified by the URI <http://www.example.com/books/book1>.  If there's something which that URI identifies, then how can it not be itself?

Thus we get:

  _:bnode1 a bf:Instance ;
     bf:uri <http://www.example.com/books/book1> .
  <http://www.example.com/books/book1> a bf:Identifier ;
     bf:identifierValue "http://www.example.com/books/book1" .

Which seems redundant but not terrible.  However, if we know the URI that identifies the instance, we should use that URI instead of a blank node. Yes?

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

     bf:uri <http://www.example.com/books/book1> .
  <http://www.example.com/books/book1> a bf:Identifier ;
     bf:identifierValue "http://www.example.com/books/book1" 

Which is actually:

Now we have a mess! :(

The solution (as above) is just to use bf:Identifier, always as a blank node, for only identifiers that are not themselves URIs.

An example in the documentation of when this isn't the case is in bf:uri (  http://bibframe.org/vocab/uri.html ) where there is a real resource as the object of the bf:uri predicate.

The example asserts, via the inference from the range, that:

  <http://lcweb2.loc.gov/pp/cphquery.html> a bf:Identifier .

And thus that it could have properties like identifierQualifier, identifierAssigner and so forth.  Maybe that's the intent, but it doesn't really seem that way?

Thanks for thinking about these, and also helping me to think about the separate points :)