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

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

From: Robert Sanderson <azaroth42@gmail.com>
Date: Fri, 10 Sep 2010 16:31:33 +0100
Message-ID: <AANLkTikAJ8fDEW7ni2xrRxyPhTFPktskvZ14K1FMsRvX@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Bernhard Haslhofer <bernhard.haslhofer@univie.ac.at>, raphael.troncy@eurecom.fr, Davy Van Deursen <davy.vandeursen@ugent.be>, Jack Jansen <Jack.Jansen@cwi.nl>, public-media-fragment@w3.org, Simon Rainer <Rainer.Simon@ait.ac.at>
Dear all,

Just to try and clarify one aspect of the discussion.  The need for the by
reference MF URI is to provide a unique and universally understood
Identifier for a part of a resource.

Annotation is just one use case for such an identifier, although it is our
current one.  Any sort of RDF data model or Linked Data approach would
benefit from a standardized way of addressing complex segments.
For example, one might want to identify a person in a photo and make the
assertion that the segment is a depiction of someone.  Or identify a SE/NW
running road (which given a rectangular bounding box would be useless) on a

For other media types which have not defined fragment schemes, it is hoped
that they would adopt a MF type of approach.  At which point it opens up a
plethora of possibilities for scholarly citation of parts of datasets,
identification of parts of 3d models, tracking moving objects in video and
so forth.

And some other comments, which can safely be ignored :)

* As to what happens when the referenced resource changes, there are many
issues with the dynamic web and defining fragments on third party
resources.  For example, defining a MF on a resource that provides content
negotiation between both an HTML description and an image is problematic as
the HTML representation has the same URI, and the fragment part of the URI
for HTML has a well defined meaning already.  Even without content
negotiation, the representation retrievable from a URI could change over
time between being HTML and an image.  So, it seems disingenuous to say that
there's a problem with by reference because the referenced resource may
change when the same applies to MFs in general.

* The rendering is orthogonal to the requirement for addressing complex
segments.  What a UA does with the by reference MF URI will be exactly the
same as what it would do with a by value MF URI. Once it has processed the
referenced information it is in the same state as after processing the by
value information included on the current URIs.  A UA might not understand
the referenced resource, but equally it might not understand the by value
information either.

* I agree that XSS is a potential rendering issue.  One could imagine
embedding malicious javascript into an SVG document that is supposed to be
acting as a mask.  I also agree that UAs will need to retrieve the
referenced resource in order to decide whether or not they can process it,
unless additional information such as the mime type were provided in the
URI.  Even mime type may not be sufficient to decide, given domain specific
description documents.  However, as above, I consider that the rendering is
orthogonal to the need for identification -- the UA can simply refuse to
process the by reference information.

Many thanks,

Rob Sanderson
Los Alamos National Laboratory

On Fri, Sep 10, 2010 at 4:55 AM, Silvia Pfeiffer

> On Fri, Sep 10, 2010 at 4:50 PM, Bernhard Haslhofer <
> bernhard.haslhofer@univie.ac.at> wrote:
>> Silvia,
>> for images  we can definitely solve the rendering with SVG; for other
>> media types (e.g., videos) we could also define / reuse elements that define
>> the necessary semantics for expressing segment/fragment/region information.
>> But then we have two divergent developments: "the MF spec for addressing
>> fragments in media objects " (implemented by browsers) and  some other "spec
>> for addressing fragments in media objects in the context of Web annotations"
>> (implemented by annotation clients running in browsers).
> I actually don't see that as a problem, because they have different goals:
> one is presentational the other is referential. I don't think you would
> share the URLs that you are using for the annotations in a single URL, since
> they actually require the annotations and everything to be delivered with
> them to mean anything, so a link to the full resource that has everything it
> in makes a lot more sense IMHO. Then, you could on top of that use a slicing
> MF URL to zoom into a particular region of the full resource to see the
> diverse annotations.
> As long as you are using SVG for providing annotations, I think you are
> following a standard and that is good enough.
>> If the MF spec proposes some solution (ref approach, SVG approach,
>> whatever) for addressing complex regions, we could build on that...
> Why not just reference a SVG directly as the mask description - that's much
> better than a MF URL. After all, it's not about delivering fragments for
> your use case, but about delivering annotations on the full resource, IIUC.
> I think I'm almost convinced now that for that use case we don't actually
> need URLs - but feel free to explain to me why it would all need to be in a
> single URL.
> Cheers,
> Silvia.
Received on Friday, 10 September 2010 15:32:06 UTC

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