Plugging Into FRBR, Killing MARC
Realizeed my diagram was sort of wrong (missing ids), and so have changed it.
Karen Coyle has a post trying to spur discussion about how to hasten a world of library metadata beyond MARC.
My response in the comments was:
You won’t be surprised to know that I think [the way] out of MARC and its legacy (including MODS frankly) is RDF. So think about stripping down MODS to something closer to DC and DCQ (though it might be different in fact) and then through RDF/OWL schemas plugging those more grounded views into the more abstract world of FRBR (which has now has a nice RDF representation).
Let me demonstrate what I mean.
I have been working on an RDF schema for citation metadata. The idea is to have a rich model and XML format (backed up by a RELAX NG schema) that is easy for pretty much any developer to pick up and use. The Zotero guys are starting to use this in fact.
This means generally to rely on really grounded property terms—author, title, shortTitle—and to embed the meaning in the OWL schema.
OK but what does this mean? An example:
sbo:creator a owl:ObjectProperty ;
rdfs:label "creator"@en ;
rdfs:subPropertyOf frbr:creator ;
rdfs:domain [ owl:unionOf (sbo:Reference sbo:Note) ] ;
rdfs:range sbo:Agent ;
rdfs:comment "An agent primarily responsible for the intellectual or artistic content of a work."@en .
What am I saying in this short space?
- sbo:creator is a reference to another object; an sbo:Agent
- its English-language label is “creator”
- it is a subProperty of frbr:creator
The last point is particularly critical, because it means I can plug my data into a FRBR view. Even just the natural language documentation value is evident here, but more importantly, RDF reasoning tools will be able to make use of this. They will know that a sbo:author is also a sbo:creator, which is also a frbr:creator, and therefore can infer additional information, such as that it refers to an agent responsible for creating a frbr:work.
This is what I mean by taking more simple, grounded, representations, and plugging them into more the more abstract view of FRBR. Through the ontology and related tools, you can—if you want (you can ignore FRBR entirely)—basically take more-or-less flat data, and explode it into a larger view, mixing and merging data as you go. Representing this graphically (where dashed lines indicate inferred statements):
I’m still working out exactly how to add this logic to my schema, but I see a lot of power in this approach: really simple and gounded vocabularies, but tied into more abstract models.
What I see in the last few decades of library metadata work (with the notable exception of DC) is a tendency to overburden the formats themselves with the task of carrying meaning. This results in formats that are not only more complex than they need to be, but also much more difficult to use.
Hmm, you seem to be implying in the last paragraph that it’s possible to still include meaning as rich as we need it (as rich as what’s in current MARC (even if that meaning isn’t generally used by systems, another issue) in a format as simple as DC. “tendency to overburden the formats themselves with the task of carrying meaning.” So your suggestion is that there’s a way to pack all this meaning in, but not in the “formats themselves”.
I’m not following how you do this.
Hi Jonathan —
Let’s take an example: titles. How does one distinguish a uniform title, from an abbrviated title, from a trnasliterated title in a relatively “simple” format like MODS? You have one complex XML structure, with four or five elements, and variety of attributes. That complex XML structure is designed to basically say “all of these are tiles.”
OK, but when you deal with complex data, you end up with quite complex XML; data which is simply difficult to work with.
What if instead you just gave each separate URIs …
http:loc.gov/standard/mng/title http:loc.gov/standard/mng/abbreviatedTitle http:loc.gov/standard/mng/transliteratedTitle
[let's not worry about details, because the above is likely not quite right; but I'm sure you get the idea]
In RDF/XML, you then end up with three different elements You define the relations between them (that the last two are sub-properties of the first) in a separate RDF/OWL schema.
In essence, you separate out the concerns (encoding and semantics).
Another example is the constant use of the uncontrolled authority attribute in MODS and MADS. Again, more complicated (and losely-controlled) XML to do work that can be done more easily and precisely. We live in the 21st century, with a huge HTTP and URI infrastructure; so use it.
<mng:subject rdf:resource=”http://loc.gov/topics/x”/>
Did I answer your question?
Bruce
[...] Darcus talks about RDF and FRBR and the death of MARC [...]
[...] Also, the main site page promises a standard format for other systems to use. If I may be so bold, I’d avoid using existing library standards to represent this sort of metadata, which will be both needlessly complicated, and frustratingly limited. As I’ve mentioned before, RDF is perfectly suited to this sort of use case, particularly given there is already a very good representation of FRBR. [...]