Agreed performance is an issue, but the two queries aren't the same.

On Fri, Jul 18, 2014 at 1:45 PM, Ford, Kevin <[log in to unmask]> wrote:

> For example, changing bf:identifierValue to bf:value jumps out in this
> case.    So this query:
>  SELECT ?s { ?s bf:value “1234567890” }
> Will be considerably slower than
>  SELECT ?s { ?s bf:identifierValue “1234567890” }

Of course, there are additional aspects one might use to limit the query,
> providing they are known, such as the identifier scheme, and not all stores
> are created equal, but sometimes this is the query one wants to run.

I agree about performance, but disagree that there's a significant
difference between the second query above and:
   SELECT ?s { ?s a bf:Identifier ; bf:value "1234567890" }

The set of resources with bf:identifierValue is the set of instances of
bf:Identifier.  That's just what the first part of the query does. Then of
that set, some number have the identifierValue/value of "1234567890", which
is the second part of the query.  But that's exactly what the
identifierValue query will do as well, we're just being more explicit about

Or better:
   SELECT ?s { ?s a bf:SomeSchemeIdentifier ; bf:value "1234567890" }

>   Even this may not be the best example because there may be only one
> triple in the system with that particular Literal, but imagine performing a
> query using bf:scheme, which will could easily have 10,000,000 hits for
> “isbn” alone, not to mention 14,000,000 for LCC and another 14,000,000 for
> DDC.

To cross the streams, this is another good reason why URIs should be used
where and when ever possible, as the queries will be much much faster.

And to avoid a second email, +1 to Jörg's comment that software solutions
will continue to improve. Hardware will continue to improve. Non SPARQL
systems will also be used... libraries have searched for identifiers like
this for many, many years without a problem.  On the other hand, if SPARQL
is a critical requirement, we should also be talking about text search and
the nightmare that becomes!