Re: temporal URI fragments (was: URIBOF at IETF meeting S.F.)

----- Original Message -----
From: <Silvia.Pfeiffer@csiro.au>

>
> In the Axioms of Web architecture - Fragments part
> http://www.w3.org/DesignIssues/Fragment.html it is stated that "When a
> document language (MIME type) has some form of intra-document naming for
> objects then it is intuitive if these names can be directly used as
> fragment identifiers." Many time-continuous Web resources have such
> named objects, e.g. QuickTime has chapter markers and Windows Media has
> marker objects. It would be intuitive to directly address them as
> fragments.
True, but using those existing media specific names within fragment
identifiers does not imply actually sending those fragment identifiers over
a network. The phrase 'intra-document' implies that resolving those names is
scoped to the retrieved representation of a resource - not to a separately
identified resource.

>
> In the W3C URI overview document
> http://www.w3.org/Addressing/URL/4_2_Fragments.html it is stated that
> "Specific syntaxes for representing fragments in text documents by line
> and character range, or in graphics by coordinates, or in structured
> documents using ladders, are suitable for standardization but not
> defined here." Time is such a property of time-continuous resources that
> also provides a structure that should be accessible directly through
> fragments.
Yes - but again this is talking about fragments /within/ a document (also
known as a retrieved representation of a resource).


>
> With both fragment types for time-continuous resources (named objects
> and timed offsets) we run into the problem of being forced to download
> the complete resource before being able to present to the user the
> expected subpart (or fragment).
Not true. If a sub-part is addressable, then only that sub-part needs to be
retrieved. Make those resources addressable using one of the many exising
syntax choices & your problem is solved.

> Understandably, fragments refering to
> anchors in html pages have been handled this way and the prescription to
> interprete the fragment component at the client side has come from this
> background. This just does not fit with large-volume time-continuous
> data. Sometimes, innovation also means changing a traditional way of
> doing things.
True - but the desire to retrieve a portion of a remote resource is not
innovative. That functionality is easily achieved with the existing
standards.
If you want to restrict the approaches to use only a URI, then you could:
 - use sub-path (the '/' character)
 - use segment parameters (the ';' character)
 - use queries (the '?' character)

If you expand your design choices to include a full request, you could use a
request header of some kind - or even introduce a new one. But I suspect you
are after a pure URI approach.

> On the other hand,
> there is "large volume data" that is stored in final-format documents
> (resources), but contain information parts of interest (URI fragments).
Those parts of interest are merely additional resources & deserve their own
identifier. Your approach does exactly this - it makes sub-parts uniquely
identifiable and retrievable. We are just saying that it is not necessary to
change the meaning of the URI or change the protocol.

>
> Let me however turn your argument upside down. There may be databases
> that contain snippets of time-continuous data and can be queried. For
> such databases you may want to use the time specification that we are
> proposing in a query language such as:
> http://foo/bar?game=football;play=@utc=20030418T200000Z
>

How about defining an XML grammar that specifies the rules for constructing
the URI rather than defining a single global URI syntax. This allows for
each media server to use their own URI syntax (query terms, sub-paths, etc),
but standardizes the names, structure and types of data used to construct
those URI.

For example:
<snippet src='http://foo/bar?game=football'>
 <input name='time_offset' type='utc' target='query' target_name='play' />
</snippet>

would generate the uri of http://foo/bar?game=football&play=20030418T200000Z

<snippet src='http://foo/bar/games/football'>
 <input name='time_offset' type='utc' target='path' target_name='start_from'
/>
</snippet>

would generate the uri of
http://foo/bar/games/football/start_from/20030418T200000Z

A generic client would only need to find the following elements
 /snippet/@src
 /snippet/input[@name='time_offset']

in order to construct a URI that conforms to what an arbitrary server
expects to receive.

Received on Tuesday, 8 April 2003 02:05:17 UTC