- From: <samuelm@dit.upm.es>
- Date: Mon, 21 Jan 2013 19:39:55 +0100
- To: "Carlos Iglesias" <carlos.iglesias@fundacionctic.org>
- Cc: public-wai-ert@w3.org
Dear Carlos, all, I would like to provide some input on Pointer Methods in RDF 1.0 [1], an ERT WG document you are editing, for the next update on the draft. I know we are not currently dealing with in the ERT WG with that document, so my apologies in advance if this is not the time when internal comments are expected; in that case, you may just archive them to have them revisited when it is time. My comment is related to the following use case: suppose I would like to assert that a specific portion of an image or a video does not conform to minimum contrast accessibility criteria. Of course, the image (or video) as a whole does not conform, but I would like to signal the offending part. Then, I would need to point to a specific point or region in time or space in a multimedia content. Pointer Methods currently support pointers based on XPath and XPointer expressions, as well as binary offsets (byte or char-based), together with others which are completely unrelated to our case. It can be quite difficult to express the pointer we need as a set of XPointer expressions and binary offsets. Moreover, I would like the pointer to be independent of the specific media format, codecs, etc. (e.g. because the same resource can be served using different media types, depending on the client capabilities and negotiation with the server), so I cannot rely on the theoretical possibility to express that as a very complex set of binary-based pointers. Fortunately, on September 25, the Media Fragments Working Group published Media Fragments URI 1.0 (basic) [2] as a W3C Recommendation, which "specifies the syntax for constructing media fragment URIs and explains how to handle them when used over the HTTP protocol." This recommendation defines (section 4) a syntax and semantics to refer to media fragments in the fragment part of a URI-ref. The fragments can refer to four dimensions: temporal, spacial, tracks, and named fragment ids (e.g. chapters). That way, e.g. the fragment #t=10,20&xywh=160,120,320,240 refers to the fragment of the video that spans from 10s to 20s and is clipped to a 320 x 240 pixel rectangle rooted at (160, 120). I would suggest reusing that W3C Recommendation in the Pointer Methods. Different approaches can be followed: a) Consider media fragments are URI fragments indeed, and thus a media pointer is simply a URI-ref, already covered by existing pointer classes. In that case, at least a reference to the Pointer Methods document should be provided, in order to suggest that the reader use it. A non-normative example of its usage could also be considered. b) Explicitly define a new Media Fragment Pointer class that extends the Expression Pointer, whose syntax is that of the Media Fragments. This would somehow parallel the case of XPointer Pointers (which could be expressed as URI fragments but deserve its own class, as they go beyond URI fragment semantics). c) Define as well all the necessary RDF properties and classes to encode the semantics of Media Fragments in RDF, plus a mapping between URI-based and RDF-based representations of Media Fragments. This would ease semantic processing of Media Fragment Pointers at the cost of increasing the complexity and adding another representation of Media Fragments. In fact, Media Fragments would not completely solve the above presented use case, as we could only provide a rough approximation to the area that needs to be revised in order to met the contrast criterion. Usually, this will be an irregular shape, not at all a rectangle. My initial idea had been to resort to HTML map and area elements, which allow defining object areas with almost any shape. However, I have not figured out how they could be mapped in a straightforward and unambiguous fashion to RDF; I mean, I am not aware of a standardized mapping of XML infosets into RDF (we could always define a set of properties that mirror map/area semantics, but we would be replicating specifications). Any ideas on this direction are welcome. Please do not hesitate to ask me for any clarifications that might be needed. Regards, Samuel.
Received on Monday, 21 January 2013 18:42:30 UTC