freenode :: #microformats

20 Feb 2009
18:02krijnhtantek: whoops
18:02krijnhThat's been a while :)
18:03MykelOkay, a few points
18:03MykelTrue, most event listing services have hCalendar available on their page, but they don't truly use it
18:03krijnhtantek: Forgot to rejoin after a restart, I think.. Sorry for the gap in the logs
18:04Mykeland if you look at the actual results of people entering events, they usually dump everything in the description (like, say age requirement or a stage), because it's not supported in the format
18:04tantekHi krijnh, thanks much for restarting the logs
18:05MykelIf you have some time, could you explain how certain differences in the XML I liked to could be accomplished in hCalendar?
18:05MykelSpecifically event instances
18:05Mykelthe way I've structured the XML, there's a single 'umbrella' event that has several instances (where the actual dates are stored)
18:05MykelThis is most useful for recurring events
18:05Mykelwhere it will always have the same description, but multiple dates
18:06tantekMykel - the problems you state and the proposal you give are not connected
18:06MykelIn the current format, everything is free-text and separated out into its own entity. This would combine them
18:06tantekregarding "most event listing services have hCalendar available on their page, but they don't truly use it" - again, add to the hcalendar-advocacy wiki page with specific points on how they can improve their hCalendar support
18:07tantekand to restate: if current sites don't adopt a simple but useful standard (including existing features of that standard), they certainly won't adopt a more complex proposal
18:07tantektherefore it is not logical to assume that a new XML proposal will help that problem at all.
18:07krijnhtantek: Np
18:08MykelI think you're missing my point. I'm saying these sites would use the hCalendar format if it supported the information being conveyed
18:08tantekregarding "if you look at the actual results of people entering events, they usually dump everything in the description (like, say age requirement or a stage), because it's not supported in the format" - that is a conflation of user interface and format, which are only related in-so-far as what an implementation does - that's a problem of user-interface and implementation, not of format.
18:08MykelMaybe, but is there a stage field in hCalendar?
18:09tantek include it as part of the "location"
18:09MykelBut that's the problem, it's free text
18:09Mykelit needs to be segmented out
18:09MykelHow would it know the difference between stage and location?
18:09tanteksee above: you can further add details by using hCard with "location" per FAQ: http://microformats.org/wiki/hcalendar-faq#How_do_you_provide_better_location_data_for_an_event_than_lat_long
18:09Mykelor what if a single location has multiple stages, as per my example
18:09tantekso the question is, how would you specify stage in the venue hCard
18:10Mykeland the event
18:10tantekthe "extended-address" in the "adr" could be used for that
18:10Mykelalso, the entire performer piece
18:10tantekalso - I have to strongly disagree with your point that "these sites would use the hCalendar format if it supported the information being conveyed"
18:10Mykelwho need to be assigned stages
18:10tantekmuch experience has shown that simpler formats are always better adopted than complex formats
18:11tantek*and* the adoption of simpler formats is how you discover *empirically* (not theoretically) what is necessary for a more a complex format
18:11MykelEvents are complex. Obviously every event wouldn't have all the fields I've presented in my XML. My XML is actually as complicated as it gets
18:11MykelI think hCalendar has been a good base to see what IS necessary for a more complex format..
18:11tantekand complex formats tend to fail more than simpler ones
18:11tantekthere's tons of data on that
18:11Mykelwhich is why I'd like to start talking abou tit
18:12MykelSince there's an inherent flaw in all the event listing services out there -- which is, they aren't agreeing on a format.
18:12tantekto be frank, you're not ready to start talking about it until you've actually *implemented* hCalendar and then discovered what is missing
18:12MykelThey all "support" hCalendar because it's the standard, but have all taken a different approach on how they're organizing it
18:12tantekare they listed on http://microformats.org/wiki/hcalendar-implementations ?
18:13tantekor rather for sites, http://microformats.org/wiki/hcalendar-examples-in-wild
18:13tantekif not - then two things
18:13tantek1. add them to that wiki page
18:13tantek2. add your specific comments about what they're doing wrong next to their listings
18:13tantekwithout such specifics, it is impossible to discuss "have all taken a different approach on how they're organizing it"
18:14tantekin any sort of scientific/rational way from which we can make logical deductions about what the sources of the differences/problems are
18:14tantekand then build solutions that address such specific problems
18:14MykelI agree -- and I will, but I'd like to get back to how hCalendar can specifically address certain parts of the XML without just arbitrarily throwing it on to an existing field that wasn't designed for it
18:14Mykel(like throwing stage at the end of location)
18:14tantekstructure location with hCard
18:15MykelWhat about performers
18:15tantekhCalendar has a property for that I believe
18:15MykelAlso, is it possible to link event instances together without them being completely different?
18:15Mykeli.e. a recurring event
18:16Mykelis there any way to link them to an "umbrella" event?
18:16Mykelto say "hey these events are all part of this one event"
18:16tantekyou can mark up performers at least as attendees: http://microformats.org/wiki/hcalendar-brainstorming#hCard_attendees
18:16MykelAh, but they are different
18:16MykelIs there any way to distinguish between a performer or an attendee in the field?
18:17MykelIf I wanted to see a list of attendees, it would be confusing to also see the artist listed there. It'd also be impossible to do things like
18:17Mykelclick a performer and see all events and venues they performed at in the past year
18:17tantekyou can distinguish them via their "role" on their hCard
18:18tantekrole is a bit free form (see hCard for details), but for example you could assign them a role of "performer"
18:18tantekattendee on the hCalendar just asserts "this person/org is attending/at this event"
18:18tantekit doesn't assert whether they are a concertgoer or performer
18:18MykelSo, what do you think is the reason sites like Zvents, Upcoming, Eventful output in their own format instead of just the hCalendar format?
18:19MykelThat depends on the user to type in exactly "performer" then, right?
18:19tantekno
18:19tantekyou can design a UI where the user *picks* a performer
18:19tantekperhaps a separate field etc
18:19tantekthat's UI design problem
18:19MykelOkay, so that can be accomplished
18:19tantekcertainly I would not advocate to simply give the user a freeform "role" field
18:20MykelI've already done some of this with other events, but I'm going to do this XML example in hCalendar to illustrate the shortcomings
18:20tantekregarding "their own format" - it makes sense to use proprietary XML etc. for experimentation, and from commonalities (80/20) more standard format fields can be determined.
18:21tantekMykel, don't use a theoretical example
18:21Mykela shortcoming being: any information that can't be reliably parsed
18:21tantekadd hCalendar to localist.com
18:21Mykelbut, this isn't a theoretical example. This is actual data from Localist for Virgin Festival
18:21tantekand then let's discuss *real* examples
18:21Mykel(the XML I'm showing you is from Localist)
18:21tantekreal example == URL
18:21tantekXML is the wrong source
18:21tantek provide a URL to the visible content
18:22MykelWell, here are the choices
18:22tantekthe point is, just by *trying* to add hCalendar markup as best as you can to localist, you will develop a better understanding of it
18:22tantekand it will make discussions make more sense
18:23tantekand then you can point to *real* hCalendar examples on localist.com and report hcalendar-issues regarding them
18:23tantekthe microformats community focuses *very* heavily on real world examples on the web
18:23tantekand generally eschews discussion of theoretical examples without URLs
18:23MykelOkay, I'm up for doing that if that's what it takes for you to continue this conversation, but just know I can just as easily paste examples that would match the true implementation exactly.
18:24MykelI'm not convinced a microformat is sufficient, since it puts a lot of weight on presentation which sites tend to throw away
18:24tantekyes. experience has shown that the process of adding hCalendar to a real live site with content always brings more understanding that helps discussions.
18:24Mykeland you're not convinced XML is the right way either
18:24tantekno, the Web is not convinced that XML is the right way. HTML has effectively "won" in terms of content publishing.
18:24Mykelfor presentation, yes
18:24MykelI'm talking about back end organization
18:24tantekno, for accurate data that users interact with
18:24Mykelfor event listing sites to share data
18:25tantekwhich also *has* presentation yes
18:25tantekbut fundamentally, HTML is data
18:25MykelSince none of them are using hCalendar data as the presentation medium
18:25Mykelmicroformats with all the extended info you're looking for seems to require a lot of hacking, mixing microformats, and other tomfoolery
18:25tantekmicroformats are simply leveraging the natural outcome of HTML data being dominant on the web
18:25MykelRight -- which is not what I want to accomplish
18:25MykelThat's not where the fundamental flaw is
18:26Mykelthe fundamental flaw is the data management these sites are practicing
18:26tantekagain, log the specific examples and the problems with their data management that you know of
18:26tantekno more theoretical assertions of "fundamental flaw is the data management"
18:26MykelWorking on it
18:27tantekMykel, as I seem to be repeating mysefl, I'm going to sign off for now, and check back in later. Let's pick this discussion back up when you've added hCalendar to localist.com and noted which other sites implement (with flaws as you say) hCalendar on the hcalendar-examples-in-wild page.
18:31Mykelwow, okay
18:32tantekno reason for us to repeat back and forth right? ;)
18:34MykelAgreed. Thanks for your time. I'll ping you when it's live
19:28MykelOkay, I'm ready for Tantek to come back! :)
21 Feb 2009
No messages
   
Last message: 5 years and 243 days ago