RDF-in-XHTML Task Force -- 29 May 2008

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]

Response to TAG

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]

Test Cases

<msporny> http://rdfa.digitalbazaar.com/rdfa-test-harness/

-- test 105; inner @rel neither CURIE nor LinkType

Manu: oops, seems I broke the test case harness

<msporny> <html xmlns="http://www.w3.org/1999/xhtml"

<msporny> xmlns:dc="http://purl.org/dc/elements/1.1/">

<msporny> <a rel="myfoobarrel" href="ben.html">Ben</a> created this page.

<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

-- test 106; chaining with empty value in inner @rel

<msporny> <html xmlns="http://www.w3.org/1999/xhtml"

<msporny> xmlns:dc="http://purl.org/dc/elements/1.1/">

<msporny> <a rel="" href="manu.html">Manu</a> created this page.

<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

handling of literals in test harness

Manu: we currently have 4 tests that fail; 100-103 because the literals are compared character by character

Manu: even though the test is correct, the harness considers ''' and '"' to be different

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> }

<msporny> ax-ns#XMLLiteral> .

<msporny> }

Manu: ^ SPARQL for test 100
... this is nearly impossible [for a human] to read

<msporny> ASK WHERE {

<msporny> }

Manu: the idea would be to include UNION statements where '"' is exchanged for '''

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.

ISSUE-120; nested @rel where inner @rel is neither CURIE nor link type

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

ISSUE-103; a URI-centric approach to CURIEs

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.

CR Transition Scheduling

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]

RDF-in-XHTML Task Force

29 May 2008

Attendees

Contents

Response to TAG

Test Cases

-- test 105; inner @rel neither CURIE nor LinkType

-- test 106; chaining with empty value in inner @rel

handling of literals in test harness

ISSUE-120; nested @rel where inner @rel is neither CURIE nor link type

ISSUE-103; a URI-centric approach to CURIEs

CR Transition Scheduling

Summary of Action Items