W3C home > Mailing lists > Public > public-html@w3.org > December 2008

Re: metadata content

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 24 Dec 2008 01:13:31 +0000 (UTC)
To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
Cc: public-html@w3.org
Message-ID: <Pine.LNX.4.62.0812232258230.24109@hixie.dreamhostps.com>

On Wed, 19 Nov 2008, Dr. Olaf Hoffmann wrote:
> > On Tue, 18 Nov 2008, Dr. Olaf Hoffmann wrote:
> > > I would only like to know, if I interprete this correct, that authors
> > > finally can put metadata elements from other namespaces like RDF in the
> > > head element of a HTML5 document without any conflicts?
> 
> Ian Hickson:
> > In the XML serialisation, yes.
> 
> Ok, XML formats provide anyway much more possibilities for authors than 
> HTML4 or HTML5. For XML it is not really a problem anyway, because in 
> doubt one can always use a compound document with a root-element from a 
> language with sufficient capabilities.
>
> To avoid disappointments, it might be a good idea to say something 
> like:
>
> "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.

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.


> 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="".


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


> The main problem of these possible HTML4 or HTML5 constructions I can 
> see is, that it is difficult (or impossible) to address a specific 
> element with metadata content as with 'about' from RDF for example.

I don't really follow. Could you describe the problem in more detail?


> The other problem is, that it is difficult (or impossible) to use more 
> than one resource for the definition of metadata and there are several, 
> not just DCMI or microformats or my 'collection'.

I don't follow. Why can't you do what users of Microformats do?


> Therefore some advanced metadata strategy like RDF or the RDFa approach 
> could be very helpful for authors, even if they do not use already the 
> XML serialisation, but still the 'HTML5 serialisation'.

RDFa in HTML5 is an open issue.

   http://www.whatwg.org/issues/#rdfa


> Is there any idea for a convenient use of structured metadata in HTML5?

It depends on what kind of metadata you mean. Could you elaborate on your 
precise use case?


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 24 December 2008 01:14:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:27 GMT