From reeder.29 at gmail.com Thu Dec 3 08:51:09 2009 From: reeder.29 at gmail.com (Doug Reeder) Date: Thu Dec 3 08:58:24 2009 Subject: [uf-discuss] Practical Examples of Project Outlines in XOXO Format Message-ID: <934CB9EA-DBD0-4BD2-BE96-58D1361DC309@gmail.com> This seems like it ought to be an FAQ, but I've had no luck searching for this nor following links. I'm writing a productivity tool which can import XOXO outlines, and it works fine for the small examples on the XOXO wiki, and re-importing outlines exported from itself. I'd like to test it with realistic examples, such as outlines written with something like MORE (for Mac OS Classic) or BrainForest for Palm OS. I'm especially interested in outlines with metadata. Where can I find such examples? Doug Reeder reeder.29@gmail.com http://reeder29.livejournal.com/ https://twitter.com/reeder29 From harald at effenberg.de Sun Dec 6 02:47:05 2009 From: harald at effenberg.de (Harald Effenberg) Date: Sun Dec 6 02:49:08 2009 Subject: [uf-discuss] vevent with rrule is not recognized Message-ID: Hi! On the top of http://www.effenberg.de/termine.htm I have a vevent with an event which should be repeated 4 times (see snippet at the bottom of this mail). With the Firefox-Operator-Add-On I can send the event to the google-calendar, but it is recognized only as a single event without recurrence. When I try to export it to the Windows(Vista32)-calendar, everything seems to work fine but in the end there is no event in the calendar - if I use my existing calendar. If I try to export it to a new windows- calendar, I receive an error message (translated): "This is no valid icalendar-file corresponding to RFC 2445." http://microformatique.com/optimus/?format=validate&uri=http%3A//www.effenberg.de/termine.htm says there are no errors but ignores the recurrence completely. Is there something wrong with the code?

"K?nig der Herzen" - Harald Effenberg als schwuler Referent des Premierministers 'Toby Frost' 12.12.-15.12.2009 im Schlosspark-Theater in Berlin. (Deutsche Erstauff?hrung) 2009-05-20-T23:42:00+02:00-1@effenberg.de Schlosspark-Theater 12165 Berlin Schlo?strasse 48 Berlin 2009-12-12T20:00:00+01:00> 2009-12-12T22:00:00+01:00> daily4 Schlosspark-Theater 2009-12-05-T14:07:00+01:00>

Thanks a lot in advance! Harry -- http://www.effenberg.de/ From jamie at jamie-thomson.net Tue Dec 8 06:26:54 2009 From: jamie at jamie-thomson.net (Jamie Thomson ) Date: Tue Dec 8 06:46:59 2009 Subject: [uf-discuss] Stack Overflow implements hResume Message-ID: Hi all, Just to let you know, http://Stackoverflow.com have implemented hResume for their http://careers.stackoverflow.com site. This was requested on 3rd November 2009 on this: http://meta.stackoverflow.com/questions/28375/should-careers-stackoverflow-com-support-hresume/31681#31681 forum post and the developer is now asking for feedback. ? Click on the link to the forum post for more info and to provide feedback. ? @JamieT From glenn.jones at madgex.com Tue Dec 8 09:07:31 2009 From: glenn.jones at madgex.com (Glenn Jones) Date: Tue Dec 8 09:12:09 2009 Subject: [uf-discuss] Stack Overflow implements hResume In-Reply-To: References: Message-ID: <36A319113CF910438942741C4727ADFF03EC4284@MOBY.Clarence.local> Jamie It's so nearly there, but the compound structures are not marked-up correctly for hResume The education and experience are currently mark-up as
when they should be
and
. The linkedin.com pattern of using hCard and hCalendar together is great, but the hCalendar's are not carrying all the information they could. They could use hCard
, but its need the compound class name. I am going to go through it in detail and try and get back them. At moment I cannot get the hResume to parse at all with my ufXtract parser. The hcard and hCalendars work fine. Looking at Jeff Atwood twitter stream [http://twitter.com/codinghorror] sounds like he has been having fun, with this. Great to see another large site support hResume. Glenn -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Jamie Thomson Sent: 08 December 2009 14:27 To: microformats-discuss@microformats.org Subject: [uf-discuss] Stack Overflow implements hResume Hi all, Just to let you know, http://Stackoverflow.com have implemented hResume for their http://careers.stackoverflow.com site. This was requested on 3rd November 2009 on this: http://meta.stackoverflow.com/questions/28375/should-careers-stackoverflow-com-support-hresume/31681#31681 forum post and the developer is now asking for feedback. ? Click on the link to the forum post for more info and to provide feedback. ? @JamieT _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From martijnst at gmail.com Wed Dec 9 05:59:38 2009 From: martijnst at gmail.com (Martijn Stegeman) Date: Wed Dec 9 05:59:42 2009 Subject: [uf-discuss] social network portability and xfn+hcard Message-ID: Hello all, I have been implementing a few microformats on a site that hosts my main personal profile. Some personal information with hCard and quite a few links, including me-links, group-links and xfn-links. Also, I love the concept of social network portability and I feel my personal profile site is complete enough for other sites to gather my personal info and contacts. Now, the third part of the publishing recipe for social network portability describes: 3. implement hCard wherever a user's name is mentioned in lists, in comments, in messages or wherever else it would help to identity that a "person" or "organization" is being referred to. My question: why would I do this -- in relation to social network portability? As I see it, XFN provides me with the means to link from my personal graph to some else's personal graph. Shouldn't this ideally be enough to identify my contacts? (Especially when my contacts have formed their own personal graph using rel=me links.) There are two problems I see with this: - It makes the process of identifying contacts unnecessarily fuzzy. - XFN-only contacts may not be seen by parsers that expect hCard attributes in contact lists. You might argue that XFN is currently not enough for a parser to identify all of my contacts, as XFN is not widely spread. But should that be a reason to include this recommendation in the design pattern? The more websites follow the portability pattern, the less need there is for this specific part. Thanks, Martijn From tobiasprinz at gmx.net Fri Dec 11 03:34:07 2009 From: tobiasprinz at gmx.net (Tobias Prinz) Date: Fri Dec 11 03:40:54 2009 Subject: [uf-discuss] hCard, "photo" element: Inlined or embedded images according to rfc 2397? Message-ID: <4B222E2F.1030101@gmx.net> Hello there, I am currently implementing hCard as import/export standard for a company I work with. So their main point is to exchange all contact data, which includes an associated image. Since we are talking about real im/export, the actual image is needed and not a link to it (also, the product does not allow using external links for images... hmpf). I think the most convenient way to do this would be using an inline(*) image within the html page. That exports the image itself (requirement) and keeps it all to one file, which makes it a lot easier to handle (uplods via http post, directory on web servers, etc.) So, here is the question: Does hCard actually support this? vCard does something similar (se 3.1.4 in the rfc). If nothing else is said about that, then I figure that means "yes", but: The main definition only mentions URLs, which I usually take as a hint that people were only thinking about web links (not that I am a big fan of the url/uri naming schism). So this is the basic question "has anyone thought about this yet?", and if "is this the way to do it?", because, of course, the behaviour of vCard cannot be copied directly and I might be missing another way to do it. Of course I also have to check whether the parser I am currently using supports this, too (which is independent of the standard), but right I am more interested in the standard itself. Kind regards, Tobias Prinz *) I haven't seen that done in a while, so it might not be a common thing to do, so here the short explanation: Instead of having a link, you use a base64 encoded string within the file. This is allowed because w3c allows any kind of URI as source for the src attribute of an image, and rfc2397 defines the data url scheme. And quick tests showed me that it works in all browsers I have installed. Yay! P.S.: Is there no way to search the mailing lists? I could not find one, so I stuck with google: site:http://microformats.org/discuss/mail/microformats-discuss/ "inline image" which netted one one result that was not related, "embedded image" got me zero results. From brian.suda at gmail.com Fri Dec 11 03:59:11 2009 From: brian.suda at gmail.com (Brian Suda) Date: Fri Dec 11 04:06:13 2009 Subject: [uf-discuss] hCard, "photo" element: Inlined or embedded images according to rfc 2397? In-Reply-To: <4B222E2F.1030101@gmx.net> References: <4B222E2F.1030101@gmx.net> Message-ID: <21e770780912110359w291a203x4f601bb75f0ac1f9@mail.gmail.com> On Fri, Dec 11, 2009 at 11:34 AM, Tobias Prinz wrote: > I think the most convenient way to do this would be using an inline(*) image > within the html page. ... > So, here is the question: Does hCard actually support this? --- it should yes. The vCard allows you to have BASE64 encoded data. If you put a URL in there, most address book applications ignore it. > This is allowed because w3c allows > any kind of URI as source for the src attribute of an image, and rfc2397 > defines the data url scheme. And quick tests showed me that it works in all > browsers I have installed. Yay! --- I have been using the data uri scheme on my site http://suda.co.uk/contact/ and i didn't think that the data uri worked in all versions of IE, instead they got a broken image. Please post your findings on the wiki so we can document browser and PIM usage and acceptance. > P.S.: Is there no way to search the mailing lists? I could not find one, so > I stuck with google: That or some of the other mailing list archiving applications are the best way to search the mail archives. -brian -- brian suda http://suda.co.uk From mail at tobyinkster.co.uk Fri Dec 11 04:47:23 2009 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Fri Dec 11 04:47:32 2009 Subject: [uf-discuss] hCard, "photo" element: Inlined or embedded images according to rfc 2397? In-Reply-To: <4B222E2F.1030101@gmx.net> References: <4B222E2F.1030101@gmx.net> Message-ID: <1260535643.32395.33.camel@ophelia2.g5n.co.uk> On Fri, 2009-12-11 at 12:34 +0100, Tobias Prinz wrote: > Of course I also have to check whether the parser I am currently using > supports this, too (which is independent of the standard), but right I > am more interested in the standard itself. Swignition does support RFC2397 data URLs. When it outputs vCard it converts them on the fly to "PHOTO;TYPE=BASE64:" properties which seem to be better supported in address book apps than data URLs are. The Swignition web service is down right now, but the Perl library and command line app is still available for download. -- Toby A Inkster From glenn.jones at madgex.com Mon Dec 14 02:57:32 2009 From: glenn.jones at madgex.com (Glenn Jones) Date: Mon Dec 14 03:13:29 2009 Subject: [uf-discuss] hResume to Word/PDF conversion API Message-ID: <36A319113CF910438942741C4727ADFF03F13B85@MOBY.Clarence.local> Hi All I have added a hResume conversion API to the lab.madgex.com site. It takes the URL of a page containing hResume and returns a Microsoft Word, Adobe PDF or HTML file. http://lab.madgex.com/hresume/ The API also supports external hCard, so when parsing Sarven Capadisli resume http://csarven.ca/cv it correctly selects his hCard at the bottom of the page outside the hResume element. There is also support for the Linked-in pattern of marking up experience and education with both hcalender and hcard. There are some easy to use code examples for dropping badges into your hResume pages. It's been quite hard to define the logic for displaying a hResume in Word or PDF. I would love to get any feedback where the output does not match your expectations. At the moment it allows you to re-order the section and chose type of terminology. I have built in such a way that I could add a number of different styles choices at a later date. Examples: Steve Ganz - Linked-in profile in Word http://lab.madgex.com/api/hresumeconversion1_0/?url=http://www.linkedin. com/in/steveganz&format=word§ion-order=name,summary,work,education,s kills,affiliation,publications,contact-details&terminology=en-us Sarven Capadisli - Blog CV in PDF http://lab.madgex.com/api/hresumeconversion1_0/?url=http://csarven.ca/cv &format=pdf§ion-order=name,summary,work,education,skills,affiliation ,publications,contact-details&terminology=en-gb Hopefully the Stack overflow implementation will be finished soon and I can try out on their page. Glenn If I get time I will create a bookmarklet and maybe even a simple Firefox extension From glenn.jones at madgex.com Mon Dec 14 12:27:18 2009 From: glenn.jones at madgex.com (Glenn Jones) Date: Mon Dec 14 12:31:55 2009 Subject: [uf-discuss] Marking up properties which reused pre-existing microformat Message-ID: <36A319113CF910438942741C4727ADFF03F13D7F@MOBY.Clarence.local> One of the problems I am see a lot with hResume is now properties which reused pre-existing microformat are mark-up. A good example is "education" in hResume which is hCalendar, I believe it should be mark-up like so:

Bighton Univ (1985 - 1988)

The education property is a hCalendar and as such the same class attribute should carry both "education" and "vevent". I have built my parser to look for this type of pattern, but quite a few authors on the web are using mark-up like this

Bighton Univ (1985 - 1988)

Breaking apart the "education" and "vevent" into separate element class attributes. Correct if I am wrong but only the first pattern should be supported by parsers. Either I need to update my parser or the wiki needs some good pointers on how properties which reused pre-existing microformat are mark-up. Glenn From mail at tobyinkster.co.uk Mon Dec 14 14:16:55 2009 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Mon Dec 14 14:17:06 2009 Subject: [uf-discuss] Marking up properties which reused pre-existing microformat In-Reply-To: <36A319113CF910438942741C4727ADFF03F13D7F@MOBY.Clarence.local> References: <36A319113CF910438942741C4727ADFF03F13D7F@MOBY.Clarence.local> Message-ID: <1260829016.32395.132.camel@ophelia2.g5n.co.uk> On Mon, 2009-12-14 at 20:27 +0000, Glenn Jones wrote: > Breaking apart the "education" and "vevent" into separate element > class attributes. Correct if I am wrong but only the first pattern > should be supported by parsers. I originally only supported the class="education vevent" style in Swignition, but eventually relented and supported the separate elements style too. It's so widespread, that I just gave up fighting against the tide. Not specifically talking about hResume here, though that is as good an example as any. Others include hCard's agent property, hCalendar's contact etc properties, hAudio's contributor property, etc. -- Toby A Inkster From tantek at cs.stanford.edu Mon Dec 14 15:53:12 2009 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Mon Dec 14 16:22:49 2009 Subject: [uf-discuss] Marking up properties which reused pre-existing microformat In-Reply-To: <36A319113CF910438942741C4727ADFF03F13D7F@MOBY.Clarence.local> References: <36A319113CF910438942741C4727ADFF03F13D7F@MOBY.Clarence.local> Message-ID: <60cb038a0912141553p7593f225xc89532ce77f6e3ef@mail.gmail.com> On Mon, Dec 14, 2009 at 12:27 PM, Glenn Jones wrote: > > One of the problems I am see a lot with hResume is now properties which > reused pre-existing microformat are mark-up. > > A good example is "education" in hResume which is hCalendar, I believe > it should be mark-up like so: > >

> ? ? ? ?Bighton Univ > ? ? ? ?(1985 - class="dtend">1988) >

Yes. This is an example of the common modular use of a microformat to provide additional structure to the property value of another microformat. > The education property is a hCalendar and as such the same class > attribute should carry both "education" and "vevent". I have built my > parser to look for this type of pattern, but quite a few authors on the > web are using mark-up like this > >
> ? ? ? ?

> ? ? ? ? ? ? ? ?Bighton Univ > ? ? ? ? ? ? ? ?(1985 - class="dtend">1988) > ? ? ? ?

>
Could you provide URLs to a few of the "quite a few authors" that you've found doing this, perhaps in the Examples In The Wild section? http://microformats.org/wiki/hresume#Examples_in_the_wild If it's a common errant pattern, we should document it as step one of deciding what to do next. > Breaking apart the "education" and "vevent" into separate element class > attributes. Correct if I am wrong but only the first pattern should be > supported by parsers. That's correct, per the hResume schema and field details: http://microformats.org/wiki/hresume#Schema "education. optional One or more hcalendar events with the class name 'education', with an embedded hCard indicating the name of school, address of school etc." note the distinction between "... events *with* the class name 'education'" and "an *embedded* hCard indicating ... " The example given in the spec demonstrates an hCalendar event with the class name 'education': http://microformats.org/wiki/hresume#Education
  1. Preston High School (2001 - 2005)
    2. > Either I need to update my parser or the wiki needs some good pointers > on how properties which reused pre-existing microformat are mark-up. The above description and example are from the hResume spec on the wiki - if you have ideas for either improving those examples or more illustrative examples that would have helped, certainly add suggestions to the feedback page! http://microformats.org/wiki/hresume-feedback Thanks Glenn, Tantek -- http://tantek.com/ From rafael.g.lepper at gmail.com Mon Dec 14 22:19:24 2009 From: rafael.g.lepper at gmail.com (=?iso-8859-1?Q?Rafael_Garc=EDa_Lepper?=) Date: Mon Dec 14 22:19:33 2009 Subject: [uf-discuss] Marking up properties which reused pre-existing microformat In-Reply-To: <60cb038a0912141553p7593f225xc89532ce77f6e3ef@mail.gmail.com> References: <36A319113CF910438942741C4727ADFF03F13D7F@MOBY.Clarence.local> <60cb038a0912141553p7593f225xc89532ce77f6e3ef@mail.gmail.com> Message-ID: El 15/12/2009, a las 00:53, Tantek ?elik escribi?: > On Mon, Dec 14, 2009 at 12:27 PM, Glenn Jones wrote: >> >> One of the problems I am see a lot with hResume is now properties which >> reused pre-existing microformat are mark-up. >> >> A good example is "education" in hResume which is hCalendar, I believe >> it should be mark-up like so: >> >>

    >> Bighton Univ >> (1985 - > class="dtend">1988) >>

    > > Yes. This is an example of the common modular use of a microformat to > provide additional structure to the property value of another > microformat. > > >> The education property is a hCalendar and as such the same class >> attribute should carry both "education" and "vevent". I have built my >> parser to look for this type of pattern, but quite a few authors on the >> web are using mark-up like this >> >>
    >>

    >> Bighton Univ >> (1985 - > class="dtend">1988) >>

    >>
    > > Could you provide URLs to a few of the "quite a few authors" that > you've found doing this, perhaps in the Examples In The Wild section? > > http://microformats.org/wiki/hresume#Examples_in_the_wild > > If it's a common errant pattern, we should document it as step one of > deciding what to do next. > > > >> Breaking apart the "education" and "vevent" into separate element class >> attributes. Correct if I am wrong but only the first pattern should be >> supported by parsers. > > That's correct, per the hResume schema and field details: > > http://microformats.org/wiki/hresume#Schema > > "education. optional One or more hcalendar events with the class name > 'education', with an embedded hCard indicating the name of school, > address of school etc." > > note the distinction between "... events *with* the class name > 'education'" and "an *embedded* hCard indicating ... " > > The example given in the spec demonstrates an hCalendar event with the > class name 'education': > > http://microformats.org/wiki/hresume#Education > >
      >
    1. > Preston High School > (2001 - class="dtend" title="2005-05-25">2005) >
      2. > > >> Either I need to update my parser or the wiki needs some good pointers >> on how properties which reused pre-existing microformat are mark-up. > > The above description and example are from the hResume spec on the > wiki - if you have ideas for either improving those examples or more > illustrative examples that would have helped, certainly add > suggestions to the feedback page! > > http://microformats.org/wiki/hresume-feedback > > I don't understand why you are being so unflexible, the definition sure tells to do it this way, but it is a draft, and in case of multiple education events the mark-up would end up like this

      Bighton Univ (1985 - 1988)

      Oxford Univ (1989 - 1992)

      isn't this pattern redundant repeating the class education? wouldn't it be much cleaner this way?

      Bighton Univ (1985 - 1988)

      Oxford Univ (1989 - 1992)

      Is it so difficult to parse it this way? Regards Rafael G. Lepper From scott at randomchaos.com Mon Dec 14 22:37:32 2009 From: scott at randomchaos.com (Scott Reynen) Date: Mon Dec 14 22:37:38 2009 Subject: [uf-discuss] Marking up properties which reused pre-existing microformat In-Reply-To: <60cb038a0912141553p7593f225xc89532ce77f6e3ef@mail.gmail.com> References: <36A319113CF910438942741C4727ADFF03F13D7F@MOBY.Clarence.local> <60cb038a0912141553p7593f225xc89532ce77f6e3ef@mail.gmail.com> Message-ID: On Dec 14, 2009, at 4:53 PM, Tantek ?elik wrote: > If it's a common errant pattern, we should document it as step one of > deciding what to do next. > if you have ideas for either improving those examples or more > illustrative examples that would have helped, certainly add > suggestions to the feedback page! On Dec 14, 2009, at 11:19 PM, Rafael Garc?a Lepper wrote: > I don't understand why you are being so unflexible Documenting real world examples doesn't strike me as a particularly onerous prerequisite to changing the standard. Peace, Scott From glenn.jones at madgex.com Tue Dec 15 00:35:43 2009 From: glenn.jones at madgex.com (Glenn Jones) Date: Tue Dec 15 03:03:26 2009 Subject: [uf-discuss] Re: Marking up properties which reused pre-existing microformat Message-ID: <36A319113CF910438942741C4727ADFF03F13D8A@MOBY.Clarence.local> Rafael wrote > Is it so difficult to parse it this way? No it's not too hard to parse this type of pattern. The question is it right to parse this type of pattern or do we tell people not to use it. Most authors use the parser as a way of testing weather they have mark-up something correctly. We need to be careful that we agree how the parsers should work to keep consistency. I think it may be a good pattern to add this pattern IF people are using it naturally and its implemented uniformly across all the parsers. If not I think there is case to update the wiki to tell people not to use it. Tantek wrote > Could you provide URLs to a few of the "quite a few authors" that you've found doing this, perhaps in the > Examples In The Wild section? You are right I do need document a some examples (a job for when I have a couple of spare hours). That said two of the hosted services have used it: Stack Overflow - http://careers.stackoverflow.com/klmr YIID - http://pfefferle.yiid.com/cv This worries me because both these authors took time to try and understand the spec and came up with the same "errant" pattern. Toby has already added this pattern to Swignition parser because he has seen it in the wild. Glenn From kavi at google.com Tue Dec 15 22:34:12 2009 From: kavi at google.com (Kavi Goel) Date: Tue Dec 15 23:04:22 2009 Subject: [uf-discuss] hreview-aggregate -- votes vs reviews In-Reply-To: <199b56630911301448t2e476902r88a003056709bf24@mail.gmail.com> References: <199b56630911102353j2bfc0d31re24150f588fd9a54@mail.gmail.com> <60cb038a0911110110x9c87318r408a66e34173811c@mail.gmail.com> <199b56630911201926h793b7ef7gf90fac999d615d56@mail.gmail.com> <199b56630911301448t2e476902r88a003056709bf24@mail.gmail.com> Message-ID: <199b56630912152234j4ff614c4q6987d49aa6f42fb9@mail.gmail.com> Hi folks, I've updated the hreview-aggregate draft spec to version 0.2 and included the new property "votes." You can see the draft here: http://microformats.org/wiki/hreview-aggregate Best, Kavi On Mon, Nov 30, 2009 at 2:48 PM, Kavi Goel wrote: > > Just wanted to raise this topic one more time. Please let me know if > you have any feedback on the proposal to extend hreview-aggregate to > allow sites to differentiate between the number of individual reviews > there are vs the number of votes towards an aggregate rating (where a > vote may or may not have an associated individual review). > > Proposal: > http://microformats.org/wiki/aggregate-review-brainstorming#Reviews_vs_ratings > > Motivating examples: > http://microformats.org/wiki/aggregate-review-examples#Ratings_without_reviews_examples > > I'm planning on updating the hreview-aggregate draft within the next few days. > > Kavi > > On Fri, Nov 20, 2009 at 7:26 PM, Kavi Goel wrote: > > > > Tantek, thanks for reviewing the hreview-aggregate draft. > > > > Per your suggestion, I've added several examples of sites that have > > separate counts for the number of ratings/votes and the number of > > reviews. The examples are here: > > http://microformats.org/wiki/aggregate-review-examples#Ratings_without_reviews_examples > > > > And to re-iterate the problem and proposal -- it's valuable to be able > > to differentiate between the number of reviews on a page vs the number > > of votes that contribute towards an average rating. For example, a > > page with 4 reviews is much more interesting than a page with 4 votes > > and 0 reviews. We'd like to extend the hreview-aggregate schema to > > include some method of differentiating these two different counts. The > > proposal is to add a new property called "votes"; more details are > > here: > > http://microformats.org/wiki/aggregate-review-brainstorming#Reviews_vs_ratings > > > > As before I'm happy to hear feedback on the proposal or any alternatives. > > > > Kavi > > > > On Wed, Nov 11, 2009 at 1:10 AM, Tantek ?elik wrote: > > > > > > On Tue, Nov 10, 2009 at 11:53 PM, Kavi Goel wrote: > > > > Hi all, > > > > > > > > I have replaced the stub page for hReview-aggregate with a draft spec > > > > describing the microformat that was decided on early this year. > > > ... > > > > http://microformats.org/wiki/hreview-aggregate > > > > > > > > > Hi Kavi, I've reviewed the hreview-aggregate page and it is an > > > excellent first draft. > > > > > > Thanks very much for writing this up. > > > > > > > > > > I have also updated the brainstorming page with a proposal to address > > > > one of the issues raised -- that users can leave a rating without > > > > writing a review. The current hreview-aggregate draft has a single > > > > property called "count" that is used to specify the number of reviews > > > > for a particular product or service. However, many sites have some > > > > number of votes (where users specify a numerical rating or a thumbs > > > > up/thumbs down vote) contributing to an average rating and a smaller > > > > number of full user reviews. > > > > > > > > The brainstorming page is here: > > > > http://microformats.org/wiki/aggregate-review-brainstorming > > > > > > Do you have documentation of real-world examples of sites that > > > separately publish number of votes/ratings and reviews? > > > > > > We should collect URLs to those examples in the > > > aggregate-review-examples page to make sure we are > > > modeling/brainstorming/proposing something that is designed > > > specifically for what is actually published today. > > > > > > http://microformats.org/wiki/aggregate-review-examples > > > > > > Thanks, > > > > > > Tantek > > > _______________________________________________ > > > microformats-discuss mailing list > > > microformats-discuss@microformats.org > > > http://microformats.org/mailman/listinfo/microformats-discuss From TobiasPrinz at gmx.net Wed Dec 16 02:34:50 2009 From: TobiasPrinz at gmx.net (Tobias Prinz) Date: Wed Dec 16 02:34:57 2009 Subject: [uf-discuss] Extended types (as in VCard, chapter 3.8) Message-ID: <20091216103450.257300@gmx.net> Hello there! Thanks for answering my last question concerning rfc2397 and embedded images. My code now works beautifully using the recommended methods. Of course I got myself another nice question, and that one concerns "extended types", which means freely defined elements of an hCard. Example: I have got a field "salary" which I want to embed into my hCard. VCard recommends (Problem here: As I read it, it does not say "requires") to prefix them with X- and that's it, so I'd go with X-SALARY there. This possible for a simple reason: A VCard does only contain VCard information, so all those additional fields are VCard fields anyway. I have not found a note on that in hCard, and I understand why: With hCard, the assumption of having only hCard data within does not hold. I cannot simply add 50000, because where is the difference to Green text from a lexer's point of view? I only see three potential solutions here: 1. Everything that is listed with a class within a hCard element is a (potential) additional type. Depending on the document size and the amount of markup used there, that might amount to loads of data. 2. Everything within a vCard-element that has a class matching /^x-/ is an extended type". This changes the recommendation within VCard to a requirement. A reasonable one, but even now I have trouble explaining to the CTO why our own data cannot have our company's nice prefix but needs to start with "x-". I ventured to rename the company, but he's not into that. Still, it would seem to be the most sensible solution. 3. Not work with extended types at all. Which makes it unattractive to all systems that want to use hCard as a basic system to exchange data but want to extend it. It also is not in the spirit of VCard, I'd say. And yes, this is an actual problem I encountered, not just a theoretical exercise to find limitations of hCard. I am currently trying to exchange extended contact data and I need to retrieve that data from the parser (well, I could do a second parse with my own parser to retrieve additional data, but where's the point?). So I might be willing to use a work-around and (ab)use another element to store those values. I was just wondering which element would make the most sense? It would need to be an element that has a type (to hold the "real" attribute name), that can appear more than once and that, ideally, has a very broad meaning. What would you use? Thanks in advance, Tobias Prinz From mail at tobyinkster.co.uk Wed Dec 16 04:42:02 2009 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Wed Dec 16 04:42:09 2009 Subject: [uf-discuss] Extended types (as in VCard, chapter 3.8) In-Reply-To: <20091216103450.257300@gmx.net> References: <20091216103450.257300@gmx.net> Message-ID: <1260967322.32395.243.camel@ophelia2.g5n.co.uk> On Wed, 2009-12-16 at 11:34 +0100, Tobias Prinz wrote: > 3. Not work with extended types at all. Which makes it unattractive to > all systems that want to use hCard as a basic system to exchange data > but want to extend it. It also is not in the spirit of VCard, I'd say. In Swignition I implemented a handful of X-* properties, though this was a list of additional properties recognised by the parser rather than just allowing the page to specify arbitrary classes beginning with "x-". > So I might be willing to use a work-around and (ab)use another element > to store those values. I was just wondering which element would make > the most sense? > It would need to be an element that has a type (to hold the "real" > attribute name), that can appear more than once and that, ideally, has > a very broad meaning. What would you use? Salary - ?50000 Shoe Size - 10.5 Favourite Pizza - Pepperoni Then skim through categories doing something like this (Javascriptish pseudo-code): $data = new Array(); foreach ($vcard.category as $category) { if ($category.matches(/ - /)) { ($key, $val) = $category.split(/ - /); if (!$data[$key]) $data[$key] = new Array; $data[$key].push($val); } } -- Toby A Inkster From info at csarven.ca Sun Dec 27 09:51:46 2009 From: info at csarven.ca (Sarven Capadisli) Date: Sun Dec 27 09:51:53 2009 Subject: [uf-discuss] geo shorthand in anchor Message-ID: <1261936306.2543.29.camel@csarven-laptop> http://microformats.org/wiki/geo-brainstorming#latitude_longitude_shorthand mentions: If a "geo" property lacks explicit "latitude" and "longitude" subproperties, then the "geo" property is treated like any other string property (e.g. following rules for parsing , etc.), where that string value has the same literal syntax as specified in RFC 2426 section 3.4.2: single structured value consisting of two float values separated by the SEMI-COLON character (ASCII decimal 59), specifying latitude and longitude, in that order. My question is, whether the following is, should, or should not be a valid geo representation: Montr?al, Quebec, Canada -Sarven From brian.suda at gmail.com Sun Dec 27 10:46:34 2009 From: brian.suda at gmail.com (Brian Suda) Date: Sun Dec 27 10:46:40 2009 Subject: [uf-discuss] geo shorthand in anchor In-Reply-To: <1261936306.2543.29.camel@csarven-laptop> References: <1261936306.2543.29.camel@csarven-laptop> Message-ID: <21e770780912271046i3bedc485m59aee2df1c469bc0@mail.gmail.com> On Sun, Dec 27, 2009 at 5:51 PM, Sarven Capadisli wrote: > My question is, whether the following is, should, or should not be a > valid geo representation: > > class="geo">Montr?al, Quebec, Canada --- that's a good question. Since the semantics of an "a" element are for the href, but GEO doesn't make sense as a URI, i would say that it would default to the visible text, just as if you had: Montr?al, Quebec, Canada There isn't a compelling argument to take the @title over the node value, "Montr?al, Quebec, Canada" does that make sense? -brian -- brian suda http://suda.co.uk From dennis.petersen at computerbild.de Wed Dec 30 04:56:55 2009 From: dennis.petersen at computerbild.de (Petersen, Dennis) Date: Wed Dec 30 04:57:45 2009 Subject: [uf-discuss] Problems with comma separated ratings in the Google Rich Snippets Testing Tool Message-ID: Hi, We are currently implementing microformats (hreview, hproduct) on our site and use the Google Rich Snippets Testing Tool to verify them. As recommend we only use content that is already available on the site and not hidden divs. Therefore, we have a problem with the actual in our reviews. It's common in Germany to separate values by comma instead of the dot used in the US. This leads to a false normalization of the value by the testing tool: rating value (normalized to 5.0 scale) = 2.0 value = 2,75 best = 1 worst = 6 The correct normalization would be: rating value (normalized to 5.0 scale) = 3.0 value = 2.75 best = 1 worst = 6 Is there any way to solve this problem without hiding content? I suppose that other non-English sites will face the problem when they use comma separated values. The same goes for the Date. A normal German date would be 19.11.2009 which is not recognized by the Testing Tool. Instead the American format is expected which leads to the same problem mentioned above. I just wanted to add that the testing tool is a great addition for verifying Microformats implementations. Not to mention Microformats themselves. I am really looking forward to all the great stuff that you can do when they are available everywhere. Thanks for your help and a happy new year Dennis From noreply at partigi.com Wed Dec 30 08:39:06 2009 From: noreply at partigi.com (partigi) Date: Wed Dec 30 08:39:25 2009 Subject: [uf-discuss] =?utf-8?q?=C3=81lvaro_Ortiz_te_invita_a_partigi?= Message-ID: <4b3b822ab5a0b_1f6041ef09c1064b@partigi.lacoctelera.com.tmail> Hola! ?lvaro Ortiz te ha invitado a Partigi. Partigi es un site donde puedes compartir con tus amigos las pelis que te gustan, y descubrir cosas interesantes que ver. Pr?ximamente, otros ?tems con los que nos solemos entretener... Puedes aceptar la invitaci?n pinchando en el siguiente enlace: http://www.partigi.com/users/new/a370558a05a086de143b57f5e2701d12290fde19 -- http://www.partigi.com Te ayudamos a elegir From tobiasprinz at gmx.net Wed Dec 30 09:57:27 2009 From: tobiasprinz at gmx.net (Tobias Prinz) Date: Wed Dec 30 09:57:36 2009 Subject: [uf-discuss] Problems with comma separated ratings in the Google Rich Snippets Testing Tool In-Reply-To: References: Message-ID: <4B3B9487.3040104@gmx.net> > Is there any way to solve this problem without hiding content? > I suppose that other non-English sites will face the problem when they > use comma separated values. > The same goes for the Date. A normal German date would be 19.11.2009 > which is not recognized by the Testing Tool. Instead the American format > is expected which leads to the same problem mentioned above. > > I'd try the trick used here: http://microformats.org/wiki/hcard#Human_vs._Machine_readable Kind regards, Tobias Prinz From mail at tobyinkster.co.uk Wed Dec 30 10:31:51 2009 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Wed Dec 30 10:31:58 2009 Subject: [uf-discuss] Problems with comma separated ratings in the Google Rich Snippets Testing Tool In-Reply-To: References: Message-ID: <1262197911.2190.32.camel@ophelia2.g5n.co.uk> On Wed, 2009-12-30 at 13:56 +0100, Petersen, Dennis wrote: > A normal German date would be 19.11.2009 > which is not recognized by the Testing Tool. Instead the American > format is expected which leads to the same problem mentioned above. US-style dates (mm/dd/yyyy) should not be expected. Microformats use ISO 8601 (yyyy-mm-dd) dates. http://microformats.org/wiki/date-pattern -- Toby A Inkster From info at csarven.ca Wed Dec 30 12:50:49 2009 From: info at csarven.ca (Sarven Capadisli) Date: Wed Dec 30 12:51:02 2009 Subject: [uf-discuss] geo shorthand in anchor In-Reply-To: <21e770780912271046i3bedc485m59aee2df1c469bc0@mail.gmail.com> References: <1261936306.2543.29.camel@csarven-laptop> <21e770780912271046i3bedc485m59aee2df1c469bc0@mail.gmail.com> Message-ID: <1262206249.4426.96.camel@csarven-laptop> On Sun, 2009-12-27 at 18:46 +0000, Brian Suda wrote: > On Sun, Dec 27, 2009 at 5:51 PM, Sarven Capadisli wrote: > > My question is, whether the following is, should, or should not be a > > valid geo representation: > > > > > class="geo">Montr?al, Quebec, Canada > > --- that's a good question. Since the semantics of an "a" element are > for the href, but GEO doesn't make sense as a URI, i would say that it > would default to the visible text, just as if you had: > > Montr?al, Quebec, Canada > > There isn't a compelling argument to take the @title over the node > value, "Montr?al, Quebec, Canada" > > does that make sense? > -brian > Yea, it does. Thanks for brining up the semantics of for @href. As far as geo links are concerned, I think it does make some sense as a URI. So, the next question is, should parsers pick up the geo data from the anchor, ignore, or do whatever they want with it? -Sarven From brian.suda at gmail.com Wed Dec 30 13:54:12 2009 From: brian.suda at gmail.com (Brian Suda) Date: Wed Dec 30 13:54:16 2009 Subject: [uf-discuss] geo shorthand in anchor In-Reply-To: <1262206249.4426.96.camel@csarven-laptop> References: <1261936306.2543.29.camel@csarven-laptop> <21e770780912271046i3bedc485m59aee2df1c469bc0@mail.gmail.com> <1262206249.4426.96.camel@csarven-laptop> Message-ID: <21e770780912301354h2b1c638fj7019592fc17f6fb@mail.gmail.com> On Wed, Dec 30, 2009 at 8:50 PM, Sarven Capadisli wrote: > Yea, it does. Thanks for brining up the semantics of for @href. > > As far as geo links are concerned, I think it does make some sense as a > URI. > > So, the next question is, should parsers pick up the geo data from the > anchor, ignore, or do whatever they want with it? --- the better question is, "are people publishing it this way?" If collect enough example, then we can make a better determination. -brian -- brian suda http://suda.co.uk From info at csarven.ca Wed Dec 30 14:09:06 2009 From: info at csarven.ca (Sarven Capadisli) Date: Wed Dec 30 14:09:13 2009 Subject: [uf-discuss] geo shorthand in anchor In-Reply-To: <21e770780912301354h2b1c638fj7019592fc17f6fb@mail.gmail.com> References: <1261936306.2543.29.camel@csarven-laptop> <21e770780912271046i3bedc485m59aee2df1c469bc0@mail.gmail.com> <1262206249.4426.96.camel@csarven-laptop> <21e770780912301354h2b1c638fj7019592fc17f6fb@mail.gmail.com> Message-ID: <1262210946.9728.14.camel@csarven-laptop> On Wed, 2009-12-30 at 21:54 +0000, Brian Suda wrote: > On Wed, Dec 30, 2009 at 8:50 PM, Sarven Capadisli wrote: > > Yea, it does. Thanks for brining up the semantics of for @href. > > > > As far as geo links are concerned, I think it does make some sense as a > > URI. > > > > So, the next question is, should parsers pick up the geo data from the > > anchor, ignore, or do whatever they want with it? > > --- the better question is, "are people publishing it this way?" If > collect enough example, then we can make a better determination. > > -brian AFAIK: The StatusNet platform as of version 0.9RC1 e.g., http://identi.ca/notice/17811123 Potentially, publicly documented sites at http://status.net/wiki/ListOfServers on update. http://*.status.net/ as well. -Sarven From brian.suda at gmail.com Wed Dec 30 14:30:59 2009 From: brian.suda at gmail.com (Brian Suda) Date: Wed Dec 30 14:31:05 2009 Subject: [uf-discuss] geo shorthand in anchor In-Reply-To: <1262210946.9728.14.camel@csarven-laptop> References: <1261936306.2543.29.camel@csarven-laptop> <21e770780912271046i3bedc485m59aee2df1c469bc0@mail.gmail.com> <1262206249.4426.96.camel@csarven-laptop> <21e770780912301354h2b1c638fj7019592fc17f6fb@mail.gmail.com> <1262210946.9728.14.camel@csarven-laptop> Message-ID: <21e770780912301430p71b37da9i93ccd7acd658d9c1@mail.gmail.com> On Wed, Dec 30, 2009 at 10:09 PM, Sarven Capadisli wrote: > AFAIK: > > The StatusNet platform as of version 0.9RC1 e.g., > http://identi.ca/notice/17811123 > > Potentially, publicly documented sites at > http://status.net/wiki/ListOfServers on update. --- great, can you add/start a page on the wiki to document these? that way we can find common formats and any emerging syntaxes. -brian -- brian suda http://suda.co.uk From info at csarven.ca Thu Dec 31 03:30:10 2009 From: info at csarven.ca (Sarven Capadisli) Date: Thu Dec 31 03:30:24 2009 Subject: [uf-discuss] geo shorthand in anchor In-Reply-To: <21e770780912301430p71b37da9i93ccd7acd658d9c1@mail.gmail.com> References: <1261936306.2543.29.camel@csarven-laptop> <21e770780912271046i3bedc485m59aee2df1c469bc0@mail.gmail.com> <1262206249.4426.96.camel@csarven-laptop> <21e770780912301354h2b1c638fj7019592fc17f6fb@mail.gmail.com> <1262210946.9728.14.camel@csarven-laptop> <21e770780912301430p71b37da9i93ccd7acd658d9c1@mail.gmail.com> Message-ID: <1262259010.4580.28.camel@csarven-laptop> On Wed, 2009-12-30 at 22:30 +0000, Brian Suda wrote: > On Wed, Dec 30, 2009 at 10:09 PM, Sarven Capadisli wrote: > > AFAIK: > > > > The StatusNet platform as of version 0.9RC1 e.g., > > http://identi.ca/notice/17811123 > > > > Potentially, publicly documented sites at > > http://status.net/wiki/ListOfServers on update. > > --- great, can you add/start a page on the wiki to document these? > that way we can find common formats and any emerging syntaxes. > > -brian > Added to http://microformats.org/wiki/geo-brainstorming#latitude_longitude_shorthand_and_geo_link for now. I left it out of http://microformats.org/wiki/geo-examples-in-wild and http://microformats.org/wiki/geo-examples thinking that only the acknowledged representations should be listed there. Am I right? -Sarven From tantek at cs.stanford.edu Thu Dec 31 07:10:45 2009 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Thu Dec 31 07:11:09 2009 Subject: [uf-discuss] geo shorthand in anchor In-Reply-To: <1262259010.4580.28.camel@csarven-laptop> References: <1261936306.2543.29.camel@csarven-laptop> <21e770780912271046i3bedc485m59aee2df1c469bc0@mail.gmail.com> <1262206249.4426.96.camel@csarven-laptop> <21e770780912301354h2b1c638fj7019592fc17f6fb@mail.gmail.com> <1262210946.9728.14.camel@csarven-laptop> <21e770780912301430p71b37da9i93ccd7acd658d9c1@mail.gmail.com> <1262259010.4580.28.camel@csarven-laptop> Message-ID: <60cb038a0912310710o3287b374h6e48226af499d3b4@mail.gmail.com> On Thu, Dec 31, 2009 at 3:30 AM, Sarven Capadisli wrote: > On Wed, 2009-12-30 at 22:30 +0000, Brian Suda wrote: >> On Wed, Dec 30, 2009 at 10:09 PM, Sarven Capadisli wrote: >> > AFAIK: >> > >> > The StatusNet platform as of version 0.9RC1 e.g., >> > http://identi.ca/notice/17811123 >> > >> > Potentially, publicly documented sites at >> > http://status.net/wiki/ListOfServers on update. >> >> --- great, can you add/start a page on the wiki to document these? >> that way we can find common formats and any emerging syntaxes. >> >> -brian >> > > Added to > http://microformats.org/wiki/geo-brainstorming#latitude_longitude_shorthand_and_geo_link for now. Sarven thanks very much for documenting that on the wiki - that page is a good place to capture existing publishing patterns regarding geo information. > I left it out of http://microformats.org/wiki/geo-examples-in-wild and > http://microformats.org/wiki/geo-examples thinking that only the > acknowledged representations should be listed there. Am I right? Yes that's right. The "examples-in-wild" pages are for documenting uses of existing microformats on real world web pages. One quick bit of feedback on this thread (which I'll also note on the wiki next to the examples added) - use of the title attribute for semicolon separated lat-long may not be the user-friendliest thing to do. Given microformats experience with various uses of the the title attribute - a good rule of thumb is to check to make sure that the content you are putting into the title attribute is both reasonably human readable and listenable. Thanks, Tantek -- http://tantek.com/