Re: metadata content

Ian Hickson wrote:
> ...
>> "In the XML serialisation elements from other namespaces whose semantics 
>> are primarily metadata-related (e.g. RDF) are also metadata content."
> 
> We can't say exactly that, because even in other serialisations (e.g. the 
> DOM), it's still true.
> ...

Since when is the DOM a serialization?

> I've added an example though. Let me know if it's clear enough.
> 
> 
>> The case for the HTML5 variant looks more problematic, because currently 
>> the profile attribute is removed too, which had the capability to 
>> produce something like a defined subject-predicate-object construction 
>> together with meta elements.
> 
> You can still do anything, in HTML5, that profile="", as defined in HTML4, 
> allowed in HTML4, since we now allow registrations of meta names.

But that's a central registry. Yes, I know you consider this a feature, 
but there are lots of people disagreeing with that.

>> The profile attribute seems to be used for example by DCMI, or 
>> 'microformats' uses it to map class value items to specific meanings.
> 
> In practice, microformats don't really use profile="".

Again, a reminder to the MF community: if you don't use @profile, please 
cleanup your documentation (<http://microformats.org/wiki/profile-uris>).

>> What seems to be left for HTML5 is the a/link with rel="profile".
> 
> As far as I can tell, that would be as useful as HTML4's profile="", which 
> is to say, not useful. Just use the features you want, without declaring 
> that you're going to use them. If name clashes are a concern, use meta 
> names that have domain components (e.g. "org.example.family.parent" or 
> whatever).

Again a recurring discussion: there's disagreement about whether an 
ad-hoc syntax as the one above is sufficient. Other vocabularies use 
either URIs or URI/local-name pairs as identifiers, and it's not clear 
to me why it would be good to invent a new syntax here.

> ...
>> Is there any idea to structure metadata with HTML5 elements or to adopt 
>> some RDF approach to avoid to reinvent the wheel?
> 
> I don't intend to introduce a generic mechanism, no; generally, the more 
> abstract a mechanism, the less it is actually used in practice. Instead, 
> we should address problems on a case by case basis. Thus <video> rather 
> than <object>, or <p> rather than <div class="prose.grammar.paragraph">.
> ...

I note that RDFa-in-HTML (or something equivalent) *is* a generic 
mechanism, to consider it is in our charter, and, as you said, *is* an 
open issue. Hopefully we'll make progress on it in 2009.

Best regards, Julian

Received on Wednesday, 24 December 2008 11:00:40 UTC