[whatwg] Annotating structured data that HTML has no semantics

Sat May 16 01:02:00 PDT 2009

Tab Atkins Jr. On 09-05-15 22.15:
> On Wed, May 13, 2009 at 10:04 AM, Leif Halvard Silli 
>   
>> Toby Inkster on Wed May 13 02:19:17 PDT 2009:
>>     
>>>> Hear hear.  Lets call it "Cascading RDF Sheets".
>>>>         
>>> http://buzzword.org.uk/2008/rdf-ease/spec
>>> http://buzzword.org.uk/2008/rdf-ease/reactions
>>>       
>>> RDFa is better though.
>>>       
>> What does 'better' mean in this context? Why and how? Because it is easier
>> to process? But EASE seems more compatible with microformats, and is
>> "better" in that sense.
>>     
>
> I'd also like clarification here.  I dislike *all* of the inline
> metadata proposals to some degree, for the same reasons that I dislike
> inline @style and @onfoo handlers.  A Selector-based way of applying
> semantics fits my theoretical needs much better.
>   

A possibly 10 year old use case where I think EASE  - or GRDDL as such - 
should fit in:

Shelley and Geoffrey reminded us that "RSS 1.0" stands for "RDF Site 
Summary 1.0".  The W3 also uses RSS 1.0. for its feed[1].  The feed is 
generated via a profile transformation [2] that happens with XSLT. The 
profile defines the <div class="item"> as news items (note the 
combination of element and class - as in EASE)-  But the profile also 
implements particular rules for particular elements without looking at 
the @class. (E.g. each <div class="item"> must contain <h2> or <h3>, for 
example.)

All in all, it sounds very similar to what the newer technology GRDDL 
does, since it is all happening based on a profile and some class names 
and specific element structures. And, this is possible to test with the 
W3 GRDDL service, which produces a "feed" that in fact, when you look 
with the right eyes, is the same as the published homepage feed[3].

If the "microdata" becomes part of the final version of HTML 5, then 
GRDDL  (with or without EASE) will probably prosper, since it probably 
doesn't matter to GRDDL whether it looks into @class or @item, as long 
as "the thing" is part of the profile and the profiletransformation. 
(But it would be interesting if someone in the know could test if the 
"triples" would be the same, etc ...) And if so, then the introduction 
of "microdata" increases the need for @profile in HTML 5.

[1] http://www.w3.org/2000/08/w3c-synd/home.rss
[2] http://www.w3.org/2000/08/w3c-synd/
[3] 
http://www.w3.org/2007/08/grddl/?docAddr=http%3A%2F%2Fwww.w3.org%2F&output=rdfxml

>> I read all the reactions you pointed to. Some made the claim that EASE would
>> move semantics out of the HTML file, and that microformats was better as it
>> keeps the semantics inside the file. But I of course agree with you that
>> EASE just underline/outline the semantics already in the file.
>>     
>
> Yup.  The appropriate critique of separated metadata is that the
> *data* is moved out of the document, where it will inevitably decay
> compared to the live document.  RDF-EASE keeps all the data stored in
> the live document, and merely specifies how to extract it.  The only
> way you can lose data then is by changing the html structure itself,
> which is much less common than just changing the content.
>   

That the structure changes seldom, /could/ be a reason for using RDFa to 
store the meta info in the very element instead of using EASE (or even 
Dublin Core in <meta> elements in the <head>). OTOH, that the structure 
changes little, could also be something that /permits/ the use of GRDDL 
... So it depends on how you see it.

>> From the EASE draft:
>>     
>>> All properties in RDF-EASE begin with the string -rdf-, as per §4.1.2.1
>>> Vendor-specific extensions in [CSS21]. This allows RDF-EASE and CSS to be
>>> safely mixed in one file, [...]
>>>       
>> I wonder why you think it is so important to be able to mix CSS and EASE. It
>> seems better to separate the two completely.
>>     
>
> I'm not thrilled with the mixture of CSS and metadata either.  Just
> because it uses Selectors doesn't mean it needs to be specifiable
> alongside CSS.  jQuery uses Selectors too, but it stays where it
> belongs.  ^_^  (That being said, there's a plugin for it that allows
> you to specify js in your CSS, and it gets applied to the matching
> elements from the block's selector.)
>   

But may be, after all, it ain't so bad. It is good to have the 
opportunity. :-) (Since you, as I perceived it, disagreed with yourself 
above, I continue the tradition.) :-)
-- 
leif halvard silli