See also: IRC log, previous 2008-05-15
ACTION: Ben followup with Fabien on getting his RDFa GRDDL transform transferred to W3C [recorded in http://www.w3.org/2007/11/15-rdfa-minutes.html#action01] [CONTINUES]
ACTION: Manu to reach out to Slashdot and attempt to get RDFa integrated into Slashdot. [recorded in http://www.w3.org/2008/05/08-rdfa-minutes.html#action10] [CONTINUES]
ACTION: [DONE] Mark to move _:a bnode notation to normative section [recorded in http://www.w3.org/2008/04/03-rdfa-minutes.html#action05]
ACTION: Michael to create 'RDFa for uF users' on RDFa Wiki [recorded in http://www.w3.org/2008/03/13-rdfa-minutes.html#action12] [CONTINUES]
ACTION: Michael to determine which useless-triples test cases to remove and which to add. [recorded in http://www.w3.org/2008/05/08-rdfa-minutes.html#action12] [CONTINUES]
Steven: I don't really understand DanC's point
Mark: the idea of "Follow your nose" seems to
mean "let's leave HTML and XHTML untouched but add something else"
... but we are changing XHTML1
... reading the TAG minutes I get the impression that Tim is open to this
... others seem to worry about folks who may accidentally use our new
attributes without intending to do so
... we should take a stand that these new attributes should be used only for
the purpose of generating triples
Steven: and furthermore, doing this does not
change the meaning of any existing HTML page
... it just formalizes what the page really means
Manu: is there a concern about the HTML5
series?
... at one point they said that while this may be good for XHTML, @profile
does not exist for HTML5
Shane: that's not our problem
Ralph: I agree with Shane
<Steven> +1
Shane: I had an off-line discussion with NoahM
and perhaps someone else
... Tim definitely concurred with adding this to core XHTML1
... and proposed annotating the namespace document to say this
... some were concerned that this means every XHTML document currently on the
Web then should generate triples
... there was a suggestion that there be an announcement mechanism that tells
parsers they _should_ generate triples
Ralph: why isn't this a problem for the
consumer of the document rather than the author of the document?
... I agree with Steven's comment that XHTML always has _meant_ this
... so the author shouldn't be telling the client whether it should or
shouldn't generate triples
... the client decides that
Manu: running fuzbot for a while, it seems every page does generate triples
Shane: so fine, and we should update the media
type spec to say that we now generate triples
... this will make it clear that this is a big step
<markbirbeck> My argument for not requiring @profile or DTDs:
<markbirbeck> http://microformats.org/wiki/rel-license
Steven: I don't agree with the argument that the media type must say that the document is used to generate triples
<markbirbeck> +1 Steven
Steven: the media type just identifies the type of document; it doesn't say how you should process it
Shane: in the RDF cases, the media type does say [something about] how to process it
Mark: that may be the TAG's point
... the question "should we waste time processing this document if it doesn't
contain RDFa" is one of two
... the second is "if we process a document as if it contains RDFa, are we
acquiring statements that people did not intend to make"?
... the second is what the TAG is currently debating
... a third question might concern @rel='license'
... they're suggesting that we should *not* process @rel='license'
... this means that >1M documents won't have this clear semantics
... we can make all these documents available to RDFa easily
... it's crazy to say none of these documents assert a license currently
Shane: as a group, we've agreed on this here
... we only need to address the 'follow your nose' question; it's about how
discovery works on the Web
... related to 302 discussion
... the TAG appears to have a whole big environment in mind, of which RDFa is
a small part, and they want to know how this fits
... how does a document containing RDFa say that it contains RDFa?
... Tim says "they all do"
Mark: we think the interpretation of a document
[is specified] even if the author didn't previously sign a contract
... we're saying "here is an RDF interpretation of billions of documents that
have [already] been published on the Web"
... and we hope people will publish even more [data] than they have already
done
Ralph: +1
Shane: it's not about imposing processing; it's
about _permitting_ processing
... the TAG's argument is that they don't see an explicit instruction and
therefore can't map this into their world view
Ralph: does the TAG not believe that it is sufficient to have updated the XHTML1 namespace document?
Shane: there are two ways to update the
namespace document; prose and with the GRDDL profile
... the prose is more interesting to me
... you go from the media type to the namespace document, not to the
modularization document
... we should propose to the TAG that we will follow Tim's recommendation and
update the namespace document, both the prose and the machine-readable and
all documents of type XHTML1 have RDF triples
Ralph: +1
Steven: +1
<Steven> "Published specification:
<Steven> The text/html media type is now defined by W3C Recommendations;
<Steven> the latest published version is ..."
<Steven> (That's from the rfc for text/html)
ACTION: Shane draft a TAG response along the lines of "we will update the namespace document, both the prose and the machine-readable and all documents of type XHTML1 have RDF triples" [recorded in http://www.w3.org/2008/05/29-rdfa-minutes.html#action06]
<msporny> http://rdfa.digitalbazaar.com/rdfa-test-harness/
Manu: oops, seems I broke the test case harness
<msporny> <?xml version="1.0" encoding="UTF-8"?>
<msporny> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<msporny> <html xmlns="http://www.w3.org/1999/xhtml"
<msporny> xmlns:dc="http://purl.org/dc/elements/1.1/">
<msporny> <head>
<msporny> <title>Test 0105</title>
<msporny> </head>
<msporny> <body>
<msporny> <div about="" rel="dc:creator">
<msporny> <a rel="myfoobarrel" href="ben.html">Ben</a> created this page.
<msporny> </div>
<msporny> </body>
<msporny> </html>
<msporny> ASK WHERE {
<msporny> <http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0105.xhtml> <http://purl.org/dc/elements/1.1/creator> _:a .
<msporny> }
Manu: _:a should be changed to ?a
... we should verify that the object is a bnode
... so needs a FILTER
<msporny> ASK WHERE {
<msporny> <http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0105.xhtm
<msporny> l> <http://purl.org/dc/elements/1.1/creator> ?a .
<msporny> FILTER IsBlank(?a)
<msporny> }
Mark: to be a full test, we should check that there's not a triple with myfoobarrel as a predicate
Manu: we can't do that in a single query
Mark: could use NOT
Manu: I'll investigate
... there are other tests that don't verify the absence of a triple
Mark: do we need @about="" ?
Steven: doesn't do any harm
RESOLUTION: test 105 accepted, with change to check for absence of myfoobarrel triple
<ShaneM> +1
<msporny> <?xml version="1.0" encoding="UTF-8"?>
<msporny> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<msporny> <html xmlns="http://www.w3.org/1999/xhtml"
<msporny> xmlns:dc="http://purl.org/dc/elements/1.1/">
<msporny> <head>
<msporny> <title>Test 0106</title>
<msporny> </head>
<msporny> <body>
<msporny> <div about="" rel="dc:creator">
<msporny> <a rel="" href="manu.html">Manu</a> created this page.
<msporny> </div>
<msporny> </body>
<msporny> </html>
<msporny> ASK WHERE {
<msporny> <http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0106.xhtml> <http://purl.org/dc/elements/1.1/creator> ?a .
<msporny> FILTER IsBlank(?a)
<msporny> }
Manu: add similar absence test to 106
Ralph: no predicate to check for absence in this case
Mark: a parser might blindly generate a predicate URI of http://www.w3.org/1999/xhtml
<Steven> Is there an empty CURIE?
Ralph: even though that wouldn't be a [semantically] valid predicate name
Mark: yep
<markbirbeck> I was thinking of the xhv namespace, Ralph.
[yep, I copied the wrong text!]
Manu: we could test that there is no triple containing "Manu" as an object
Mark: yes, that's more sensible for both 106 and 105
RESOLUTION: test 106 accepted, with change to check for absence of triples containing manu.html as either subject or object
Manu: we currently have 4 tests that fail; 100-103 because the literals are compared character by character
<msporny> <div />
Manu: even though the test is correct, the harness considers ''' and '"' to be different
<msporny> <div></div>
Manu: also, our test doesn't cover the case
that <div /> and <div></div> are equivalent
... I propose that we add two versions of each test; one in short form and
one in long form
Ralph: sounds reasonable to me to duplicate the tests for the convenience of implementors
<msporny> ASK WHERE {
<msporny> <http://www.example.org> <http://example.org/rdf/example> 'Some text here in <strong xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg">bold</strong> and an svg rectangle: <svg:svg xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg"><svg:rect svg:height="100" svg:width="200"/></svg:svg>'^^<http://www.w3.org/1999/02/22-rdf-syntASK WHERE {
<msporny> <http://www.example.org> <http://example.org/rdf/example> 'Some text here in <strong xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg">bold</strong> and an svg rectangle: <svg:svg xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg"><svg:rect svg:height="100" svg:width="200"/></svg:svg>'^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .
<msporny> }
<msporny> ax-ns#XMLLiteral> .
<msporny> }
Manu: ^ SPARQL for test 100
... this is nearly impossible [for a human] to read
<msporny> ASK WHERE {
<msporny> <http://www.example.org> <http://example.org/rdf/example> 'Some text here in <strong xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg">bold</strong> and an svg rectangle: <svg:svg xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg"><svg:rect svg:height="100" svg:width="200"/></svg:svg>'^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .
<msporny> }
Manu: the idea would be to include UNION statements where '"' is exchanged for '''
<msporny> </svg:rect>
Manu: and has both self-closed and explicit
close tags
... for the convenience of both sax-based and DOM-based parsers
... any objections?
[no objections]
Manu: I propose to update test 100-103 to add all four cases
Shane: I don't really object but I point out it's an "interesting" combinatorial problem to add all the cases to the SPARQL
Manu: modified proposal; only add those requested by implementors
Shane: also add a comment to the tests so when new implementors come along they know why they might be failing
<msporny> PROPOSE: Add implementors valid XML Literals to TC 100-103 and add comments to tell other implementors that the tests may fail due to XML Literal issues.
<msporny> PROPOSE: Add valid cases of XML Literals as requested by implementers to TC 100-103 and add comments to tell other implementors that the tests may fail due to XML Literal issues.
<Steven> ok
RESOLUTION: Add valid cases of XML Literals as requested by implementers to TC 100-103 and add comments to tell other implementors that the tests may fail due to XML Literal issues.
Manu: I believe we've resolved this
Shane: the resolution was a minor change in the document ~1 month ago
Mark: this was a case of reading the text two
possible ways, where one way was really awkward
... the problem I thought people were raising was that although the second
[myfoobarrel] line does not generate a triple, it may also cause the first
[dc:creator] line to not generate a triple
... we should be more explicit that the nested element does complete the
first triple even though it doesn't contain a valid @rel
... I argued this was clear in the spec by interpretation of step 5
... the wording is changed to refer to the presence of @rel attribute rather
than to a @rel value
<msporny> PROPOSE: Resolve ISSUE-120 having made a minor change to the Syntax Document specifying that the presence of a @rel generates an incomplete triple
<msporny> PROPOSE: Resolve ISSUE-120 having made a minor change to the Syntax Document specifying that the presence of a @rel is sufficient to complete and incomplete triple.
<ShaneM> http://htmlwg.mn.aptest.com/viewcvs/viewcvs.cgi/rdfa-syntax/Overview.mhtml.diff?r1=1.228&r2=1.229
RESOLUTION: Resolve ISSUE-120 having made a minor change to the Syntax Document specifying that the presence of a @rel is sufficient to complete an incomplete triple.
<msporny> http://www.w3.org/2006/07/SWD/track/issues/103
Manu: our email discussion boils down to "let's not change anything"
-> http://www.w3.org/2006/07/SWD/track/issues/103 ISSUE-103 a URI-centric approach to CURIEs
Shane: the argument is that CURIEs are _not_
URIs
... the implication of being a URI is that they could be used over the wire,
but they can't be used over the wire
Mark: and we've suggested that languages that currently use QNAMEs could migrate over time to using CURIEs
Shane: in the TAG's recent CURIE Last Call comments they say that the CURIE syntax is too rich for use in SPARQL
Steven: and we're trying to fix that limitation in other languages
<msporny> PROPOSE: Resolve ISSUE-103, CURIEs are not URI schemes, they are a macro expansion mechanism. No need to change the Syntax document.
<Steven> There are queries you would like to make that SPARQL cannot do, and CURIEs fix that
Mark: I'd like my email comment to be included; this is QName-like
<msporny> PROPOSE: Resolve ISSUE-103, CURIEs are not URI schemes, they are a macro expansion mechanism. No need to change the Syntax document. CURIEs are also QName-like, allowing legacy languages to migrate forward cleanly.
Ralph: +1
<markbirbeck> +1
RESOLUTION: ISSUE-103 closed, CURIEs are not URI schemes, they are a macro expansion mechanism. No need to change the Syntax document. CURIEs are also QName-like, allowing legacy languages to migrate forward cleanly.
Ralph: in SWD WG meeting, Ben was asked to confirm that the XHTML2 WG will be able to resolve a CR transition request by Tuesday 10 June
Shane: yes, XHTML2 WG will be able to resolve this by 11 June
Steven: but there's an XForms WG meeting on the 11th
Shane: XHTML2 WG will be able to resolve CR
transition request by 17 June
... and we should discuss the CR exit criteria
Steven: I propose "2 implementations that pass all tests"
Shane: we've had a request that there also be
an XSLT implementation
... however, I do not believe that such an implementation is possible
Steven: the minimum requirement is that there are 2 implementations of all features, and they don't all even have to be in one implementation
[adjourned]