A nice quick post on Allison Jai O’Dell’s article, On BIBFRAME Interfaces. It sounds like a lot of the confusion on BIBFRAME and RDF benefits comes from not quite getting what databases were doing before.
LS569 is now going through the paces on SQL and database design, and, on occasion, you hear, “Why do librarians have to learn this?” Little do they know that, in LS566, we’re looking at, “So, what’ll happen after SQL?” RDF databases don’t use SQL to define their data structures; the analogous technology is SPARQL. So, what are some differences in how our new semantic web databases hold data?
- SQL as a “set questionnaire” vs. RDF’s “open interview”. SQL databases have a set number of attributes for each of their items. For example, if I have a DB that holds customers, then I know their first and last name, address, and balance. I have to then say, for example, that last name is required, that it can’t be more than 50 characters long, and so on. Every time I make a new customer, the DB sets aside one block of space, always the same size, to hold the data. It is not easy to change a database once it’s set up. If a person’s last name is too long, or they don’t have a first name when I require one, or they want two addresses (PO Box!), I’m in trouble.
RDF doesn’t set aside a block of space right at the beginning. It goes one statement at a time. When it gets a last name, it makes space and stores it. Some databases don’t even edit; if the name changes, they add it as new and mark the old one as old. If we want to constrain the DB in some way, we have the user interface check for it. And new types of information are always easily addable.
- Interoperability. SQL databases often must speak to each other, but they’re not very good at it. Even within a company, it’s not uncommon to have two databases, created for different purposes, suddenly have to communicate with each other for a project. And always, always there will be a “What do you mean you store that as a number? And you store dashes with your SSNs?” type discussion, and there will be (imperfect) translations, and programs break for a bit, and oh goodness…
RDF, especially with linked data, does much better with this, because a linked data provides, not only a stable piece of data, but a shared, controlled vocabulary. If you design your RDF data with these shared vocabularies in mind, then your system understands any other system that shares the lingo. It’s more like, “yes, I know what people are, and addresses. You do too? Okay, we’re good. Oh, and you know what crochet patterns are? Wow, okay, well, I’ll pass on any queries for that in your direction.”
- Fluid user interfaces. Allison’s right; Ravelry‘s a hoot. But take a look at their browsing, detail screens, and especially, the advanced search. It’s incredibly modular. It’s very easy to add new fields for filters, it quickly adapts to categorical (types of yarn) vs. plain text (designer name) vs. numbers (difficulty level), and it fits a lot of differing types of information into one screen (although it are moving from mobile-friendly design to apps). In fact, yes, Ravelry has an API. There may be a SQL DB under all of this, but this is the sort of thing at which RDF excels. In fact, if Ravelry suddenly wanted to link to another site’s data (which they kind of do, since they allow PayPal), they can, and the user interface will adapt to allow browsing the new information with very little coder input (maybe a “put it here”).
So, there you have it. What are we doing with Semantic Web? Adding another assignment to LS569…