Re: open annotation / media fragments

Dear Herbert,

> Many thanks for having started a discussion about the mail I sent via Erik
> Mannens, last week.

No problem, but please, come directly here to discuss further. This 
mailing list is open and public, so just subscribe to it (or read the 
archive online) and post to it.

>  Based on your feedback so far, I would like to make
> some clarifications regarding the proposal I formulated:

As others from this group, I understand better your motivation with 
these clarifications.

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

Most of our use cases require indeed to defined the segment boundaries 
within the URI, so it comes down to what you call the "by-value" 
description of segments of resources. We have furthermore the 'name' 
dimension, which I agree, is currently weakly defined in our document. 
The idea is that the URI contains just the reference to a label which 
dereference for a particular media to the actual (spatio-temporal) 
boundaries of segment. Here, we are closer to what you call a 
"by-reference" description of segments of resources.

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

Yes ... but you create an indirection. I second therefore Sylvia and 
Jack replies. This is out-of-scope of the Media Fragments URI version 1 
charter. I note also that this is exactly what MPEG-7 provides: the way 
to define arbitrary complex segments of multimedia content (potentially 
even not temporally and spatially connected) within an XML file.
What you're adding is a specific keyword where the URI of this XML file 
is pass in the URI. As Jack pointed out, there is danger in doing so 
regarding security.

The Media Fragments URI (version 1) limits itself to simple rectangle 
bounding box for addressing still images. It seems you have use cases 
where you would like to have arbitrary shapes? Is this the case? We have 
postponed such possibilities to a possible version 2 of the 
recommendation, but by curiosity, I would like to know which use cases 
require such complexity. Do you have such a document written with some 
use cases that would justify to define arbitrarily complex segments in a 
URI? Is this just for identification purpose or also for retrieval 
through the network?

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

Yes. Actually, in this case, you advocate that the fragment is not sent 
by any means to the server. You expect to send a request to the server 
to GET the full original resource, and once the full original resource 
is received, you would like the UA to parse this specific XML file 
defining a potentially complex segment in order to overlay or highlight 
it on client side. Is this right? What prevents you to do that already 
with some custom scripting code on UA side? I can imagine a browser 
plugin that does that, so what should be standardized?

Thanks for the discussion.
Best regards.

   Raphaël

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Wednesday, 14 October 2009 07:41:02 UTC