Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Breton Slivka wrote: I think this sort of counter argument is a straw man. The proposal from Guillaume was not to write a natural language parser that can parse any kind of human written date. The proposal was to parse a very specific and standardized format of date. If one were to write Oktober, the specified behavior for parsers should be to fail, and possibly throw errors. I for one, strongly agree with this approach. Essentially the problem with the ABBR problem that the microformat community faces, is a set of three restrictions, all applied, results in a set of 0 solutions. Every solution I've seen so far only satisfies two of those restrictions, and is immediately shot down by someone in the community who thinks the third restriction is invoilatable. the restrictions: 1. No information hiding 2. Humans first, machines second. 3. It must be in a format that's easily machine parsable. You see the problem here? You guys are going to have to comprimise on one of these three damned restrictions, or face irrelevance! I suggests a 4th should be taken very seriously: 4. Respect the natural language, calendar, and writing system preferences of the human content author. cheers, Dan -- http://danbri.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
On Mon, Jun 30, 2008 at 5:54 PM, Dan Brickley [EMAIL PROTECTED] wrote: Breton Slivka wrote: I think this sort of counter argument is a straw man. The proposal from Guillaume was not to write a natural language parser that can parse any kind of human written date. The proposal was to parse a very specific and standardized format of date. If one were to write Oktober, the specified behavior for parsers should be to fail, and possibly throw errors. I for one, strongly agree with this approach. Essentially the problem with the ABBR problem that the microformat community faces, is a set of three restrictions, all applied, results in a set of 0 solutions. Every solution I've seen so far only satisfies two of those restrictions, and is immediately shot down by someone in the community who thinks the third restriction is invoilatable. the restrictions: 1. No information hiding 2. Humans first, machines second. 3. It must be in a format that's easily machine parsable. You see the problem here? You guys are going to have to comprimise on one of these three damned restrictions, or face irrelevance! I suggests a 4th should be taken very seriously: 4. Respect the natural language, calendar, and writing system preferences of the human content author. cheers, Dan I thought that was implied by restriction #2, and thus leads to proponents of restriction #3 getting in a hoot because perfectly satisfying #2 is too hard. so from there you can either comprimise #2 or #1 to satisfy proponents of #3. violating #2 is a bad idea, but if you violate #1, Tantek steps in and says you can't do that. Since it's difficult to overcome the influence and authority of Tantek in this community, comprimising #3 is the only way you can go. Otherwise the argument is just going to go around in circles forever. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
the restrictions: 1. No information hiding 2. Humans first, machines second. 3. It must be in a format that's easily machine parsable. You see the problem here? You guys are going to have to comprimise on one of these three damned restrictions, or face irrelevance! I suggests a 4th should be taken very seriously: 4. Respect the natural language, calendar, and writing system preferences of the human content author. cheers, Dan I thought that was implied by restriction #2, and thus leads to proponents of restriction #3 getting in a hoot because perfectly satisfying #2 is too hard. so from there you can either comprimise #2 or #1 to satisfy proponents of #3. violating #2 is a bad idea, but if you violate #1, Tantek steps in and says you can't do that. Since it's difficult to overcome the influence and authority of Tantek in this community, comprimising #3 is the only way you can go. Otherwise the argument is just going to go around in circles forever. But really, when you get right down to it, in this community there is at least one, strongly influential person who is a proponent of each of the three restrictions, and you're never going to make all three of them perfectly happy. I'm vastly simplifying the case here, but I think that's basically why the community hasn't cracked this nut yet. It's a wicked problem. Any solution is going to be some kind of comprimise, and there's going to be someone in the community quite passionately against it, so we're basically paralyzed until we can all decide which of the three rules is not sacred. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
On Tue, Jul 1, 2008 at 9:49 AM, Breton Slivka [EMAIL PROTECTED] wrote: On Tue, Jul 1, 2008 at 3:11 AM, Ben Ward [EMAIL PROTECTED] wrote: I'd like to make a very important point. On 30 Jun 2008, at 10:38, Breton Slivka wrote: if you violate #1, Tantek steps in and says you can't do that. Since it's difficult to overcome the influence and authority of Tantek in this community, comprimising #3 is the only way you can go. Otherwise the argument is just going to go around in circles forever. To quote the wiki: Microformats are not controlled by any individual or organization — http://microformats.org/wiki/microformats#microformats_are_not Disagreement within community members is always likely, such is the nature of community. At this point in this community's life, no one person is more important than another, and if that were ever to be the case, the community and the effort of microformats generally will suffer greatly. When someone says you 'can't' do something, it's likely in the context of the microformats principals. Someone saying 'no' cannot be backed up only by their reputation and stature. 'Citation needed', is perhaps the most succinct requirement. The most worrying thing about this message is that anyone should perceive the direction of this community as being dictated by one personality's viewpoint. That is not the case, and the microformats effort will fall apart if it ever was. To make decisions pre-emptively out of this misperception is not going to lead us to the best solutions. Additionally, it may well be that we're dealing with a problem right now calls for an exception to a principal. I'm not aware that we've ever consciously made exceptions before, so there's no precedent. As such, the justification for and the scope of such exception needs to be _very clearly documented_ and approached thoroughly. The justification for making an exception needs to be held to very careful scrutiny. B Yes, I know that's the party line, but vehemantly insisting on the truth of such an assertion does not make it true. Are you seriously suggesting that there are cases where someone has proposed a solution involving information hiding, and Tantek HASN'T stepped in, and immediately put an end to all conversation along those lines? If there is such a case, I'm quite curious to see it, and I'm also quite curious to see what else must have stepped in the way to put an end to that line of solutions. Yes, restriction #1, no information hiding is a microformats community principle, but it's quite obviously Tantek's baby, and in the past, it's primarily been Tantek who has enforced that rule, and Tantek's enforcement has been effective. If this reality disrupts your rose colored idealistic view of the microformats community, well, I can't help you. You haven't stated a particularly compelling case. You've only recited community dogma. That said, I actually agree with the rule, and I'm glad it's being enforced, and I don't mind that it happens to be Tantek that's enforcing it. It's a good rule, and I understand the reasoning behind it. All I'm saying is that if we're not going to hide information, and we're not going to make things difficult for humans reading the microformat, or humans writing the microformat, violating restriction #3 is the *ONLY* way to go, until someone happens to pull a magic bullet out of the air. But I'm honestly not holding out hope. If nobody wants to violate Rule #1, and nobody wants to violate Rule #2, we're going to have to make bulkier more complicated parsers. Also, I would like to point out, that the restrictions I've listed are not binary. All the solutions I've seen fall somewhere along a continuum, and indeed many existing microformats violate some principle or another to some extent. The ABBR pattern at the center of this debate violates restriction #1 and restriction #2 to some extent. It's semi hidden data that is semi unfriendly to humans. And it's the truth and value of the restrictions #1 and #2, I think, that have led to the failure of the ABBR pattern- It failed because of those violations. And it's especially those failures in restriction #1, and #2 that I think will force a solution that must violate the implicit community rule of avoiding complicated parsers. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
I think this sort of counter argument is a straw man. The proposal from Guillaume was not to write a natural language parser that can parse any kind of human written date. The proposal was to parse a very specific and standardized format of date. If one were to write Oktober, the specified behavior for parsers should be to fail, and possibly throw errors. I for one, strongly agree with this approach. Essentially the problem with the ABBR problem that the microformat community faces, is a set of three restrictions, all applied, results in a set of 0 solutions. Every solution I've seen so far only satisfies two of those restrictions, and is immediately shot down by someone in the community who thinks the third restriction is invoilatable. the restrictions: 1. No information hiding 2. Humans first, machines second. 3. It must be in a format that's easily machine parsable. You see the problem here? You guys are going to have to comprimise on one of these three damned restrictions, or face irrelevance! On Sat, Jun 28, 2008 at 9:07 PM, Fil [EMAIL PROTECTED] wrote: I'm not a great fan of natural language here. What if I want to write 3l33t (well, not at my age mind you), or punk, maybe use Oktober instead of October cause I'm a (admittedly bad) poet? The human will understand, the computer won't. -- Fil ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
the restrictions: 1. No information hiding 2. Humans first, machines second. 3. It must be in a format that's easily machine parsable. You see the problem here? You guys are going to have to comprimise on one of these three damned restrictions, or face irrelevance! To continue- the reason I strongly agree with Guillaume's proposal (go back and read it, this time without attempting to distort it in order to discredit it), is that it comprimises in the most ridiculous and disingenuous of the three inviolable restrictions. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
I'm not a great fan of natural language here. What if I want to write 3l33t (well, not at my age mind you), or punk, maybe use Oktober instead of October cause I'm a (admittedly bad) poet? The human will understand, the computer won't. -- Fil ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Fil wrote: I'm not a great fan of natural language here. What if I want to write 3l33t (well, not at my age mind you), or punk, maybe use Oktober instead of October cause I'm a (admittedly bad) poet? The human will understand, the computer won't. Or Chinese? Dan -- http://danbri.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
On 28 Jun 2008, at 13:03, André Luís wrote: October Oct. And other languages, like Portuguese: Outubro Out. This, however, could be handled with abbr, without hindering accessibility. span class=monthabbr title=OctoberOct./abbr/span With the current abbr-pattern, your example should be: abbr class=month title=OctoberOct./abbr That's a perfectly valid abbreviation, but doesn't address the internationalisation issue. abbr class=month title=OctoberOutubro/abbr is not an abbreviation, it's translation. We end up with the same problem that exists in hcard with supporting span class=tel span class=typecell/span… in languages outside US English. B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Message: 3 Date: Thu, 26 Jun 2008 11:16:19 -0700 From: Guillaume Lebleu [EMAIL PROTECTED] Subject: Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Belov, Charles wrote: I'd suggest modifying that to not require the computer to parse the date. Something like: span class=dstartm lang=en-usOctober/span span class=dstartd5/span, span class=dstarty2004/span +1: DRY-, POSH- and humans first-compatible IMO. Maybe the following may be POSHer and backward-compatible with the existing dstart class name convention? span class=dtstart lang=en-usspan class=monthOctober/span span class=day5/span, span class=year2004/span/span By George, I think you've got it! Then there is the time issue, including 24-hour vs. 12-hour. So perhaps (with all characters outside the inner spans being optional for human readability): span class=dtstart lang=en-usspan class=monthOctober/span span class=day5/span, span class=year2004/span, span class=hhmm1740/span GMTspan class=tz-7/span/span would be equivalent to: span class=dtstart lang=en-usspan class=monthOctober/span span class=day5/span, span class=year2004/span, span class=hhmmampm5:40 a.m./span span class=tzabbrPDT/span/span noting that hhmmampm might be expressed with or without the m, or with n for noon (12n) or midnight (12m). Hope this helps, Charles Chas Belov SFMTA Webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
-Original Message- Message: 2 Date: Tue, 24 Jun 2008 15:17:24 -0700 From: Guillaume Lebleu [EMAIL PROTECTED] Subject: Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Belov, Charles wrote: I feel it is unreasonable to ask a non-technical person to produce ISO-format dates/times, so microformats do not produce an acceptable solution at this time for marking up meeting announcements. I agree that only an editor extension would make writing ISO-format date/time practical by humans, which I never felt was compliant with designed for humans first, machine second. What about the idea of a plain old English microformat (POEM?) based on well-known practices in various languages [1], in the tradition of paving the cows path: these practices are pretty-well established IMO and used by authors in the newspapers, magazines, etc. For instance, in English: span class=dstart lang=en-usOctober 5, 2004/span span class=dstart lang=en-us10/5/2004/span span class=dstart lang=fr5 Octobre 2004/span span class=dstart lang=fr5/10/2004/span The locale could be specified locally (lang=en-us) or inherited from the HTML document or a containing div. Granted it would make the parsing more complex, but it would comply with designed for humans first, machine second. Also, additional class would be required to distinguish the date part from the time part in something like: span class=dstart lang=en-usspan class=dateOctober 5, 2004span at span class=time6PM/span/span I'd suggest modifying that to not require the computer to parse the date. Something like: span class=dstartm lang=en-usOctober/span span class=dstartd5/span, span class=dstarty2004/span Hope this helps, Charles Chas Belov SFMTA Webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Belov, Charles wrote: I'd suggest modifying that to not require the computer to parse the date. Something like: span class=dstartm lang=en-usOctober/span span class=dstartd5/span, span class=dstarty2004/span +1: DRY-, POSH- and humans first-compatible IMO. Maybe the following may be POSHer and backward-compatible with the existing dstart class name convention? span class=dtstart lang=en-usspan class=monthOctober/span span class=day5/span, span class=year2004/span/span Just a thought. G ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Message: 8 Date: Tue, 24 Jun 2008 12:03:30 -0400 From: Manu Sporny [EMAIL PROTECTED] Subject: [uf-discuss] Microformats and RDFa not as far apart as previously thought To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8 There have been some interesting blog posts by people at the BBC, Mozilla and W3C about Microformats and RDFa in the past two days. The first covers BBC's decision to drop support for the abbr-based design pattern written by Michael Smethurst (who worked with this community on hAudio among other things): Removing abbr-based Microformats from BBC http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from _bbc.shtml I have come to a similar decision. In my case, I will split the human-readable portion entirely from the microformat portion, and the microformat portion will be entirely styled display:none. That applies to machine-intermediated content. I feel it is unreasonable to ask a non-technical person to produce ISO-format dates/times, so microformats do not produce an acceptable solution at this time for marking up meeting announcements. Charles Chas Belov SFMTA Webmaster www.sfmta.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Belov, Charles wrote: I feel it is unreasonable to ask a non-technical person to produce ISO-format dates/times, so microformats do not produce an acceptable solution at this time for marking up meeting announcements. I agree that only an editor extension would make writing ISO-format date/time practical by humans, which I never felt was compliant with designed for humans first, machine second. What about the idea of a plain old English microformat (POEM?) based on well-known practices in various languages [1], in the tradition of paving the cows path: these practices are pretty-well established IMO and used by authors in the newspapers, magazines, etc. For instance, in English: span class=dstart lang=en-usOctober 5, 2004/span span class=dstart lang=en-us10/5/2004/span span class=dstart lang=fr5 Octobre 2004/span span class=dstart lang=fr5/10/2004/span The locale could be specified locally (lang=en-us) or inherited from the HTML document or a containing div. Granted it would make the parsing more complex, but it would comply with designed for humans first, machine second. Also, additional class would be required to distinguish the date part from the time part in something like: span class=dstart lang=en-usspan class=dateOctober 5, 2004span at span class=time6PM/span/span Just an idea, Guillaume [1] http://www.ego4u.com/en/cram-up/vocabulary/date/written ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Guillaume Lebleu wrote: span class=dstart lang=en-usOctober 5, 2004/span Cognition already supports this as a last ditch attempt at parsing dates - but I wouldn't recommend it get adopted widely. It's too unreliable; too much work to deal with internationalisation; too much work full-stop in languages that don't provide a handy library that takes care of most of the work. -- Toby A Inkster mailto:[EMAIL PROTECTED] http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Toby A Inkster wrote: Guillaume Lebleu wrote: span class=dstart lang=en-usOctober 5, 2004/span Cognition already supports this as a last ditch attempt at parsing dates - Thank you for the attempt. but I wouldn't recommend it get adopted widely. It's too unreliable; Why is this that requiring that English content writers (I mean only those don't want to use the abbr pattern) to write dates and times in accordance to the existing precise rules of English grammar and publishing style guides (ex. AP stylebook) they know about (or used to know about) is less reliable than asking them to write them twice, one in the format they like and a second time in an ISO format most of them likely don't know about in an relatively arcane syntax? I think it really depends on where our priorities are as a community. If most hCalendar items are destined to be software-generated (including via, say, a TinyMCE plugin) or are added by specialized staff, after the content is authored, I agree with you. On the other hand, if we want actual content authors to be able to add this mark-up, then I think plain old English microformats may be more reliable, and actually more used in the first place, than dark data or RDFa. too much work to deal with internationalisation; I don't think we need to support all locales at once. I don't know in how many written languages BBC publishes in, but it might be that supporting en-uk and en-us might be enough for a start. Also, one can imagine that Microformats tools could focus on the most common written languages and then expose hooks for others to implement support for other locales. too much work full-stop in languages that don't provide a handy library that takes care of most of the work. True, but again, what are our priorities? making programmers' life easier or making content authors and content readers' life easier? Anyway, there are other problems. Just trying to think outside of the class. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
