We are working on a number of improvements to the BIBFRAME vocabulary – more on that soon.
One critical issue is “dual properties”. There has been discussion on this, here on this listserv, but rather than rehash old discussion I ask that we take a fresh look.
If a single RDF property can, for some triples, have as its object a literal (string), and for other triples, a resource – is this necessarily a bad thing? Or should there be dual properties defined.
There are several such potential BIBFRAME properties (by “potential”, I mean in the revised/improved vocabulary we are working on) and while I hesitate to single out one, I’ll use title for an example.
Clearly, people want to be able to say ….
<http://bibframe.example.com/workX> bf:title “Lord of the Flies” .
… without having to construct a bf:Title resource.
And it is equally clear that there will be a need, in many cases, to create a bf:Title resource.
So what’s better (a) a single property, bf:title, that can take on literal or resource; or (b) dual properties, bf:titleLiteral and bf:title (or bf:title and bf:titleResource; take your pick).
The debate seems to go along these lines: Approach (a) imposes on a client the burden of inspecting the object to determine its type. On the other, hand it is argued, the added complexity of dual properties outweighs that burden.
Furthermore, It seems that the debate hinges on whether or not you are optimizing the ontology for inferencing: if so, then you want dual properties. If not, then the extra complexity of dual properties should be avoided.
In fact, this exact debate was played out recently in the W3C, over annotations. Many (if not most) annotations are going to be short strings, “simple textual bodies”, in some cases, a few characters. The first draft of the model defined dual properties for an annotation body, hasBody and hasBodyLiteral. There was debate and the result is that the current draft model (http://www.w3.org/TR/annotation-model/) has a single property, hasBody.
As is the case for annotations, I believe, we are not optimizing the BIBFRAME vocabulary for inferencing, which would suggest approach (a).
Opinions on this issue are solicited.