Print

Print


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 ..****
>
> ** **
>
> http://annotation.com/xyz****
>
> a****
>
> bf:ContributorBio ; ****
>
>  ****
>
> bf:annotationBodyLiteral****
>
> "Ronald M. Schneider is professor of political ****
>
> science at QueensCollege, City ****
>
> University of New York" ;****
>
>  ****
>
> bf:annotationAssertedBy****
>
> ( some authority)  . ****
>
> ** **
>
> is simpler than this ****
>
> ** **
>
> http://annotation.com/xyz****
>
> a****
>
> bf:ContributorBio ; ****
>
>  ****
>
> bf:annotationBody****
>
> genid:A21760 ; ****
>
>  ****
>
> bf:annotationAssertedBy****
>
> ( some authority)  . ****
>
> genid:A21760****
>
> a****
>
> cnt:ContentAsText ; ****
>
>  ****
>
> cnt:chars ****
>
> "Ronald M. Schneider is professor of political ****
>
> science at QueensCollege, City ****
>
> University of New York" ; ****
>
> ** **
>
> dc:format ****
>
> ** **
>
> "text/plain" .****
>
> **
>


Well, not quite ...

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

Becomes:

_: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.


Rob


>