/irc-logs / freenode / #microformats / 2009-02-20 / end

Options:

  1. # Session Start: Fri Feb 20 19:10:00 2009
  2. # Session Ident: #microformats
  3. # [19:10] * Now talking in #microformats
  4. # [19:10] * Topic is 'http://microformats.org/wiki/irc - if you are new here, add yourself to http://microformats.org/wiki/irc-people'
  5. # [19:10] * Set by tantek on Mon Apr 09 16:30:07
  6. # [19:10] #microformats url is http://microformats.org
  7. # [19:10] <krijnh> tantek: whoops
  8. # [19:10] <krijnh> That's been a while :)
  9. # [19:10] * Joins: Hey_neken (n=kaxero@215.Red-213-96-129.staticIP.rima-tde.net)
  10. # [19:11] <Mykel> Okay, a few points
  11. # [19:11] <Mykel> True, most event listing services have hCalendar available on their page, but they don't truly use it
  12. # [19:11] <krijnh> tantek: Forgot to rejoin after a restart, I think.. Sorry for the gap in the logs
  13. # [19:12] <Mykel> and 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
  14. # [19:12] <@tantek> Hi krijnh, thanks much for restarting the logs
  15. # [19:13] <Mykel> If you have some time, could you explain how certain differences in the XML I liked to could be accomplished in hCalendar?
  16. # [19:13] <Mykel> Specifically event instances
  17. # [19:13] <Mykel> the way I've structured the XML, there's a single 'umbrella' event that has several instances (where the actual dates are stored)
  18. # [19:13] <Mykel> This is most useful for recurring events
  19. # [19:13] <Mykel> where it will always have the same description, but multiple dates
  20. # [19:14] <@tantek> Mykel - the problems you state and the proposal you give are not connected
  21. # [19:14] <Mykel> In the current format, everything is free-text and separated out into its own entity. This would combine them
  22. # [19:14] <@tantek> regarding "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
  23. # [19:15] <@tantek> and 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
  24. # [19:15] <@tantek> therefore it is not logical to assume that a new XML proposal will help that problem at all.
  25. # [19:15] <krijnh> tantek: Np
  26. # [19:16] <Mykel> I think you're missing my point. I'm saying these sites would use the hCalendar format if it supported the information being conveyed
  27. # [19:16] <@tantek> regarding "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.
  28. # [19:16] <Mykel> Maybe, but is there a stage field in hCalendar?
  29. # [19:17] <@tantek> include it as part of the "location"
  30. # [19:17] <Mykel> But that's the problem, it's free text
  31. # [19:17] <Mykel> it needs to be segmented out
  32. # [19:17] <Mykel> How would it know the difference between stage and location?
  33. # [19:17] <@tantek> see 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
  34. # [19:17] <Mykel> or what if a single location has multiple stages, as per my example
  35. # [19:17] <@tantek> so the question is, how would you specify stage in the venue hCard
  36. # [19:18] <Mykel> and the event
  37. # [19:18] <@tantek> the "extended-address" in the "adr" could be used for that
  38. # [19:18] <Mykel> also, the entire performer piece
  39. # [19:18] <@tantek> also - I have to strongly disagree with your point that "these sites would use the hCalendar format if it supported the information being conveyed"
  40. # [19:18] <Mykel> who need to be assigned stages
  41. # [19:18] <@tantek> much experience has shown that simpler formats are always better adopted than complex formats
  42. # [19:19] <@tantek> *and* the adoption of simpler formats is how you discover *empirically* (not theoretically) what is necessary for a more a complex format
  43. # [19:19] <Mykel> Events 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
  44. # [19:19] <Mykel> I think hCalendar has been a good base to see what IS necessary for a more complex format..
  45. # [19:19] <@tantek> and complex formats tend to fail more than simpler ones
  46. # [19:19] <@tantek> there's tons of data on that
  47. # [19:19] <Mykel> which is why I'd like to start talking abou tit
  48. # [19:20] <Mykel> Since there's an inherent flaw in all the event listing services out there -- which is, they aren't agreeing on a format.
  49. # [19:20] <@tantek> to be frank, you're not ready to start talking about it until you've actually *implemented* hCalendar and then discovered what is missing
  50. # [19:20] <Mykel> They all "support" hCalendar because it's the standard, but have all taken a different approach on how they're organizing it
  51. # [19:20] <@tantek> are they listed on http://microformats.org/wiki/hcalendar-implementations ?
  52. # [19:21] <@tantek> or rather for sites, http://microformats.org/wiki/hcalendar-examples-in-wild
  53. # [19:21] <@tantek> if not - then two things
  54. # [19:21] <@tantek> 1. add them to that wiki page
  55. # [19:21] <@tantek> 2. add your specific comments about what they're doing wrong next to their listings
  56. # [19:21] <@tantek> without such specifics, it is impossible to discuss "have all taken a different approach on how they're organizing it"
  57. # [19:22] <@tantek> in any sort of scientific/rational way from which we can make logical deductions about what the sources of the differences/problems are
  58. # [19:22] <@tantek> and then build solutions that address such specific problems
  59. # [19:22] <Mykel> I 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
  60. # [19:22] <Mykel> (like throwing stage at the end of location)
  61. # [19:22] <@tantek> structure location with hCard
  62. # [19:23] <Mykel> What about performers
  63. # [19:23] <@tantek> hCalendar has a property for that I believe
  64. # [19:23] <Mykel> Also, is it possible to link event instances together without them being completely different?
  65. # [19:23] <Mykel> i.e. a recurring event
  66. # [19:24] <Mykel> is there any way to link them to an "umbrella" event?
  67. # [19:24] <Mykel> to say "hey these events are all part of this one event"
  68. # [19:24] <@tantek> you can mark up performers at least as attendees: http://microformats.org/wiki/hcalendar-brainstorming#hCard_attendees
  69. # [19:24] <Mykel> Ah, but they are different
  70. # [19:24] <Mykel> Is there any way to distinguish between a performer or an attendee in the field?
  71. # [19:25] <Mykel> If 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
  72. # [19:25] <Mykel> click a performer and see all events and venues they performed at in the past year
  73. # [19:25] <@tantek> you can distinguish them via their "role" on their hCard
  74. # [19:26] <@tantek> role is a bit free form (see hCard for details), but for example you could assign them a role of "performer"
  75. # [19:26] <@tantek> attendee on the hCalendar just asserts "this person/org is attending/at this event"
  76. # [19:26] <@tantek> it doesn't assert whether they are a concertgoer or performer
  77. # [19:26] <Mykel> So, what do you think is the reason sites like Zvents, Upcoming, Eventful output in their own format instead of just the hCalendar format?
  78. # [19:27] <Mykel> That depends on the user to type in exactly "performer" then, right?
  79. # [19:27] <@tantek> no
  80. # [19:27] <@tantek> you can design a UI where the user *picks* a performer
  81. # [19:27] <@tantek> perhaps a separate field etc
  82. # [19:27] <@tantek> that's UI design problem
  83. # [19:27] <Mykel> Okay, so that can be accomplished
  84. # [19:27] <@tantek> certainly I would not advocate to simply give the user a freeform "role" field
  85. # [19:27] * Quits: MrTopf (n=cs@p5B395503.dip.t-dialin.net)
  86. # [19:28] <Mykel> I've already done some of this with other events, but I'm going to do this XML example in hCalendar to illustrate the shortcomings
  87. # [19:28] <@tantek> regarding "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.
  88. # [19:28] * Quits: georgebrock (n=georgebr@host217-42-138-35.range217-42.btcentralplus.com) (Read error: 113 (No route to host))
  89. # [19:29] <@tantek> Mykel, don't use a theoretical example
  90. # [19:29] <Mykel> a shortcoming being: any information that can't be reliably parsed
  91. # [19:29] <@tantek> add hCalendar to localist.com
  92. # [19:29] <Mykel> but, this isn't a theoretical example. This is actual data from Localist for Virgin Festival
  93. # [19:29] <@tantek> and then let's discuss *real* examples
  94. # [19:29] <Mykel> (the XML I'm showing you is from Localist)
  95. # [19:29] <@tantek> real example == URL
  96. # [19:29] <@tantek> XML is the wrong source
  97. # [19:29] <@tantek> provide a URL to the visible content
  98. # [19:30] <Mykel> Well, here are the choices
  99. # [19:30] <@tantek> the point is, just by *trying* to add hCalendar markup as best as you can to localist, you will develop a better understanding of it
  100. # [19:30] <@tantek> and it will make discussions make more sense
  101. # [19:31] <@tantek> and then you can point to *real* hCalendar examples on localist.com and report hcalendar-issues regarding them
  102. # [19:31] <@tantek> the microformats community focuses *very* heavily on real world examples on the web
  103. # [19:31] <@tantek> and generally eschews discussion of theoretical examples without URLs
  104. # [19:31] <Mykel> Okay, 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.
  105. # [19:32] <Mykel> I'm not convinced a microformat is sufficient, since it puts a lot of weight on presentation which sites tend to throw away
  106. # [19:32] <@tantek> yes. experience has shown that the process of adding hCalendar to a real live site with content always brings more understanding that helps discussions.
  107. # [19:32] <Mykel> and you're not convinced XML is the right way either
  108. # [19:32] <@tantek> no, the Web is not convinced that XML is the right way. HTML has effectively "won" in terms of content publishing.
  109. # [19:32] <Mykel> for presentation, yes
  110. # [19:32] <Mykel> I'm talking about back end organization
  111. # [19:32] <@tantek> no, for accurate data that users interact with
  112. # [19:32] <Mykel> for event listing sites to share data
  113. # [19:33] <@tantek> which also *has* presentation yes
  114. # [19:33] <@tantek> but fundamentally, HTML is data
  115. # [19:33] <Mykel> Since none of them are using hCalendar data as the presentation medium
  116. # [19:33] <Mykel> microformats with all the extended info you're looking for seems to require a lot of hacking, mixing microformats, and other tomfoolery
  117. # [19:33] <@tantek> microformats are simply leveraging the natural outcome of HTML data being dominant on the web
  118. # [19:33] <Mykel> Right -- which is not what I want to accomplish
  119. # [19:33] <Mykel> That's not where the fundamental flaw is
  120. # [19:34] <Mykel> the fundamental flaw is the data management these sites are practicing
  121. # [19:34] <@tantek> again, log the specific examples and the problems with their data management that you know of
  122. # [19:34] <@tantek> no more theoretical assertions of "fundamental flaw is the data management"
  123. # [19:34] <Mykel> Working on it
  124. # [19:35] <@tantek> Mykel, 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.
  125. # [19:36] * Parts: tobyink (n=tai@acton-2.nct.org.uk) ("Leaving")
  126. # [19:39] <Mykel> wow, okay
  127. # [19:40] <@tantek> no reason for us to repeat back and forth right? ;)
  128. # [19:42] <Mykel> Agreed. Thanks for your time. I'll ping you when it's live
  129. # [19:48] * Quits: @tantek (n=tantek@adsl-69-106-241-178.dsl.pltn13.pacbell.net)
  130. # [19:52] * Joins: pjkix (n=pjkix@c-24-130-160-254.hsd1.ca.comcast.net)
  131. # [20:00] * Parts: emrojo (n=emrojo@163.117.139.88)
  132. # [20:05] * Joins: leahculver (n=leahculv@204.9.180.30)
  133. # [20:36] <Mykel> Okay, I'm ready for Tantek to come back! :)
  134. # [20:40] * Joins: MrTopf (n=cs@pD9EBD923.dip.t-dialin.net)
  135. # [20:53] * Quits: lokeshdhakar (n=lokeshdh@c-68-34-120-222.hsd1.md.comcast.net)
  136. # [20:57] * Joins: Politoed (n=theorem@aulas-c.fe.up.pt)
  137. # [20:58] * Quits: @dglazkov (n=dglazkov@nat/google/x-f3407b335b2985b5) (Read error: 104 (Connection reset by peer))
  138. # [21:05] * Joins: dglazkov (n=dglazkov@nat/google/x-6d1755e68e7ffa0b)
  139. # [21:05] * ChanServ sets mode: +o dglazkov
  140. # [21:35] * Joins: lokeshdhakar (n=lokeshdh@c-68-34-120-222.hsd1.md.comcast.net)
  141. # [21:49] * Quits: lokeshdhakar (n=lokeshdh@c-68-34-120-222.hsd1.md.comcast.net)
  142. # [21:51] * Joins: benward (n=benward@nat/yahoo/x-c019a1884b9f6874)
  143. # [21:51] * ChanServ sets mode: +o benward
  144. # [21:54] * Joins: broheem (n=broheem@72.16.138.81)
  145. # [21:58] * Quits: levitation[A] (n=levitati@rubiin.physic.ut.ee) (Remote closed the connection)
  146. # [22:05] * Quits: broheem (n=broheem@72.16.138.81) ("Leaving...")
  147. # [22:28] * Quits: Politoed (n=theorem@aulas-c.fe.up.pt) (Read error: 110 (Connection timed out))
  148. # [22:29] * Joins: Politoed (n=theorem@aulas-c.fe.up.pt)
  149. # [23:25] * Joins: csarven (n=csarven@dhcp-0-18-f8-35-d5-97.cpe.quickclic.net)
  150. # [23:37] * Joins: dpdearing (n=ddearing@dsl081-014-025.sea1.dsl.speakeasy.net)
  151. # [23:37] * Parts: dpdearing (n=ddearing@dsl081-014-025.sea1.dsl.speakeasy.net)
  152. # [23:37] * Joins: dpdearing (n=ddearing@dsl081-014-025.sea1.dsl.speakeasy.net)
  153. # [23:53] * Joins: StaceyC (n=stacey@174.6.146.52)
  154. # Session Close: Sat Feb 21 00:00:00 2009

The end :)