Hi Ray,

On Tue, Jul 23, 2013 at 03:26:17PM -0400, Ray Denenberg wrote:
> > The loss of this very sensible mapping would be a pity if the basic
> > models -- at the level of what OA calls the Open Annotation Core --
> > really were compatible which, as far as I can see, they really are.
>
> Tom - No, they really aren't. [...]
>
> One example of how BIBFRAME is different: each different type of Annotation
> has properties defined for that type. For example, consider cover art. We
> define a class CoverArt, and properties bf:coverArt and bf:coverArtThumb.

Okay, that's fine. But I see nothing in the OA ontology -- i.e., the
beautifully generic properties and classes underpinning the more specifically
constrained OA Data Model -- that would preclude this.

> I.e. the Annotation provides a link to a thumbnail of the cover art which
> the user can examine to determine if he wants to retrieve the larger cover
> art image. Thus, the payload of an Annotation isn't a single resource as in
> OA, it often may be several resources.

If by "payload of an Annotation" you mean what OA calls a "body" -- or in this
case two things, a thumbnail and a larger image, together constituting a body
-- then this appears to be consistent with the OA Data Model, which says:
"There SHOULD be 1 or more oa:hasBody relationships associated with an
Annotation but there MAY be 0" [1]. It is at any rate consistent with the
nicely minimal formal definition of oa:hasBody in the OA ontology. If the idea
is to use bf:coverArt and bf:coverArtThumb instead of oa:hasBody, that is a
legitimate implementation decision but I do not see how this would be
inconsistent with either the OA Data Model or the OA ontology.

[1] http://www.openannotation.org/spec/core/core.html#BodyTarget

> (And I should mention here, we
> continue to define Annotation classes, rather than motivations as suggested
> by OA, for this reason, that each Annotation class has properties defined
> specifically for that class.)

Another legitimate decision, but I see no obvious contradiction to the OA
ontology there either.

> So, in fact, there is no formal "Body" defined. (There is the concept of a
> Body, defined to be the aggregate of triples corresponding to properties
> defined for that Annotation class, but there is no property hasBody formally
> defined.)

I think I get your point. To "aggregate" them as a Body, if they are indeed
being "defined for" the Annotation class, perhaps you could declare
bf:coverArt, etc, as sub-properties of bf:annotationBody. Then
bf:annotationBody could be a sub-property of oa:hasBody.

> On the other hand though, the concept of Target remains the same, and is
> still the same concept as an OA Target. So, you could legitimately argue
> that
>
> bf:annotates -> subPropertyOf -> oa:hasTarget
>
> still makes sense, I suppose. Does it really though, with all the other
> differences?

Yes, it can indeed be useful. Consider the case of a single triple using
oa:hasTarget. This tells you that the subject of that triple is an instance of
oa:Annotation, and that the triple links an annotation to some target resource.
In a Linked Data context, such a link can be useful independently of whatever
other properties that annotation may have.

Bottom line: If OA and BF properties are compatible [2], it is helpful to map
them explicitly.

Tom

[2] http://kcoyle.net/img/OAnBFcore.jpg

--
Tom Baker <[log in to unmask]>