[uf-discuss] picoformats and extracting event data from text email
I'm thinking about easy (for the user) ways an event promoter could add machine-readable data to their emails for adding events to spraci.com I get a lot of emails about upcoming events but there is no time to do data entry (I say to them the correct way to add events to spraci.com is to use the forms on the website or to provide a data feed). However, it would be good if at least some of the stuff sent by email could be included in the listings (as that could be a significant amount of extra data). Obviously for html emails they could use hcalendar, but for plain text emails and for users who are not familiar with html,xml, etc I'm thinking an easy way for them might be just to include something like this in their email. Name: (event name) Date: event dates (fill date or start-end including the year) Location: (including city and country) Description: (short description, lineup, etc) Categories: (comma separated list of tags for things such as event-type, music, genres, etc) This could be added after each event blurb with at least one blank line separating it from any other text. The important thing here is it has to be easy for any event promoter to do without too much thought and must not need any special authoring tools. (so the names must be obvious - this could get complicated if support for other languages is added so initially I guess its just English) If they omit the location field I could also make it check for '@' and use anything between that and a new line. Of course the names would have to be loose because it has to be very easy for people to do without having to look them up. (otherwise I would probably think of using the iCal/hCal names - A parser could accept both). For date formats I think it would have to accept most common formats, such as those accepted by commonly used perl modules or strtotime in php. (with a warning to people not to use dd/mm/ or mm/dd/ as those are ambiguous). It will probably be hard to explain to event promoters why the year is required (they seem to be so used to leaving it off), I will probably have to provide them with a list of accepted formats for dates. I don't really see any easy way around that. For the city/country a parser could check words against a list of known cities/countries. If both a city and country (or state) are found it could reduce the possibility of an incorrect match. (of course they will have to be careful to spell them correctly and I probably would have to make it somehow check for common alternate spellings of names and common abbreviations for state names). If there are no matches it probably should default to the area/city associated with the user. This is similar to something I had for processing incoming events from a certain contributor back in the mid 90s. I needed something like this because the data from that person was basically just plain text that was sent to me by email and I wanted to reduce the amount of manual retyping. I think this idea is closely related to picoformats so I'll be watching that closely! I'm thinking about this (yet again) for incoming emails and possibly also future mobile applications where people are manually typing text as a single blob. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] PicoFormats
Yay! Picoformats live! :DG On 6/6/06, Chris Messina [EMAIL PROTECTED] wrote: Well, you knew it had to happen, but we're getting smaller. After discussing this idea with Tantek and receiving his blessing, I would like to begin pursiing Picoformats in the context of the microformats wiki, as we will be exploring many of the same issues, praxis and problems that we have been grappling with here on this list -- but at a smaller and more atomic level. The goal of this effort is to establish some basic patterns of syntax for mobile devices interacting with SMS-based services. We will be documenting current behavior and following the well-worn paths that the microformats community has set as baseline process for developing such open standards. In any case, the opening intro page is here: http://microformats.org/wiki/picoformats I'm curious to hear thoughts on how to organize this kind of content... At first I was thinking to organize it by task type... like Communicating with people or Interacting with services but then I thought that maybe the existing microformats types might be useful... like Create an event (hcal) or Send a message to a person (hcard). But I dunno. I mean, this is kind of like building a command-line interface but for regular people who aren't familiar with ls, cd, chmod and so on. Anyway, wanted to put it out there before I leave for France and see if anyone had thoughts or suggestions. Thanks, Chris ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
