[uf-discuss] Did I do something wrong?
I searched for my name: http://kitchen.technorati.com/contact/search/colin%20devroe And I get Flickr and Corkd (expected). However, I have an hCard on my site at: http://cdevroe.com/about/ How do I ensure that my information comes up in that search? I ping Technorati with each post I do. Colin D. Devroe ___ 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
Re: [uf-discuss] Did I do something wrong?
On 6 Jun 2006, at 14:47, Colin D. Devroe wrote: I searched for my name: http://kitchen.technorati.com/contact/search/colin%20devroe And I get Flickr and Corkd (expected). However, I have an hCard on my site at: http://cdevroe.com/about/ How do I ensure that my information comes up in that search? I ping Technorati with each post I do. Looks like there's no level of spidering occurring - i.e. the page submitted is index, but no links are followed. Have you tried explicitly submitting your About page? (That's a stated example for Pingerati use). drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vjournal?
Yes, yes it would. If we accept that hCalendar is only about hevent, and the other component types of RFC 2445 are not applicable. - - - Hans Gerwitz hans.gerwitz.com On Jun 5, 2006, at 9:13 PM, Chris Messina wrote: Wouldn't it be more like: hentry I met rel=friend methcardRyan/hcard/rel heventtoday for lunch at hcardThe Pink Door/hcard/hevent?/hentry Chris On 6/3/06, Hans Gerwitz [EMAIL PROTECTED] wrote: Thanks for replying, Ryan. That's exactly what I suspected had occurred and is completely reasonable. Would you mind sharing your thoughts on formatting records like I ? met hcardRyan/hcard today for lunch at hreviewThe Pink Door/ hreview/?? It looks like if I want to live in the uf ecosystem I need to use hcalendar's vevent; but that feels like an abuse of that spec, since it would be inappropriate in iCalendar. Perhaps I'm showing my age by taking an RFC too seriously. - - - Hans Gerwitz hans.gerwitz.com On Jun 2, 2006, at 5:30 PM, Ryan King wrote: Our reasoning behind dropping vjournal is this: 1. For the most part, vjournal and hatom cover the same ground. 2. vjournal was rejected in the hatom process 3. we don't want two ways to do the same thing 4. perhaps we should drop vjournal? The only part that's up for debate is #1, and I, personally, think that making that case would be pretty difficult, as I think there is a significant overlap, with the divergences amounting to edge cases, which we tend to no worry about. -ryan ___ 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar scope
Not to throw a spanner in the works, but i would disagree. Part of the reason the other VComponents were never formalized into a microformat was use-cases. When we started working with encoding events, it seemed most natural to look to iCalendar. Now, iCalendar DOES have several of those other components, but no one was interested in looking to see if applications consumed them, or if people were even publishing their free-busy time on the web already. After a year of working on microformats, there has been some interest recently in starting a ToDo format. It only makes sense to look to VTODO for a model since applications support it already. So wouldn't throw the baby out with the bath water and disallow all non-vevent components in the RFC spec. As for free-busy time, it is exactly the same as vevent with a different root class name vevent=vfreebusy, the main reason it has not been implements is interest, not because of parsing or application support. So i think we should keep our options open for that as well. Also, hCalendar doesn't support the full spectrum of iCalendar. There is still on going discussion about how to encode Re-occurring events properly and if it is even an issue? There has been discussion of modeling hCalendar after the ICAL Basic spec[1,2] and NOT the RFC (of which the ICAL Basic is a subset). -brian [1] - http://www.ietf.org/internet-drafts/draft-royer-ical-basic-04.txt [2] - http://www.google.com/search?rls=enq=site:http://microformats.org/discuss/+ical+basicie=UTF-8oe=UTF-8 Hans Gerwitz wrote: Alright, I'm giving in to the hegemony and will adopt vevent for all calendar use cases. My sample content http://hans.gerwitz.com/2006/06/01/she-said-yes.html has been adjusted and the various parsers all like it, now. What drove this decision is a consideration of the iCalendar-hCalendar impedance mismatch. VJOURNAL is not the only component not represented in hCalendar; VTODO and VFREEBUSY are also unaccounted for (in the ecosystem, at least. Only Mark Mansour's parser accounts for non-event components). So, I'd like to propose the VEVENT-centric scope of hCalendar be formalized: - Ryan's remove vjournal to-do item should be expanded to include vtodo and vfreebusy, and executed to prevent others falling into the trap I did. - References to iCalendar (especially 1:1 representation of RFC 2445!) in wiki/hcalendar should be re-worded to specify that only the VEVENT component is mapped. I'd be happy to handle the wikicleanup if there is a consensus. Is there a voting process here? - - - Hans Gerwitz hans.gerwitz.com On Jun 3, 2006, at 12:00 PM, Hans Gerwitz wrote: Thanks for replying, Ryan. That's exactly what I suspected had occurred and is completely reasonable. Would you mind sharing your thoughts on formatting records like I ?met hcardRyan/hcard today for lunch at hreviewThe Pink Door/hreview/?? It looks like if I want to live in the uf ecosystem I need to use hcalendar's vevent; but that feels like an abuse of that spec, since it would be inappropriate in iCalendar. Perhaps I'm showing my age by taking an RFC too seriously. - - - Hans Gerwitz hans.gerwitz.com On Jun 2, 2006, at 5:30 PM, Ryan King wrote: Our reasoning behind dropping vjournal is this: 1. For the most part, vjournal and hatom cover the same ground. 2. vjournal was rejected in the hatom process 3. we don't want two ways to do the same thing 4. perhaps we should drop vjournal? The only part that's up for debate is #1, and I, personally, think that making that case would be pretty difficult, as I think there is a significant overlap, with the divergences amounting to edge cases, which we tend to no worry about. -ryan ___ 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
Re: [uf-discuss] hCalendar scope
On Jun 6, 2006, at 11:19 AM, Hans Gerwitz wrote: Alright, I'm giving in to the hegemony and will adopt vevent for all calendar use cases. My sample content http://hans.gerwitz.com/ 2006/06/01/she-said-yes.html has been adjusted and the various parsers all like it, now. What drove this decision is a consideration of the iCalendar- hCalendar impedance mismatch. VJOURNAL is not the only component not represented in hCalendar; VTODO and VFREEBUSY are also unaccounted for (in the ecosystem, at least. Only Mark Mansour's parser accounts for non-event components). So, I'd like to propose the VEVENT-centric scope of hCalendar be formalized: - Ryan's remove vjournal to-do item should be expanded to include vtodo and vfreebusy, and executed to prevent others falling into the trap I did. Actually, I'm not convinced that these need to disappear– the reason they aren't described yet is that no one (besides Mark) has spent any time on them. If you'd like to work on them, I'd certainly help pull together the notes I have on them. - References to iCalendar (especially 1:1 representation of RFC 2445!) in wiki/hcalendar should be re-worded to specify that only the VEVENT component is mapped. I'd be happy to handle the wikicleanup if there is a consensus. Is there a voting process here? Nah, its by consensus. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats for newcomers, rel=must-include?
On 6/6/06, Brian Suda [EMAIL PROTECTED] wrote:
Great to hear that Microformats are making their way into this book!
Sorry we missed you at www2006.
Me too ('fraid I didn't have a clean kilt).
A good resource for digestible chunks of microformat information can
be found in the many presentations about microformats:
http://microformats.org/wiki/presentations
There is also a list of Podcasts that deal with microformats as well:
http://microformats.org/wiki/podcasts
Thanks Brian. To be honest I've a feeling the microformats bit will
write itself, the trickiest bit being resisting quoting the Wiki
verbatim.
btw, Tantek, I will probably mention RDF/A, but I assure you it'll be
done in the best possible taste* :-)
Cheers,
Danny.
* bleah, spit it out: if we're now transitioning to/are on Web 2.0 I
can't see XHTML 2.0 getting much traction before Web 4.6 or so, which
I'm afraid to my eyes undermines any visible promise of RDF/A, much
that I appreciate the motivation behind it. In the meantime
microformats are RDF-interpretable, and Ian's eRDF offers (near-?)
full RDF in the currentish HTML...and then there's always link
rel=alternate type=application/rdf+xml...
--
http://dannyayers.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] include pattern
If you're not familiar with the include pattern, is a method for doing transclusion within a webpage. It was invented to deal with several use-cases where existing microformats specifications would required that a piece of data be repeated multiple times on a page, despite this being human/author unfriendly. Read the wiki page [http://microformats.org/wiki/include-pattern] for more info. Anyway, there's been some discussion on the microformats-dev list, which raised an issue with this pattern. The issue is this: does the inclusion include only the children of the referenced element, or the referenced element itself? If we take referenced elements and their children, you can do something like this: span class=fn id=aRyan King/span span class=vcardobject class=include data=#a type=text/ html //span If we only take children, then the above would have to become. span id=aspan class=fnRyan King/span/span span class=vcardobject class=include data=#a type=text/ html //span Of course, the issue is a bit more complex than this, as it can create a bit more complexity for parsers to deal with. DanC's summarized the discussion over on mf-dev in this email [http:// microformats.org/discuss/mail/microformats-dev/2006-May/97.html]. I think I know where the people in the mf-dev conversation think about this (Dan, Tantek, Brian and myself) , but I'd like to open this discussion up to more people, as it was the potential to impact publishers. thanks, ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] mf-dev
I think I know where the people in the mf-dev conversation think about this (Dan, Tantek, Brian and myself) , but I'd like to open this discussion up to more people, as it was the potential to impact publishers. I've tried to subscribe to mf-dev a few times and gave up - no response... ..given that I am experimenting with parsing microformats (especially hcalendar - as most of this is related to events listings - but some vcard stuff will probably be also used to specify location details such as cities) and plan to include such parsers in software to be given to event promoters and also server-side aggregators, I thought I should subscribe to it to learn better ways of doing this and to make sure I don't repeat mistakes others may have made before me. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
