 |
 |
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]>