Print

Print


I completely agree, Rob.

cheers
stuart

On 07/23/2014 04:57 AM, Robert Sanderson wrote:
>
> 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