Print

Print

On 7/24/13 8:09 AM, Robert Sanderson wrote:
[log in to unmask]" type="cite">


* The motivation vs subclass issue and the literal body vs body as resource were discussed at length and the consensus was reached for the model based on interoperability and cross-community requirements.  If Bibframe wishes to not be interoperable with other communities, that's perfectly fine, but there's no point using an interoperability framework at that point.
(and so forth)

Robert,

Can you envision a way that one could "type" the annotation in the kind of detail that BIBFRAME seems to need (like annotating with cover art vs. thumbnail of cover art) within the OA model? (I apologize if it's in the OA spec and I haven't seen it.) Then we could discuss whether there could be motivation values that make sense within the library context. ("Providing cover art thumbnail" seems a bit over the top, yes?)

I suspect that libraries are not unique in this need.

Thanks,
kc

[log in to unmask]" type="cite">

So while the reaction to explicitly and intentionally not be compatible with Open Annotation is definitely disappointing, it is in my view the correct decision rather than claiming compatibility where none really exists.  Bibframe's apparent requirement to re-invent everything within the bibframe namespace world view is equally confusing and disappointing.

Rob



On Wed, Jul 24, 2013 at 10:15 AM, Thomas Baker <[log in to unmask]> wrote:
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]>


-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet