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
|