RDFa in XHTML Task Force

Action Items

<scribe> ACTION: Manu to update the charter to talk about RDFa API [recorded in http://www.w3.org/2009/11/05-rdfa-minutes.html#action08] [DONE]

<scribe> 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] [CONTINUES]

Manu: any additions/changes to agenda?

<Steven> Nothing from me.

Manu: We had discussed RDFa API last week, any input Mark, Steven?

Mark: Some input - there are "Storage APIs" in Prototype, mootols, etc. They allow you to store name-value pairs.
... Little storage packets at level of element. We should look at all of the APIs - the foundations... it would be good if the thing we came up with extended what developers are already working with.
... We may look at looking at the "name" in the name-value pair as a full URI....
... We should do it in such a way as to get it to fit with present tools.

Ivan: We agreed that RDFa API is a part of the charter...
... We also want to say we will look at a more general case, will most probably publish a W3C NOTE on the issue, and we /may/ go beyond that.
... So, what you said Mark, is in line with what we discussed.
... We try to make the distinction that we don't have the obligation to produce an TripleStore API.

<scribe> 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] [CONTINUES]

<Steven> I approve test #142

Shane: You raised an issue about TC 140 and why it shouldn't generate a triple.

Manu: Adding to agenda, review TC140

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

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

Manu: Any ideas on who we'd like to invite? Browser vendors?

Mark: We may want to discuss this with the browser vendors because we haven't been focusing on that in the past.

Steven: It would be good to get browser vendors involved.
... This could be of interest to browser vendors as semantic objects in pages could be used to do commerce.
... This would give browser vendors an incentive to participate - there is an economic incentive.

Ivan: I think we should be very conservative in what we sign ourselves up to do.
... This could become a great deal of work.
... We want to make sure that the group is independent and if we go toward browser vendors too much, it could be interpreted as we're doing all HTML5 work, which is not true.

<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] [DONE]

Shane: They're reserved, but they can start with 'xml'

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

Manu: Update on sparql.org - bug in librdfa. It uses datatype="rdf:XMLLiteral" not parseType="Literal"

Ivan: I disagree - you should canonicalize in both cases.
... It's not clear, but I don't think we should pursue it.

Shane: I do emit parsetype="Literal"

RDFa WG charter updates

Manu: I have started asking others to join... what happens if they don't get back to us in time?

Ivan: I have started working at charter at W3C.
... The process has been started.

Manu: Anything you need?

<scribe> ACTION: Manu to convert WG Charter page to W3C charter format [recorded in http://www.w3.org/2009/11/12-rdfa-minutes.html#action08]

Ivan: Would be nice to convert wiki page to HTML charter.

Shane: The only place CURIEs are defined normatively are in XHTML and RDFa.
... CURIE spec is never going to be published as a REC...
... There are other specs that need to refer to CURIEs normatively.
... Do we need to separate out CURIE spec and make it normative?
... @role, access and XMLEvents refer to CURIE normatively.

<Steven> WAI ARIA

Steven: I don't think we're going to take them out of XML Events 2 - we'll still use the notation.

Ivan: Having it as a separate REC in RDFa WG would be bad.

URIs in @rel, @rev, @property, @typeof and @datatype

Mark: So, the only real sustained objection to RDFa has been the use of CURIEs.
... We do like CURIEs, and it does help more than it hinders in most cases.
... But, it wouldn't hurt to support an alternative.
... We could allow URIs where only CURIEs can be used.
... It's a useful feature in it's own right... we should make it a greater priority.
... If we can address this issue, we should.
... In terms of the actual solution itself, the core of what I've argued is that we may be able to solve this by thinking about the problem differently.
... We could say that an entry without a clearly defined prefix is certainly not a CURIE and certainly is something else... a URI, for example.
... This solution is backwards-compatible.

<Zakim> ShaneM, you wanted to ask about relative URIs

Shane: I want to confirm that we're discussing absolute URIs, not relative URIs.
... What about rel="/foo/bar" ?
... you can't do that... you have to start with a scheme name... it has to be an absolute URI.

Mark: There are two RFCs on this - one of them allows it, one of them discourages it... it's undefined.
... So, if you do "file:FILENAME" - in lots of systems, that will be your desktop.

Shane: If we are talking about absolute URIs, this solution is dead-easy.
... We should go ahead and plan to do it.
... Mark, you use the term protocol, I think the term is "scheme"

Ivan: I agree, but there is one more step that we could make.
... What about CURIEs for @about and @resource?
... So, it's okay for @about and @resource, but what about @href and @resource?
... What about safe curies in @href?

Steven: We don't allow it in @href.

Ivan: I meant @href and @src.
... We don't even allow safe CURIEs in @href and @src...

Shane: The RDFa spec doesn't talk about it in @href and @src - we defer to the host language.

Ivan: Do we have a test case for this? Test case to test safe CURIEs in @href and @src?

Steven: Safe CURIEs wouldn't validate in @href and @src.

Manu: Any objections to moving forward with this?
... Perhaps Mark can author some spec text and post it to the list?

<scribe> ACTION: Mark to author URIs in @about, @rel, @rev, @typeof and @datatype spec text [recorded in http://www.w3.org/2009/11/12-rdfa-minutes.html#action09]

Mark: What about having a way to trigger this experimental behavior?

Triggering experimental behavior

Shane: Do we have an announcement mechanism for enabling this new URIs everywhere feature?

Mark: Perhaps we don't need that for this feature, since it's backwards-compatible?

Manu: What if we do rel="rdfa:featureX"?

Mark: I think it isn't correct to do that. In-band triples shouldn't change the triples that the the processor is generating.

Test Case 140

<ShaneM> the test says <p xmlns:_="http://example.org/" property="_:test">Test</p>

<Steven> property="rdfa:version"

Ivan: I think we got confused? Maybe had an HTTP 400 error.
... I think this is perfectly legal, and we should generate a triple?
... Wait a second...

<ivan> _:test

Shane: We say that '_' is a reserved prefix for bnodes.

<ShaneM> http://www.w3.org/TR/rdfa-syntax/#s_curies

Shane: spec text says - the mapping to use with the '_' prefix, is not explicitly stated, but since it is used to generate [bnode]s, its implementation needs to be compatible with the RDF definition.

Ivan: RDF doesn't say anything about '_'
... We have to agree how we specify blank-nodes.
... In TURTLE, the _ as a prefix defines blank nodes.

Manu: That sentence isn't clear.

Ivan: What is intended is clear to me...

Manu: I think we need errata text.

Ivan: Yes, we should have more errata text.

Shane: Yes, more errata text.

Manu: any objections to moving to ASK WHERE { ?s ?p ?o. } ?

Ivan: I may generate warning triples...

<ivan> <> ?p "Test" .

Manu: Everybody okay about using that SPARQL instead?

<ivan> <> <http://example.org/test> "Test"

Manu: Yes, we'll change the SPARQL to that.

<ShaneM> Question: in Mark's proposal for URI processing, should the parser ensure it is a valid URI ?

syntactically valid?

probably.

<ShaneM> kk thanks

although, that's going to be a PITA for my parser.