Print

Print


Thanks Ray - this is a good insight into the issues and compromises that need to be considered. Of course it is easy to argue (and I would!) that information is no more 'degraded' by becoming an 'annotation' than it is by being put into '852$$z' rather than '100$$a' - but I also understand that sometimes compromises will be made not because they are technically correct, but because it affects the adoption of a scheme in more subtle ways. (as an aside I continue to be fascinated by why it seems so difficult for some to see http URIs as 'identifiers' - surely a topic that could generate some psychology papers :)

I guess the one thing that we need to be careful about in terms of such compromises that we don't end up with a 'pleasing no one' situation - it may be better to compromise to one side or the other rather than some notional middle ground - but I'll stop before I start on about sucking eggs.

Looking forward to the holdings paper :)

Owen

Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: [log in to unmask]
Telephone: 0121 288 6936

On 7 May 2013, at 20:08, Ray Denenberg <[log in to unmask]> wrote:

(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 ;
                                             motivatedBy           bf:Holdings
 
 
……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.
 
--Ray
 
 
 
From: Bibliographic Framework Transition Initiative Forum [mailto:BIBFRAME@LISTSERV.LOC.GOV] 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


On 7 May 2013, at 16:35, "Denenberg, Ray" <[log in to unmask]> wrote:

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.
 
--Ray
 
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Owen Stephens
Sent: Tuesday, May 07, 2013 10:48 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] BIBFRAME annotation
 
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 :)
 
Owen