On 7/24/13 8:09 AM, Robert Sanderson wrote:
> * The use of predicates, which are not subProperties of hasBody, to 
> link what OpAn would consider a body. A client would assume that 
> there's no body and thus not know what to do with the target.  Without 
> also a motivation, it's simply meaningless in Open Annotation.
> * The different semantics -- hasCoverArt conveys a very different 
> relationship to hasBody.  The /annotation/ does not have the image as 
> its cover art, the target of the annotation is the resource that it is 
> the cover art for.

I find it often helps to break things down into triples. In this case 
you would have:

A has target B
A has cover art C

If this means that B is the target of A, then it also means that C is 
the cover art of A.

Instead, what I believe BIBFRAME is looking for is a way to say:

C is a X (cover art, table of contents, publisher review)

Then you would have:

A has target B
A has body C
C is a X

Presumably X could be any class, so it would be a matter of finding or 
creating the appropriate set of classes.

If this were a discussion, someone would immediately suggest 
using, which is an ontology that makes 
use of Wikipedia page names for things. You would then have

If such an option were chosen, this would either replace or co-exist 
with the DC Type vocabulary in the annotations. The key thing about the 
product ontology is that it is much more detailed than DC Type.


> * Multiple bodies, and their semantics, are covered very clearly in 
> OpAn -- having multiple resolutions of an image is semantically an 
> oa:Choice.  Clients would display both the thumbnail and the full 
> resolution resource, as semantically both are individual bodies.
> * 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)
> 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]
>     > (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]
>     --
>     Tom Baker <[log in to unmask] <mailto:[log in to unmask]>>

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