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:-Ross.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.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.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…
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.
On the bibframe site, if you take the classs bf:Work for example:
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.
Network Development & MARC Standards Office
LA308, Mail Stop 4402
Library of Congress
Washington DC 20540
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?