Simeon,

On Wed, Jul 23, 2014 at 3:36 PM, Simeon Warner <[log in to unmask]> wrote:
Having caught up on this very illuminating thread, I think Ray was onto
something when he clearly separated the URI and non-URI cases:

On Jul 16, 2014, at 5:39 PM, "Denenberg, Ray" <[log in to unmask]> wrote:
I think the advice is:
(1) don't use a URI to identify a bf:Identifier.  Treat it as a blank
node.
(2) Only a non-URI identifier (e.g. isbn) should be treated a
bf:Identifier.
Aside from discussions of how useful or not it is to have non-URI identifiers, it seems there is little debate that something like the bf:Identifer way of talking about non-URI identifier is fine.


To quote my position from the first email in the thread:

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.

:) 

If it's also important to capture assigners for URIs, then you would need to still use a bf:Identifier with a reified URI...


URI Identifier Use Case 2: "I want to describe the origins, provenance, etc. of a URI (in a similar way to other forms of identifier)". This use case is not supported by simple owl:sameAs suggestion. The problem is how to talk about URIs because in RDF they aren't first class citizens, they are simply ways to talk about resources. How can we associate the provenance properties that a bf:Identifier has with a URI without generating bad semantics? I think that a robust answer must use some kind of reification --- the way out of the "the first rule of identifier club is that you can't talk about identifiers" conundrum.

... but is that really in scope for BibFrame to try and capture? It's the _Bibliographic_ Framework, not a framework for describing the provenance of URIs, surely?

If it is, then use, certainly reification. And the easiest technique is to put it in a string, as you say:


But now, let's take a step back and look at the current bf spec with bf:identifierValue [3]:
<http://example.org/persons/kcoyle> a bf:person ;
  bf:identifier [
    a bf:Identifier ;
    bf:identifierAssigner "Simeon" ;
    bf:identifierValue "http://example.com/people/kc"
  ].


Is fine ... you're asserting something about the provenance of a URI-as-identifier, not the resource that the URI identifies.  But it seems like a very deep rabbit hole...

<http://linked-data.stanford.edu/titles/books/1234> a bf:Title ;
  bf:value "Lord of the Rings" ;
  bf:identifier [
    a bf:Identifier ;
    bf:assigner "Rob" ;
    bf:identifierValue "http://linked-data.stanford.edu/titles/books/1234"  ] . 

Really? Really?! :)

Rob 

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