Subject: Re: PaceDateline

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 25 Jul 2004 14:11:23 +0200

* Dave Pawson:
> I don't think that geo-data should be part of the core. It would be a
> cool extension though.
> 
> I definitely don't think it should be associated with a date element,
> I don't see them as being at all related. Besides, I'd rather we nail
> down these date issues before we start expanding the permathread to
> discussing the format and implications of geo-data.

I agree with you. Partly.

The connection between geodata and notion of time is interesting, from a
human point of view. If we reduce the connection between geodata and
date/time to numbers, information is lost.

"Mid-February, northern Norway, in the middle of a spooky winter night"
carries different information from: 

Date: 2005-02-14T03:07:32+02:00
Latitude: 69 Deg 01 Min. 21 Sec.
Longitude: 17 Deg 13 Min. 0 Sec.

The first one says this is winter. Says that it is in Norway. Says it is
spooky. This cannot be derived from the geodata, unless the reader already
has knowledge of Norway, where Norway is on the globe, and has experience
with mid-winter nights in the north of Norway.

Of course, there is data loss when going the other way as well.

In conclusion: connecting date and geo-information when this information is
only meant for machine parsing, is quite meaningless. Allowing connection of
human-provided info for humans is not. 

(Having said that, the "Mid-February ..." thing belongs somewhere in the
content.

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 25 Jul 2004 15:55:10 -0400

> date/time to numbers, information is lost.

I disagree.  Furthermore I'll stress that the notion of equating time to
location is a horrible one, right up there with all the idiotic assumptions
about character encoding and well-formedness.  If you want to express geo-data
then do so, but do not expect a timestamp to reflect it.

> spooky. This cannot be derived from the geodata,

Yes it most certainly can.  Just as many news and mail reading programs handle
showing you things grouped by Today, Yesterday, Last week and Ages ago, it's
entirely reasonable for them to provide filtering based on geo-data when
present.  A reader program interested in providing this sort of functionality is
a hell of a lot better off having machine processable data; not some mishmash of
text parsing hacks.

> human-provided info for humans is not.

This is an application issue, not a data storage or transport issue.

Don't get me wrong, I think it's a fascinating idea.  To be able to put material
into context based on locality and time is indeed a wonderful thing.

-Bill Kearney