Print

Print


On 7/22/14, 1:26 PM, Trail, Nate wrote:
>
> Rob,
>
> 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:
>
> bf:LCCClassfication
>
> bf:UDCClassification
>
> bf:DDCClassification
>
> 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 <http://id.loc.gov/authorities/subjects/sh85038796>

y bf:subject <http://vocab.getty.edu/tgn/7001393>


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 200A293s 2010" [2]


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

z bf:classification <http://dewey.info/class/636.7/>

kc


[1] http://bibframe.org/vocab-category/
[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.

> Nate
>
> -----------------------------------------
>
> Nate Trail
>
> LS/TECH/NDMSO
>
> 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?
>
> Rob
>
> On Fri, Jul 18, 2014 at 2:44 PM, Cole, Timothy W <[log in to unmask] 
> <mailto:[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] <mailto:[log in to unmask]>] on 
> behalf of [log in to unmask] <mailto:[log in to unmask]> 
> [[log in to unmask] <mailto:[log in to unmask]>]
> Sent: Friday, July 18, 2014 16:11
> To: [log in to unmask] <mailto:[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.
>
> Jörg
>
> On Fri, Jul 18, 2014 at 10:45 PM, Ford, Kevin <[log in to unmask] 
> <mailto:[log in to unmask]><mailto:[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] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet