See also: IRC log, 2006-10-03
Ben: everyone please send me email giving times you are available for TF telecons
ACTION: All to send Ben email giving times you are available for TF telecons [recorded in http://www.w3.org/2006/10/09-htmltf-minutes.html#action01]
Ben: nothing earlier than 8am EST (== 1200 UTC until 29 Oct)
Steven: nothing starting later than 5PM my
local time == 11am EST (== 1500 UTC until 29 Oct)
ACTION: Elias start an FAQ [recorded in http://www.w3.org/2006/10/03-htmltf-minutes.html#action10] [CONTINUES]
ACTION: [DONE] Ben make sure RDFA bookmarklet runs locally [recorded in http://www.w3.org/2006/09/19-htmltf-minutes.html#action06]
Ben: I've made a tar
file of the bookmarklets that will work with pretty much any Web
server
... there's some javascript magic; have to re-install the bookmarklet when
you move servers
ACTION: Ben start separate mail threads on remaining discussion topics [recorded in http://www.w3.org/2006/09/19-htmltf-minutes.html#action07] [CONTINUES]
ACTION: Ben update the issues list [recorded in http://www.w3.org/2006/09/19-htmltf-minutes.html#action08] [CONTINUES]
ACTION: [DONE] Ben write a prototype hGRDDL profile for XHTML 1 [recorded in http://www.w3.org/2006/09/19-htmltf-minutes.html#action09]
-> new bookmarklets (not stable yet) with hGRDDL for XHTML1 support [Ben 2006-10-09]
Ben: the May version of the bookmarklets
assumed that the default namespace was XHTML
... the October versions of the bookmarklets assume the default namespace is
the local document
... tested in FireFox and some in Safari
... LINK and META in the body get repositioned to the HEAD by FireFox for
contentType text/html
... though if added to body via DOM they stay in body
ACTION: Steven to put together sample XHTML2 doc with all mime type, etc.. [recorded in http://www.w3.org/2006/09/19-htmltf-minutes.html#action01] [CONTINUES]
<Steven> http://www.w3.org/MarkUp/2006/xhtml2.xml
Steven: first part is partly
done
... intentionally not yet serving with a proper content type (just plain XML)
so I can test the stylesheet
... I've added dotted borders to indicate the sections
... the styling is just pure CSS
... links should render with a hand pointer and appear clickable, though
they're not yet clickable
Ben: I've put schedule on the TF home page
Ben: my bookmarks and Elias' RDFLib are the cited 'parsing code'
Elias: rdflib parses XML so I don't expect XHTML2 to be a problem
Ben: Ivan sent a bibtex example and asked how
RDFa would represent this
... Mark proposed a solution
Mark: ages ago we debated whether rel
should become a default predicate for contained elements
... fortunately we decided against this, which is good as now we can use
rel alone as a way to connect 2 things
... my proposal is a bit like RDF/XML striping
... the object becomes a nested subject
... as Ivan pointed out, we had pretty good bnode support already but
required explicit naming
... in this proposal the element itself becomes the bnode
<benadida> Re: better support for bnodes [Ben 2006-10-08]
Ben: currently, rel without
href is not valid
... the proposal is to say that absence of href means the child
element is the bnode
Steven: re: your comment at the start of that
message, I don't see why even META is needed
... I'd need to understand why you thought SPAN was wrong
Ben: by current rules, using SPAN would make
the subject the DIV
... in this case, with rel and no href maybe we want an
implicit about; so we could use SPAN, but we wouldn't be able to
elide a second href
... we want the subject to be the bnode so META is better
... there may be a way to make SPAN work but according to the current rules
SPAN would give a different subject
Mark: <A rel= href= ...> is really about the current document given current HTML rules
Ben: in the example in 0015,
if the P had an about then all the contained triples would have the
explicitly named node as their subject
... in this case we just want to drop the explicit name
Mark: nice to use the techniques we've designed
to avoid having to duplicate markup
... another interesting question is whether we could ever have a bnode
without a rel?
... perhaps would need this for reification, which IPTC needs
... IPTC wants to say what time the statements were made, and by whom,
etc.
Ben: not sure we have a way right now to reify a statement
Mark: yes, if META is a child of META then we reify
Ben: we had said this at one time but I though
we'd dropped it
... let's put reification on the agenda for next week
Ralph: striping is often a complaint of the XML syntax
... we've tried hard to make the RDFa markup sensible for HTML folk; does it
looks like what it represents? Does HTML intuition work?
... it's explicable, but it should be intuitive, too.
Ben: it seems a natural idea to provide more detail in child elements
Elias: I like that it reduces our dependency on
META and LINK
... I'd like to try a variety of examples
... would be good to have a test suite so we can examine the interactions
Ben: agree that we need test scenarios. In an
early proposal we had striping but we took it out when Jeremy Carroll's XSLT
uncovered that that proposal produced many more triples than we'd expected
... let's produce more test examples to help evaluate how intuitive this
is
Steven: the important part of Ivan's example is
the triples, not necessarily the representation
... e.g. we don't necessarily need to use LI to accomplish this
Ben: I can try to update my bookmarklet to support this example
Mark: we can revisit our current examples to see which ones would no longer need to give a local name to the bnodes
ACTION: Ben add striping support to bookmarklet to test new bnode support proposal [recorded in http://www.w3.org/2006/10/09-htmltf-minutes.html#action08]
Ben: [summarizing current state]
... class maps to rdf:type
... role becomes xhtml:role and we decide later whether to extend
this
Mark: we do have the idea that role is a predicate of some sort
Ben: and we don't need to implement role in XHTML1, right?
Mark: but role is one of the XHTML2 success stories; people are already implementing it in current browsers, e.g. FireFox
Steven: I am worried that people will be up in
arms about us adding new meaning to class where it has such a long
history
... I don't think from classic HTML that one can derive an rdf:type of 'red'
if someone has written class='red'
... I think Dan Connolly would complain as he's said that we should not
change the meaning of existing documents
... and the CSS and microformats communities consider class to be
theirs
... but this proposal does do something that microformats are already
doing
... though they use it both for type and for predicate
Ben: if we say that non-namespaced things are only local concepts; they'll generate RDF triples but things will only be local
Steven: is it true that all the triples we care about in RDFa will have explicit namespaces indicated?
Ben: yes, I think so
Steven: I still fear backlash
Elias: would we need '[...]' ?
Ben, Mark: no
Elias: I'd like to get more feedback from the
community
... we're not changing people's meaning
Ben: it should not happen that we're making an RDF triple that people did not mean
Elias: nor are we matching lots of microformats
Ben: should not conflict with properly implemented microformats when they add a profile attribute
Elias: class looks better, and I don't think the microformats folk own class
<Ralph> [I'm inclined to think that using class is a good idea precisely because the microformats folk have shown that people like it]
Mark: we really are talking about rdf:type
... and this affects only people who do know what they're doing
... class='red' works as it did before; if a processor wants to generate
rdf:type=red it could do so but why worry?
... people need rdf:type in some form or another and the class
solution works from lots of different angles
Ben: I do think it's safe to use class
but I want to be sure we have consensus
... any objections to sending mail to the community describing the proposal
and explaining why we think it doesn't break existing uses?
[no objections]
ACTION: Ben to draft message to the community describing the class proposal and explaining why we think it doesn't break existing uses [recorded in http://www.w3.org/2006/10/09-htmltf-minutes.html#action09]
Elias: Dan notes that Ian Davis' ERDF proposal
already put RDF classes into the class attribute, with some punctuation
... why new URL for syntax document?
Ben: the previous draft had no official standing
Elias: note that the label text for Latest
Version is not the same as the actual link
... will http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-syntax
always be the latest editor's draft?
[long discussion of 'Latest Version' and 'This Version' URIs for editor's drafts between Elias, Ben, and Ralph]
Ralph: about the new URIs Ben posted in "update:
TF page, RDFa documents, and portable bookmarklets" ...
I propose:
1. edit http://www.w3.org/2001/sw/BestPractices/HTML/2006-10-01-rdfa-syntax
and fix the Latest Version URI
2. edit http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-syntax
and fix the Latest Version URI
in both cases the Latest Version URI is http://www.w3.org/2006/07/SWD/rdfa-syntax
RESOLVED: Latest Version URIs are http://www.w3.org/2006/07/SWD/RDFa/syntax and http://www.w3.org/2006/07/SWD/RDFa/primer; these are the URIs of the live editor's drafts
edit in http://www.w3.org/2006/07/SWD/RDFa/syntax/Overview.xml
ACTION: Ben move his live editor's draft to http://www.w3.org/2006/07/SWD/RDFa/syntax/Overview.xml [recorded in http://www.w3.org/2006/10/09-htmltf-minutes.html#action10]
Ralph: I will redirect the URIs in 0013 to these new Latest Version URIs once the documents are in place.