On Tue, Jul 30, 2013 at 02:17:31PM -0700, Karen Coyle wrote:
> On 7/30/13 12:15 PM, Ray Denenberg wrote:
> >points out that an OA Annotation may have multiple bodies. So if
> >we were to declare for example that the two properties,
> >bf:hasCoverArt and bf:hasCoverartThumb, were both subproperties
> >of oa:hasBody, then a cover art Annotation which incudes both
> >(i.e. a link to cover art as well as to a thumbnail) could be
> >viewed from an OA perspective as an Annotation with two bodies.
> Thanks, Ray, but I think this misses the point of Rob Sanderson's
> message, which I then tried to illustrate. Rob says:
> * 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 illustrated it this way:
> 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.
> "hasCoverArt" could not be a sub-property of oa:hasBody, since "has
> body" is saying that the annotation is the subject of the statement,
> and the body is its object. Unless Rob and I are mistaken in our
I agree that in the absence of a fuller definition, the property name alone --
"hasCoverArt" -- invites this interpretation, but a name is just a name...
If hasCoverArt were a sub-property of oa:hasBody, I would take it to mean
something like "has-body-that-happens-to-be-cover-art". If that is indeed the
intended meaning, then I do not see an obvious way to convey that notion in a
short property name, so if defined appropriately, the property could be called
"hasCoverArt" and formally mean something like: "the annotation is associated
with cover art of which we can infer, since the property is a sub-property of
oa:hasBody, that it is the body of an annotation".
So I agree that the name "hasCoverArt" is problematic because it implies a
model that is probably not intended. However, a property with this name
_could_ be formally defined in a way that is compatible with what you and Rob
> ...this is a modeling error, unrelated to any conflicts
> between OA and BF. The body could have a type, but the type is not
> logically the relationship to the annotation.
> If Body1 is an image of a cover, then you can see the difference between:
> Anno1 -> hasBody -> Body1 -> is type of:cover art
> Anno1 -> hasCoverArt -> Body1
> The body can BE an instance of cover art, but I don't think that the
> annotation can have cover art. The annotation is a relationship
> between a body and a target.
> In that email  I proposed a way that BIBFRAME could type its
> annotation bodies, which I believe would give you the detailed body
> type information you desire. You then can still have multiple bodies
> and be compatible with OA, as Tom pointed out.
>  http://listserv.loc.gov/cgi-bin/wa?A2=ind1307&L=bibframe&T=0&P=4206
>  http://listserv.loc.gov/cgi-bin/wa?A2=ind1307&L=bibframe&T=0&P=4656
>  http://listserv.loc.gov/cgi-bin/wa?A2=ind1307&L=bibframe&D=0&T=0&P=4206
> >I knew that an OA Annotation could have multiple bodies but I
> >hadn't thought through the implications of that quite in these
> >terms. Tom's argument is convincing enough for me. So we will
> >define all BIBFRAME Annotation-class-specific properties to be
> >subproperties of oa:hasBody. And, we will define bf:annotates to
> >be a subproperty of oa:hasTarget.
> >I appreciate the comments on and discussion of BIBFRAME
> >Annotations and we hope to have draft 2 of the model ready to
> >review soon.
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
Tom Baker <[log in to unmask]>