- From: Ben Adida <ben@mit.edu>
- Date: Thu, 8 Jun 2006 15:00:01 -0400
- To: Dan Connolly <connolly@w3.org>
- Cc: Mark Birbeck <mark.birbeck@x-port.net>, "'public-rdf-in-xhtml task force'" <public-rdf-in-xhtml-tf@w3.org>, public-swbp-wg@w3.org
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