W3C home > Mailing lists > Public > public-media-fragment@w3.org > October 2009

Re: FW: open annotation / media fragments

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 11 Oct 2009 22:36:43 +1100
Message-ID: <2c0e02830910110436y35e081a1h9d31dfb8b98022fa@mail.gmail.com>
To: erik mannens <erik.mannens@ugent.be>
Cc: public-media-fragment@w3.org
Hi Erik, all,

On Thu, Oct 8, 2009 at 1:46 AM, erik mannens <erik.mannens@ugent.be> wrote:
> Attached a mail from a colleague from another consortium asking if their UC
> for Fragments could be in-scope of our MF group. To be discussed!

I'll start the discussion.

> From: Herbert van de Sompel [mailto:hvdsomp@gmail.com]
> Sent: donderdag 1 oktober 2009 20:19
> To: erik.mannens@ugent.be
> Cc: hvdsomp@gmail.com; azaroth42@gmail.com
> Subject: open annotation / media fragments
> Dear Erik,
> As I mentioned while at WWW2009, I am involved in the Open Annotation
> Project (http://www.openannotation.org) that aims at creating specs and
> demonstrators of an interoperable annotation environment. The focus is on
> annotating scholarly resources, but the project takes a generic
> resource-centric perspective, and the requirements go beyond what is covered
> by the W3C's Annotea. It is our impression, BTW, that there's quite some
> people that feel like Annotea needs some serious revision anyhow in light of
> extensive evolutions since its conception. Annotea is definitely inspiring
> but it needs some clarification and extension at the least.
> Anyhow, as you can imagine, fragment addressing is an utterly important
> aspect in our annotation framework requirements, and hence we are delighted
> with the W3C Media Fragment effort. It is clear that our framework will be
> able to leverage the proposed "temporal", "spatial", "track", and "named"
> approaches. So, many thanks for your work on this!
> However, while discussing our annotating requirements, we came across a type
> of use case that we think is currently not covered by the Media Fragment
> proposal, and for which we will need a solution. Generally speaking, it is
> about cases where the resource fragment that needs to be annotated can not
> be specified by means of any of the proposed "inline fragment specification"
> approaches, but rather would need to be defined by means of a pointer to a
> special-purpose machine-readable document in which the fragment is
> specified. And the nature/content of that document would most likely depend
> on the type of resource one needs to specify a fragment for.
> An example would be an image resource - say - URI-IMG, where a third party
> (not the author) wants to externally specify an arbitrary (non-rectangular)
> region of the resource and subsequently wants to annotate it.

Annotations can be done with RDFa combined with the Media Annotations
work, I would think. Those could then link to a picture with a image
map. With the image map you can either link through from the image to
the RDFa annotation, or the RDFa annotation can link to the image map
where the area would have an id and identify it. If it was
rectangular, the link could also be given in a media fragment URI
without having to define a image map.

> In this case,
> one could create a separate resource (e.g. an SVG document) - say -
> URI-FRAG-DESC in which the to-be-annotated region would be described. And,
> then, following the # convention proposed in the media Fragment work, one
> could specify the region as: URI-IMG#description:URI-FRAG-DESC.

Except we only do rectangular regions for a reason - when using it
with a query, it defines a new resource. If we did arbitrary shapes,
we could only use them for referencing, not for "subresourcing".

> In essence,
> the idea here is that of a by-reference instead of a by-value description of
> the fragment.

If the shape is identified in a different document (such as the SVG
above, or the HTML with image map in my example), then you do not need
a media fragment URI - you can just define your own, which is much
more flexible.

> The SVG example is just one instance of a rather general class of problems,
> we think. There's only that much one can put by-value in a fragment. Another
> example that comes to mind is annotation of slices/views of scientific
> datasets, regions in a 3D resource,

Our focus is on *media*, i.e. audio and video (and possibly image). If
somebody cares to consider the different types of fragmentation
possible on other resources, they can go and define their own schemes.

> and one could even think of addressing
> arbitrary regions of HTML using a by-ref description.

Arbitrary regions of HTML are already addressable through the HTML URI
fragments, where "name" attributes are given. Not sure what the use
case here is.

> I wonder whether this class of problems fits in the scope of the Media
> Fragment work, and if so, whether it is something that you would be willing
> to further discuss and maybe even take on board. It goes without saying that
> we would be very happy to provide help if that were deemed appropriate
> and/or welcome.

Honestly: I didn't quite understand what technology he wants to
integrate. Is it reference files that can point to arbitrary segments?
Is it non-square regions? Is it slices/views of scientific datasets,
or regions in a 3D resource? I think all of these require different
solutions. I cannot really see that they are part of the same "class
of problems" and solvable with the same approach. Or does anyone see a

Received on Sunday, 11 October 2009 11:37:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:43 UTC