Dear all,

To clarify some points...

On Wed, May 8, 2013 at 1:47 PM, Denenberg, Ray <[log in to unmask]> wrote:

The question was asked why has the draft Annotation model defined the property bf:annotationBodyLiteral (in addition to bf:annotationBody). Well the easy answer is:


Because this …..


bf:ContributorBio ;



"Ronald M. Schneider is professor of political

science at QueensCollege, City

University of New York" ;



( some authority)  .


is simpler than this ……


bf:ContributorBio ;



genid:A21760 ;



( some authority)  .



cnt:ContentAsText ;



"Ronald M. Schneider is professor of political

science at QueensCollege, City

University of New York" ;




"text/plain" .

Well, not quite ...

_:anno1 a oa:Annotation ;
  bf:annotationBodyLiteral "..." ;
  oa:hasTarget <some-URI> .


_:anno1 a oa:Annotation ;
  oa:hasBody _:body1 ;
  oa:hasTarget <some-URI> .

_:body1 cnt:chars "..." ;

So there's only one mandatory additional triple. The ContentAsText class can be inferred from the cnt:chars predicate, but it's good practice to put it in ... in the same way that it's good practice to put in classes on any resource.  Ditto the media type.

It's disingenuous to say that there are many more triples, as this information simply isn't present in the literal case, so to add additional information is not comparing like with like.

In discussion we've had here (at LC), we don't think this violates OA. If BIBFRAME did not define bf:annotationBody then that would violate  OA, but allowing the additional option of providing the body as a literal, when the annotator feels it is appropriate to do so, seems a reasonable feature, at least worth discussion. 

However any OA compatible system will reject your annotation, or at the very least not understand that it has a body. In the same way that I could create an alternative way, say .. dc:title ... of stating a work's title.  I don't think you'd say that was "compatible" with bibframe?


 We do understand that this could create a potential incompatibility, that tools based on OA would not process BIBFRAME Annotations. That's a fair point.  On the other hand, some of us think that this feature is important because of the potential simplicity it can provide, and if enough of us feel that way then maybe it is worthwhile to try to convince OA to allow this feature.

Simplicity for whom? No end user needs to understand it, that'll be taken care of by the tools.  So simplicity, of leaving out one triple, for a developer who has to understand the rest of the model anyway.  And instead the developer gains the complexity of always having to check: is there a literal body or is there a real body. Further, if a developer was to find a literal body AND a regular body, they have no way to interpret the semantics of that annotation.  By following the specification, debated extensively already, there are clear ways to model the requirements and understand how to process it.


 Rob offered this example for why literal bodies should not be allowed:

Rob:  A video could be available in French and Spanish, however it wouldn't be possible to use the literal language tag to convey that information.

No, that was an argument for why language tags are not sufficient, and oa:Choice is required to say that two bodies (in this case videos) are alternatives and only one should be processed rather than both.


 Rob also offered another reason (this was in private discussion, but I'm sure Rob won't object):  

Rob: The consumer of the Annotation will not know the content type

My answer to that is, if it is anything other than plain text, it needs to be represented as a resource; anytime the body is a literal it is assumed to be plain text.

Rob doesn't object :)  You also cannot assert *anything* else about the comment, including its author. Or when it was created. Or what rights are claimed on it.  You can't make any assertions about it, and worse...

You can't refer to it *at all*, as it has no identity. You can't annotate it. It's not on the web itself, it's a blob of text stuck in a graph.


Rob countered (paraphrasing):

If a literal body is allowed, you can be absolutely certain that people will stick html and other content types in there and there will be no way for the client to know the type.

Perhaps that's true, but if the rule is that you don't use a literal unless its plain text, then if someone willfully violates that rule, what, are we supposed to protect people from themselves?

Or you follow the specification, which already protects people from themselves by requiring only a single method that's compatible with all other use cases.


 Another argument:

If the body is a literal, it isn't searchable.  

That's a fair point. I would simply respond, if you want the body to be searchable, don't represent it as a literal.

So now you *always* have to check, just in bibframe annotations, which of the multiple ways a body is represented rather than having a single consistent model.

Other arguments:

* You cannot distinguish textual tags from regular comment style bodies, yet systems have to treat them very differently.
(No the tagging motivation is not sufficient, as you could have a comment AND a tag in the same annotation. This happens if you export your web bookmarks, for example)

* It's a very marginal case that /only/ plain text is used. No links, no images, no styling, no nothing. Practically every annotation system available today allows some markup.

* It's a slippery slope to simply including ALL resources inline as literals, such as SVG and CSS, which should have identities. This would be terrible for interoperability and consistency.

* They're incompatible with multiplicity constructs in the OA model, which aren't used in Bibframe (yet).

* More than one property makes the model more complex to learn (as well as implement) -- this argument was made by one of the pro-literal people in the discussion in the community group.