Re: Using feeds for time/event data?

["kelliottmccrea" <kellan@protest.net>]

--- WK =  "wkearney99" <wkearney99@h...> wrote:

First,  Bill your primary concern seems to be on the consumption of
this information by a computer, where I'm positing the likelihood
of a human being involved somewhere in the chain of events.

For a full fledged event sharing, and scheduling protocol between
calendar stores see iCal, iTip, and CAP.

What I think would be cool would be an agreed upon format for
sharing event information such that we could create a slashbox-like
event listing (ala the dnalounge example mentioned by Brandon) and
also look at them in aggregate.

I always thought one of the key insights in RSS was that it was
pointer with just enough info to be intriguing, it doesn't try to
capture everything about a piece of data.

So I guess I'm hoping for a format for the syndication of pointers
to events, rather then events themselves.  And I think the relative
popularity-to-development-time of RSS and the Calsch WG standards
back this up.

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

On Protest.net we give calendars two options for a location field,
either a simple text box, or a complex address widget.  The simple
text field is the default, and very few people have ever had the
desire or interest in changing it.  What this means is, as the feed
provider (but not the event owner) we *don't* know anything more
about the location.

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

 WK> Per item or per feed?

 The fact that we might want to do both seems to point to a
 separate module ala the dc module, which is used both in the
 description of channels as well as in individual items

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

 WK> This assumes you somehow know the events contained are
 WK> associated with the containing feed. What if they're not? 

I do make that assumption based on the hierarchical nature of XML, and
the way RSS is specified.  It is news to me that RSS items
shouldn't be considered contained by their channel.  I suppose we
could see something like is arise in the context of aggregation.

 WK> If the items lacked the info then should it be assumed the
 WK> feed's info be used?

Ugh.  Yeah you're right, that might be a confusing aspect of add
location info to a channel.  Lets not start tell applications they
have to guess our intent.  Or it might be enough that location info
of a channel is implied but not guaranteed to be that of an item.

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

I personally find the Coverage element confusingly vague.  And the
DCMI-Period spec is just plain a bad idea for the computing world
we'll inhabit for the next 10 years.

If we allow people to define events as starting 3 days after the
beginning of the Italian Renaissance period (as allowed by
DMCI-Period) we might as well stop now.

My preference to text vs a URL goes back to simplicity of consuming
the feed, and simplicity of displaying it.

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

Yes I think this is a good idea.  No I don't think its core to what
it means to be an event.  Yes I can see how it would be very useful
for certain classes of events.  It would be equally useful if I was
providing a feed of new 802.11 access points in SF.

I might also want to use it to describe an entire feed, or just a
single item as discussed above.

Therefore I think it should be separate.  Then we're left with the
problem of still needing a location/venue on events.

However I'm going to assume that most people are familiar with most
of the metadata associated with an event feed they find
interesting.  And if they aren't then following the link associated
with the item should be an obvious way to acquaint themselves with
it.  Therefore if you tell me an event is happening at the Warburg,
I can find it without consulting anything fancier.  And if I do
need something more precise (like an address, or map, or something
more exotic like lat/long/gps) then if the feed has been kind
enough to provide a pointer to such info using the location module,
I'm all set.


kellan