(I changed the subject line.)
…. now having said that there is no technical reason for "class" over "motivation", there is an argument for subclassing. Not a compelling argument but subclassing does have a certain appeal.
There was debate during the development of the draft over whether this or that category of information should be treated as an Annotation. In at least one case a number of people thought that a certain category of information became degraded if it was relegated to be an Annotation rather than a "first class BIBFRAME citizen".
The category in question was "Holdings". (I don't wish to start a debate here about holdings; if you want to discuss it please initiate a new thread. In fact, I think there will be a paper coming out on holdings, so you might want to wait for that. ) Some said, you can't make a holding an Annotation because that makes it seem less important, to which a response was, well then don't call it an Annotation (or a Holding Annotation), call it a Holding (or Holding Resource).
So if http://holding.com/xyz is a holding resource (and 'Holding' is an Annotation class, so bf:Holding is a subclass of bf:Annotation, which is a subclass of oa:Annotation), then the fact that http://holding.com/xyz is a holding resource is expressed as:
http://holding.com/xyz a bf:Holding
And saying that…..
as opposed to
http://holding.com/xyz a bf:Annotation ;
……sweeps the fact that it is an Annotation under the rug.
I'm not offering this as a compelling reason to use subclassing rather than motivation, just relaying part of the conversation we had about this.
And to avoid confusion, I should note that Holding is NOT an Annotation in the current draft. Whether or not it becomes an Annotation is for discussion.
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Owen Stephens
Sent: Tuesday, May 07, 2013 12:58 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] BIBFRAME annotation
Thanks Ray - good to know and really appreciate this clarification
Owen - I can answer the second. I'll have more to say on all of this but you've asked a straigthforward question which I can answer quite easily.
The current OAM draft is dated February 2013. The previous, May 2012. This current BIBFRAME draft is based on the earlier OAM draft, which used classes, and had not yet introduced the concept of motivations. At the time the February draft was released, we were just about ready to put up the BIBFRAME draft (yes, it did get delayed a couple months), and, frankly, we were not yet convinced that the motivation concept was stable, so we decided to stick with the class approach, for at least this draft, mainly to avoid destabalization. There is no technical reason why we cannot change from "class" to "motivation" in the next draft.
My first question about Annotations in Bibframe was about whether the existing proposed uses of Annotation were 'valid' - or could be said to meet some criteria as to why they were 'annotations'.
My second is about the differences between Bibframe annotations and Open Annotation. As bf:Annotation is declared a subclass of oa:Annotation it seems that there is a desire to share a common conception of what an 'annotation' is.
The immediately obvious major difference between the way Bibframe Annotations and OA is that to specify the type of annotation Bibframe uses subclasses while OA uses the concept of 'motiviation'. I have to admit I struggle to see why Bibframe should do this differently to OA given that there is so much to gain through doing it in the same way. If there is anything to say about why bibframe proposes to do this via subclassing it would be really good to know, as the OA documentation makes it clear why they decided to go with the 'motivation' approach http://www.openannotation.org/spec/core/core.html#Motivations, and seems explicitly designed for scenarios such as the BIBFRAME one where a community has some need to specify a certain type of annotation.
In a recent email Rob Sanderson also highlighted another difference which is allowing the use of literals to carry the body of an annotation. Again the OA case for not allowing this is documented http://openannotation.org/spec/core/core.html#BodyEmbed and seems to include some use cases that seem likely to impact on the library domain - e.g. knowing directionality of text, knowing how text is encoded. Again I think some explanation of why Bibframe feels it is important to support the annotationBodyLiteral would be welcome.
In Eric Miller's recent email he noted that "Ray Denenberg (the Editor for this doc) [...] sees the compatibility and interoperability differences to be minor to negligible,". If these two differences are the major issues here, I tend to agree that there are not major differences - which, to be honest, just makes me wonder all the more why they are necessary :)