 |
 |
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 schema.org discussion, someone would immediately suggest using http://www.productontology.org/, which is an ontology that makes use of Wikipedia page names for things. You would then have http://www.productontology.org/Cover_art http://www.productontology.org/Thumbnail 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. kc > * 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] 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