Re: More on the 'legacy' namespacing question

Ben Adida wrote:
> 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.)
> 

I will *not* put a big fight on that:-)

Ivan


> 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
>>>
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Monday, 3 September 2007 08:15:43 UTC