Re: Using feeds for time/event data?

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

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

No, not at all.  I do, however, think it's worth making the formats 
reasonably parseable by both.

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

Again, not interested in full-fledged sharing.  

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

Yes, this is my general intention as well.

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

Right, and this is why I suggested the possiblity of a URL being 
associated with some of the fields like venue, host, organization, 
etc.  

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

And I'm hoping for the same thing.

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

Then go with what you've got.  However, should the format be dumbed 
down just because you're not collecting anything more complex?  I'm 
not espousing the requirement of a URL just the ability to support 
one.  

> 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

Er, yes, I keep forgetting that DC is itself a module.

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

No, using your protest.net example, the items certainly don't all 
occur at a protest.net location.  You're aggregating the events, 
they're not directly associated with the feed.  Therefore a location 
found in the feed would not be appropriate for the items.  I'm not 
suggesting deviation from the hierarchical nature of RSS files.

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

Now we're on the same wavelength.  I'm suggesting that a feed could 
contain URLs that would allow a 'smarter' program (or user) to find 
out more information /if it existed/.  

Using just the item link tag might not be sufficient.  It would 
require that document to contain something 'predictably' parseable 
about the location.  That would be great but I could see the site 
people bitching about it.  Better to have a reference to the "one 
place" that's know to contain location info.

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

I agree.  I do like what the documentation appears to intend.  But 
the vagueness is very troubling.

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

No, not really.  Look at Bloggus Caesari [1].  
[1] http://www.sankey.ca/caesar/

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

And I'm with you in this regard.  We should just toss out RDF if this 
is what you really mean.  I'm being facetious.  I would like to see a 
way to implement this with the possiblity of using "simple" RSS 
syntax if possible.

> 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 can work with that idea provided the format allows for the option 
of attaching URLs to the fields.  Using RDF would allow this anyway 
but I'm interested in how the simple XML would deal with it.

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

Yes.

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

Yes, links for the item could/should be different than links for meta 
data about location and other things.

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

How about a more complex scenario.  Someone's a resident of distant 
town and wants to find out "what's happening" in another town.  How 
would they know what's where?  Where would they start?  Now imagine 
trying this from a WAP phone.

There's nothing "exotic" about lat/long.  It's not commonly used, 
I'll grant you, but it's the one thing that overcomes the vague-ness 
of place names.  Is "Redwood City" the same thing as "San 
Francisco"?  No, but if you're coming from New York and flying into 
San Jose, it might be nice to find things based on the overall 
region.  Lat/long would aid in this process.

Let's imagine they knew to consult something like Syndic8.com's 
database of newsfeeds.  They could (soon) query Syndic8 for feeds 
located "near" the town in question.  They'd read the feeds and start 
learning more.  

I'd like to see events be capable of being found based on location 
information. Most events have a location and if you have a way to 
find it, why not include it?  If you're not going to stuff it into 
the feed itself then how about providing a URL that helps find it?

This is certainly a "Field of dreams" problem.  If you build it they 
will come.  I can forsee the search portals start to present results 
based on location.  But they can't do this without reasonably 
accurate info existing within the searched materials.  

Yes, I shudder when I see advertising folks start foaming at the 
mouth here.

Back to your protest.net example, consider putting something in your 
system that extrapolates what people input into geographic data.  I 
like how you've grouped things by region using the UI.   Should you 
have a different feed for each region?  Or should you have region 
defining information within one larger feed?

Has metaevents.com tanked?  The site doesn't come up.

-Bill Kearney