See also: IRC log, previous 2006-04-24
ACTION: Ben start separate mail threads on remaining discussion topics [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action04] [CONTINUES]
ACTION: Ben to draft full response to Bjoern's 2004 email [recorded in http://www.w3.org/2006/01/24-swbp-minutes.html#action03] [CONTINUES]
Ben: work with DanC last week pre-empted things
ACTION: once Steven sends editors' draft of XHTML2, all TF members take a look and comment on showstopper issues only [recorded in http://www.w3.org/2006/02/06-htmltf-minutes.html#action01] [CONTINUES]
Steven: it's being worked on
Ben: does HTML WG have a deadline?
Steven: we have a face-to-face shortly after WWW2006
Steven: regrets for next week
Ben: in 2 weeks (10 days before WWW2006) I propose we use the telecon to review WWW2006 presentation
ACTION: Ben, Mark be ready on 15 May to discuss WWW2006 presentations [recorded in http://www.w3.org/2006/05/01-htmltf-minutes.html#action04]
Mark: 15 May is the day before XTech and I'm doing an RDF/a presentation there. Steven is doing a tutorial. AJAX is being discussed on Tuesday, I'm involved in that too
Steven: my tutorial is on 16 May (Tuesday)
Mark: we should use same examples in our sessions so it sounds like the same pitch repeated
Ben: I propose that the presenters send an outline this week of their presentations
ACTION: Ben, Mark, Steven send outlines of their XTech and WWW2006 presentations this week [recorded in http://www.w3.org/2006/05/01-htmltf-minutes.html#action05]
Mark: if we've agreed that calendar examples in the primer are good illustrations of RDF/a we should all use them. It is good to sound coordinated so we might get blogged
Ben: the hGRDDL idea that DanC and I came up with last week might be a bridge to microformat folk; hGRDDL allows domain-specific apps to be built
<Steven> 11 slides starting http://www.w3.org/2006/Talks/05-16-steven-XHTML2-XForms/#metadata
<Steven> (That was my action item fulfilled)
Mark: I've recently been looking into the information resource vs. non-information resource issue. I'll explain in mail. The question arises whenever metadata is embedded in the document it describes. Many metadata embedding formats require the application to have domain-specific knowledge
Ben: DanC and I spent Thursday hacking GetCal
<benadida> http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues#nested-metas-and-links
<benadida> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Mar/0060
Mark: I'd like to take up the role attribute first
Steven: issues 4 and 7 are really one issue. When I did the RSS example I came to the conclusion that role as rdf:type solved a number of problems and made things easier to write
Mark: my original thought was to use the class attribute. The words "class" and "type" are almost synonymous. Role connotes a purpose; e.g. exchanging one script for a different one giving the same functionality, so 'role' might be of type 'hint'. I've come back around to thinking that the role something plays does not necessarily mean it has that type. By making class= serve this function we get closer to microformats and to Ian Davis' Embedded RDF proposal
Ben: playing devil's advocate, class= is currently playing a kind of local role; the namespace for class values is the local document. So it is harder to move from class="vEvent" to class="html:vEvent". But maybe this is ok; an author can say that html:vEvents _in this document_ are styled in a particular way
Steven: class has so much existing usage that I'd prefer to leave it alone and choose a new attribute
Ben: role= could create two triples: both xhtml:role and rdf:type
Mark: we should do xhtml:role anyway -- the question is whether xhtml:role is rdfs:subPropertyOf of rdf:type. To me it doesn't feel that to play the role of a toolbar is the same as being a toolbar
Ben: xhtml:class could also be rdfs:subPropertyOf rdf:type; an author might be able to use either one
Mark: I do think we need to say something about class attribute; it's too close to having semantic meaning. I think xhtml:class should definitely be subPropertyOf rdf:type
Steven: we're talking about the whole world's use of class
Mark: processors that want to draw conclusions from unqualified markup are on their own
Ben: people will complain if we generate triples without telling folk
Ralph: we'll regret it in the future if we specify that some markup generates triples that really do not mean anything
Mark: I think it would be a mistake not to define some behavior of class=; lots of people have been using it correctly for years
Ben: do we agree that role= should generate some triples?
Mark: yes, xh2:role. The question is whether xh2:role is also rdf:type. I was hoping the community would comment on whether role is rdf:type or not; folk who are good at logic and semantics may care
Ben: my personal opinion is that defining triples only for xh2:role and not xh2:class would feel wierd
Mark: because we don't know what the current deployed values of rel, rev, and class are then maybe the unqualified properties are only in the local namespace of the document
Ralph: yes, I've been nervous for a long time about imputing semantics on existing markup when it's not completely clear that the author meant those semantics. Perhaps a specific profile value gives us a way to handle the author's intent
Ben: profile could be a way to handle the hGRDDL idea; a profile for XHTML1 that says this document is intended to have transformations. In XHTML1, rel='next' really does mean rel='html:next' so we handle legacy XHTML markup by adding a profile that does that next -> html:next transformation. We specify that these transformations happen before RDF/a processing which keeps RDF/a more regular
Steven: will people have to write xhtml2:index in the future?
Ben: no, we'd define an XHTML2 profile that takes care of that. This allows RDF/a to be generic but handle language-specific conventions in the languages themselves
Ralph: that does seem to put the burden in the more appropriate places
Ben: taking the hGRDDL idea further, we can
decide that:
1) CURIEs always resolve to the current URI as the base namespace,
2) each language has a default profile,
3) for example, XHTML1 has a profile which transforms <ul></ul>
into an rdf:Bag, class="" into rdfs:type, rel="next" into rel="xh:next",
etc..,
4) if XHTML2 wants to have its own special values, then it can have its own
hGRDDL profile,
5) if Google wants rel="nofollow", they can define a Google profile that
makes that work
Basically, all language specific syntactic sugar can be come part of the
pre-processing by profile and that's it :)