Re: URLs should contain types [AND DATES]

Terry Winograd (winograd@interval.com)
Sat, 22 May 1993 10:04:32 -0800

Message-Id: <9305221704.AA25025@interval.interval.com>
Date: Sat, 22 May 1993 10:04:32 -0800
To: Larry Masinter <masinter@parc.xerox.com>
From: Terry Winograd <winograd@interval.com>
Subject: Re: URLs should contain types [AND DATES]

As long as Larry is muddying the waters by arguing for adding types to URLs
(with which I actually differ), I will also toss in a suggestion I have
been holding onto for a while that they should include Date/Times. I'll
start with a fable:

-----

Imagine finding among the debris on your desk a scrap of paper that says
"Joe Doe, Marriott Hotel, 445-9834 room 334". Seems like a perfectly good
locator, but should you call that number to find Joe?

PROBLEM 1 (relative context): Maybe that slip of paper came back with your
notes from your last trip. Maybe the number is from some other city. So
we need a more universal format for locators: it would be better to have
"Joe Doe, Marriott Hotel, USA +01-415-445-9834x334".

PROBLEM 2 (time of knowledge): This is a step in the right direction, but
should you call? What if the note was written last year? Clearly it would
be more useful if the note said "5/20/92 - Joe Doe, Marriott..." Then you
would have an idea whether or not it was from your distant past.

PROBLEM 3 (extent of validity): Even if it said "5/20/93 - Joe..." you
wouldn't know if you could call. What if it added "... He will be there
until the 23rd"? Then you would know whether it was usable today.

-----

I have chosen a hotel number consciously, since the kind of transience we
associate with hotel residence is the appropriate metaphor for on-line
objects, when we look at the decades-centuries time scale. In general the
world will be full of "stale locators" and it is very useful to be able to
detect them. Notice that the problem is not just one of failure to find
something where you expect it, but also of getting the wrong item (someone
else has checked into the hotel room!).

So the basic proposal is to have two OPTIONAL date/time fields in a URL,
one the "AS-OF" time, which gives a time at which the locator was asserted
to be valid, and the other an "UNTIL" time, which declares a commitment by
the management of the location that the item will not be changed or moved
before that time. This does not mean that it will necessarily go away
after that. A locator with a past-due UNTIL time may still be a very good
hint for finding something.

--t