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.  (I.e. a URI  should not be treated as a bf:Identifer.
> Thus the property bf:uri should be eliminated.)

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.

For the URI case I think the thread conflates two use cases that can't 
be supported in the same way:

URI Identifier Use Case 1: "I want to assert that another URI identifies 
the same resource and have this work well in LOD". In this case 
owl:sameAs is clearly the useful/practical way to implement and follows 
common LOD practice (as Rob suggests).

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.

I'll use an example from Thomas and Rob to think about these 2 use cases:

On 7/17/14 12:17 PM, Robert Sanderson wrote:
>Thomas Berger wrote:
>> Now consider
>> <> a bf:person;
>>   bf:identifier [
>>     bf:schema "VIAF";
>>     bf:identifierValue "195531823";
>>     bf:identifierValueURI <>
>>   ].

It seems that here the bf:identifierValueURI is a sleight of hand for 
bf:identifies (inverse of bf:identifier) and thus implies (though 
doesn't explicitly include):

> Or ... <> owl:sameAs
> <> .

The bf:identifierValueURI form is both somewhat circular and hard to 
compute on without bf-specific understanding. It thus doesn't serve use 
case 1 well.

One could argue that the bf:schema and bf:identifierValue properties are 
redundant in the example above (implied by the URI itself). However, I 
don't think that argument could be made for other predicates such as 
bf:identifierAssigner, bf:identifierStatus so let's imagine a slightly 
different example (following Thomas's form):

<> a bf:person ;
   bf:identifier [
     a bf:Identifier ;
     bf:identifierAssigner "Simeon" ;
     bf:identifierValueURI <>

where the bf:identifierAssigner is not redundant and cannot be expressed 
in the simple owl:sameAs form.

Does this form meet use case 2? I think it does because although the RDF 
spec does not include the notion of reification of a Resource, it 
follows the rdfs pattern that is blessed for the reification of a 
statement [2], where the correspondence is:

rdf:Statement class <-> bf:Identifier class
rdf:subject predicate <-> bf:identifierValueURI predicate

But now, let's take a step back and look at the current bf spec with 
bf:identifierValue [3]:

<> a bf:person ;
   bf:identifier [
     a bf:Identifier ;
     bf:identifierAssigner "Simeon" ;
     bf:identifierValue ""

I can feel the knee-jerk "yuck" to see a URI in quotes but this is 
actually a very clean reification of the identifier. None other than 
TimBL in 2004 suggested use of a literal form for a URI in reification 
[4] and included the notion of reification of URIs as "Symbols" (though 
the community has not gone that way). A benefit of this form over the 
bf:identifierValueURI form (or, say, reification of an owl:sameAs 
statement) is that the quoted value is immune to expansion or reduction 
of owl:sameAs equivalences in a processing/query/inference system. I 
think this form meets use case 2 well though it is terrible for use case 1.

It is ugly and I think I'm going to get some flak for even mentioning 
this... but I wonder whether to meet the two use cases of both useful 
LOD _and_ describing URI provenance then one needs to do both owl:sameAs 
and something like the current bf:identifierValue? Can you say data 

<> a bf:person ;
   owl:sameAs <> ;
   bf:identifier [
     a bf:Identifier ;
     bf:identifierAssigner "Simeon" ;
     bf:identifierValue ""

Fire away,

P.S. Then, of course, there is the question of how "same-as" an 
owl:sameAs really is [5], but we can leave that for another day ;-)