- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 20 Oct 2010 06:36:56 +1100
- To: Raphaël Troncy <raphael.troncy@eurecom.fr>
- Cc: Bernhard Haslhofer <bernhard.haslhofer@univie.ac.at>, Davy Van Deursen <davy.vandeursen@ugent.be>, Jack Jansen <Jack.Jansen@cwi.nl>, public-media-fragment@w3.org, Robert Sanderson <azaroth42@gmail.com>, Simon Rainer <Rainer.Simon@ait.ac.at>
I've not really replied to this - going through my backlog. 2010/9/14 Raphaël Troncy <raphael.troncy@eurecom.fr>: > Hi Silvia, > >> 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. > > Playing the devil advocate, I think I disagree. I see a lot of value in > sharing such URI that reference a part of a media in the context of an > annotation. You said such URI require the annotations, but I would object > that a web server could decide to do content negotiation on this resource > and either serve the image (that could have a region cropped/highlighted in > the browser) or directly the annotation. Whether using content negotiation > for such a setting is a good idea or not is another debate. But in my case, > this URI would have the purpose to either highlight a part of a media > (presentational) or serve the annotations that concert this part. As an example: Annotation: <?xml version="1.0" encoding="UTF-8"?> <rdf:RDF .... > <rdf:Description rdf:about="http://example.com/annotations/1"> <a:annotates rdf:resource="http://example.com/image1.jpg#xywh=200,300,40,40"/> <d:title>Some annotation text....</d:title> </rdf:Description> </rdf:RDF> Something has to interpret that annotation in the browser, since no browser will know natively what to do with that markup. So, it can be converted (either on the server or in JavaScript) to one of the following three: 1) A spliced image with annotation text <img src="http://example.com/image1.jpg#xywh=200,300,40,40"/> <p id="annotation">Some annotation text...</p> 2) A image map with annotation text <map name="annotation1"> <area href="http://example.com/annotations/1" title="Some annotation text...." shape="rect" coords="200,300,40,40"> </map> <img src="http://example.com/image1.jpg" usemap="#map1"/> 3) An image with an SVG mask <img id="target" src="http://example.com/image1.jpg"/> <style> #target { mask: url("#c1");} </style> <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <defs> <mask id="c1" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse"> <rect id="rect" width="40" height="40" style="fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)"/> </defs> <use xlink:href=”#rect”/> </svg> <p id="annotation">Some annotation text...</p> So my argument was that in option 1 we have to determine what that URI means because the browser interprets it for presentation. But the annotation itself can have it no matter whether what decision we make for 1, because there is an additional step of interpretation necessary. Option 1 just makes it easier to specify a splice - just look at how complex 3 is in comparison and that example only works in Firefox. >> 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. > > Q: SVG mask would work for the temporal dimension? The temporal dimension is already decided to be full representation and a highlight on the selected area. The discussion was focused on spatial issues, not temporal. > The annotations are about a part of the media, there is not necessary a > reason for serving them when requesting the full resource. I do not understand what you mean by that. It sounds to me like you are supporting the splicing for the spatial domain, which is where I have moved to with my opinion now, too. Cheers, Silvia.
Received on Tuesday, 19 October 2010 19:37:50 UTC