For what it's worth, Stanford's current set of triples is around 800 million, and Harvard's is over a billion.
So no, it's not in the order of single millions.
Sent from my iPad
> On Apr 10, 2015, at 01:25, Martynas Jusevičius <[log in to unmask]> wrote:
> Usage patterns do matter, I agree. But if we're only talking about an
> order of millions of triples, there is no reason to believe that a
> triplestore could not perform adequately in real-world usage
> scenarios. This has been done already many times.
> To my knowledge, BIBFRAME was designed as an RDF vocabulary and
> intended for Linked Data use. So it's not me prescribing RDF. RDF is
> the natural data model of choice here, while RDBMS a source of data
> from legacy systems. Putting RDF data into an RDBMS makes no sense.
>> On Fri, Apr 10, 2015 at 11:09 AM, Ross Singer <[log in to unmask]> wrote:
>> Martynas, the number of triples don't matter. It's the usage pattern that
>> 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,
>> 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.
>> On Fri, Apr 10, 2015 at 8:58 AM Martynas Jusevičius <[log in to unmask]>
>>> 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:
>>> On Fri, Apr 10, 2015 at 10:47 AM, Bernhard Eversberg <[log in to unmask]>
>>>> 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
>>>>> 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.