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 it.

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!

Rob