- From: Ben Adida <ben@adida.net>
- Date: Sun, 02 Sep 2007 10:08:53 -0700
- To: Ivan Herman <ivan@w3.org>
- CC: Mark Birbeck <mark.birbeck@formsPlayer.com>, W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
Quick note: according to current resolutions and implementations, we currently do *not* use @name. I lean towards what Mark is saying: I don't think we should add it, especially after we agreed not to use @class with a CURIE because of its existing type and the potential confusion (I know that @class is more complicated because of CSS, but the principle of not overriding the previous data type still stands.) In any case, the DCMI decision to endorse RDFa upon completion is fantastic! -Ben Ivan Herman wrote: > Hi Mark, > > you actually pre-empted me; I just come back from the DC conference > where the issue vs RDFa came up. Having talked to the DCMI guys, here is > the standpoint of DCMI at the moment: > > - in the first round, DCMI will update their document to include DC > information in the HTML header using the current 'DC.tite' scheme. That > will be done using a special profile in the header, and they will also > provide a GRDDL transform on the profile document level. Ie, if somebody > uses this approach, and a GRDDL processor, the RDF information can be > extracted using GRDDL. > > However, that is clearly a mechanism in <head> only. > > - once RDFa is finalized and officially published, DCMI will endorse > RDFa and propagate to use _full RDFa syntax everywhere_, with no special > requirement. Ie, xmlns for the namespaces, dc:title syntax (both in the > header and elsewhere), etc. > > Ie: as far as DCMI goes (which _is_ our biggest customer for that > issue), the whole question on 'dotted' vs. 'coloumn' synstax is moot, > and we should put it on ice for our own technical discussion. I think > this is a win-win. But this also means, that we do *not* really need any > hGRDDL rules for this use case either.... > > This is a bit orthogonal to the @name issue that you refer to below. My > impression is that we should keep to what we decided before. The various > adaptations to different targets can still be done, after all > > name="DC.title dc:title" > > is also perfectly valid, isn't it? Ie, I am not sure why Bob's mechanism > would shed any new light... > > Ivan > > Mark Birbeck wrote: >> Hi Ivan, >> >> I was just reading this: >> >> <http://www.snee.com/bobdc.blog/2007/08/automated_rdfa_output_from_dit.html> >> >> from Bob du Charme. In it he makes the point that it's very easy to >> change your server-side generation code from generating this: >> >> <meta name="DC.Title" content="My Topic" /> >> >> to generating this: >> >> <meta property="dc:title" content="My Topic" /> >> >> I was about to fire off an email pointing out that you can actually >> use @name as well, and then it occurred to me that perhaps we should >> actually _exclude_ @name from our processing. In other words, rather >> than being indifferent about this we would say it doesn't actually >> work: >> >> <meta name="dc:title" content="My Topic" /> >> >> By doing this we can keep @name 'unpolluted' with new stuff, and when >> we see it we can be sure that it contains legacy values. We therefore >> create two possible scenarios, which may prove useful. >> >> The first is that Bob's server-side code could actually generate this, instead: >> >> <meta name="DC.Title" property="dc:title" content="My Topic" /> >> >> Since he is in control of what his server is generating, he might >> choose to target both RDFa parsers (with @property) and existing HTML >> processors like search-engine crawlers, with @name. This might be >> particularly useful if the <meta> property is something that a >> search-engine might make use of, but the value is something that we >> want to use in an RDFa processor, like this: >> >> <meta name="description" property="dc:description" content="My description" /> >> >> The second scenario is that our hGRDDL rules can be more focused--at >> least in relation to the <head> of the document. If the pre-processor >> were to detect certain values in @name, then all it has to do is add a >> 'property' attribute to the element, containing a more RDF-friendly >> value, and which will be picked up by the RDFa processor. If a >> 'property' attribute already exists then the pre-processor need do >> nothing. >> >> By explicitly confining the 'legacy' problem to the one attribute--or >> at least a large chunk of the legacy problem--we might find this issue >> easier to manage; we'll probably find it easier to define the >> 'mapping' rules. >> >> Any thoughts on that? >> >> Regards, >> >> Mark >> >
Received on Sunday, 2 September 2007 17:08:51 UTC