On 7/22/14, 1:26 PM, Trail, Nate wrote:
[log in to unmask]" type="cite">


You wrote:


However, even better given the query optimization scenario would be:

    _:x bf:classification [ a bf:NlmClassification ; value "123" ]



Haven’t you gone here from deproliferating properties to proliferating classes?  If we did this, wouldn’t we also have to have these classes:




and you’d still probably need the generic bf:Classification and a way to say what scheme it represents, as we develop or accept new mechanisms to organize new types of material that don’t rise yet to the level of having their own class?

Nate, et al.

I note that in the BF vocabulary [1] in the " Very general related work or instance relationship information," there are a number of properties for different classifications schemes, similar to the examples above, but a single property "subject." Yet subject headings can be from as diverse schemes as classifications can. Aren't these analogous?

I wonder if there is an implicit assumption that subject schemes will be expressed in SKOS/RDF and therefore will be unambiguous:

x bf:subject <>
y bf:subject <>

But that classification schemes (which are also subject schemes, but have some different functionality in Western libraries) will continue to be presented as strings?

x bf:Nlm:classification "QZ 200 A293s 2010" [2]

Otherwise, wouldn't this be consistent with the subject property treatment?:

z bf:classification <>

[2] That NLM classification in MARC has two subfields with different semantics:
    $a QZ 200 $b A293s 2010
$a being the class number and $b the book number. This same situation exists, of course, in LC classification. That is another complication that we may wish to set aside for a future conversation.

[log in to unmask]" type="cite">





Nate Trail


LA308, Mail Stop 4402

Library of Congress

Washington DC 20540




From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Robert Sanderson
Sent: Tuesday, July 22, 2014 12:57 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Deproliferation of Predicates



To expand on my URI point...


Instead of scheme and similar categorization-by-string properties, classes and subclasses would be much more effective and understandable.


For example, to use a different but parallel case:


Currently we have:

    _:x bf:classificationNlm [ a bf:Classification ; bf:classificationValue "123" ; bf:classificationScheme "NLM" ]


This could easily be:

    _:x bf:classification [ a bf:Classification ; bf:value "123" ; bf:scheme "NLM" ]


Via the currently suggested deproliferation of predicates.


However, even better given the query optimization scenario would be:

    _:x bf:classification [ a bf:NlmClassification ; value "123" ]


And the same for Identifier subclasses.



This also avoids the problem of:

    _:x bf:classificationNlm [ a bf:Classification ; bf:classificationValue "123" ; bf:classificationScheme "SomethingElse" ]


Is it NLM by believing the predicate, or is it SomethingElse by believing the resource.  Yes, "don't do that then"... but ... "don't allow that then" would be even better, surely?







On Fri, Jul 18, 2014 at 2:44 PM, Cole, Timothy W <[log in to unmask]> wrote:

Agreeing with Jörg in a slightly more long-winded way:

Creating additional predicates solely to improve query system performance seems a slippery slope -- akin to de-normalizing your relational db schema to make your SQL queries simpler. Everybody has done it, but if the project goes on long enough you usually wish you hadn't. Query engines get better and optimization / query anticipation strategies evolve. Predicates once declared are hard to deprecate.

On the other hand, if we had no sub-properties (and no sub-classes) we'd just have RDF by itself, and that would not be enough. Domain-specific properties and classes are essential ways we instantiate shared understandings and agreements.

So I think the goal should be to justify the granularity based on the inflections and differences in meaning, not based on query performance. To me the distinction between authorityAssigner, classificationAssigner, and audienceAssigner seems weak. Do these distinctions reflect real specializations? Or did we get carried away? Certainly it's hard to imagine that the ranges of these predicates are or will become meaningfully different classes.

I am a little more sympathetic to your bf:xxxValue differentiation example. Seems there could be a distinction made in ranges.  But unless we are specific about differentiating ranges of these predicates, it's hard to justify them. And I don't think falling back on what are likely to be transient query performance issues is good enough.

-Tim Cole
University of Illinois at UC
From: Bibliographic Framework Transition Initiative Forum [[log in to unmask]] on behalf of [log in to unmask] [[log in to unmask]]
Sent: Friday, July 18, 2014 16:11
To: [log in to unmask]
Subject: Re: [BIBFRAME] Deproliferation of Predicates

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]<mailto:[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.



Rob Sanderson

Technology Collaboration Facilitator

Digital Library Systems and Services

Stanford, CA 94305

Karen Coyle
[log in to unmask]
m: 1-510-435-8234
skype: kcoylenet