This is funny and sad at the same time. 

I suggest that Bibframe predicates should not follow software that can not scale with the triples, instead, software implementers should follow the Bibframe model. If there are too many triples, an inverted index of a search engine might help. Please do not make fundamental model design choices like a vocabulary that shall last for the next 40 years dependent on the behavior of a software product that exists today. Tomorrow, software will change.


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

Dear Rob, all,


Thanks for this.   We here had a quick chat about this list this morning. 


One of the reasons for the predicate proliferation was to address query performance.


In our experience, when we’ve loaded gobs of triples into various stores, we often experienced much improved query performance when the predicate is itself fairly distinctive.  When querying for a value of a “common” predicate, then query performance declines.


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” }


Because the first query has to potentially interrogate so many more triples.