Hi Kevin,

On Thu, May 9, 2013 at 5:12 PM, Ford, Kevin <[log in to unmask]> wrote:

Your email, and one or two from others, does raise an issue we regularly consider: how do we devise a model that at once meets the needs of its (relatively defined) community but is also flexible enough so that others can work with it easily while ensureing that the model does what it can to ensure that data is exchanged in a predictable manner?

Indeed, and this is one of the issues with RDF, the open world and linked data notions -- it isn't 100% predictable, and that allows for expansion to accomodate new requirements in the future.  If the desired result is a constrained record that can be exchanged in a 100% predictable fashion, then I would question why RDF is at the core of the model.  RDF isn't the solution for everything, and particularly not for constrained records.

 You've championed how simple an Open Annotation is and, indeed, it is.  Target, body, motivation.  But if the body of an Annotation can be anything (any Thing), then that's a pretty big unknown.  Not only is it a big unknown, but it is so flexible as to render the body potentially unpredictable and different from annotation to annotation (or at least annotation creator to annotation creator). 

Absolutely. We consider the flexibility to be a strength. The model provides a framework /within/ which communities can create local solutions to specific problems while maintaining interoperability with the rest of the world by following the pretty straightforward set of guidelines.  By associating provenance, metadata and at the very least type information with resources, then there are clear paths for graceful degradation by systems that don't understand all of the local additions.  This includes the motivation scheme which is cross-community via the SKOS framework, and the fact that everything is a resource rather than a plain literal allowing as much metadata to be associated with it as possible.

Exchange is a huge aspect of BIBFRAME and so we prefer to proceed cautiously when faced with such a possibility.  We (the library community generally) need to be able to receive data from large numbers of varying entities and the data must be predictable.  As painful as rules can be, there's also an enormous amount to be gained from them. 

Completely agreed. The point being that if Bibframe is going to buy into the Open Annotation model, then there are some rules there intended to enhance interoperability between communities.  No, they're not essential within a single community. If you can enumerate all of the possible properties that anyone might want to express about a body, then you could duplicate them all along with the bodyLiteral...

... But you would not be following the Open Annotation model, and we would ask that you did not claim to be doing so.

You've mentioned the possible problems with needing to guess, or at least test, whether the annotation body is a literal or a resource.  How would it be to figure out what we're getting as an annotation body each and every time?  Did this annotation creator use DCTERMS or something else entirely?  Imagine what code would look like if it had to make sense of the complete unknown. 

Certainly.  That's why we have models and rules :)  

 Is your list of properties anything much more than hyperbole?  Probably not but it's hard to deny that a number of those could be shared across all annotations to the mutual benefit of all annotation consumers. 

The list was intended to demonstrate that once you've made a shortcut for the literal, you then have to make increasingly many shortcuts for the creator and all of the other properties and relationships that would normally be applied to the body resource.  In the economics of RDF, an identity is very cheap, whereas semantics are very expensive.  For another community to use the bibframe annotations, they would need to understand all of those duplicated terms.

If you don't intend for the information to be used outside of the library community, then again I would question why you're using RDF at all.

In any event, in the course of writing the above, I visited the Open Annotation spec once or twice.  Without crawling back through my email, I have a vague memory of you mentioning that an Annotation processor encountering an Annotation with a literal body would not know what to do with it.  I take this to mean that "because there is no 'hasBody' relationship pointing to a resource, then the OA processor would not know what to do with this unknown property."  I've two questions:


1) The Open Annotation spec says of the hasBody property, "There SHOULD be 1 or more oa:hasBody relationships associated with an Annotation but there MAY be 0".  If the Annotation spec already permits OA Annotations without bodies, either the processor will gracefully treat a BIBFRAME Annotation with only a literal body in the same way or it would also choke on Open Annotation annotations with no oa:hasBody property.  No?

The processor would check to see if the Annotation has the hasBody relationship.  It would find that it doesn't.  
In the highlighting / bookmarking use cases, it would go on to process the target as appropriate, understanding the motivation as meaning the body is implicit.

However consider an Annotation that does not have a hasBody relationship, but the motivation is "commenting", "reviewing" or similar.  The comment /is/ there, but the processor would need to know in advance to look for bf:annotationBodyLiteral... which would be community specific.  So it would then choke as a comment without a body doesn't make much sense.

Essentially, the motivation is the key for switching client side behavior.  A bodyless comment isn't going to help anyone. A bodyless highlight is very useful, and in fact the CEO of diigo.com commented that 9 out of 10 of their annotations are exactly that.

 2) The Open Annotation spec says of the oa:Annotation class: "All Annotations MUST be instances of the class oa:Annotation, and additional subclassing is ONLY RECOMMENDED in order to provide additional, community-specific constraints on the model."  Can you give me an example of a community-specific contraint?

This is where the distinction between motivation and structure is important.

If all of the annotations MUST target a bf:Work, then you could very legitimately create a subClass of oa:Annotation and assert that the targets of those annotations must be resources of class bf:Work.  That's fine -- we'd ask that you *also* give it the oa:Annotation class in order to let processors gracefully degrade.

On the other hand, using a subclass to provide a motivation would be to ignore the Open Annotation framework.  So a PublisherDescription isn't a legitimate subClass, as it's about the motivation for the annotation's creation. It also subsumes metadata about the body (it was created by a "publisher") which should be associated with the body itself. Similarly, ContributorBio.


 It's worth noting that I don’t believe we've ever stated that a BIBFRAME Annotation and an Open Annotation are the same thing and I feel that has been an assumption.

You haven't but the document claims compatibility that just doesn't exist.  You are of course completely welcome to ignore Open Annotation and go your own community specific route, if you think that's the best option for the library world.  It's your community and requirements, we're only here to try and ensure that the Open Annotation model /as currently described in the Bibrame Annotation document/ is used effectively and correctly.

  Perhaps they are the same, but I'm not entirely confident we can definitively conclude that yet.  Nevertheless, they are undoubtedly closely similar and we've, all along, entertained alignment with OA, if possible.  But, first and foremost, we're interested in a model that best serves the needs of the community of users we envision using BIBFRAME.

Sure. Coming up with the full set of requirements and use cases, then analyzing the overlap with Open Annotation would be a good starting point, I suggest.  And we [the Open Annotation community] are happy to help with that process, if it's desired.

Apologies for the apoplexy regarding literal bodies and the subsequent hacks required to make them work, however this is something that was debated *at length* in the Open Annotation Community Group. If a little apoplexy can save the bibframe community going down an infinitely deep rabbit hole, then it was hopefully well placed :)