Print

Print


But if you're just using DESCRIBEs, why bother with a triplestore?  Why
bother storing it natively as RDF at all?  Model the concise bounded
descriptions as however you need for your preferred database type (RDBMS,
document database, whatever) and make sure it's able to ingest/export RDF.

BIBFRAME only touches part of a library's data, and it doesn't make much
sense to model the rest as RDF.  Updates in triplestores are awkward and
using multiple data stores (if you're using a triplestore for the
bibliographic data and something else for the administrative, acquisitions,
user, etc. data) introduces an unnecessary overhead.  Even more unnecessary
if it's sole purpose is to enable queries that are not even particularly
useful.

-Ross.

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

> Ross,
>
> we'll see about that :)
>
> An arbitrary SPARQL query hundreds of lines long might be challenging for
> a triplestore, but a DESCRIBE on a specific URI is not. So why not use a
> triplestore in this case? I find your reasoning backwards.
>
> I think it comes down to the scale of the data. Does anyone have any
> estimates from BIBFRAME projects in terms of triples?
> On Apr 10, 2015 2:01 AM, "Ross Singer" <[log in to unmask]> wrote:
>
>> I would disagree with the general line of thinking "BIBFRAME is RDF, so
>> use a triplestore".  The current crop of triplestores work fine for
>> performing arbitrary queries over data, but (generally) do not (easily)
>> scale well.  The question is, are arbitrary queries over all of the data
>> really that important?  What are actually the usage patterns of how the
>> data is accessed?
>>
>> My gut feeling is that for the actual day-to-day usage of a library
>> system, the need to perform ad-hoc sparql queries is fairly minimal and
>> that 99% of the time the system will be doing (the functional equivalent
>> of) DESCRIBEs on a particular URI and selected objects associated with the
>> subject of the DESCRIBE.  For that sort of use case, there's little need
>> for a triple store or graph database.
>>
>> I suspect that in reality, you'll see production solutions lean more
>> towards databases like PostgreSQL which allow for some of the schema-less
>> needs of RDF, but also have the traditional RDBMS model to use when
>> appropriate, but, honestly, until we know what exactly the usage patterns
>> are, it's all rather academic.
>>
>> -Ross.
>>
>> On Tue, Apr 7, 2015 at 10:01 PM Trail, Nate <[log in to unmask]> wrote:
>>
>>> Well, its rdf data, therefore triples, therefore, use a triplestore.
>>> However, it’s also got lots of nice descriptions, which are not easily
>>> searched in a triplestore, therefore, use elasticsearch or solr or some
>>> other indexer also. If you wanted, you could put it into a relational
>>> database, but I don’t know what it’d gain you, unless you only had access
>>> to a relational db.  I dn’t know about library data not belonging in a
>>> relational database. Most ILSs probably have their marc data in Oracle; the
>>> difference is in how how you store it in-house; no one should care if you
>>> have  a blob of marc or have shredded it out into different fields in a
>>> database, if you get the job done.
>>>
>>> RDF can be serialized in lots of ways, to make it easier to ingest into
>>> your favorite store: rdfxml, jsonld, nt, ttl…
>>>
>>>
>>>
>>> Nate
>>>
>>>
>>>
>>> *From:* Bibliographic Framework Transition Initiative Forum [mailto:
>>> [log in to unmask]] *On Behalf Of *Jon Miller
>>> *Sent:* Tuesday, April 07, 2015 4:37 PM
>>> *To:* [log in to unmask]
>>>
>>>
>>> *Subject:* Re: [BIBFRAME] How is Bibframe data stored?
>>>
>>>
>>>
>>> So, the thought is not using a relational database for storing the data?
>>> I keep hearing that relational database is inappropriate for storing
>>> library data, but, I don’t see how library data is any different than any
>>> other kind of data that has no problem being stored relationally.
>>>
>>>
>>>
>>> Jon
>>>
>>>
>>>
>>> *From:* Bibliographic Framework Transition Initiative Forum [
>>> mailto:[log in to unmask] <[log in to unmask]>] *On
>>> Behalf Of *Trail, Nate
>>> *Sent:* Tuesday, April 07, 2015 3:05 PM
>>> *To:* [log in to unmask]
>>> *Subject:* Re: [BIBFRAME] How is Bibframe data stored?
>>>
>>>
>>>
>>> Jon,
>>>
>>>
>>>
>>> On the bibframe site, if you take the classs bf:Work for example:
>>>
>>> http://bibframe.org/vocab/Work.html
>>>
>>> It tells you the properties from it’s parent “Resource” class, plus the
>>> properties used in the class, plus those that are unconstrained in domain.
>>> Is that not where you were looking?
>>>
>>>
>>>
>>> Storage of bibframe data is up to implementers. Several seem to be
>>> putting the data into a nosql database and using elastic search or solr,
>>> and into a triplestore for sparql queries on the relationships among
>>> nodes.  LD4P and the Library of Congress are starting up pilot projects to
>>> flesh this all out.
>>>
>>>
>>>
>>> Nate
>>>
>>>
>>>
>>> -----------------------------------------
>>>
>>> Nate Trail
>>>
>>> Network Development & MARC Standards Office
>>>
>>> LS/ABA/NDMSO
>>>
>>> LA308, Mail Stop 4402
>>>
>>> Library of Congress
>>>
>>> Washington DC 20540
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Bibliographic Framework Transition Initiative Forum [
>>> mailto:[log in to unmask] <[log in to unmask]>] *On
>>> Behalf Of *Jon Miller
>>> *Sent:* Tuesday, April 07, 2015 3:57 PM
>>> *To:* [log in to unmask]
>>> *Subject:* [BIBFRAME] How is Bibframe data stored?
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I’m wondering how Bibframe data is stored? I’m wondering if anyone has
>>> thought about defining mappings between it and a relational database or at
>>> least an object oriented programming model that could be manipulated
>>> easily? Does such a thing exist, or are ILS implementers left to figure
>>> this out on their own? How is a programmer expected to work with the data?
>>> XML parser, then, build your own programming model? On bibframe.org
>>> there is a list of classes and properties. If you click on a class, it
>>> takes you to a once sentence description of the class. However, it doesn’t
>>> enumerate the properties that are applicable to that class. Shouldn’t there
>>> be a list of the properties for the class?
>>>
>>>
>>>
>>> Jon
>>>
>>>
>>>
>>