W3C home > Mailing lists > Public > uri@w3.org > April 2003

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

From: Paul Prescod <paul@prescod.net>
Date: Mon, 07 Apr 2003 22:43:32 -0700
Message-ID: <3E926184.5080005@prescod.net>
To: Silvia.Pfeiffer@csiro.au
CC: uri@w3.org, Conrad.Parker@csiro.au

Silvia.Pfeiffer@csiro.au wrote:
> Dear Paul,
>> 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).

Good, then we agree!

> Let's not get philosophical about it.

That's fine with me. Concrete is better than philosophical. What 
concrete problem arises from using query strings instead of fragment 

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

I absolutely agree. When you want the decomposition of the object to 
occur on the client side, use fragment identifiers. When you want it to 
happen on the server side, use query strings. One nice thing is that you 
can construct a URL that uses both and each component understands its 

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

As you said, it isn't useful to get too philosophical. There is a 
"thing" on the other side. You want some information from that thing, 
not the thing itself. That's what query strings are for. I can avoid the 
word database if you prefer.

According to Tim B-L:

When a query string and fragment identifier are used, the function 
evaluated on dereferencing a URL

          select(get( "foo", "query("bar","baz")), "frag")


     * query (resource, querystring) is evaluated by the resource "bar"
     * "bar" is opaque to all except the server "foo" ;
     * "baz" is a format understood by client and by the resource "foo/bar";
     * get(server, restofuri) is executed by the client engine which 
understands "foo" but not "bar"
     * select(fragmentid, resource) is evaluated on the client by the 
resource's handling code


You obviously want the time-specifier to go within the "get" not within 
the "select" because only the stuff within the "get" goes across the 
wire. Time-specifier stuff could also go in the "select" but that will 
be client-handled.

>  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

I agree. I do not understand how this turns my argument upside down. To 
me, it makes sense that you would use the same syntax for what you call 
a database and what you call a final-format resource. The Web makes no 
distinction between those two things and you haven't demonstrated any 
need to introduce such a distinction.

What's the practical problem with using the pre-existing query 
identifier syntax?

  Paul Prescod
Received on Tuesday, 8 April 2003 01:43:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:05 UTC