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

On Wed, Sep 8, 2010 at 7:16 PM, Bernhard Haslhofer <
bernhard.haslhofer@univie.ac.at> wrote:

>
> On Sep 8, 2010, at 2:51 AM, Silvia Pfeiffer wrote:
>
> > More personal opinion here. :-)
> >
> > I agree with Jack that you should experiment with this using your own
> approach, since without use cases and experience the browsers will not
> implement any of this.
> >
> > I have, however, a pretty big caveat with standardising this approach:
> right now we are discussing with the browser vendors on how to present
> spatial media fragment URIs. There is a preference to use them for splicing
> pictures, i.e. for rendering only the referenced image or video region.
> >
> > I do not believe that matches your intentions here. IIUC your intentions
> here are to only have a means to provide annotations to regions. I think
> this is more of a "image map" type approach than an "image splicing"
> approach - correct me if I'm wrong.
> >
>
> We need MFs to have a standard means to *address* annotated media fragments
> on the Web using URIs. So it is really about addressing and not so much
> about retrieving subparts of resources.



Note that I never spoke about what parts will be retrieved. That is already
specified in the media fragment URI specification. In the case of spatial
fragments there will not be a partial retrieval, but always a full
retrieval. What we are talking about is the rendering: what will actually be
displayed in the Web browser.



> Annotation clients will follow the reference in the URI fragment for
> instructions on how to render the annotated regions; e.g., with SVG
> overlays.


That's interesting. What is an "annotation client"? Is it a Web browser? And
how are you specifying the instructions for how to render the spatial
regions? Is that part of the URI? Do you have an example?



> Splicing complex spatial regions (e.g., polygons) out of media objects
> doesn't make much sense, I guess.
>

Probably not. I am wondering if we need to specify a separate mechanism for
when you want to do highlighting in comparison to splicing.


> In this context, I have a very direct question: what do you expect the
> user will see differently for your Web page when they browse to content
> which has such annotations?
> > Will they see hyperlinks on different areas? Will they see overlays? What
> would be the consequence of this? The problem is: as long as there is no
> visual consequence of having such annotations available, there isn't really
> anything that the browser vendors can implement and they will just leave it
> all to javascript technologies.
>
> The feature we are requesting is really for annotation clients, most of
> them running in browsers (as Web-apps or browser extensions). These clients
> will render the visual overlays. But it would be great if these annotations
> clients use the same mechanism for addressing fragments as the browsers do.
> Therefore my request for some extension mechanism (or at least
> recommendation). Otherwise each annotation client will implement its own
> fragment identification hack....
>

Since they will be running in a Web browser, and since we expect the browser
vendors to implement support for media fragments, and if that support will
imply splicing, then it would seem that if we used the same URLs, the
plugins would need to over-rule a browser mechanism to make the visual
overlays (if that is even possible).

But if you want a standard means of doing highlighting with a standard means
of specifying regions, then that is IMO a different type of media fragment
and needs its own specification. If it is standard, then it should also be
implemented by browsers and not separately by every "annotation client". I
wonder if we can find a means to make it without having to reference another
file - after all, that will increase the round trip time before anything can
be done with the URL. We might be able to just put something like the canvas
path into a url.

Cheers,
Silvia.