[whatwg] RDFa

[Henri Sivonen]

On Aug 22, 2008, at 22:53, Ben Adida wrote:

> Perfectly reasonable: we'll put together a precise proposal regarding:
> (1) what would need to validate, (2) what would browsers be expected  
> to
> do, and (3) why we think this is useful.

When you do so, please consider the HTML Design Principles from the  
W3C side (particularly the one about DOM Consistency between HTML5 and  
XHTML5):
http://www.w3.org/TR/html-design-principles/#dom-consistency

As an anecdote, the part of HTML5 that violates this principle for  
historical reasons (lang in no namespaces vs. lang in the XML  
namespace) has probably had the highest incidence of validator bugs  
per spec sentence so far.

>> Indeed, we have design principles that make addressing the needs of
>> small communities an explicit non-goal.
>
> How about adding one feature that will help make many small  
> communities
> happy, each in their own way? That's the power of RDF, and the idea
> behind RDFa is to enable that distributed innovation within HTML.

The problem is that communities seldom resign to being happy on their  
own. They often start propagating their happiness onto others, at  
which point it would be better for the syntax for happiness not to be  
crufty to begin with.

>> Use a unique name, e.g. include a domain name in the name, as in
>> "license.creativecommons.org" or "home.foaf.w3.org", or use a name  
>> you
>> know isn't used because it's an unusual name, e.g. "cc:license".
>
> That doesn't scale (unless you expect people to actually use GUIDs  
> with
> timestamps), and it's extremely web-unfriendly, since you can't look  
> up
> a concept to figure out what it might mean.

It seems to scale for the Java community, and looking stuff up works.  
(Yeah, Java has 'import' but it doesn't involved inventing prefixes  
when importing.)

> Some problems with existing extension mechanisms:
>
> - no way to make statements about another document (a PDF), etc...  
> in a
> way that is *consistent* across different data types.

FWIW, I think that's a requirement-level bug. The PDF should talk for  
itself.

> Henri Sivonen writes:
>> It really isn't HTML5-friendly, since it depends on the namespace  
>> mapping context at a node.
>
> Well, we can discuss that part.

Previously, you said that it was too late to change RDFa, though.

> But that's 10% of the syntax. The rest
> is all simple attributes with clear meaning. No change to the  
> elements,
> no change to the structure of the HTML document. (And HTML already
> ignores extra attributes.) That's pretty close to HTML5-friendly, I  
> think.

Adding Namespaces to HTML is much, much bigger a deal than adding a  
few attributes in no namespace.

> Regarding the long discussion of "XML Namespaces." We don't use XML
> namespaces. We use CURIEs = Compact URIs. We've chosen to bind them to
> xmlns for now, but they are *not* XML namespaces.

Whether they are called CURIEs or qname-in-content is unimportant.  
They come with the same problems.

Binding them to something other than the namespace mapping scope in  
*both* HTML5 and XHTML5 (for DOM Consistency) would make things less  
bad than binding them to the namespace mapping context. The  
indirection would still likely confuse authors as much as Namespaces  
confuse them.

> I disagree with you strongly on indirection. I don't think this sub- 
> discussion is all that
> productive, though.

It seems to me that the subdiscussion is unavoidable if you seek to  
get RDFa included in HTML5.

>> If Hixie made a proposal about HTML syntax citing Google's needs, but
>> there was something else going on at Google making the syntax moot, I
>> think it would be relevant. (I guess metadata aiding
>> translate.google.com is the recent example.)
>
> You're claiming that because one of our videos doesn't contain the URL
> in its actual content (though it does in its surrounding HTML, which  
> is
> all that's needed), then we're contradicting ourselves? That's silly.

Many videos consistently from a founder--not some random CC fan. Also,  
I'm still not talking about the license of the *video*. I'm talking  
about the licenses of the *photos* remixed into the video. Their  
license URIs are not (unless it's for each one the same as that of the  
video--I can't tell) in the surrounding HTML (which doesn't always  
travel with the video).

Also, I gather that the videos are captured with something like Snapz  
Pro X--not exported directly from Keynote. The "tools will save us"  
vision would break if one of the products in the chain had non- 
metadata-related issues like Keynote leading the user to capture the  
pixels without the metadata--bringing us back to the user having to  
take care about pointing to license by URI.

>> This doesn't allow you to say things about *another* resource, but
>> that's OK, because out-of-band metadata and data often travel their
>> separate ways.
>
> It's not okay for us. There are no good ways to embed metadata in  
> media
> files that the average user can understand.

So tools for existing metadata schemes aren't there. I think RDFa  
isn't something that "the average user" can understand, either. Do you  
expect tools will emerge for *this* metadata scheme?

>> For example, in PDF, do people *really* need all this cruft:
>
> People don't need it, machines do.

Why can't machines pick key-value pairs from the document information  
dictionary? Why is an RDF graph needed?

>> I think trying to break complex licenses [...]
>
> Appreciate the feedback, but that's irrelevant to this conversation.

Actually, it's relevant to the extent the "requires"/"permits" part of  
ccREL is supposed to work. (HTML5 shouldn't include stuff that doesn't  
work.)

> If we had an attribute-value-only way of defining prefixes, would  
> that make you happier?

Happi*er*, yes, but I think having the layer of prefix-based binding  
to URI is a design bug regardless of syntax. But yes, having a non- 
xmlns binding for *both* HTML5 and XHTML5 would make things less bad  
than using xmlns.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/