Re: RDFa and its relationship to XHTML

Dan,

> I'm pretty sure the author didn't know that it produced any RDF  
> triples.

This continued claim of yours is confusing, especially after we  
discussed this in great detail at the DIG meeting in early April,  
which you attended and which was publicly logged (though I can't find  
the link now for the life of me, but I'm sure you've got that pointer  
handy). The fact that triples are produced should not be a problem,  
as long as those triples don't generate meaning that the author  
didn't intend.

I'm fairly certain that folks who use microformats don't know that  
the MF parsers will produce XML specifically, or iCal specifically.  
They care about the abstract notion that they're expressing a  
calendar event, or a contact card. The exact serialization of these  
abstract notions is really not the author's concern.

The same goes here. An HTML author who says @rel="license" may not  
*know* that there's an RDF triple in there, but he certainly knows  
he's indicating a license property. Why should it matter that there's  
an RDF triple behind it?

Note that, as of a few months ago, we've been talking about having  
CURIEs without a namespace default to the current URI, which prevents  
authors from unwillingly expressing triples they didn't intend. All  
concepts are local unless you ground them in namespaces. A few, well- 
established exceptions are made, like rel="next", rel="prev",  
rel="license", as per the HTML WG's decisions. These are transformed  
into their properly namespaced-equivalent using a the default XHTML1  
hGRDDL transform, which we're working on.

This is, in fact, exactly what authors intend.

If you say

<a rel="wacky" href="...">...</a>

then, what is "wacky?" It's a local concept, grounded in the local  
URI. What else could it possibly be? And there's a clickable link,  
from this current page, to the page indicated in the href. That's a  
triple. Of type "wacky," which is locally scoped.

This really is the author's intent, and it almost certainly doesn't  
ever interact with any other triples, since it's all locally scoped.

> I just installed Elias's RDFa parser from
> http://torrez.us/archives/2006/06/05/453/
> http://svn.rdflib.net/trunk/ revision 783.
>
> It produces, among other things:
>
> <> <http://www.w3.org/Copyright>
> <http://www.w3.org/Consortium/Legal/copyright-documents> .
>
> and I'm sure the author didn't mean to use http://www.w3.org/Copyright
> as an RDF property name.

correct, that's because we haven't finished spec'ing the default  
hGRDDL transform, and rel="copyright" is clearly an HTML reserved  
name, which we'll transform appropriately into rel="xhtml:copyright".

Please don't hold us up to perfect standards just yet. We're on  
working draft #2. Elias's work is a fantastic tool that will help us  
iron out the inconsistencies.

[...]

> When I put that markup in
>   /home/connolly/src/rdflib/trunk/,rdfa.html
> I get one triple out of Elias's parser:
>
> <> <file://home/connolly/src/rdflib/trunk/details> <file://home/ 
> News/2006#item101> .
>
> That's sorta close to what I sketched above...
>
> <http://www.w3.org/#item23> <http://www.w3.org/#details>
> <http://www.w3.org/News/2006#item101>.
>
> If we correct for base URI, we get
>
> <http://www.w3.org/> <http://www.w3.org/details>
> <http://www.w3.org/News/2006#item101>.
>
> but the subject is wrong and the # before details is missing.
>
> The W3C webmaster-in-chief, TimBL, is never going to make an
> RDF property called http://www.w3.org/details , I can assure you ;-)

So, if you have a GRDDL transform that specifies this, then it's not  
much more work to have your transform also support hGRDDL. We need to  
spec out exactly how, but the basic gist is that you would make the  
transformation inline, in the HTML, so that you don't lose the  
context of the triples.

Your HTML wouldn't change. Just your profile URI would return a bit  
more information: GRDDL *and* hGRDDL. In fact, it could return only  
hGRDDL, since from that you can always extract RDF, too, via RDFa.

>> <div
>>  id="x20050714a" class="item"
>>  about="http://www.w3.org/News/2006#item101"
>
> That'll get a thumbs down from the HTML validation service, no?
> I don't even think it's allowed by the text of the XHTML 1.0
> spec without being namespace qualified.

Currently, yes, because we're not done.

But, as you know from the DIG meeting and public postings on this  
list, we're working to build this into the XHTML standard.

> I'm happy for you to pick any example you like.
>
> But please pick an example where
>  (a) the document conforms to one of the XHTML 1.x specs;
>      preferably, it gets a thumbs-up from the validation service

This is not going to happen yet, not until we have finalized the  
standard. It's not possible to fulfill all the requirements without  
updating the specs.

>  (b) there's some code that generates RDF triples from it

That's done.

>  (c) the triples were meant by the author

That's not a fair point, as per above. The *triples* may not have  
been meant, but the concept was certainly meant.

> You brought up rel="tag", so I'm particularly interested in an example
> using that idiom.

That idiom is poorly defined, unless there's a profile attribute. If  
it's used with a profile URI, then it can easily be transformed,  
using hGRDDL, into the right RDFa. In other words, if the microformat  
is propertly implemented, then it's easy as cake to get RDFa from it.

> No, I don't agree that producing
>
> <> <http://www.w3.org/Copyright>
> <http://www.w3.org/Consortium/Legal/copyright-documents> .
>
> from rel="Copyright" is already standardized.

But producing

<> xhtml:copyright <http://www.w3.org/Consortium/Legal/copyright- 
documents>

is perfectly the intent of the author.

This is what will happen when we've finalized the hGRDDL stuff and  
fixed the tools accordingly.

> As explained above, I don't agree. RDFa seems to interpret @rel and  
> @rev
> in a way that is not what XHTML 1.x authors intend.

No, this is simply not true. You're implying that RDFa is somehow  
distinct from the XHTML effort. It's not. We're part of the XHTML WG.  
And we're working hard to make sure that existing uses of rel= and  
rev=, as per HTML specs, still end up meaning exactly the same thing  
they used to mean. That's a requirement.

> "would?" under what circumstances? I'm asking for an example that
> does validate, not one that would validate.

That's an unreasonable request. It's as if, when you were writing  
HTML2, you had been asked to make sure it validates against HTML1.  
We're trying to fulfill needs that simply aren't fulfilled by the  
existing XHTML attributes. There's no reason to fear these small  
updates that are generic enough for everyone to use, and that are  
specifically shoe-horned into attributes so that current browsers  
don't break.

> I look forward to an example test case and running code.

Let's not forget that we have running code that works today, with  
current browsers, even in XHTML1 strict mode, and it doesn't break  
anything except the W3C validator, which is perfectly normal since  
our specification isn't finished yet.

We will have the modules, but let's be very clear that this is purely  
a validation problem, not a backwards compatibility problem.

-Ben

Received on Thursday, 8 June 2006 19:00:20 UTC