Print

Print


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

Rob