Print

Print


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.

Jörg


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