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] class=tag
On 6/28/08, Fil [EMAIL PROTECTED] wrote: a class=tag href=http://example.com/tags/NotThis;TheTag/a We use rel='tag' heavily, even embed it in RSS to convey metadata. Toby's suggestion would help us be compliant with µF in any case, and not only in when the user chooses the clean URLs option. --- if you take a look at the 'category' property, it works how you are proposing to use 'tag'. Instead of trying to redefine or create new class properties, we should look at existing ones and reuse those instead. There are some rules for using category and rel-tag together, but this proposal is just about extracting the 'tag' value from the node rather than the URL. This is what class=category does, so i would experiment with that first. Thanks, -brian -- brian suda http://suda.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 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
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: Using object for datetimes (was: Microformats and RDFa not as far apart as previously thought)
On 28 Jun 2008, at 17:03, Ed Lucas wrote: 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 This particular example is invalid, as the data= attribute must contain a URI, and a URI cannot start with a number. 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]. For note, I don't feel that CSS support on an element should be of consideration when designing microformats. We are operating at the HTML level and must not produce techniques which depend on them (although documenting techniques where CSS can be used to enhace/alter microformats is still valuable, I'm simply meaning that HTML+CSS must not ever be the primary solution to a problem). 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? So, one solution I saw offered to the URIs-can't-start-with-numbers issues was to do everything as a URL fragment, converting it to: object data=#20050125January 25/object That, however, causes Safari 3 to render a box of the current page within the OBJECT element, and so would introduce a CSS dependency to keep it hidden. No good, I fear. *However*, the following appears to be well behaved inline in Safari 2.04 and 3.1.1, Firefox 1, 1.5, 2 and 3, and Opera 7, 8 and 9. object class=dtstart data=data://20080712/object That uses the DATA URI scheme, which without a specified mime type and charset, defaults to text/plain;chartset=US=ASCII. I think that would be sufficient. I've pastied my test case, and would be grateful if people could test the behaviour in Internet Explorer: http://pastie.org/224023 Given that IE has a history of abysmal support for OBJECT and no support for data: URIs… I have no idea what might happen. See also: http://en.wikipedia.org/wiki/Data:_URI_scheme http://tools.ietf.org/html/rfc2397 (data: spec) http://www.ietf.org/rfc/rfc2396.txt (URI spec) B ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Using object for datetimes (was: Microformats and RDFa not as far apart as previously thought)
On [Jun 28], at [ Jun 28] 11:09 , Ben Ward wrote: On 28 Jun 2008, at 17:03, Ed Lucas wrote: 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 This particular example is invalid, as the data= attribute must contain a URI, and a URI cannot start with a number. About a week ago I wrote: On the abbr-design-pattern page, markup rejections section [1] is the following text: OBJECT with param value. (requires significant extra markup and CSS in order to *behave* correctly) Can anyone provide more detail about this parenthetical rejection explanation? If this problem has in fact been resolved (or at least improved) in more recent browser versions, I suggest we look again at using object and param together, e.g.: object class=dtstartparam name=value value=20050125 / January 25/object I expect using param will result in more readable and flexible markup than data URIs. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Using object for datetimes (was: Microformats and RDFa not as far apart as previously thought)
On 28 Jun 2008, at 18:09, Ben Ward wrote: I've pastied my test case, and would be grateful if people could test the behaviour in Internet Explorer: http://pastie.org/224023 IE 6, 7 and the beta version of IE 8 all visibly render the object element as a small box, similar to the way they would render a missing image: http://georgebrock.com/misc/object-in-ie.png ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] class=tag
Brian Suda wrote: if you take a look at the 'category' property, it works how you are proposing to use 'tag'. Yes 'category' is defined for hCard, hCalendar and (possibly - it's ambiguous) hListing. But it's not for xFolk, hReview, hAtom or simply tagging whole pages. -- 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] Re: Using object for datetimes (was: Microformats and RDFa not as far apart as previously thought)
Ben Ward wrote: On 28 Jun 2008, at 17:03, Ed Lucas wrote: object data=20050125January 25/object This particular example is invalid, as the data= attribute must contain a URI, and a URI cannot start with a number. It's perfectly valid. Absolute URIs can't start with a number, but relative ones can - and the data attribute is permitted to contain relative URIs. This proposal is far less elegant than Frances' though. -- 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
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 previouslythought
The focus seems to have drifted toward smarter parsing of dates, but the Sure ... splitting the date into day, month and year could be workable, or somehow describing a date format in another element, if there is a standard way to do it and it is easy to do, but I'm opposed to anything that relies on unreliable heuristics or localisation to parse dates. There are situations where markup clues used for localisation might be misleading, such as people using microformats in a post on a site they do not themselves run that may even be in a different country. (a shared blogging site that allows html tags in posts would be a good example here) If a parser gets even 1% of dates wrong because of localisation errors it could lead to a lot of people turning up to events on the wrong dates and I'm sure those people would not be too happy about it. So please lets not underestimate the importance of reliable date parsing! It's already bad enough trying to cope with timezone issues in the real world (eg people misusing 'Z' in their datetimes) OK, maybe some aspects of ISO dates are not human-friendly enough and we need to look at this, but dates do still need to marked up in a standard way somehow! There is also the issue of parsers becoming slow and bloated. Yes I know its humans first but there are limits. If people turn away from using a tool because it is unreliable or too slow is it really humans first then? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
