RDF in XHTML Task Force

Action Items

http://www.w3.org/2009/10/22-rdfa-minutes.html#ActionSummary

<scribe> ACTION: Ben to finish authoring RDFa WG charter. [recorded in http://www.w3.org/2009/10/22-rdfa-minutes.html#action07] [CONTINUES]

Ben: Updated it a bit

Manu: I also fixed some very small issues
... Ivan had an issue with mentioning the Microsoft extensibility proposal.

Ben: We're interested in supporting that language extension proposal.

<benadida> --> http://rdfa.info/wiki/Rdfa-wg-charter

(side-bar Google Chrome discussion) Everybody seems to love it.

Ben: Manu has been asked to co-chair RDFa WG.
... We have 12 months to do the work and 6 months of slack.
... It does assume that it is going to take RDFa 1.1 to REC.

Manu: Sent it off for review by HTML WG chairs.

<scribe> ACTION: Ivan to talk with Peter Mika at ISWC2009 about RDFa WG. [recorded in http://www.w3.org/2009/10/22-rdfa-minutes.html#action06] [DONE]

<scribe> ACTION: Manu to try and find other interested parties in RDFa WG. [recorded in http://www.w3.org/2009/10/22-rdfa-minutes.html#action08] [CONTINUES]

<scribe> ACTION: Shane to look at XML spec and see if xml: is illegal in RDF/XML re: TC 142 [recorded in http://www.w3.org/2009/10/22-rdfa-minutes.html#action09] [CONTINUES]

<scribe> ACTION: Ben to update JS xmlns getter code on implementors' guide for xhtml mime type support [recorded in http://www.w3.org/2009/09/17-rdfa-minutes.html#action02] [DONE]

<benadida> --> http://rdfa.info/wiki/Rdfa-implementors-guide#JavaScript

Ben: Is this test good?

Shane: Opera isn't the special case, Opera is the one that works correctly.
... It seems as if this works for all cases.

<scribe> ACTION: Manu speak with Andy Seaborne about SPARQL.org implementation re: c14n [recorded in http://www.w3.org/2009/10/15-rdfa-minutes.html#action06] [CONTINUES]

Manu: Jeremy thinks it is a bug in sparql.org
... Andy seems to think it is, but hasn't responded yet (I just e-mailed him last night)

<scribe> ACTION: Shane to re-draft XMLLiteral errata text [recorded in http://www.w3.org/2009/10/15-rdfa-minutes.html#action04] [CONTINUES]

RDFa WG Charter

Ben: Any additions/changes?

Manu: We might want to put a validator as a work item for the RDFa WG.
... We might also want to produce an Javascript-based live editor for RDFa.

Shane: We might also want to look at XMLSPEC - W3C recs could be semantically rich.

Manu: We would probably want to say that we'd work with SVG WG and ODF standards body on integrating RDFa
... We should create a test suite for SVG.

Shane: There are people that continue to need modularization.
... Maybe RDFa WG could work on modularization - it's specific to W3C. RDFa depends on modularization now.

Manu: We might want to discuss this with the people at Microsoft that are working on decentralized extensibility.

<benadida> ACTION: Manu to aggressively push review of test cases via mailing list [recorded in http://www.w3.org/2009/10/29-rdfa-minutes.html#action08]

Test Cases

Manu: I'll try to drive the discussion via the mailing list and keep pressing people to review them.

Shane: We may want to take a deadline approach - no comments means the TC is approved.

RDFa 1.1 issues

Ben: Where do we stand on these RDFa 1.1 issues

Manu: My preference is to work on these in this order: @profile, DOM API, URIs everywhere, @typeof

Ben: Shane, what do you think should happen when @typeof is empty based on what the spec says?

Shane: The presence of @typeof should trigger a bnode to be created.

Ben: Maybe this already happens, maybe our test cases don't test this.
... This issue may already be resolved.

<ShaneM> check http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata/

Ben: Manu, you're not against typeof="", right?

Manu: Correct, just not a high priority for me.
... typeof="[]"
... typeof="foobar"?
... What does that do? It creates a bnode still?

Ben: Yes, except we can't set the type.
... We think the processing rules and the errata already say this - it would be worth clarifying step 4 in the processing rules.

<benadida> PARTIAL CONSENSUS (because we're 3 on the call): @typeof presence already creates bnode, as per spec and errata. Step #4 could use some clarification to prevent confusion.

Ben: URIs everywhere - how can we support rel="http://example.org/vocab#term" ?
... That's the goal, let's not talk about the mechanism.

Manu: I'm fine with that goal.

Shane: Fine with the goal, not a high priority for me.

Ben: Don't feel very strongly about this, not going to make/break anything.
... If we find a good way to do it, then great.
... We know some RDFa community members and WHATWG community members care deeply about this.

<benadida> PARTIAL CONSENSUS: we note that some community members care deeply about this. The three of us are not strongly opposed, but it is not a high priority to resolve.

Manu: Fine with that.

Shane: Fine.

Ben: DOM API - I'm not opposed, unless it's done in a pure RDF way.
... I think that would be a strong negative.

Manu: The other point to make is that we might want to start with something very specific and let jQuery plugins aggregate RDFa/Microformats/Microdata APIs into an uber data API

Shane: We've told the browser folks that we don't need browser support for a very long time.
... Now we roll out a DOM API.
... We don't need them to implement the API - we might get pushback from the browser manufacturers.

Ben: Yes, it is a valid concern.
... Most concerned about the interplay between the @vocab discussion and the DOM API support.
... We're basically saying that RDFa 1.1 might require browser vendors to retrieve vocabulary documents.
... Pain lies in the intersection between @vocab and DOM API.

Manu: We can take the JSON approach (as Sam Ruby and Doug Schepers outlined a month ago)... implement in jquery/javascript first... speed it up with native implementations later.

Ben: Yes, I do think that may be the right approach.
... Direction for DOM API should be a jQuery plugin.

Shane: We should use the DOM hasFeature mechanism.

Ben: Don't know if Jeni's plugin does this - but it would be nice to trace a triple back to the DOM node element that generated it.
... Bi-directional visual data correspondence.

Shane: Don't think that Mark's concept does that.

Ben: Triple stores have origins - we might be able to hack it to make it an xpath into a document.

Shane: Provenence - XPATH expression into a URI using a hash.
... Mark's worked on that... Document API

Ben: Shane - regarding @vocab - I might be convinced about Mark's approach. Don't know if my approach is taking hold with anybody - I think we need to make life easier for authors, as Manu has been evangelizing for some time.
... The big problem is the requirement for dereferencing....
... Wondering if the parser should generate some sort of intermediate format?

Shane: Isn't the intermediate format the CURIE?
... In the @profile proposal, you can define new keywords and remote mappings.

Ben: Yes, the remote mappings thing is something I would have an issue with...
... A @vocab proposal where the only thing you're doing is adding a source of unprefixed keywords.
... The goal of author ease-of-use is to remove the prefixes entirely.
... If you're asking the author to understand that there are different vocabularies, I don't think you're making it transparent anymore.
... For example, adding foaf:name and dc:title into the same vocabulary - that's not easier.

Shane: link rel="vocab" ... would override the words that are not core reserved words.
... Is that correct?

Ben: yes, more or less.
... I'm making the point that you shouldn't pull in prefix definitions... but it would be a reserved words only approach.
... Indirection for definition of prefixes seems wrong to me.

Shane: Need to think about it.