Re: [uf-discuss] Microformats and RDFa not as far apart as previously thought
On Wed, Jun 25, 2008 at 5:23 AM, George Brocklehurst [EMAIL PROTECTED] wrote: Is it worth revisiting Tantek's original suggestion of using the object element to represent dates? [1] The idea was to do something like this: object data=20050125January 25/object From what Tantek said on his blog, the main reason for not using objects was that they were not well supported in Safari. However, Safari's object support is now much improved: fallbacks are supported and display:inline and intrinsic sizing will work correctly. Safari 2.0.2, which came out in November 2005, was the first version to contain these improvements [2]. 1. The purpose of the object element is to allow the browser to run an external application for a non-native data type (e.g., Java applet) [1]. 2. Safari 3 is actually handling object the corect way. [2] object is not the right way to go in this case. [1] http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3 [2] http://microformats.org/wiki/include-pattern-feedback#Objects_and_Browser_Behavior (see point: Sarven Capadisli 16:34, 23 Jun 2008 (PDT)) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and RDFa not as far apart as previously thought
On Sat, Jun 28, 2008 at 1:33 AM, Martin McEvoy [EMAIL PROTECTED] wrote: On Sat, 2008-06-28 at 00:11 +0100, Toby A Inkster wrote: The gist of mine is more about using RDFa to add information to hCards in order to encapsulate information which hCard itself can't represent (height, shoe size, whatever). Now that is an interesting idea, your article should make good reading. Indeed. Let me just ask this to see if we're on the same wave length or if I misundertood something this extension would only work on xHTML, right? Or is it possible to use rdfa in html? (I'm not that proficient in rdfa) Cheers, -- André Luís ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and RDFa not as far apart as previously thought
Perhaps we could solve this by changing the value of the abbr title attribute to a different, widely used date format that is both machine and date friendly? Take the JS date format, for instance? On 6/28/08, Dan Brickley [EMAIL PROTECTED] wrote: 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and RDFa not as far apart as previously thought
Dimitri Glazkov wrote: Perhaps we could solve this by changing the value of the abbr title attribute to a different, widely used date format that is both machine and date friendly? Take the JS date format, for instance? Not everyone uses the same calendar. For example there are lot of blogs in Persian/Iranian/Farsi. See http://en.wikipedia.org/wiki/Iranian_Blog ... In these cases, often the machine format (notably Atom/RSS) will use ISO-8601 and suchlike; while the human-facing text will often use a 'local' calendar. I don't have stats handy but I doubt this can be dismissed as a corner-case. http://en.wikipedia.org/wiki/Chinese_calendar#The_relevance_of_the_calendar_today suggests this is also an issue in China. cheers, Dan -- http://danbri.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and RDFa not as far apart as previously thought
André Luís wrote: this extension would only work on xHTML, right? Or is it possible to use rdfa in html? (I'm not that proficient in rdfa) It's not possible to use RDFa in valid HTML and adding all the element changes and new attributes necessary for RDFa to HTML is not part of the current proposals for HTML5. If you want to to use RDF in an HTML context, look to eRDF: http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml Note that some of the examples there misuse the TITLE attribute as badly as some of the microformat patterns we've seen. -- Benjamin Hawkes-Lewis ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and RDFa not as far apart as previously thought
George Brocklehurst wrote: Is it worth revisiting Tantek's original suggestion of using the object element to represent dates? [1] The idea was to do something like this: object data=20050125January 25/object From what Tantek said on his blog, the main reason for not using objects was that they were not well supported in Safari. However, Safari's object support is now much improved: fallbacks are supported and display:inline and intrinsic sizing will work correctly. Safari 2.0.2, which came out in November 2005, was the first version to contain these improvements [2]. It might be that there are other reasons for not using object that I've missed (I'm fairly new to the wonderful world of Microformats) and it might be that there's still a significant population of Safari users on 2.0.1 or older, but if not this could be a way forward that gets around the abbr issue. I'm normally just a lurker here, but no-one has replied, so... Using the object element seems like a very sensible solution. What are the blocking issues now that Safari handles it? I've run a few quick tests and Firefox,Opera, Safari and IE7 seem ok. IE6 won't display the content, but that may be an issue with my copy of MultipleIE. According to the Include-pattern page on the wiki ( http://microformats.org/wiki/include-pattern ) this may be due my to ActiveX being disabled/broken. The focus seems to have drifted toward smarter parsing of dates, but the two nice things about the title=somethingmachinereadible pattern were that it could potentially be used for other data (not just dates), and that it was simple enough for us muggles to understand and implement. Any thoughts? Ed Just a thought, G [1] http://tantek.com/log/2005/01.html [2] http://webkit.org/blog/32/webkit-fixes-in-safari-202-mac-os-x-1043/ ___ 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
[uf-discuss] Microformats and RDFa not as far apart as previously thought
André Luís wrote: this extension would only work on xHTML, right? Or is it possible to use rdfa in html? (I'm not that proficient in rdfa) The RDFa people have only specifically defined RDFa in terms of XHTML. This is for mostly pragmatic rather than ideological reasons - it was far easier to spec out that way. In practice, it was always expected that RDFa parsers would also support HTML, and indeed the majority do. There are two pitfalls with adding RDFa to HTML: 1. It adds a few new attributes, plus allows a handful of existing attributes like 'rel', 'rev' and 'content' to be set on more elements than before. Any non-trivial RDFa will make use of these facilities, so can't be validated against the HTML 4.01 Strict DTD. It would probably be not much more than 20 minutes work to download a copy of the DTD, add these attributes in and get your HTML valid though. (Some people seem to have an irrational dislike for custom DTDs, so this solution may not be satisfactory to them.) 2. It also uses xmlns:X attributes, where X can be pretty much anything. Because DTDs don't allow wildcard attributes to be defined, you won't be able to create a DTD that can handle this. Again, use of xmlns:X is not required by RDFa, but any non-trivial page will probably need to. If you know that you're only going to be using a limited number of RDF vocabs, your DTD can however define those ones specifically (e.g. xmlns:dc for Dublin Core, xmlns:foaf for FOAF, etc). But in the general case, this is less easy to get around. Although, it is beyond the scope of the RDFa spec, so is not likely to become official in the foreseeable future, I've proposed an alternative syntax for the xmlns:X stuff to be used in HTML - basically to use RFC 2731. (Which is what eRDF does.) I don't know how many parsers have implemented it, but Cognition includes support - http://buzzword.org.uk/cognition/ In short, if you're using the standard HTML 4.01 DTDs, RDFa will not validate. But it will 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
[uf-discuss] Microformats and RDFa not as far apart as previously thought
Benjamin Hawkes-Lewis: If you want to to use RDF in an HTML context, look to eRDF eRDF is an interesting experiment, but not particularly practical. Probably the biggest practical problem with it is the use of the id attribute to indicate that (by the attribute's mere presence) an element is the subject of any data found in descendant elements. This makes it difficult to add eRDF to existing documents which are usually already sprinkled liberally with id attributes. For example, if you have a side bar on a page and want to use it to provide some supplementary information about the main body of text, you might expect something like this to work: div id=sidebar h2About this page/h2 div class=dc-titleFoo bar/div div class=dc-creatorJoe Bloggs/div /div However, this actually says that the title of #sidebar (i.e. not of the whole page) is Foo bar, and that #sidebar was created by Joe Bloggs. Yes, you can rejig things a bit, make your sidebar use a class instead of an id, but adding eRDF to existing pages a pain - especially if they're not simple static pages, and you would need to go through thousands of lines of server side code to find all those id attributes. If you're writing an eRDF page from the ground up, this will probably not bother you as much. The other serious concern is that any information you wish to state about a resource which is not a physical anchor on the current page needs to be made within a link. So if Alice wants to link to Bob's page and mention the title of Bob's page, and when it was last updated, she would need to write something along the lines of: a href=http://bob.example.net; span class=dc-creatorBob/span's blog span class=dc-titleGroovin' with Bob/span was updated span class=dc-date title=20080629today/span /a whereas without eRDF, most normal people would probably only want to link the blog's title, not the whole phrase. This gets pretty awkward if you want to say substantial amounts of information about an off- page resource. (It's possible to work around it by using an id attribute somewhere, saying the information about the id attribute instead of saying it about the link, and then using owl:sameAs to say that the link and the id attribute are the same thing. But that is a hack.) Final annoyance: varying between dots and hyphens to separate the QName prefix and suffix, seemingly at random. Yes, it's quite impressive what they managed to achieve, bringing most of the RDF stack to HTML 4, without adding any new attributes or elements. Yet when it comes to implementing it on real life pages, it's annoying. RDFa is a much nicer solution to work with. -- 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] Microformats and RDFa not as far apart as previously thought
Hello Toby On Tue, 2008-06-24 at 21:25 +0100, Toby A Inkster wrote: I'm about half-way through writing an article on extending hCard with RDFa You might like to read this http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html and this http://weborganics.co.uk/articles/show/extending-hcard-using-rdfa may be relevant/helpful towards your article. Martin ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Microformats and RDFa not as far apart as previously thought
Martin McEvoy wrote: On Tue, 2008-06-24 at 21:25 +0100, Toby A Inkster wrote: I'm about half-way through writing an article on extending hCard with RDFa You might like to read this http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa- in-microformats.html Yep - if you take a look at the comments, you'll see I left one back in March. ;-) and this http://weborganics.co.uk/articles/show/extending-hcard-using-rdfa Yes - have read that too. The gist of mine is more about using RDFa to add information to hCards in order to encapsulate information which hCard itself can't represent (height, shoe size, whatever). -- 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] Microformats and RDFa not as far apart as previously thought
On 24 Jun 2008, at 17:03, Manu Sporny wrote: Like Edd stated in his post, we have a bug that we need to fix (abbr design pattern causing screen reader usability issues) and that has been hanging over our heads for some time now. BBC's decision is a lesson learned but is in no way some sort of sign that Microformats is on it's way out. Is it worth revisiting Tantek's original suggestion of using the object element to represent dates? [1] The idea was to do something like this: object data=20050125January 25/object From what Tantek said on his blog, the main reason for not using objects was that they were not well supported in Safari. However, Safari's object support is now much improved: fallbacks are supported and display:inline and intrinsic sizing will work correctly. Safari 2.0.2, which came out in November 2005, was the first version to contain these improvements [2]. It might be that there are other reasons for not using object that I've missed (I'm fairly new to the wonderful world of Microformats) and it might be that there's still a significant population of Safari users on 2.0.1 or older, but if not this could be a way forward that gets around the abbr issue. Just a thought, G [1] http://tantek.com/log/2005/01.html [2] http://webkit.org/blog/32/webkit-fixes-in-safari-202-mac-os-x-1043/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and RDFa not as far apart as previously thought
Hello! Apologies for not joining this thread earlier but my machine's been on the flip. Anyway, just wanted to say it was never my / our intention to fan the flames of any uf vs rdfa skirmish. I've posted a follow up note here: http://www.bbc.co.uk/blogs/radiolabs/2008/06/microformats_and_rdfa_and_rdf.s html that hopefully gives a little more context. To be double clear the issue at hand is about the accessibility of the datetime abbreviation design pattern (although I suppose the geo microformat would run into similar problems). It's still possible to use both hCalendar and the abbreviation design pattern on bbc.co.uk. What's been banned is the use of non-human-readable data in the title attribute of the abbreviation element. We do realise that hCalendar can be used without the ADP - but in this case none of the alternatives work for /programmes either. On the ufs / rdfa front I'm sure the two can coexist peacefully. Without wanting to drag myself any further into the mire and without wanting to sound too much like an old hippy I'm also sure that the two communities working together would benefit all. So apologies for any consternation caused. Hope it all works out soon. Michael On 24/6/08 17:03, Manu Sporny [EMAIL PROTECTED] wrote: 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.sh tml The second is a response from John Resig, of jQuery/Mozilla fame, here: BBC Removing Microformat Support http://ejohn.org/blog/bbc-removing-microformat-support/ The third is written by Mark Birbeck, who is the guy that proposed RDFa several years ago and is the primary one behind the processing rules and architecture for RDFa: Microformats and RDFa are not as far apart as people think http://internet-apps.blogspot.com/2008/06/microformats-and-rdfa-are-not-as-far .html We've had discussions that parallel the ones above last summer: http://microformats.org/discuss/mail/microformats-new/2007-July/000592.html http://microformats.org/discuss/mail/microformats-discuss/2007-October/010850. html http://microformats.org/discuss/mail/microformats-discuss/2007-October/010859. html http://microformats.org/discuss/mail/microformats-discuss/2007-October/010879. html I tend to agree with Edd Dumbill's post: http://times.usefulinc.com/2008/06/24-uf-rdfa Some are moving too quickly to dismiss both Microformats AND RDFa - the two communities are cross-pollinating and there has been significant lessons learned from both approaches. If you're going to blog about this or discuss it - please don't fuel the Microformats vs. RDFa fire by picking sides... it's detrimental to both communities. Like Edd stated in his post, we have a bug that we need to fix (abbr design pattern causing screen reader usability issues) and that has been hanging over our heads for some time now. BBC's decision is a lesson learned but is in no way some sort of sign that Microformats is on it's way out. Thoughts from the community? Anybody else blogging about this? -- manu http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Microformats and RDFa not as far apart as previously thought
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 The second is a response from John Resig, of jQuery/Mozilla fame, here: BBC Removing Microformat Support http://ejohn.org/blog/bbc-removing-microformat-support/ The third is written by Mark Birbeck, who is the guy that proposed RDFa several years ago and is the primary one behind the processing rules and architecture for RDFa: Microformats and RDFa are not as far apart as people think http://internet-apps.blogspot.com/2008/06/microformats-and-rdfa-are-not-as-far.html We've had discussions that parallel the ones above last summer: http://microformats.org/discuss/mail/microformats-new/2007-July/000592.html http://microformats.org/discuss/mail/microformats-discuss/2007-October/010850.html http://microformats.org/discuss/mail/microformats-discuss/2007-October/010859.html http://microformats.org/discuss/mail/microformats-discuss/2007-October/010879.html I tend to agree with Edd Dumbill's post: http://times.usefulinc.com/2008/06/24-uf-rdfa Some are moving too quickly to dismiss both Microformats AND RDFa - the two communities are cross-pollinating and there has been significant lessons learned from both approaches. If you're going to blog about this or discuss it - please don't fuel the Microformats vs. RDFa fire by picking sides... it's detrimental to both communities. Like Edd stated in his post, we have a bug that we need to fix (abbr design pattern causing screen reader usability issues) and that has been hanging over our heads for some time now. BBC's decision is a lesson learned but is in no way some sort of sign that Microformats is on it's way out. Thoughts from the community? Anybody else blogging about this? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Blacksburg BarCamp 1.0 http://blog.digitalbazaar.com/2008/05/15/blacksburg-barcamp-10/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and RDFa not as far apart as previously thought
On 24/06/2008, Manu Sporny [EMAIL PROTECTED] wrote: Hey Manu, Thanks for the links. I'm trying to keep track of all the converastions popping up around this. Some are moving too quickly to dismiss both Microformats AND RDFa - the two communities are cross-pollinating and there has been significant lessons learned from both approaches. If you're going to blog about this or discuss it - please don't fuel the Microformats vs. RDFa fire by picking sides... it's detrimental to both communities. Agreed. I'm so tired of this verses debate. This isn't a war where anyone has to pick a side. They can work along side one another. Like Edd stated in his post, we have a bug that we need to fix (abbr design pattern causing screen reader usability issues) and that has been hanging over our heads for some time now. BBC's decision is a lesson learned but is in no way some sort of sign that Microformats is on it's way out. I don't know if you saw, but the discussion is happening over on dev [1] (mostly to get parser writer's feedback in the first instance) on how to deal with the abbr. There's been work by Ben Ward on the machine-data[2] options for a while now. I agree, this is just *one* issue that we've failed to solve so far. [1] http://microformats.org/discuss/mail/microformats-dev/2008-June/000552.html [2] http://microformats.org/wiki/machine-data -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
