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

Dear Paul,

Paul Prescod wrote:
> Silvia.Pfeiffer@csiro.au wrote:
>> 1) With the temporal offsets we are not querying any databases nor are 
>> we composing a previously non-existent Web resource. All we are doing 
>> is addressing a subpart of a Web resource. 
> 
> The subpart is a resource. You want the client to address it and the 
> server to return a representation of it. To me, this is the definition 
> of a resource.

Anything can be called a resource as a resource is a conceptual entity 
(see http://www.w3.org/DesignIssues/Generic.html). Let's not get 
philosophical about it.

>> ... It is my understanding that that was the original intention of 
>> creating the fragment component and therefore we should make use of it.
> 
> The fragment component is something interpreted entirely on the client. 
> That's why it doesn't generate a "new resource" the way the fragment 
> identifier is perceived to.

That is a technical way of looking at fragments. Let me extend my 
argument a little.

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.

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.

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). 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.

>> 2) Query results cannot be cached in network proxies, though Web 
>> resources can.
> 
> Query results can be cached in network proxies.
<...>

OK, accepted.

> Caches will treat a fragment identifier on the wire as a bug, as they 
> should. They will probably discard it.

That's ok and conformant to the current standard. Doesn't mean the 
software cannot be extended though - especially if there is a market 
requirement. By the way, not all existing software treats fragment 
identifiers on the 'net as bugs: Apache for example is perfectly happy 
to handle it.

>> While this usage prescriptions may be appropriate for html pages, it 
>> is not good for Web resources that consist of large volume data, of 
>> which the user is only interested in receiving a small subpart.
 >
> I believe your "large volume of data" is equivalent to what the specs 
> mean when they talk about "database".

No, definately not. On the one hand, there is (or rather: are) "large 
volume data" that is (are) stored in databases, which contain structured 
textual and binary information in queryable format and are never 
regarded as one complete entity (or resource), but rather as a set of 
entities containing information that composed together correctly answer 
certain questions of users (returned as a resource). 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). 
Therefore, please do not call time-continuous resources a "database".

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

Cheers,

Silvia.

Received on Tuesday, 8 April 2003 00:17:47 UTC