Minutes are at:
Text version below.
RDF in XHTML Task Force
19 Nov 2009
See also: IRC log
Manu_Sporny, Ivan_Herman, Mark_Birbeck, Ben_Adida,
1. Test Cases
2. Action Items
3. Working Group Charter
* Summary of Action Items
we are doing these via e-mail, but there is a general topic.
<Steven> put that in the record manu
Manu's action to confert the charter to HTML format is complete.
<benadida> ACTION: Manu to convert WG Charter page to W3C charter
format [recorded in
<scribe> ACTION: Mark to author URIs in @about, @rel, @rev, @typeof
and @datatype spec text [recorded in
<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
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
<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
ivan1: agrees but doesn't seem to find a reason to forbid it.
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
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
markbirbeck: points out that we could downplay SafeCURIEs if we
... 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
<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
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
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
<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
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
<msporny> I haven't done that yet
I did this.
<msporny> Thanks Shane :)
<scribe> ACTION: Ben to finish authoring RDFa WG charter. [recorded
<scribe> ACTION: Manu to aggressively push review of test cases via
mailing list [recorded in
<scribe> ACTION: Manu to try and find other interested parties in
RDFa WG. [recorded in
<scribe> ACTION: Shane to re-draft XMLLiteral errata text [recorded
<benadida> consider thew new XMLLiteral errata text:
<benadida> RESOLVED to accept the XMLLiteral errata text
<benadida> consider the _ prefix errata text:
ivan1: why "SHOULD NOT" instead of "MUST NOT" for authors
ShaneM: I have never seen a spec where we said "MUST NOT" to a spec
<benadida> RESOLVED to accept the _ prefix errata text
<markbirbeck> Abstaining. :)
<markbirbeck> I have use-cases for redefining '_', but they're a
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
... If everything goes well this week or monday we will let the AC
know we are planning to move ahead with this charter.
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
Steven: notes that we list coordination with external groups when
they are outside of W3C.
<Steven> Here is the ODF TC link -
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
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
... Suggests we say we will produce a cookbook or produce standard
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
... 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'.
Summary of Action Items
[NEW] ACTION: Manu to ask somebody to draft errata text, clarifying
that prefixes cannot be '_' character [recorded in
[NEW] ACTION: Mark to author URIs in @about, @rel, @rev, @typeof and
@datatype spec text [recorded in
[NEW] ACTION: Someone let Ivan know what Open Document Format
reference to use in the charter [recorded in
[PENDING] ACTION: Manu to aggressively push review of test cases via
mailing list [recorded in
[PENDING] ACTION: Manu to try and find other interested parties in
RDFa WG. [recorded in
[DONE] ACTION: Ben to finish authoring RDFa WG charter. [recorded in
[DONE] ACTION: Manu to convert WG Charter page to W3C charter format
[DONE] ACTION: Shane to re-draft XMLLiteral errata text [recorded in
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.135
$Date: 2009/11/20 10:27:15 $
Ivan Herman, W3C Semantic Web Activity Lead
PGP Key: http://www.ivan-herman.net/pgpkey.html
smime.p7s (5K) Download Attachment
|Free forum by Nabble||Edit this page|