- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Tue, 27 Mar 2007 01:36:44 -0400
- To: Jeremy Carroll <jjc@hpl.hp.com>
- Cc: Brian Suda <brian.suda@gmail.com>, public-grddl-wg <public-grddl-wg@w3.org>
Indeed, this is sort of a problem from a deployment standpoint. It would be great if one of the results of deploying GRDDL was that most deployed microformat data was usable as RDF data. It is not so great if we have to convince, one by one, every purveyor of microformat data to use profile URIs. It can be done but it's a lot of work. How do applications like Tails license the use of microformats? Simply by looking for the use of certain rel and class values like div="vcard". So, according to microformats applications, the use of div="vcard" is the precise *license* of the microformat, just as the use of a profile URI is a *license* for the use of GRDDL. This causes microformats to lose the ability of self-description and being grounded in URI-space, and so unable to use the "follow-your-nose" principle of good Web architecture that GRDDL takes advantage of. However, if that is how people are using them on the ground, is there anyway that GRDDL can be made comaptible with that sort of non-URI grounded data? It seems to stick to good Web arch principles the answer is "no," since hard-coding into any GRDDL-aware client the use of a certain transformation to map with the use of class/div elements in HTML is just wrong. Without the chair's hat on I'd like to offer a suggestion that lets us GRDDL-enable microformat data that does not have a profile URI without completely sacrificing our principles. If we stick to our guns on using profile URIs then at the current moment virtually no microformat data will be GRDDL-enabled. One could imagine the low-road, where a GRDDL-aware agent encounters no profile URI but encouters the use of a vcard attribute for rel, and so as a back-up manuever knows that using a vcard attribute in a rel makes the page hCard, and so it gets the hCard transformation from a local cache and applies it. Again, the issue is that the profile URI not being there - but one could imagine setting the profile URI for microformats in the "local policy". While allowing one's local policy to say "if you encounter this microformat X without a profile URI then apply transformation from profile URI Y (that may be in a cache)" should be of course officially discouraged, if we leave some wiggle-room for that sort of local policy in the spec/test-cases, it would leave us some actual credence to say "Well, really if you look at it with GRDDL-aware lenses, all the microformat data is SemWeb data..." What do people think? Since local-policy is pretty underspecified right now, I think it wouldn't be a major modification but would have huge practical effects - i.e. letting GRDDL-aware RDF applications use microformat data as is. Jeremy Carroll wrote: > > > A couple of questions: > > Therefore the creators do NOT have the <body> > > or <head> elements where we would need to add the profile attribute. > > a) can you put profile on a <body> tag? > > b) can we think of any other value for including the profile URL other > than GRDDL - the microformats people are more likely to do something > if it works for them for some task that they see immediate benefit in. > The more benefit the better. > > Jeremy > > > > Brian Suda wrote: >> >> My other action[1] this week was to contact the Microformats folks >> about getting Profile attributes built into the creator-o-matics[2]. >> >> I had a look at the creators and have some good news and bad news. >> >> The bad news is that the creators only make HTML snippits for pasting >> into other HTML content. Therefore the creators do NOT have the <body> >> or <head> elements where we would need to add the profile attribute. >> >> The good news is that the code is in the HG repository[3] which i have >> access too. I CAN make a note on the page that says something like "Be >> sure to include this profile attribute in the head element ..." >> "what's a profile? [link here]" and/or "what is grddl? [link here]" >> >> I can go ahead and add those into the creators, then email the staff >> to see if they accept/modify/rollback the changes to take it to the >> live site. >> >> #1) any suggestions about the wordsmithing? >> #2) i could only find the following profiles: >> - hCard profile: http://www.w3.org/2006/vcard/ns.html (which doesn't >> actually have an XMDP profile, but that is fixable) >> - hCalendar profile: http://w3.org/2002/12/cal/hcal (which returns an >> empty RDF statement) >> >> Are these the profiles we want to use for the creator-o-matics? >> >> thanks, >> -brian >> >> [1] - http://www.w3.org/2007/03/21-grddl-wg-minutes.html#action02 >> [2] - http://microformats.org/code/ >> [3] - http://hg.microformats.org/generators >> >> > -- -harry Harry Halpin, University of Edinburgh http://www.ibiblio.org/hhalpin 6B522426
Received on Tuesday, 27 March 2007 05:36:53 UTC