Comment to Pointer Methods in RDF 1.0

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