Print

Print


Martynas, the number of triples don't matter.  It's the usage pattern that
does.

To answer your question about "Because when you decide a DESCRIBE is not
enough and you want a custom CONSTRUCT instead, you simply do that with the
triplestore and you're stuck in the RDBMS setup that you suggest."

In that scenario, export to a triplestore and do what you need.  The vast
majority of operations (and libraries) will never need or want to do this,
though.

And I disagree about using a triplestore for everything and I think it will
be a very long time (if ever) that you'll see it embraced by the
enterprise.

Regardless, it's counter-productive to prescribe a specific technology if
the goal is to increase adoption.  Especially if you don't know what the
needs and constraints are.

-Ross.

On Fri, Apr 10, 2015 at 8:58 AM Martynas Jusevičius <[log in to unmask]>
wrote:

> I question I've already asked here, but received no answer to: what's
> the ballpark number of triples we're talking about?
>
> Here's a list of large triplestore setups to compare with:
> https://www.w3.org/wiki/LargeTripleStores
>
> On Fri, Apr 10, 2015 at 10:47 AM, Bernhard Eversberg <[log in to unmask]>
> wrote:
> > 10.04.2015 09:18, Ross Singer:
> >>
> >> But if you're just using DESCRIBEs, why bother with a triplestore?  Why
> >> bother storing it natively as RDF at all?
> >>
> >> BIBFRAME only touches part of a library's data, and it doesn't make much
> >> sense to model the rest as RDF.  ...  Even
> >> more unnecessary if it's sole purpose is to enable queries that are not
> >> even particularly useful.
> >>
> > It is unfortunate that not much can be said up to now about the use
> > cases to be expected. Though it was very likely deliberate by LC to not
> > specify anything about use scenarios when they commissioned the
> > development of BIBFRAME - so as not to anticipate anything that might
> > be too library specific or backward.
> > But one thing is clear: storage methods will have to scale well. Very
> > well indeed. Both in terms of data volume and access traffic volume.
> > What's the attitude of OCLC in that regard, and the vendors'? I mean,
> > they should have some views, based on their experience.
> >
> > B.Eversberg
>