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
>> <http://example.org/persons/kcoyle> a bf:person;
>> bf:identifier [
>> bf:schema "VIAF";
>> bf:identifierValue "195531823";
>> bf:identifierValueURI <http://viaf.org/viaf/195531823>
>> ].

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 ... <http://example.org/persons/kcoyle> owl:sameAs
> <http://viaf.org/viaf/195531823> .

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):

<http://example.org/persons/kcoyle> a bf:person ;
   bf:identifier [
     a bf:Identifier ;
     bf:identifierAssigner "Simeon" ;
     bf:identifierValueURI <http://example.com/people/kc>
   ].

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]:

<http://example.org/persons/kcoyle> a bf:person ;
   bf:identifier [
     a bf:Identifier ;
     bf:identifierAssigner "Simeon" ;
     bf:identifierValue "http://example.com/people/kc"
   ].

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
duplication:

<http://example.org/persons/kcoyle> a bf:person ;
   owl:sameAs <http://example.com/people/kc> ;
   bf:identifier [
     a bf:Identifier ;
     bf:identifierAssigner "Simeon" ;
     bf:identifierValue "http://example.com/people/kc"
   ].

Fire away,
Simeon


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 ;-)

[1] http://bibframe.org/vocab/Identifier.html
[2] http://www.w3.org/TR/rdf-schema/#ch_reificationvocab
[3] http://bibframe.org/vocab/identifierValue.html
[4] http://www.w3.org/DesignIssues/Reify.html
[5] http://www.w3.org/2009/12/rdf-ws/papers/ws21