Subject: Re: PaceDateline

From: "Arve Bersvendsen" <[email-masked]>
Date: Mon, 26 Jul 2004 00:16:04 +0200

* Bill Kearney
> > 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.
> 
> 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.

Eh. I think we are in agreement here. I might have expressed it in a clumsy
way: I think geodata is wonderful as well: I just don't think it belongs
inside a date construct.

> > "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,
> 
> Yes it most certainly can.  

It carries a lot of the information, but not all. Note that I'm not arguing
in favour of the textual piece of information: I'm simply arguing that
they're different, and carries different information to the person _reading_.

btw: I don't think the first construct belongs in DateLine. It would suit
much better within the first few paragraphs of the actual content.

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

+1 

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

Yeah, but you don¨t think it belongs inside a date construct either?

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 25 Jul 2004 21:21:52 -0400

> I think geodata is wonderful as well: I just don't think it belongs
> inside a date construct.

Indeed, the ambiguities on timestamps are bad enough already.

> they're different, and carries different information to the person _reading_.

Well, to a certain extent there's a desire to have syndication data be able to
provide reasonably detailed data.  What varies are people's ideas of what's
considered reasonable.  Some folks would annotate the beejeesus out of the text,
others are fine with letting their own minds fill in the details.

> much better within the first few paragraphs of the actual content.

In the text content?  No, I don't think so...  There's enough gibberish inside
content elements now.  Inside the entry container more likely.

> Yeah, but you don¨t think it belongs inside a date construct either?

My turn to be clumsy, I wasn't under the impression anyone was trying to jam it
there.  I agree that it seems like a tremendously bad idea.

Besides, it seems like it ought to be some sort of per-channel default.  Better
to let something publish 'where' it's source should be considered such that it
could be inherited.  Should an individual entry need to be different, much like
language, it'd be appropriate to add it as needed.  Prepare yourself, however,
for a huge mess as to what are considered 'location' constructs.  If you think
timestamps are bad....

I suppose that raises the question of which location is being stated.  An XML
document is delivered from a source. But it's unlikely most feeds would care to
have the location of their colocated server or hosting provider be used as
"their" location.  In the profile scenario of creation/editing it might be
useful to have the content management system track something to this effect.  I
shudder to think about management abuses of said data.  And much like the
timestamp issue it's likely the published 'location' would be different.  Of
course there's also are we publishing location "from" someplace or "about"
someplace else?  What do we markup while on a flight from NYC to LA (somewhere
over Kansas) while posting about a meeting in London?  Open can, prepare worm
recipes...

This is reminiscent of the arguments RSS had over the item link element.  Is it
a link "to" something or "about" something?

Likewise, is this the location about which the content describes or is it some
location (or god help us, various locations) involved in its creation?  I'm sure
the feeping creaturitis crowd would happily run amok annotating it to an
infinite degree.

-Bill Kearney