RDF in XHTML Task Force

 

 

Test Cases

we are doing these via e-mail, but there is a general topic.

<Steven> put that in the record manu

Action Items

Manu's action to confert the charter to HTML format is complete.

<benadida> --> http://www.w3.org/2009/11/12-rdfa-minutes.html#ActionSummary

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

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

<scribe> --continues - nearly done

<msporny> we should accept the test cases based on the current published rules and then change the test cases if we change the rules in the future.

markbirbeck: original proposal said we should advise people to use safe curies.

ivan and shane said why bother? It gets handled automatically.

Ben seems to have opened the question again. So there seems to be an open issue. Should we encourage people to use safe curies or not?

Also, what if a prefix name is used that collides with a scheme

Steven says this is not a problem since if I meant it to be a prefix, it will always remain a prefix

markbirbeck: if I edit that document later and am inserting a link that now uses some new scheme that collides with prefixes I declared ages ago, that could be an issue.

benadida: As long as the document doesnt change meaning if the document is not edited later, it is not an issue

ivan1: the chances for something like this to occur are non-zero, but it is so rare as to be uninteresting
... we should put in some warning

markbirbeck: we could plug all holes if we insist on a safe curie. But if we are happy these edge cases are not a real issue, then let's leave it

<msporny> I don't think we should ever depend on people correctly using Safe CURIEs

<msporny> yes, I was in agreement with this direction.

ivan1: if we keep to the priority in processing that we look to see if something is a CURIE or not, then this is backward compatible
... if we go one step further, we could have relative URIs in @typeof

<msporny> I don't know if we should have relative URIs in @property - I realize the use case, but it's very uncommon.

benadida: feels the use case is very rare.

<msporny> I think the reason to forbid it is because it overcomplicates RDF.

ivan1: agrees but doesn't seem to find a reason to forbid it.

<msporny> s/RDFa\./RDFa./

benadida: RDF/XML is an example of having many ways to write the same thing, and this makes it complicated to learn.
... if we have CURIEs and SafeCURIEs in the same datatype this is complicated

ivan1: thinks that we have inconsistency in our rules today between @rel and @rev vs. @about and @resource

<msporny> That said, I would be in favor of playing down Safe CURIEs...

markbirbeck: points out that we could downplay SafeCURIEs if we wanted too
... remarks that lately we have realized that if there is no defined prefix, it can be easily interpreted as a URI. that means there is less possibility for confusion.

<msporny> I haven't seen Safe CURIEs used in the wild...

benadida: if we are going this route, we should downplay the importance of SafeCURIEs
... Wants to wait to see Mark's proposed spec text before making a decision

<msporny> other than through somebody in this task force.

<Zakim> ShaneM, you wanted to discuss tag objections

<msporny> we might want to revisit this with the TAG based on our new findings.

ShaneM: points out that the reason we have SafeCURIEs is that the TAG said we cannot put CURIEs and URIs in the same attribute
... the TAG didn't want the possibility for confusion on the part of humans, not software.

ivan1: for many people this is a stumbling block (using full URIs instead of CURIEs)

ShaneM: we are conflating two issues

benadida: yes, but the one flows into the other
... proposes we wait for Mark's wording on this (but admits Ben is the hold up!)

ivan1: make it clear to everyone (including the TAG) that we do not intend to introduce this behavior for non-RDFa attributes such as @href and @src

markbirbeck: we can consider this as an RDF interpretation of existing markup

Steven: w.r.t. Ivan's remark Steven thinks if we do this people are going to expect it to work in @href and @src. The advantage of having two different notations

<msporny> We're going to get severe push-back from HTML WG if we change @href and @src

is that you KNOW it was not allowed in @href. Validation might spot an error today. Going forward there is no way that validation would catch the use of a CURIE in @href and @src

benadida: But the browsers would not do it right... so page authors would notice immediately that their links didn't work

ShaneM: at least if there is a SafeCURIE in @resource I would not be confused into thinking it was a URI.

markbirbeck: That's not the point. The point is that a consumer might think that @href=SafeCURIE should woirk. and going forward @href=CURIE should work. And they won't!
... perhaps we should cross this bridge when we come to it.
... the reason this is back on the agenda is because of HTML5. And this change (full URIs just work) will help us get past the technical objection that some in the HTML5 community have raised.

Steven: The issue isn't that we can say "we won't apply this to @href and @src" but that might not be compelling

benadida: I dont see browser manufacturers implementing interpretation of CURIEs in @href and @src

<msporny> We should ask the TAG directly.

<msporny> I also think that the danger that Steven has outlined does exist...

<msporny> If there is a chance of surprising somebody with this change, I think it would be best to point it out.

ivan1: we should ensure that if we are moving in this direction we inform the objectors to CURIEs that there will be this option in the next version.

ShaneM: I personally would object to a change that permits CURIEs in places where we only permits SafeCURIEs

benadida: thinks we ar econverging

<scribe> ACTION: Manu to ask somebody to draft errata text, clarifying that prefixes cannot be '_' character [recorded in http://www.w3.org/2009/11/12-rdfa-minutes.html#action10]

<msporny> I haven't done that yet

I did this. http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Nov/0043.html

<scribe> --done

<msporny> Thanks Shane :)

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

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

<benadida> consider thew new XMLLiteral errata text: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Nov/0044.html

<benadida> +1

<markbirbeck> +1

+1 (obviously)

<Steven> +1

<benadida> RESOLVED to accept the XMLLiteral errata text

<benadida> consider the _ prefix errata text: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Nov/0043.html

<benadida> +1

<Steven> +1

+1

ivan1: why "SHOULD NOT" instead of "MUST NOT" for authors

<ivan1> +1

ShaneM: I have never seen a spec where we said "MUST NOT" to a spec author

<benadida> RESOLVED to accept the _ prefix errata text

<markbirbeck> Abstaining. :)

<markbirbeck> I have use-cases for redefining '_', but they're a little esoteric.

Working Group Charter

ivan1: I made some edits and initiated some discussion within the W3C (management team etc.)
... for the time being it seems fine. Mike Smith suggested we make the Javascript API a higher priority.
... If everything goes well this week or monday we will let the AC know we are planning to move ahead with this charter.

<ivan1> http://www.w3.org/2009/11/rdfa-wg-charter.html

ivan1: ... removed text that would cause people to be concerned about the open-endedness of the charter. The charter has specific deliverables. That should help assuage concerns about open-endedness

<scribe> ACTION: Someone let Ivan know what Open Document Format reference to use in the charter [recorded in http://www.w3.org/2009/11/19-rdfa-minutes.html#action08]

Steven: notes that we list coordination with external groups when they are outside of W3C.

<Steven> Here is the ODF TC link - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

ivan1: pushed out milestones by a month because it assumed we would start in January, and that was not going to happen
... we could stretch the deliverables out to make it easier.

benadida: the draft plans for slack time by having the schedule tight, but has the end of the charter out a little bit

ivan1: we can extend the charter if we need to when deadlines are missed. dont' need to build in slack in this way.
... some deliverables in the charter look like software development. W3C working groups do not develop software. also, it looks like that is what the group would be doing in its last 8 months. that might be bad.

Steven: discussed the charter with the Interaction Domain team group. They felt we should be doing work on some basic set of advised vocabularies as a way to help people start using RDFa more quickly.
... Suggests we say we will produce a cookbook or produce standard vocabularies

ivan1: vocabularies is not an RDFa issue. it is a semweb issue. this group should not pick it up.
... having something that is richer than the Primer (e.g., a Cookbook) that uses some of the vocabs out there as examples might be a real benefit. We should not be blessing vocabs.

<markbirbeck> +1 to Ivan

Steven: I think a cookbook / examples is just fine and will help address their problem.

ShaneM: +1 to Ivan

ivan1: RDFa is a serialization syntax - vocab to use is a general sem web issue.

re: software development...

benadida: understands w3c is not in the software implementation business. However, when we started building prototypes of RDFa things really moved ahead.
... if we shouldn't put them in the charter that's one thing. but we should still prototype to ensure that things work!

markbirbeck: not convinced things took off when we started prototyping. The problem is that mentioning specific libraries like jQuery or Dojo might be limiting. we should not be pushing a specific library set. We should have something more abstract but we should not lock ourselves in and therefore miss whatever is going to be happening two years from now.

ivan1: +1 to Mark. moreover, saying we are adapting to jQuery or Dojo or whatever, that is something individuals are doing to ensure that the ideas work. It should not be a deliverable of the working group though.
... should have in the scope and deliverables more detailed text about community building. We have the Primer. We could do a note about triple store. There could be a cookbook. But we could also say that at the end of the working group we have a deliverable that is a Note about how RDfa is used in practice and what libraries are around at the time and how RDFa is used in the wild. This is the 'start of the art' at the time.

benadida: feels there should be implementation work, but if there is no room for it in the charter so be it

ShaneM: is concerned that a Note at the end becomes some 'iconic thing' that gets referred to forever even though it is immediately out of date

ivan1: What I try to do is set up wikis for groups so that it can be maintained over time, rather than just producing a Note. Make it explciit that there is also a wiki so the community can keep it up once the group ends
... knows there is already a wiki outside of w3c space.
... sem web wiki was just set up by Ivan. For the time being, in the sem web wiki there is apointer to the existing RDFa wiki.
... 'I am not in the business of trying to rule the world'.