Our experience is to design and scale our systems for the most important and used use cases.
What new use cases will actually be needed because of LD and how much they will be used still remains to be seen.
Given that, the best approach will be evolutionary and revolutionary.
This translates to:
- Support information exchange in BF (including import files, export files, URIs…)
- Add LD use cases as they become useful (e.g. during cataloging).
- Periodically rethink technology decisions based changes use cases and technology (software and hardware)
See the all new Developer Network
Experience the all-new, singing and dancing interactive Primo brochure.
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]
] On Behalf Of Bernhard Eversberg
Sent: Friday, April 10, 2015 10:47
To: [log in to unmask]
Subject: Re: [BIBFRAME] How is Bibframe data stored?
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
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.