Print

Print


Dear Rob,

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?

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).  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.  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.

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.  We're identifying use cases and what we need to realize those use cases efficiently and predictably.  Properties (and Annotation types) would be defined as needed, possibly per Annotation type.   Patterns will emerge.

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?

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?

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.  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.

Instead of seeing this as zero sum game, it might be more fruitful to ask, "is there a middle ground solution?"

Cordially,
Kevin



From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Robert Sanderson
Sent: Thursday, May 09, 2013 2:48 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] BIBFRAME annotation: (annotator vs. body creator)


And bodyCreated, bodyLicense, bodyDescription, bodyPublished, bodyDateAccepted, bodyRequires, bodyHasPart, bodyAudience, bodyAvailable, bodyConformsTo, bodyContributor, bodyRights, bodyRightsHolder, bodyProvenance, bodyRelation, bodyReplaces,  ... and then you're about half way done with the Dublin Core terms vocabulary.

I guess that would be consistent with the bibframe mentality of creating new versions of everything, though ;)

Rob


On Thu, May 9, 2013 at 12:39 PM, Ray Denenberg <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Would it help to define an annotation property "bodyCreator".

  So if the publisher created the publisher description and the library of congress asserted the annotation:

http://annotation

a

bf:PublisherDescription ;

                                             .................



bf:annotates

http://instance ;



bf:annotationAssertedBy

(Library of Congress)



bf:BodyCreator

(publisher)


Or if a third party created the publisher description:

http://annotation

a

bf:PublisherDescription ;

                                             .................



bf:annotates

http://instance ;



bf:annotationAssertedBy

(Library of Congress)



bf:BodyCreator

(third party)


Ray

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]<mailto:[log in to unmask]>] On Behalf Of Owen Stephens
Sent: Thursday, May 09, 2013 1:46 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] BIBFRAME annotation

On 9 May 2013, at 18:05, "Ford, Kevin" <[log in to unmask]<mailto:[log in to unmask]>> wrote:

True, but the 520 is also the other source of BIBFRAME Annotation types (Review, Abstract, ContentAdvice).  Also, the principle Stephen raised ([publisher] bias) still holds, especially with the the Publisher description and (potentially) Contributor Bio (bias is really not a factor with Sample Text and Table of Contents).


Acknowledged - thanks both.

I think the point here about 'bias' is back to the issue of the 'who' being important. However, I'm back to my confusion on this - if the annotation approach doesn't inherently allow you to say 'this statement is made by the publisher, not the library', then why use an annotation? It may as well be just another bibframe property? (at least, knowing that a library stated this is a publisher description is no more important to me than knowing that the library stated this is the title from the title page - which I think is one of the points made by Tom Meehan)

Owen