On 7/24/13 8:09 AM, Robert Sanderson wrote:
>
>
> * 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
>
> 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]
> <mailto:[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] <mailto:[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
