Hi Karen,

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

>  Owen,
> 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.