Re: Using feeds for time/event data?

["wkearney99" <wkearney99@hotmail.com>]

> Alright, I can see the argument that someone will often need to know
> where an event is happening, so often that you might say its a
> fundamental characteristic of an event.

I agree.

> However picking up the Bay Guardian and flipping through a set of
> event listings much like I would find anywhere in the world the
> events have venue names, but certainly not detailed geographic
> information.  The metadata is assumed to be known.

Certainly, but where would a program consuming this feed obtain that 
same information?  If the source of the feed knows more then how 
about providing it?

> I think any more exact information would need to be in a separate
> location module.

Per item or per feed?  

Location and time can be represented using dc.coverage.spatial and 
dc.coverage.temporal.  Of course that only works if you intend to use 
RDF.  If you're using simple XML, what then?

> Also location is often going to inherited from the feed itself.  
> If I have a feed of events happening at my bar, then the location is
> implied.

This assumes you somehow know the events contained are associated 
with the containing feed.  What if they're not?  How should something 
consuming the feed come to this assumption?   If the items lacked the 
info then should it be assumed the feed's info be used?

> I would rather not use URLs, but use simple text descriptor like
> Dublin Core.  

And the dc.coverage elements apply, correct?  I don't see the 
validity of using text vs a URL.

> I think the taxo module has been one of the larger
> disappointments as its overly complicated to do anything with.

Oh, I concur, the taxo module is quite complicated and implemented 
properly in ONE feed.  I'll venture it's not a fair comparison.

> But calendar systems are the only thing you want to query for
> location information.  So wouldn't it make more sense to have
> location info independent?

Sure, but instead of bulking it up into the feed or it's items, why 
not use a URL pointing to a document that contains extractable data?

In your example, the Bay Guardian could have a document listing 
locations with their full street address.  They could go so far as to 
add the lat/long positioning info as well.  Then they'd just 
reference that document#location in an item.  If anything consuming 
the item cared about the location info, it could delve into the 
document.  Nothing extra in the feed besides the URL.

So a feed could contain the URL of a location document.  If items 
didn't contain a location URL then you'd assume the feed info should 
be used.  However, what if the feed document contained many 
locations? The items could then contain a partial URL to be used as a 
suffix.

My suggestion for using a URL instead of only plain text is to allow 
something that's "smarter" to programmatically delve into that URL 
and extract additional information.  So if someone's location URL 
contained additional meta data like phone numbers, directions, 
keywords, etc, it would be available.  Using just text in the feed 
seriously inhibits the potential.

-Bill Kearney