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