Hi Karen,

On Tue, May 7, 2013 at 9:57 AM, Karen Coyle <[log in to unmask]> wrote:

One other difference that I see is the typing of the target. This may not be a vital difference since such typing is non-mandatory (for whatever mandatory means in the open world of linked data, but that's a whole other question I have about the OA model). OA uses dctypes, like "text," "image," "sound." Even for OA I question whether these are sufficiently granular to be useful ("image" and "sound" can be a whole plethora of actual digital file types).

Mandatory for us means that if you expect regular clients to process the model as intended, then the triple must be present.  For example the hasTarget predicate is mandatory, because an Annotation that doesn't annotate anything is pretty much meaningless.  (And thus see also the issue we have with "embedded" annotations in BF)  Of course, we can't /enforce/ any such rules, and it may emerge that systems don't follow the specification are widely adopted... at which point we would have to reconsider the spec!

For the granularity issue, we also recommend dc:format to carry the specific media type.


<some:image.jpg> a dctypes:Image ;
    dc:format "image/jpeg" .

The rationale behind the type versus the format is:
  * Most consuming systems do not need to know the media type of all resources, you can put an image into an <img> tag regardless of whether it's a PNG, GIF or JPEG.
  * Many publishing systems will not know the media type either -- if you annotate an image in an HTML page the browser knows its URL, and that it's an image, but not necessarily what media type it is.
  * Some systems and formats do need more information.  For example an application/flv (flash video) may require a different player to a video/mpeg4.  Equally plain text vs TEI encoded XML would require very different handlers (and would indeed require even more granularity to know in advance it was TEI rather than just XML).

And other than that I completely agree with your earlier post that the BF work needs to define their use cases and stack of technologies clearly and then provide reasoning as to why each was chosen, and each deviation from existing standards was added.  I would suggest thinking about it in terms of agents, as this seems like the easiest line in the sand to draw:  Annotations could, for example, be limited to only those descriptions that are produced by untrusted third parties.