W3C home > Mailing lists > Public > public-media-fragment@w3.org > September 2010

Re: Expressing complex regions with media fragments - use cases + possible solution

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 8 Sep 2010 09:00:39 -0400 (EDT)
To: Bernhard Haslhofer <bernhard.haslhofer@univie.ac.at>
cc: public-media-fragment@w3.org, Robert Sanderson <azaroth42@gmail.com>, Simon Rainer <Rainer.Simon@ait.ac.at>
Message-ID: <alpine.DEB.1.10.1009080859140.30590@wnl.j3.bet>
On Tue, 7 Sep 2010, Bernhard Haslhofer wrote:

> Since it is hardly possible to address all possible segment shapes in a 
> fragment identification specification, we propose to introduce a new 
> fragment key/value pair for the spatial dimension, which enables 
> fragment identification by reference. The key could be "ptr", "ref" or 
> something similar and the value a URI. The URI points to a resource, 
> which provides further information about the properties of the spatial 
> region/segment.
> For example:
> http://www.example.com/map1.jpg#ref=http://www.example.com/region/1 addresses a complex segment (polygon) in a map (image)
> http://www.example.com/video1.avi#t=10,20&ref=http://www.example.com/region/2 addresses a complex segment (ellipse) within a video sequence
> We propose to leave the interpretation of by-reference fragments to the 
> client. In our annotation use cases this information will typically be 
> delivered as part of the annotation RDF document and the fragment nodes 
> (http://www.example.com/region/1, http://www.example.com/region/2) will 
> have types (e.g., xyz:SVGFragment, xyz:MPEG7Fragment, etc.) assigned 
> that indicate how to correctly interpret the information. If clients do 
> not understand the used fragment identification type, they can still 
> fallback and at least display the annotation for the full media object.

And the main issue is... what happens when the content pointed by 'ref' 
changes over time, or disappear?

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Wednesday, 8 September 2010 13:00:45 UTC

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