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.

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

So, my question: do you, or anyone, have thoughts on this?


From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Robert Sanderson
Sent: Wednesday, July 16, 2014 7:27 PM
To: [log in to unmask]
Subject: [BIBFRAME] Deproliferation of Predicates

As promised, an initial list of predicates that could be collapsed without affecting the model at all (as far as I can tell)

authorityAssigner --> assigner
authoritySource --> source
categorySource --> source
categoryType --> type
categoryValue --> value
classificationAssigner--> assigner
classificationDesignation --> designation
classificationEdition --> edition
classificationItem --> item
classificationNumber --> number
classificationScheme --> scheme
classificationSpanEnd --> spanEnd
classificationStatus --> status
classificationTable --> table
classificationTableSeq --> tableSeq
eventAgent --> agent
eventPlace --> place
eventDate --> date
identifierAssigner --> assigner
identifierQualifier --> qualifier
identifierScheme --> scheme
identifierStatus --> status
identifierValue --> value
audienceAssigner --> assigner
providerName --> name
providerPlace --> place
providerRole --> role
providerDate --> date
relatorRole --> role
titleAttribute --> attribute
titleQualifier --> qualifier
titleSource --> source
titleType --> type
titleValue --> value
titleVariationDate --> date

There are other classes of predicate that could also be changed, which I'll try to discuss in a separate mail.


Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305