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.

         ~~Yves
Received on Wednesday, 8 September 2010 13:00:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:39 GMT