Re: URIBOF at IETF meeting S.F.

At 12:22 AM 2003-03-07, Silvia.Pfeiffer@csiro.au wrote:
What we want to standardize is a way of describing time offsets,

[some general comments]

+ FYI re process:

Dan Brickley forwarded this proposal to <public-tt@w3.org> and 
<www-annotation@w3.org> on
account of their [presumable] interest in the topic.

+ IMHO re standing of the question for a URI-spec solution:

Usually we say that the interpretation of #fragment is strictly up to the 
rules of the type
of the recovered representation.  In this case it makes sense to think 
again, because there
is a broad class of temporal-data datatypes where the representation of the 
data is peculiar
to each but the common concept of a proper timebase for each such temporal 
media object is
generally interoperable.

+ W3C prior art:

The prior art in W3C is summarized in the SMIL timing model.

  http://www.w3.org/TR/smil20/smil-timing.html#Timing-Overview

This demonstrates the capability to deal in terms of local-time-base-valued 
parameters with a
welter of media types and achieve a unified presentation responsive to one 
common master
timebase.

For an example of the use of this SMIL timing model in annotations, see the 
annotations
capabilities in the ANSI/NISO Z39.86 Digital Talking Book:

   http://www.niso.org/standards/resources/Z39-86-2002.html#Bkmk

see also

  http://www.loc.gov/nls/niso/

+ Notation options within the URI framework

The semantics of this reference fits a natural English expansion of
   ".. where [some named parameter] is [some given value]"  In other words, 
it fits
the generic semantics of the searchPart syntax.  So an alternative syntax for
this functionality would yield the examples


>http://foo/bar.mov?smpte=00:00:14:15
>(start downloading at 14 seconds and 15 frames into bar.mov)
>
>rtsp://foo/bar.avi?utc=20030308T143000.00Z
>(start streaming data recorded on 8th March 2003 at half past 2pm)
>
>http://foo/bar.mpg
>(start downloading from the start)
.. is the default, not indicated by fragment.

>rtsp://foo/bar.rm?utc=now
>(start streaming now)

needs a parameter name that implies wall-clock time, maybe not utc, but not
an anonymous reserved token, must be qualified that this token is a metavalue
in the timeStamp dimension.  That is a limitation that comes with using the
generic searchPart syntax, but it's worth it.

This may also be the default.

+ Other coordination points:  timestamp formats for SMTP and 
calendaring-and-scheduling.

+ Other process:  Sounds like an example of what one would want to register
broadly-applicable property-names for use in ?name-value-pair-list
searchParts in URIs.  Of course any properties one would be likely to want
to commonly use are also likely to have standard definitions somewhere
already.  A registry of short names for standard properties?  Or
URI-references as property names as in RDF?  All it takes is encoding the '#'.
But 'who wants to write those things' when 'smpte' works?

Al

>Dear Larry, URI specialists,
>
>My background is in multimedia, having been involved in the IETF mainly in 
>the Audio/Video transport area. We noticed that there will be a URIBOF at 
>S.F. and that the URI standard is getting reworked. We'd like to put some 
>additional information into this process.
>
>What we really want to be able to do is to reference particular events in 
>audio and video files, and we want this to be part of the URI so that 
>these references can be used in links from other resources, result lists 
>of search engines, or written on the back of a beer coaster.
>
>For some video formats it's possible for the author to include named 
>markers, and that's great -- these can already be referenced as a normal
>named fragment.
>
>What we want to standardize is a way of describing time offsets, because 
>this is a very useful and intuitive concept, and is technically feasible 
>in streamable file formats. With a standard notation for time offsets in 
>the URI, user agents and servers can behave consistently and users can 
>construct URIs in a well-known way when they find an interesting point in 
>a media file and wish to reference it.
>
>Our proposal:
>-------------
>What we want is to address time offsets into videos in a simple, intuitive 
>and human readable form. The "#fragment" part of URIs naturally lends 
>itself to this task and have therefore come up with the following 
>solution, inspired by the timestamp specification in RTSP:
>
>#@npt=14.5
>
>-> the "#" part signifies a fragment specification
>-> the "@" tells us to look "at" that time specification
>-> the "npt=" part is a time scheme just like in RTSP and we are also 
>proposing npt, smpte, smpte-30-drop, smpte-25, and clock
>-> the time format itself depends on the time scheme, this one signifying 
>a 14.5 seconds offset
>
>More details are specified in an I-D that we have submitted as a 
>discussion document to IETF:
>
>http://www.ietf.org/internet-drafts/draft-pfeiffer-temporal-fragments-00.txt
>
>Here are examples for temporal URI fragment offsets that we envisage:
>
>http://foo/bar.mov#@smpte=00:00:14:15
>(start downloading at 14 seconds and 15 frames into bar.mov)
>
>rtsp://foo/bar.avi#@utc=20030308T143000.00Z
>(start streaming data recorded on 8th March 2003 at half past 2pm)
>
>http://foo/bar.mpg#@start
>(start downloading from the start)
>
>rtsp://foo/bar.rm#@now
>(start streaming now)
>
>
>Fragment handling
>-----------------
>Currently, the preferred handling of "fragment" offsets is that they are 
>only interpreted by the client and not transmitted to the server at all. 
>For multimedia data and the "#@..." fragments we're proposing, it makes 
>sense, however, to allow the server to interpret the fragment offset in 
>order to reduce network load by serving out data only from the offset that 
>a user is really interested in receiving.
>
>A more detailed discussion of this is included in the draft:
>
>http://www.ietf.org/internet-drafts/draft-pfeiffer-temporal-fragments-00.txt
>
>
>Best Regards,
>
>Silvia Pfeiffer & Conrad Parker.

Received on Monday, 10 March 2003 09:07:51 UTC