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

Re: open annotation / media fragments

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 13 Oct 2009 19:29:34 +1100
Message-ID: <2c0e02830910130129uaf6960dr7d1ea859378d7385@mail.gmail.com>
To: erik mannens <erik.mannens@ugent.be>
Cc: Jack Jansen <Jack.Jansen@cwi.nl>, public-media-fragment@w3.org
On Tue, Oct 13, 2009 at 6:32 PM, erik mannens <erik.mannens@ugent.be> wrote:
> Dear all,
> Here's already some feedback/clarification on our feedback ...
> ====
> Dear all,
> Many thanks for having started a discussion about the mail I sent via Erik
> Mannens, last week.  Based on your feedback so far, I would like to make
> some clarifications regarding the proposal I formulated:
> 1. The current approaches specified by your Media Fragment work are crucial
> for the Open Annotation project I am involved in. We will extensively apply
> them.
> 2. The currently specified Media Fragment approaches can all be regarded as
> "by-value" descriptions of segments of resources, i.e. the fragment on the
> URI contains all the information required to specify the segment. An example
> from your specs is
> http://www.example.com/example.ogv#track='audio'&t=10s,20s.
> 3.The "by-value" approach of (2) can cover a lot of cases, but when trying
> to specify a complex segment of a resource it will most likely not provide
> an adequate level of expressivity. Think, for example, of an arbitrary path
> drawn on top of an image resource.  In order to cover these kinds of cases,
> we think a generic "by-reference" approach would be a flexible solution
> providing extensibility.
> 4. We think that a by-reference approach aligned with your existing
> approaches would consist of a pointer expressed as a fragment on a URI. The
> pointer refers to a resource that contains a description of a complex
> segment of the resource. For example:
> http://www.example.com/example.jpg#description=http://www.example.com/segmen
> t.xml, whereby:
> - http://www.example.com/example.jpg is the image for which a complex
> segment is being specified;
> - http://www.example.com/segment.svg is a machine-readable document that
> describes the segment.
> 5. The essence of our approach is the fragment/pointer mechanism.
> Communities could leverage this generic mechanism by specifying which types
> of machine-readable documents should be used to specify segments for which
> types of resources (e.g. by media types). Hence, the generic by-reference
> approach would allow covering a wide variety of cases including the ones
> mentioned I mentioned in my original post (arbitrary segments of an image;
> slices/views of dataset, regions in a 3D resource). Indeed, they would most
> likely require a different kind of machine-readable document to describe the
> segment,  but the pointer mechanism would be shared by all.
> 6. We do understand that, unlike in your current approaches, the
> by-reference approach would not always yield the possibility of generating a
> sub-resource that only contains the specified segment. But, it would always
> allow the delineation of the "region of interest" in the original resource.
> For example, the SVG-expressed path could be overlaid on the image by a
> client or server.
> 7. We also understand that we could define our own fragment approach to
> handle these cases, but given the similarity of the problem spaces, we would
> very much prefer this to be covered in a W3C spec that focuses on media
> fragments already.
> I hope this clarifies our request/proposal.
> Kind regards
> Herbert Van de Sompel

Hi all,

It seems Herbert is reading this thread - he should just get involved
here directly! :-)

It seems I did understand some of what Herbert is asking about.
However, the biggest problem with an indirection is the resolution.
Such an approach would require the specification of the format of the
resource being redirected to. Doing something like this generically
across all application possibilities is IMHO impossible. It could be
restricted to a SVG file - at least then it would be specific.

In any case - such an approach lies outside the scope of our working
group and will really require a whole new cycle to go through:
requirements document & specification of not only the fragment
addressing scheme, but also the format of the file that identifies the
fragment. Definitely outside what we can do here.

Received on Tuesday, 13 October 2009 08:30:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:44 UTC