From martin at weborganics.co.uk Sat Jan 3 12:03:38 2009 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Jan 3 12:03:45 2009 Subject: [uf-new] media info Draft (hMedia) Message-ID: <495FC49A.2000804@weborganics.co.uk> Hello All I would like to announce a New version of the Media Info Proposal[1] The current proposal only includes the 80/20 of common elements discovered in Media and as recommended by Tantek[2] has an emphasis on modularity. There are now some new examples of how hMedia may be published with other Microformats such as hAtom, hCalendar and hReview. I would like to move the proposal to its own page http://microformats.org/wiki/hmedia in the next few days if that is ok. Comments and feedback are welcome Thanks [1] http://microformats.org/wiki/media-info-proposal [2] http://microformats.org/discuss/mail/microformats-new/2008-November/001866.html -- Martin McEvoy http://weborganics.co.uk/ "You may find it hard to swallow the notion that anything as large and apparently inanimate as the Earth is alive." Dr. James Lovelock, The Ages of Gaia From martin at weborganics.co.uk Sun Jan 4 06:56:22 2009 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Jan 4 06:56:29 2009 Subject: [uf-new] Re: media info Draft (hMedia) In-Reply-To: <495FC49A.2000804@weborganics.co.uk> References: <495FC49A.2000804@weborganics.co.uk> Message-ID: <4960CE16.5050907@weborganics.co.uk> Martin McEvoy wrote: > Hello All > > I would like to announce a New version of the Media Info Proposal[1] > The current proposal only includes the 80/20 of common elements > discovered in Media and as recommended by Tantek[2] has an emphasis on > modularity. > There are now some new examples of how hMedia may be published with > other Microformats such as hAtom, hCalendar and hReview. > > I would like to move the proposal to its own page > http://microformats.org/wiki/hmedia in the next few days if that is ok. After tree and a half years in development by various esteemed members of this community hMedia 0.1 is now a Draft Specification http://microformats.org/wiki/hmedia Please add any issues with version 0.1 hMedia to http://microformats.org/wiki/hmedia-issues If you would like hMedia to reach a version 0.2 version please add your thoughts to http://microformats.org/wiki/hmedia-brainstorming Comments and feedback are again welcome -- Martin McEvoy http://weborganics.co.uk/ "You may find it hard to swallow the notion that anything as large and apparently inanimate as the Earth is alive." Dr. James Lovelock, The Ages of Gaia From kavi at google.com Mon Jan 12 15:15:06 2009 From: kavi at google.com (Kavi Goel) Date: Mon Jan 12 15:15:13 2009 Subject: [uf-new] Microformats support for aggregate reviews In-Reply-To: <199b56630812221929x67e835a9p47747efbbd91e120@mail.gmail.com> References: <199b56630812221929x67e835a9p47747efbbd91e120@mail.gmail.com> Message-ID: <199b56630901121515u6410e1f8nf4ce875086115ad0@mail.gmail.com> Resending since the previous email fell on deaf ears due to the holidays. Microformats gurus -- please respond with your advice or concerns on the brainstorming wiki or by replying to this email! ---------- Forwarded message ---------- From: Kavi Goel Date: Mon, Dec 22, 2008 at 7:29 PM Subject: Microformats support for aggregate reviews To: microformats-new@microformats.org Hi folks, I'm interested in finding a way for microformats to support marking up aggregate reviews. Currently, hReview is focused on individual reviews, but there are many sites that aggregate reviews. I would love to hear your feedback. Some examples from the wild: http://microformats.org/wiki/aggregate-review-examples Brainstorming possible implementations: http://microformats.org/wiki/aggregate-review-brainstorming Existing formats that have been proposed (I didn't find any): http://microformats.org/wiki/aggregate-review-formats Thanks, Kavi From csarven at gmail.com Mon Jan 12 15:51:57 2009 From: csarven at gmail.com (Sarven Capadisli) Date: Mon Jan 12 15:52:00 2009 Subject: [uf-new] Microformats support for aggregate reviews In-Reply-To: <199b56630812221929x67e835a9p47747efbbd91e120@mail.gmail.com> References: <199b56630812221929x67e835a9p47747efbbd91e120@mail.gmail.com> Message-ID: On Mon, Dec 22, 2008 at 10:29 PM, Kavi Goel wrote: > I'm interested in finding a way for microformats to support marking up > aggregate reviews. Currently, hReview is focused on individual > reviews, but there are many sites that aggregate reviews. I would love > to hear your feedback. If I understand your intent correctly, I don't particularly see a need for a format to do this at this time. I think the aggregation part should be solved at the parser level. i.e., parser takes a document marked with hReview and provides an RSS or Atom feed that can be subscribed to. Alternatively, you might want to look into http://microformats.org/wiki/hAtom -Sarven From mail at tobyinkster.co.uk Tue Jan 13 03:17:29 2009 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Tue Jan 13 03:17:33 2009 Subject: [uf-new] re: Microformats support for aggregate reviews Message-ID: <50DB029C-E9AC-4401-B92C-D61D0FC8C552@tobyinkster.co.uk> Kavi Goel wrote: > I'm interested in finding a way for microformats to support marking up > aggregate reviews. Currently, hReview is focused on individual > reviews, but there are many sites that aggregate reviews. I would love > to hear your feedback. I don't understand what is needed that is not already present in hReview. If you wish to publish a list of reviews plus an average rating at the top, then use hReview for each individual review, and an hReview at the top containing the average rating. For the average rating, set the hReview "reviewer" property to an hCard for the aggregation organisation. To avoid repeating the item info in each review, just put it in the aggregate review and use the include pattern in the individual reviews. The aggregate review can be explicitly marked as an aggregate by rel-tagging it so. The aggregate review "description" property could be along the lines of "This rating is an average of 38 people's reviews". -- Toby A Inkster From kavi at google.com Tue Jan 13 22:08:56 2009 From: kavi at google.com (Kavi Goel) Date: Tue Jan 13 22:09:03 2009 Subject: [uf-new] re: Microformats support for aggregate reviews In-Reply-To: <50DB029C-E9AC-4401-B92C-D61D0FC8C552@tobyinkster.co.uk> References: <50DB029C-E9AC-4401-B92C-D61D0FC8C552@tobyinkster.co.uk> Message-ID: <199b56630901132208y3571c0f5y656db63c2bb8ca17@mail.gmail.com> Sarven and Toby, thanks for your responses. Sarven -- the challenge with doing aggregation at the parser level is that not all reviews are contained on a single page. For example, this iPod page on Amazon (http://www.amazon.com/gp/product/B001FA1NFA/) has 443 reviews. Only 10 are contained on each page. Even if the parser knew which pages to go to, it would still have to crawl 45 pages to come up with the aggregate rating. Much easier is to simply read the aggregate information that is already summarized on the first page. Toby -- I think your approach makes sense, but I have two questions. 1) how does the parser know how many user reviews contributed to the aggregate score? I think we would need some sort of explicit markup of this information rather than extracting it from a natural language review description. 2) can you clarify how a site would use the rel-tag to mark a review as an aggregate, for example, how Amazon or Yelp might do it on their page? I expect that very few sites will be willing to change their pages' UI to include metadata about reviews. Rel-tags, as far as I know, are visible links. Apologies in advance if I am misunderstanding. Kavi On Tue, Jan 13, 2009 at 3:17 AM, Toby A Inkster wrote: > > Kavi Goel wrote: > >> I'm interested in finding a way for microformats to support marking up >> aggregate reviews. Currently, hReview is focused on individual >> reviews, but there are many sites that aggregate reviews. I would love >> to hear your feedback. > > I don't understand what is needed that is not already present in hReview. > > If you wish to publish a list of reviews plus an average rating at the top, then use hReview for each individual review, and an hReview at the top containing the average rating. For the average rating, set the hReview "reviewer" property to an hCard for the aggregation organisation. To avoid repeating the item info in each review, just put it in the aggregate review and use the include pattern in the individual reviews. The aggregate review can be explicitly marked as an aggregate by rel-tagging it so. The aggregate review "description" property could be along the lines of "This rating is an average of 38 people's reviews". > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From jamie at jamierumbelow.net Wed Jan 14 00:23:39 2009 From: jamie at jamierumbelow.net (Jamie Rumbelow) Date: Wed Jan 14 00:23:52 2009 Subject: [uf-new] re: Microformats support for aggregate reviews In-Reply-To: <199b56630901132208y3571c0f5y656db63c2bb8ca17@mail.gmail.com> References: <50DB029C-E9AC-4401-B92C-D61D0FC8C552@tobyinkster.co.uk> <199b56630901132208y3571c0f5y656db63c2bb8ca17@mail.gmail.com> Message-ID: <002801c97621$67e8fb10$37baf130$@net> See, comments like that lead me on to think that we need some form of pagination system for microformats - pagination is much more popular among sites these days and a rel="paginate" might come in handy. Jamie Rumbelow Designer / Developer / Writer / Speaker +44 (0)7956 363875 | jamie (at) jamierumbelow (dot) net | http://jamierumbelow.net Founder of FourthTimeLucky Author of Practical CodeIgniter Projects Host of the popular podcast the Catch22 Podcast -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Kavi Goel Sent: 14 January 2009 06:09 To: For discussion of new microformats. Subject: Re: [uf-new] re: Microformats support for aggregate reviews Sarven and Toby, thanks for your responses. Sarven -- the challenge with doing aggregation at the parser level is that not all reviews are contained on a single page. For example, this iPod page on Amazon (http://www.amazon.com/gp/product/B001FA1NFA/) has 443 reviews. Only 10 are contained on each page. Even if the parser knew which pages to go to, it would still have to crawl 45 pages to come up with the aggregate rating. Much easier is to simply read the aggregate information that is already summarized on the first page. Toby -- I think your approach makes sense, but I have two questions. 1) how does the parser know how many user reviews contributed to the aggregate score? I think we would need some sort of explicit markup of this information rather than extracting it from a natural language review description. 2) can you clarify how a site would use the rel-tag to mark a review as an aggregate, for example, how Amazon or Yelp might do it on their page? I expect that very few sites will be willing to change their pages' UI to include metadata about reviews. Rel-tags, as far as I know, are visible links. Apologies in advance if I am misunderstanding. Kavi On Tue, Jan 13, 2009 at 3:17 AM, Toby A Inkster wrote: > > Kavi Goel wrote: > >> I'm interested in finding a way for microformats to support marking >> up aggregate reviews. Currently, hReview is focused on individual >> reviews, but there are many sites that aggregate reviews. I would >> love to hear your feedback. > > I don't understand what is needed that is not already present in hReview. > > If you wish to publish a list of reviews plus an average rating at the top, then use hReview for each individual review, and an hReview at the top containing the average rating. For the average rating, set the hReview "reviewer" property to an hCard for the aggregation organisation. To avoid repeating the item info in each review, just put it in the aggregate review and use the include pattern in the individual reviews. The aggregate review can be explicitly marked as an aggregate by rel-tagging it so. The aggregate review "description" property could be along the lines of "This rating is an average of 38 people's reviews". > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From brian.suda at gmail.com Wed Jan 14 00:45:32 2009 From: brian.suda at gmail.com (Brian Suda) Date: Wed Jan 14 00:45:44 2009 Subject: [uf-new] Microformats support for pagination Message-ID: <21e770780901140045i7fb5b2d0m38029498ccda510b@mail.gmail.com> On 1/14/09, Jamie Rumbelow wrote: > See, comments like that lead me on to think that we need some form of > pagination system for microformats - pagination is much more popular among > sites these days and a rel="paginate" might come in handy. --- There are several features built right into HTML itself to handle this. There is rel="prev" and rel="next" if you have pagination links with those values a good parser should know to continue along those paths for more information. This is a good question, can you add it to the FAQ so we can refer to it in the future? Thanks, -brian -- brian suda http://suda.co.uk From mail at tobyinkster.co.uk Wed Jan 14 00:48:34 2009 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Jan 14 00:48:43 2009 Subject: [uf-new] re: Microformats support for aggregate reviews Message-ID: <4B362894-1372-4A38-9FDC-667079487BCE@tobyinkster.co.uk> Jamie Rumbelow wrote: > See, comments like that lead me on to think that we need some form of > pagination system for microformats - pagination is much more > popular among > sites these days and a rel="paginate" might come in handy. HTML already has perfectly good rel="next"/"prev" for that. http://www.w3.org/TR/REC-html40/types.html#type-links -- Toby A Inkster From andr3.pt at gmail.com Wed Jan 14 05:02:31 2009 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Wed Jan 14 05:02:37 2009 Subject: [uf-new] Microformats support for pagination In-Reply-To: <21e770780901140045i7fb5b2d0m38029498ccda510b@mail.gmail.com> References: <21e770780901140045i7fb5b2d0m38029498ccda510b@mail.gmail.com> Message-ID: Hi Brian, On Wed, Jan 14, 2009 at 8:45 AM, Brian Suda wrote: > On 1/14/09, Jamie Rumbelow wrote: >> See, comments like that lead me on to think that we need some form of >> pagination system for microformats - pagination is much more popular among >> sites these days and a rel="paginate" might come in handy. > > --- There are several features built right into HTML itself to handle > this. There is rel="prev" and rel="next" if you have pagination links > with those values a good parser should know to continue along those > paths for more information. Do you have any suggestions on how to deal with repetitions? I've tried parsing several pages of several websites and some of them used rel-tags on tagclouds... these would be present on every page (sidebar of blog) thus rendering the data kinda useless. Should/can we create guidelines for producers AND parsers alike on how to deal with this? Like adding site-wide unique id's to the root elements? Or is this out of the scope of microformats altogether? Cheers, -- Andr? Lu?s From brian.suda at gmail.com Wed Jan 14 06:10:06 2009 From: brian.suda at gmail.com (Brian Suda) Date: Wed Jan 14 06:10:11 2009 Subject: [uf-new] Microformats support for pagination In-Reply-To: References: <21e770780901140045i7fb5b2d0m38029498ccda510b@mail.gmail.com> Message-ID: <21e770780901140610r7f99a50q6be7adf2ae6a8953@mail.gmail.com> On 1/14/09, Andr? Lu?s wrote: > Do you have any suggestions on how to deal with repetitions? I've > tried parsing several pages of several websites and some of them used > rel-tags on tagclouds... these would be present on every page (sidebar > of blog) thus rendering the data kinda useless. --- do you have a real world example of where this would be a problem? The old technorati kitchen crawled the web and allowed you to search it. Having repetitions actually allowed for a nice merging of the data. > Should/can we create guidelines for producers AND parsers alike on how > to deal with this? Like adding site-wide unique id's to the root > elements? Or is this out of the scope of microformats altogether? --- again, this would depend on the format in question. The existance of multiple events with the same timestamp and name could be used to merge data, UIDs and URLs could be as well, but everything could be gamed. But this isn?t unique to microformats, other semantic technologies would have this issue as well. There was talk of a rel-canonical awhile ago, but it wasn't big enough a problem to pursue. If you have an example we could work through it. -brian -- brian suda http://suda.co.uk From andreluis.pt at gmail.com Wed Jan 14 07:53:57 2009 From: andreluis.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Wed Jan 14 07:54:00 2009 Subject: [uf-new] Microformats support for pagination In-Reply-To: <21e770780901140610r7f99a50q6be7adf2ae6a8953@mail.gmail.com> References: <21e770780901140045i7fb5b2d0m38029498ccda510b@mail.gmail.com> <21e770780901140610r7f99a50q6be7adf2ae6a8953@mail.gmail.com> Message-ID: Thanks for the insight, Brian. Comments inline. On Wed, Jan 14, 2009 at 2:10 PM, Brian Suda wrote: > On 1/14/09, Andr? Lu?s wrote: >> Do you have any suggestions on how to deal with repetitions? I've >> tried parsing several pages of several websites and some of them used >> rel-tags on tagclouds... these would be present on every page (sidebar >> of blog) thus rendering the data kinda useless. > > --- do you have a real world example of where this would be a problem? > The old technorati kitchen crawled the web and allowed you to search > it. Having repetitions actually allowed for a nice merging of the > data. Right, in certain contexts it makes sense to merge data and end up with a more meaningful set of instances (of events, vcards, etc), but in others, not quite. I'll give an example. I coded a script that looks at a given page and grabs the rel-tags in that page. It then counts the occurrences and orders them in descending order. the script is at http://workshop.andr3.net/tageater/ this was meant to infer the user's attention profile from the rel-tags... the problem starts if I follow the rel-* links. For example the website macacos.com marks-up the tagcloud with rel-tags on every page, so if I follow the rel-archives I'll end up getting the tagcloud on every one of them... Have a look at http://workshop.andr3.net/tageater/?url=http%3A%2F%2Fmacacos.com I'm not following the links here because I was stuck with this doubt so I just print a link to them. Using rel-tags in tagclouds might be discouraged, but the fact is that it happens quite a bit in the wild. I saved a static html page of the scraping I did back then at all the barcamp atendees' webpages. you can have a look here: http://workshop.andr3.net/tageater/examples/barcamp.html , but for instance these are a few that use rel-tags on tagclouds: - http://macacos.com/ - http://www.devile.net/ - http://blog.pfragoso.org/ - http://www.brunoamaral.com/ - ... So, how to detect repetition in these cases? > >> Should/can we create guidelines for producers AND parsers alike on how >> to deal with this? Like adding site-wide unique id's to the root >> elements? Or is this out of the scope of microformats altogether? > > --- again, this would depend on the format in question. The existance > of multiple events with the same timestamp and name could be used to > merge data, UIDs and URLs could be as well, but everything could be > gamed. So what you're saying is that this falls out of the spec's scope, right? It should be the parsers adapting their behaviour depending on their goal? > > But this isn?t unique to microformats, other semantic technologies > would have this issue as well. There was talk of a rel-canonical > awhile ago, but it wasn't big enough a problem to pursue. You're right. Do you have a link where I can read more about that discussion? Thanks. > > If you have an example we could work through it. > > -brian > cheers, -- Andr? Lu?s From jamie at jamierumbelow.net Wed Jan 14 12:24:02 2009 From: jamie at jamierumbelow.net (Jamie Rumbelow) Date: Wed Jan 14 12:24:49 2009 Subject: [uf-new] rel-code In-Reply-To: <21e770780901140610r7f99a50q6be7adf2ae6a8953@mail.gmail.com> References: <21e770780901140045i7fb5b2d0m38029498ccda510b@mail.gmail.com> <21e770780901140610r7f99a50q6be7adf2ae6a8953@mail.gmail.com> Message-ID: <000f01c97686$0a7b2e70$1f718b50$@net> Hello All, A quick concept for you to digest - rel-code By adding rel="code" to a hyperlink, a page indicates that the destination of the hyperlink contains a source code file. By adding a lang="whatever-programming-language" attribute, the document can specify what programming language the destination contains. Regards, Jamie Rumbelow From brian.suda at gmail.com Wed Jan 14 13:49:52 2009 From: brian.suda at gmail.com (Brian Suda) Date: Wed Jan 14 13:57:29 2009 Subject: [uf-new] Microformats support for pagination In-Reply-To: <21e770780901141348r5a0fb091i9815172a8e4ff64d@mail.gmail.com> References: <21e770780901140045i7fb5b2d0m38029498ccda510b@mail.gmail.com> <21e770780901140610r7f99a50q6be7adf2ae6a8953@mail.gmail.com> <21e770780901141348r5a0fb091i9815172a8e4ff64d@mail.gmail.com> Message-ID: <21e770780901141349r53539618h283d24a046f9d1e@mail.gmail.com> On 1/14/09, Andr? Lu?s wrote: > I coded a script that looks at a given page and grabs the rel-tags in > that page. It then counts the occurrences and orders them in > descending order. > > the script is at http://workshop.andr3.net/tageater/ > > this was meant to infer the user's attention profile from the rel-tags... > > the problem starts if I follow the rel-* links. For example the > website macacos.com marks-up the tagcloud with rel-tags on every page, > So, how to detect repetition in these cases? --- wouldn't you just keep a list of the pages you have already crawled? So if you find a tagcloud on page /item1.html and it links to /tags/tag1 then on page item2.htm you re-find the tag cloud which links to /tags/tag1 you don't follow it again? > So what you're saying is that this falls out of the spec's scope, > right? It should be the parsers adapting their behaviour depending on > their goal? --- probably out of side of the spec, but certainly a best-practices should cover these sorts of issues. > You're right. Do you have a link where I can read more about that > discussion? Thanks. There was discussion about canonical hCards 2 years ago http://microformats.org/discuss/mail/microformats-discuss/2007-January/008265.html I am not sure how helpful any of that discussion was/is to this problem. -brian -- brian suda http://suda.co.uk From mail at tobyinkster.co.uk Wed Jan 14 14:18:50 2009 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Jan 14 14:19:00 2009 Subject: [uf-new] rel-code Message-ID: Jamie Rumbelow wrote: > By adding rel="code" to a hyperlink, a page indicates that the > destination > of the hyperlink contains a source code file. By adding a > lang="whatever-programming-language" attribute, the document can > specify > what programming language the destination contains. The HTML 4.01 recommendation defines the lang attribute as being an RFC 1766 code. (RFC 1766 has since been obsoleted by RFC 3066, itself obsoleted by RFC 4646/4647, so one assumes that authors should now use RFC 4646/4647 codes instead.) Putting a programming language in there is against the spirit of the spec, and (although SGML validators won't spot it) against the defined syntax. HTML already contains a perfectly good way of indicating that a linked file is in a particular programming language - the type attribute. Foo (download script) -- Toby A Inkster From jamie at jamierumbelow.net Wed Jan 14 14:32:34 2009 From: jamie at jamierumbelow.net (Jamie Rumbelow) Date: Wed Jan 14 14:32:48 2009 Subject: [uf-new] rel-code In-Reply-To: References: Message-ID: <2835143E-59A6-4DAD-B363-708BD59D9A87@jamierumbelow.net> Ok, I wasn't doing my homework, I apologize. JamieRumbelow designer / developer / writer / speaker +44 (0)7956 363875 jamie (at) jamierumbelow (dot) net On 14 Jan 2009, at 22:18, Toby A Inkster wrote: > Jamie Rumbelow wrote: > >> By adding rel="code" to a hyperlink, a page indicates that the >> destination >> of the hyperlink contains a source code file. By adding a >> lang="whatever-programming-language" attribute, the document can >> specify >> what programming language the destination contains. > > The HTML 4.01 recommendation defines the lang attribute as being an > RFC 1766 code. (RFC 1766 has since been obsoleted by RFC 3066, > itself obsoleted by RFC 4646/4647, so one assumes that authors > should now use RFC 4646/4647 codes instead.) Putting a programming > language in there is against the spirit of the spec, and (although > SGML validators won't spot it) against the defined syntax. > > HTML already contains a perfectly good way of indicating that a > linked file is in a particular programming language - the type > attribute. > > Foo (download script) > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From mail at tobyinkster.co.uk Wed Jan 14 14:46:51 2009 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Jan 14 14:47:01 2009 Subject: [uf-new] Microformats support for pagination Message-ID: Brian Suda wrote: > But this isn?t unique to microformats, other semantic technologies > would have this issue as well. FOAF (and RDF more generally) has a set of well-established conventions for merging data. Certain properties are taken to be what is called "inverse functional properties" (IFPs) - what that means in English is that if P is an IFP, and two people have a property P with the same value, then they're really the same person. foaf:mbox is for example defined as an IFP - each mailbox marked up with foaf:mbox belongs to exactly one person. If two people share a foaf:mbox, then they are the same person, so their data can be merged. (I know what you're thinking... there are people who share a mailbox, so doesn't this break? In theory, no it doesn't break - the specification says that it's for "personal mailboxes" only, "ie. an Internet mailbox associated with exactly one owner". In practice, people occasionally ignore the spec, but for the most part it works well.) There are other IFPs too, such as foaf:jabberID, foaf:openid, etc. So, for hCard/vCard, what are candidates for IFPs? We've discussed "uid" before, and the general agreement is that that should be fairly safe. "Photo" looks like it might be a good candidate to begin with, and probably will do in practice, but in theory the vCard spec defines it far too loosely - two people could allowably have the same photo. "Key" is pretty much in the same bucket as "photo", but is probably less useful as few people use it anyway. So really, "uid" is just about it - shame not many people use that either. > wouldn't you just keep a list of the pages you have already > crawled? So if you find a tagcloud on page /item1.html and it links to > /tags/tag1 then on page item2.htm you re-find the tag cloud which > links to /tags/tag1 you don't follow it again? I don't think that that's quite Andr?'s point. A lot of blogs have tag clouds - long lists of perhaps a hundred tags, in various sized fonts which act as jumping off points to other parts of the site. They are not tags in the rel=tag sense of the word in that they do not describe the content of the current page, but of the site as a whole. People should not be marking them with rel=tag, but nonetheless some people do. And it means that essentially every single page on their site has the same massive set of tags - rel=tag becomes useless on the whole site. -- Toby A Inkster From andr3.pt at gmail.com Wed Jan 14 15:07:30 2009 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Wed Jan 14 15:07:34 2009 Subject: [uf-new] Microformats support for pagination In-Reply-To: <21e770780901141349r53539618h283d24a046f9d1e@mail.gmail.com> References: <21e770780901140045i7fb5b2d0m38029498ccda510b@mail.gmail.com> <21e770780901140610r7f99a50q6be7adf2ae6a8953@mail.gmail.com> <21e770780901141348r5a0fb091i9815172a8e4ff64d@mail.gmail.com> <21e770780901141349r53539618h283d24a046f9d1e@mail.gmail.com> Message-ID: On Wed, Jan 14, 2009 at 9:49 PM, Brian Suda wrote: > On 1/14/09, Andr? Lu?s wrote: > > I coded a script that looks at a given page and grabs the rel-tags in > > that page. It then counts the occurrences and orders them in > > descending order. > > > > the script is at http://workshop.andr3.net/tageater/ > > > > this was meant to infer the user's attention profile from the rel-tags... > > > > the problem starts if I follow the rel-* links. For example the > > website macacos.com marks-up the tagcloud with rel-tags on every page, > > > >> So, how to detect repetition in these cases? > > > --- wouldn't you just keep a list of the pages you have already > crawled? So if you find a tagcloud on page /item1.html and it links to > /tags/tag1 then on page item2.htm you re-find the tag cloud which > links to /tags/tag1 you don't follow it again? > Like Toby said in a later reply (which I'll reply after this, to avoid confusion), I don't follow the tags, but I would follow the rel-[next|prev|archives|...] links.. so the same set of tags keep popping up... even if the url changes (and yes, you should keep a bucket of crawled-links to avoid infinite loops) if you keep getting the same set of tags, it will only increase in number of occurrences thus, the weight loses meaning. However, from my little testing and later interview with the sites owners, I think the weight of each tag is relative... since pretty much all of the tags are meaningful to the owner of the website... you just can't say that X > Y... but you can say that the owner of that site is at least interested in X and Y. Unless you see some holes in my logic. ;) > > > So what you're saying is that this falls out of the spec's scope, > > right? It should be the parsers adapting their behaviour depending on > > their goal? > > > --- probably out of side of the spec, but certainly a best-practices > should cover these sorts of issues. > Agreed. > > > You're right. Do you have a link where I can read more about that > > discussion? Thanks. > > > There was discussion about canonical hCards 2 years ago > http://microformats.org/discuss/mail/microformats-discuss/2007-January/008265.html > > I am not sure how helpful any of that discussion was/is to this problem. > Alright, I'll have a look. And on the wiki as well. I think tags are a whole different matter though, because they're based on a single element (just like xfn, and other rel-based ufs) -- Andr? Lu?s From andr3.pt at gmail.com Wed Jan 14 15:17:14 2009 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Wed Jan 14 15:17:16 2009 Subject: [uf-new] Microformats support for pagination In-Reply-To: References: Message-ID: On Wed, Jan 14, 2009 at 10:46 PM, Toby A Inkster wrote: > Brian Suda wrote: > >> But this isn?t unique to microformats, other semantic technologies >> would have this issue as well. > > FOAF (and RDF more generally) has a set of well-established conventions for > merging data. Certain properties are taken to be what is called "inverse > functional properties" (IFPs) - what that means in English is that if P is > an IFP, and two people have a property P with the same value, then they're > really the same person. > Wow.. I wasn't aware of this. Thanks for the tip. > foaf:mbox is for example defined as an IFP - each mailbox marked up with > foaf:mbox belongs to exactly one person. If two people share a foaf:mbox, > then they are the same person, so their data can be merged. (I know what > you're thinking... there are people who share a mailbox, so doesn't this > break? In theory, no it doesn't break - the specification says that it's for > "personal mailboxes" only, "ie. an Internet mailbox associated with exactly > one owner". In practice, people occasionally ignore the spec, but for the > most part it works well.) There are other IFPs too, such as foaf:jabberID, > foaf:openid, etc. > > So, for hCard/vCard, what are candidates for IFPs? We've discussed "uid" > before, and the general agreement is that that should be fairly safe. > "Photo" looks like it might be a good candidate to begin with, and probably > will do in practice, but in theory the vCard spec defines it far too loosely > - two people could allowably have the same photo. "Key" is pretty much in > the same bucket as "photo", but is probably less useful as few people use it > anyway. So really, "uid" is just about it - shame not many people use that > either. > Hmmm.. can't we use emails? if two hcards have the same email, aren't they the same entity? >> wouldn't you just keep a list of the pages you have already >> crawled? So if you find a tagcloud on page /item1.html and it links to >> /tags/tag1 then on page item2.htm you re-find the tag cloud which >> links to /tags/tag1 you don't follow it again? > > > I don't think that that's quite Andr?'s point. A lot of blogs have tag > clouds - long lists of perhaps a hundred tags, in various sized fonts which > act as jumping off points to other parts of the site. They are not tags in > the rel=tag sense of the word in that they do not describe the content of > the current page, but of the site as a whole. People should not be marking > them with rel=tag, but nonetheless some people do. And it means that > essentially every single page on their site has the same massive set of tags > - rel=tag becomes useless on the whole site. Exactly. I agree that this is not the purpose of rel-tags but I only brought it up because out of a very small sample, quite a few examples popped out. The only way out of this mess that I can think of, is to create a microformat for tagclouds, like a root element with class="tagcloud" (the actual name could be based on the most used term) and that would give parsers the mechanism to either exclude all rel-tags inside .tagcloud or to grab the rel-tags inside of the .tagcloud and bail out... This brings me to yet another point that I considered when I gave that talk... if there was a semantic way of attaching a site-wide weight to a rel-tag, that would be *awesome* for these cases. :) But we've seen that embedding machine-data into microformats is a dangerous path... ;) Thanks for your feedback, Andr? Lu?s From brian.suda at gmail.com Thu Jan 15 00:30:39 2009 From: brian.suda at gmail.com (Brian Suda) Date: Thu Jan 15 00:30:44 2009 Subject: [uf-new] Microformats support for pagination In-Reply-To: References: Message-ID: <21e770780901150030l36f816c0s73c5c8a654a1cedc@mail.gmail.com> On 1/14/09, Andr? Lu?s wrote: > Hmmm.. can't we use emails? if two hcards have the same email, aren't > they the same entity? --- yes, but you also have the situation where you have two different email addresses and it is the same entity. > > I don't think that that's quite Andr?'s point. A lot of blogs have tag > > clouds - long lists of perhaps a hundred tags, in various sized fonts which > > act as jumping off points to other parts of the site. They are not tags in > > the rel=tag sense of the word in that they do not describe the content of > > the current page, but of the site as a whole. People should not be marking > > them with rel=tag, but nonetheless some people do. And it means that > > essentially every single page on their site has the same massive set of tags > > - rel=tag becomes useless on the whole site. > > > Exactly. I agree that this is not the purpose of rel-tags but I only > brought it up because out of a very small sample, quite a few examples > popped out. The only way out of this mess that I can think of, is to > create a microformat for tagclouds, like a root element with > class="tagcloud" (the actual name could be based on the most used > term) and that would give parsers the mechanism to either exclude all > rel-tags inside .tagcloud or to grab the rel-tags inside of the > .tagcloud and bail out... --- OK, now this makes more sense. Yes, there are several ways to get around this. One would be to ignore it in the results if it was part of a tag cloud. Also, if they are publishing hAtom, you could do the inverse and only look at the rel-tags inside an hEntry. Finally, you might be able to apple some sort of normalizing algorthim to the data set. If every page had the same 15 tags, plus X more, you could drop the 15 from every entry thus removing the influence of the tag cloud on each page. > This brings me to yet another point that I considered when I gave that > talk... if there was a semantic way of attaching a site-wide weight to > a rel-tag, that would be *awesome* for these cases. :) But we've seen > that embedding machine-data into microformats is a dangerous path... > ;) --- well, one way to proposed to show weight was multiple elements around a rel-tag. This gives literally, more emphasis to it. There has been discussions in the past if this is an abuse of semantics or not. But the bigger issue is that you might have weighted it with 2 on a blog post two years ago, but now you are much more interested so you weight it with 6 . Are you going to go back and change other values? If the weight is site-wide then you probably need to have some sort of internal consistency. We should capture more of these ideas on the wiki so future mailing list questions can be pointed there rather than over several email threads. -brian -- brian suda http://suda.co.uk From kevinmarks at gmail.com Thu Jan 15 01:03:28 2009 From: kevinmarks at gmail.com (Kevin Marks) Date: Thu Jan 15 01:09:03 2009 Subject: [uf-new] Tag clouds: [was Microformats support for pagination Message-ID: <73766b160901150103g33cc3edj21b229d36fab4619@mail.gmail.com> On Thu, Jan 15, 2009 at 12:30 AM, Brian Suda wrote: > > On 1/14/09, Andr? Lu?s wrote: > > Hmmm.. can't we use emails? if two hcards have the same email, aren't > > they the same entity? > > --- yes, but you also have the situation where you have two different > email addresses and it is the same entity. > > > > I don't think that that's quite Andr?'s point. A lot of blogs have tag > > > clouds - long lists of perhaps a hundred tags, in various sized fonts which > > > act as jumping off points to other parts of the site. They are not tags in > > > the rel=tag sense of the word in that they do not describe the content of > > > the current page, but of the site as a whole. People should not be marking > > > them with rel=tag, but nonetheless some people do. And it means that > > > essentially every single page on their site has the same massive set of tags > > > - rel=tag becomes useless on the whole site. > > > > > > Exactly. I agree that this is not the purpose of rel-tags but I only > > brought it up because out of a very small sample, quite a few examples > > popped out. The only way out of this mess that I can think of, is to > > create a microformat for tagclouds, like a root element with > > class="tagcloud" (the actual name could be based on the most used > > term) and that would give parsers the mechanism to either exclude all > > rel-tags inside .tagcloud or to grab the rel-tags inside of the > > .tagcloud and bail out... > > --- OK, now this makes more sense. Yes, there are several ways to get > around this. One would be to ignore it in the results if it was part > of a tag cloud. Also, if they are publishing hAtom, you could do the > inverse and only look at the rel-tags inside an hEntry. Finally, you > might be able to apple some sort of normalizing algorthim to the data > set. If every page had the same 15 tags, plus X more, you could drop > the 15 from every entry thus removing the influence of the tag cloud > on each page. The latest HTML5 draft covers tag clouds: http://www.whatwg.org/specs/web-apps/current-work/#tag-clouds 4.5.13.1 Tag clouds This specification does not define any markup specifically for marking up lists of keywords that apply to a group of pages (also known as tag clouds). In general, authors are encouraged to either mark up such lists using ul elements with explicit inline counts that are then hidden and turned into a presentational effect using a style sheet, or to use SVG. Here, three tags are included in a short tag cloud: ... The actual frequency of each tag is given using the title attribute. A CSS style sheet is provided to convert the markup into a cloud of differently-sized words, but for user agents that do not support CSS or are not visual, the markup contains annotations like "(popular)" or "(rare)" to categorise the various tags by frequency, thus enabling all users to benefit from the information. The ul element is used (rather than ol) because the order is not particular important: while the list is in fact ordered alphabetically, it would convey the same information if ordered by, say, the length of the tag. The tag rel-keyword is not used on these a elements because they do not represent tags that apply to the page itself; they are just part of an index listing the tags themselves. From meitarm at gmail.com Fri Jan 16 06:07:31 2009 From: meitarm at gmail.com (Mr. Meitar Moscovitz) Date: Fri Jan 16 06:07:39 2009 Subject: [uf-new] A search form microformat? Message-ID: <782AD409-3B95-4E0C-B2C0-97452C3D2C2C@gmail.com> Hello everyone, I'm writing to continue a discussion that spawned from Aleksander Kmetec's work on Mosembro[0], a microformats-enabled mobile web browser, that originally started on the -discuss list. In the thread on the -discuss list[1], Aleksander and I began discussing the possible uses of (what might be) a microformat for determining which forms on web pages provide particular functionality. In the case of Mosembro's implementation, this makes it possible for the browser to display a consistent UI for a web site's site-wide search form, a feature present on the vast majority of web sites of all scales. One of the reasons we both feel this is a useful thing is because search form placement and visual appearance is not consistent across many sites, but its presence is. Furthermore, site search functionality is frequently used in many contexts in an effort to "get results faster," notably from handheld devices. Providing consistent interfaces to access a site's search form is therefore helpful from a usability perspective. In the same thread listed above, Brian Suda pointed me towards a discussion in 2006 about OpenSearch and microformats[2]. (Thanks, Brian!) From briefly reading the thread, it seems like there was a larger scope to the OpenSearch and microformats effort than what Aleksander has implemented in Mosembro and what I'm proposing here. Specifically, the search *results* of search forms were included. In the spirit of "solving only the simplest problems first," when I say "search form microformat" I specifically exclude consideration of the results of a search form. It seems logical to me for any page, including a SERP, to return microformat content based on the type of content it is. I.e., a search on Google Product Search (formerly known as Froogle) would ideally return a page marked up with hProduct (and even hReview). Many blogs that implement hAtom have search functionality and they return search results marked up in hAtom by providing lists of hentry results. However, to date, I'm unaware of a simple solution like this that allows one to discover where to *aim* a search request. WordPress blogs, as an example, use the 's' variable in a GET request's querystring to indicate a search: http://example.com/wordpress/?s=search+terms However, Google uses the 'q' variable: http://google.com/search?q=search+term In all typical cases, an HTML form element exists on the home pages of these sites that provides search functionality. However, in a typical web page, there are many forms, including email subscription forms, comment forms, and so forth. It would therefore be beneficial if these forms used standardized semantics such as a microformat that indicated what kind of functionality they provide. This way, user agents of various types, e.g., mobile web browsers, can provide simple yet consistent UI's for such specific functionality. So?the above (and more) are my preliminary thoughts on this topic. What are yours? I should state that I've used microformats in the past, but never participated in a microformat's development process. The first thing I did was go to the Wiki, read the Introduction and Process pages, and as they directed me to mail this list first, that's what I'm doing. :) There seems to be a well-developed framework for exploring the viability of additional microformats, and I am learning about that as I go. I'd appreciate pointers or constructive meta-feedback as well as feedback on the search form microformat idea specifically. Cheers, -Meitar Moscovitz Personal: http://maymay.net Professional: http://MeitarMoscovitz.com EXTERNAL REFERENCES [0] http://lexandera.com/mosembro/ [1] http://microformats.org/discuss/mail/microformats-discuss/2009-January/012765.html [2] http://microformats.org/discuss/mail/microformats-discuss/2006-August/005298.html From ryan at theryanking.com Fri Jan 16 09:41:40 2009 From: ryan at theryanking.com (Ryan King) Date: Fri Jan 16 09:41:45 2009 Subject: [uf-new] A search form microformat? In-Reply-To: <782AD409-3B95-4E0C-B2C0-97452C3D2C2C@gmail.com> References: <782AD409-3B95-4E0C-B2C0-97452C3D2C2C@gmail.com> Message-ID: <92BCE0F1-12E8-4D83-AC3A-10605DB3BD0B@theryanking.com> On Jan 16, 2009, at 6:07 AM, Mr. Meitar Moscovitz wrote: > ... > In all typical cases, an HTML form element exists on the home pages > of these sites that provides search functionality. However, in a > typical web page, there are many forms, including email subscription > forms, comment forms, and so forth. It would therefore be beneficial > if these forms used standardized semantics such as a microformat > that indicated what kind of functionality they provide. This way, > user agents of various types, e.g., mobile web browsers, can provide > simple yet consistent UI's for such specific functionality. > > So?the above (and more) are my preliminary thoughts on this topic. > What are yours? This is already covered by HTML5: http://dev.w3.org/html5/spec/Overview.html#text-state-and-search- state -ryan From meitarm at gmail.com Fri Jan 16 18:17:57 2009 From: meitarm at gmail.com (Mr. Meitar Moscovitz) Date: Fri Jan 16 18:18:09 2009 Subject: [uf-new] A search form microformat? In-Reply-To: <92BCE0F1-12E8-4D83-AC3A-10605DB3BD0B@theryanking.com> References: <782AD409-3B95-4E0C-B2C0-97452C3D2C2C@gmail.com> <92BCE0F1-12E8-4D83-AC3A-10605DB3BD0B@theryanking.com> Message-ID: On Jan 17, 2009, at 4:41 AM, Ryan King wrote: > On Jan 16, 2009, at 6:07 AM, Mr. Meitar Moscovitz wrote: > >> ... >> In all typical cases, an HTML form element exists on the home pages >> of these sites that provides search functionality. However, in a >> typical web page, there are many forms, including email >> subscription forms, comment forms, and so forth. It would therefore >> be beneficial if these forms used standardized semantics such as a >> microformat that indicated what kind of functionality they provide. >> This way, user agents of various types, e.g., mobile web browsers, >> can provide simple yet consistent UI's for such specific >> functionality. >> >> So?the above (and more) are my preliminary thoughts on this topic. >> What are yours? > > This is already covered by HTML5: > > http://dev.w3.org/html5/spec/Overview.html#text-state-and-search- > state > > -ryan Hi Ryan, Apologies on the long email before?it may have not been clear enough. Though HTML5 does offer a , that fact alone doesn't specify what the form in which this input element is specified searches. If I understand correctly, It merely indicates that the form field itself is "a search field," and so it must adhere to certain sanitization behaviors and so forth. This is helpful, but by itself still doesn't tell me what the form will search?the site I'm on? All of it or a specific section? A site somewhere else? In the case of a user agent like Mosembro, just trying to find the first element isn't enough to identify the form field to link up to its browser chrome, for example. Trying to find a combination of
and the aforementioned input element might get one closer, but doesn't solve the case where there are multiple search forms on a single site, such as the My Yahoo! portal page. So the idea is that the semantics of the form as a whole need to be able to aim such tools to particular forms. While Yahoo! and Google's search APIs are well known, smaller site's often aren't. Each of the three examples I talked about so far (the two search engines and a WordPress site), each use different indicators for the HTML that defines their forms. Making those consistent isn't what the HTML5 spec is talking about, unless of course I'm misunderstanding the part of the HTML5 you've linked me to, in which case I'd appreciate the edification. :) Cheers, -Meitar Moscovitz Personal: http://maymay.net Professional: http://MeitarMoscovitz.com From kavi at google.com Thu Jan 22 16:02:07 2009 From: kavi at google.com (Kavi Goel) Date: Thu Jan 22 16:02:19 2009 Subject: [uf-new] re: Microformats support for aggregate reviews In-Reply-To: <4B362894-1372-4A38-9FDC-667079487BCE@tobyinkster.co.uk> References: <4B362894-1372-4A38-9FDC-667079487BCE@tobyinkster.co.uk> Message-ID: <199b56630901221602v114791f7je2a3e779dc8d7759@mail.gmail.com> In order to move this discussion about aggregate reviews along, I'd like to have a discussion over IRC. As a heads-up, I'll plan on discussing alternatives around 2PM Pacific time tomorrow. For folks in different timezones who will be out enjoying the nightlife, sleeping or otherwise away from a computer, please feel encouraged to post ideas via this email discussion or on the brainstorming wiki here: http://microformats.org/wiki/aggregate-review-brainstorming Thanks, Kavi On Wed, Jan 14, 2009 at 12:48 AM, Toby A Inkster wrote: > > Jamie Rumbelow wrote: > >> See, comments like that lead me on to think that we need some form of >> pagination system for microformats - pagination is much more popular among >> sites these days and a rel="paginate" might come in handy. > > HTML already has perfectly good rel="next"/"prev" for that. > > http://www.w3.org/TR/REC-html40/types.html#type-links > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Sat Jan 24 08:04:49 2009 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Jan 24 09:31:40 2009 Subject: [uf-new] Blog post on HTML5, Microformats and RDFa Message-ID: <497B3C21.8090907@digitalbazaar.com> Mark Birbeck (the lead technical mind behind RDFa) has written an interesting piece about HTML5, Microformats and RDFa. In the piece, he explores distributed semantics extension (RDFa/XHTML2) vs. centralized semantics extension (uF/HTML5). It's an interesting post because it outlines the two philosophies at play and how they're affecting the next-generation of web semantics. http://webbackplane.com/mark-birbeck/blog/2009/01/rdfa-means-extensibility No surprises in his conclusion (he thinks RDFa is the way forward)... worth a read, even for the die-hard uFers, as several interesting points are made along the way. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.1 Website Launch http://blog.digitalbazaar.com/2009/01/16/bitmunk-3-1-website-launch From danbri at danbri.org Sat Jan 24 10:54:48 2009 From: danbri at danbri.org (Dan Brickley) Date: Sat Jan 24 11:17:24 2009 Subject: [uf-new] Blog post on HTML5, Microformats and RDFa In-Reply-To: <497B3C21.8090907@digitalbazaar.com> References: <497B3C21.8090907@digitalbazaar.com> Message-ID: <497B63F8.9010101@danbri.org> +cc: Mark Birbeck On 24/1/09 17:04, Manu Sporny wrote: > Mark Birbeck (the lead technical mind behind RDFa) has written an > interesting piece about HTML5, Microformats and RDFa. In the piece, he > explores distributed semantics extension (RDFa/XHTML2) vs. centralized > semantics extension (uF/HTML5). It's an interesting post because it > outlines the two philosophies at play and how they're affecting the > next-generation of web semantics. > > http://webbackplane.com/mark-birbeck/blog/2009/01/rdfa-means-extensibility > > No surprises in his conclusion (he thinks RDFa is the way forward)... > worth a read, even for the die-hard uFers, as several interesting points > are made along the way. While there is some some interesting history in there, and plenty of design observations that I agree with, it's not a very helpful post, in terms of communication between diverse communities. "The WHATWG for example are pursuing a much more monolithic approach with HTML5; they see no need for extension points, since the language itself will cover everything." "The Microformats approach is also counter to the idea of 'extension points' that are open to anyone, since it, too, attempts to centrally control the creation of new formats, stifling the evolution of new vocabularies by specialists within their sectors." I fail to see how presenting microformat and HTML5 enthusiasts as control freaks is going to help anything. I know from talking with various developers from the WHATWG and Microformats scene that they simply don't see things this way. I can see why Mark might think this, but it's an needlessly provocative way of phrasing things. HTMLVery binary, them-and-us thinking, at a time when many "RDF people" are also working with microformat parsers, and many "microformat people" are also busy with RDFa, SPARQL, GRDDL and so on. It's also in a week when http://validator.nu/ acquired an experimental HTML5+RDFa parser for a no-namespaces/CURIEs subset of RDFa. While this might not be what everyone wants, that's the nature of compromise and collaboration. What we need right now is a sincere effort from all parties to understand and respect those they're arguing with, rather than picking fights and suggesting the worst motives lie behind every action. Mark, can you try to be a teeny bit more empathy-minded when writing about other communities' work? RDFa is good enough to stand on its strengths. cheers, Dan -- http://danbri.org/ From davidjanes at blogmatrix.com Sat Jan 24 14:43:32 2009 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Jan 24 14:43:36 2009 Subject: [uf-new] Blog post on HTML5, Microformats and RDFa In-Reply-To: <497B63F8.9010101@danbri.org> References: <497B3C21.8090907@digitalbazaar.com> <497B63F8.9010101@danbri.org> Message-ID: <21e523c20901241443n4dea3985ufa5e0b60e3eccee0@mail.gmail.com> On Sat, Jan 24, 2009 at 1:54 PM, Dan Brickley wrote: > +cc: Mark Birbeck > > On 24/1/09 17:04, Manu Sporny wrote: >> >> Mark Birbeck (the lead technical mind behind RDFa) has written an >> interesting piece about HTML5, Microformats and RDFa. In the piece, he >> explores distributed semantics extension (RDFa/XHTML2) vs. centralized >> semantics extension (uF/HTML5). It's an interesting post because it >> outlines the two philosophies at play and how they're affecting the >> next-generation of web semantics. >> >> http://webbackplane.com/mark-birbeck/blog/2009/01/rdfa-means-extensibility >> >> No surprises in his conclusion (he thinks RDFa is the way forward)... >> worth a read, even for the die-hard uFers, as several interesting points >> are made along the way. > > While there is some some interesting history in there, and plenty of design > observations that I agree with, it's not a very helpful post, in terms of > communication between diverse communities. > > "The WHATWG for example are pursuing a much more monolithic approach > with HTML5; they see no need for extension points, since the language itself > will cover everything." > > "The Microformats approach is also counter to the idea of 'extension > points' that are open to anyone, since it, too, attempts to centrally > control the creation of new formats, stifling the evolution of new > vocabularies by specialists within their sectors." > > I fail to see how presenting microformat and HTML5 enthusiasts as control > freaks is going to help anything. I know from talking with various > developers from the WHATWG and Microformats scene that they simply don't see > things this way. > > I can see why Mark might think this, but it's an needlessly provocative way > of phrasing things. HTMLVery binary, them-and-us thinking, at a time when > many "RDF people" are also working with microformat parsers, and many > "microformat people" are also busy with RDFa, SPARQL, GRDDL and so on. It's > also in a week when http://validator.nu/ acquired an experimental HTML5+RDFa > parser for a no-namespaces/CURIEs subset of RDFa. While this might not be > what everyone wants, that's the nature of compromise and collaboration. What > we need right now is a sincere effort from all parties to understand and > respect those they're arguing with, rather than picking fights and > suggesting the worst motives lie behind every action. > > Mark, can you try to be a teeny bit more empathy-minded when writing about > other communities' work? RDFa is good enough to stand on its strengths. > > cheers, > > Dan Very interesting reading. One point though which I think eludes some RDF people (to be a tiny bit provocative myself) is this: people don't want a format that does _anything_, they want a format that does _something_. Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com