Chatlog 2012-04-05

See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.

13:26:22 <RRSAgent> RRSAgent has joined #rdfa
13:26:22 <RRSAgent> logging to http://www.w3.org/2012/04/05-rdfa-irc
13:26:24 <trackbot> RRSAgent, make logs world
13:26:24 <Zakim> Zakim has joined #rdfa
13:26:26 <trackbot> Zakim, this will be 7332
13:26:26 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 34 minutes
13:26:27 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:26:27 <trackbot> Date: 05 April 2012
13:41:01 <danbri> danbri has joined #rdfa
13:53:34 <MacTed> MacTed has joined #rdfa
13:57:12 <Steven_> Steven_ has joined #rdfa
13:59:28 <niklasl> niklasl has joined #rdfa
14:00:06 <ShaneM> ShaneM has left #rdfa
14:00:23 <ShaneM> ShaneM has joined #rdfa
14:00:56 <Zakim> SW_RDFa()10:00AM has now started
14:01:03 <Zakim> +??P30
14:01:07 <niklasl> zakim, I am ??P30
14:01:07 <Zakim> +niklasl; got it
14:01:31 <Zakim> +??P31
14:01:36 <gkellogg> zakim, I am ??P31
14:01:39 <manu1> zakim, I am ??P31
14:01:47 <Zakim> + +1.540.961.aaaa
14:01:53 <Zakim> +gkellogg; got it
14:01:54 <manu1> zakim, I am ??aaaa
14:01:57 <Zakim> sorry, manu1, I do not see a party named '??P31'
14:01:58 <gkellogg> zakim, I am ??P31
14:02:00 <manu1> zakim, I am aaaa
14:02:15 <Zakim> sorry, manu1, I do not see a party named '??aaaa'
14:02:19 <Zakim> sorry, gkellogg, I do not see a party named '??P31'
14:02:21 <Zakim> +manu1; got it
14:02:44 <gkellogg> zakim, I am ?P31
14:03:04 <Zakim> sorry, gkellogg, I do not see a party named '?P31'
14:03:09 <gkellogg> zakim, I am ??P31
14:03:27 <Zakim> sorry, gkellogg, I do not see a party named '??P31'
14:03:43 <gkellogg> zakim, who is on the call?
14:03:51 <Zakim> On the phone I see niklasl, gkellogg, manu1
14:03:54 <Zakim> +scor
14:04:11 <scor> scor has joined #rdfa
14:04:26 <Steven> Steven has joined #rdfa
14:05:41 <scor> zakim, who is on the phone?
14:05:50 <Zakim> +OpenLink_Software
14:06:06 <Zakim> +Steven
14:06:18 <Zakim> On the phone I see niklasl, gkellogg, manu1, scor, OpenLink_Software, Steven
14:06:29 <MacTed> Zakim, OpenLink_Software is temporarily me
14:06:30 <MacTed> Zakim, mute me
14:07:01 <Zakim> +MacTed; got it
14:07:04 <Zakim> MacTed should now be muted
14:07:44 <MacTed> Zakim, unmute me
14:07:55 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Apr/0016.html
14:07:57 <MacTed> Zakim, mute me
14:08:07 <manu1> scribenick: scor
14:08:17 <Zakim> MacTed should no longer be muted
14:08:39 <Zakim> MacTed should now be muted
14:09:08 <manu1> Topic: Implementation Status
14:09:32 <scor> niklasl: re. my own implementation, it passes all regular tests
14:09:47 <scor> ... adapted it to the Jena interface
14:09:51 <manu1> https://github.com/niklasl/clj-rdfa
14:10:20 <scor> ... solves 1) easy to adapt to any other framework, 2) can use Jena reasoner to use vocabulary expansion
14:10:46 <scor> manu1: very good work, will help people using java to parse RDFa
14:11:14 <gkellogg> Current EARL report: http://rdfa.info/earl-reports/
14:11:17 <Zakim> +??P0
14:11:26 <scor> manu1: we have 3 three fully compliant RDFa 1.1 implementations: Gregg's, Ivan's and Niklas'
14:11:30 <ShaneM> zakim, ??P0 is ShaneM
14:11:30 <Zakim> +ShaneM; got it
14:12:06 <scor> gkellogg: some tests have been added since the last EARL report. I believe the three parsers are still passing all tests
14:12:25 <scor> gkellogg: only gkellogg's and Ivan's are passing vocab expansion
14:12:38 <scor> niklasl: should have the vocab expansion working by the end of the month
14:13:06 <scor> manu1: been working on librdfa - taking longer due to the lack of pure C libs
14:13:26 <scor> ... trying to keep memory usage as low as possible
14:14:04 <scor> gkellogg: interested to see how fast it performs compared to the clojure implementation
14:14:15 <scor> manu1: librdfa is well underway
14:14:36 <scor> ShaneM: planning to have my implementation done by the end of the month but not sure I'll make it
14:16:03 <scor> manu1: spoke with Lin Clark - there isn't a good PHP implementation of RDFa 1.1 and that could affect Drupal 8. We need to focus on getting a PHP implementation ready after RDFa 1.1 hits REC.
14:18:29 <Zakim> -niklasl
14:19:20 <MacTed> Zakim, unmute me
14:19:20 <Zakim> MacTed should no longer be muted
14:22:40 <niklasl> niklasl has joined #rdfa
14:23:51 <Zakim> +??P30
14:23:54 <scor> gkellogg: Someone came forward with questions on javascript
14:23:59 <niklasl> zakim, I am ??P30
14:23:59 <Zakim> +niklasl; got it
14:24:09 <scor> gkellogg: possibly a js implementation on the way
14:24:16 <manu1> Topic: ISSUE-133: Processing step bug for [typed resource]
14:24:26 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/133
14:25:05 <scor> gkellogg: overview: one of the changes we made was typeof being magnetic to about or other properties
14:25:10 <scor> ... but we forgot to add a step in the spec that brings it inline with the prose in the spec.
14:25:28 <manu1> Gregg's proposal: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Mar/0020.html
14:26:22 <scor> manu1: I agree with gkellogg on the processing rule bug and his proposal to fix it.
14:26:24 <scor> gkellogg: Ivan suggested a slightly different wording and put it in a version of the spec on his machine, pending the decision of the WG
14:26:26 <gkellogg> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Mar/0031.html
14:27:14 <niklasl> q+
14:27:15 <scor> manu1: does anyone believe this is a substantive change?
14:27:19 <manu1> ack niklasl
14:27:37 <scor> niklasl: I don't think so, if I recall correctly, this is what RDFa 1.0 does
14:27:39 <scor> gkellogg: yes
14:27:59 <ivan> chiming in: this fix to the processing rules is addressing an inconsistency in the specification
14:28:38 <gkellogg> Proposed changes from Ivan: 
14:28:39 <gkellogg> - the case when everything happens on the root element, described in the first part of 5.1, should also be included
14:28:40 <gkellogg> - the last step of 5.1, ie, setting the current object resource, should not happen in this case. @about attracts ('absorbs') the @typeof and @property should be used with the textual outcome. Editorially, what I did was to take the current bulleted items one level deeper in the bulleted items
14:29:14 <gkellogg> q+
14:29:57 <manu1> ack gkellogg
14:30:09 <ivan> zakim, dial ivan-voip
14:30:09 <Zakim> ok, ivan; the call is being made
14:30:10 <Zakim> +Ivan
14:30:33 <scor> gkellogg: the fact it's been there for so long indicates it is not a substantive change, since the test suite has always been consistent
14:31:47 <scor> ivan: these is an inconsistency in the document, the prose is inconsistent with the steps, though all tests were correct from the beginning
14:31:55 <scor> s/these/there
14:32:15 <Steven_> Steven_ has joined #rdfa
14:32:47 <manu1> PROPOSAL: Fix the inconsistency in the RDFa Core 1.1 processing rules regarding @typeof and @about usage by adopting language that effectively achieves what Gregg has proposed.
14:32:59 <ivan> +1
14:33:02 <niklasl> +1
14:33:02 <gkellogg> +1
14:33:03 <manu1> +1
14:33:07 <ShaneM> +1
14:33:08 <scor> scor: +1
14:33:10 <Steven> +1
14:33:22 <MacTed> PROPOSAL: Fix the inconsistency in the RDFa Core 1.1 between processing rules and explanatory text regarding @typeof and @about usage by adopting language that effectively achieves what Gregg has proposed.
14:33:27 <scor> q+
14:34:06 <manu1> ack scor
14:34:24 <manu1> scor: Clarification - to our knowledge, there is no library that implemented the mistake in the processing steps, right? 
14:34:27 <manu1> Ivan: That's correct.
14:34:32 <manu1> manu: Yes.
14:35:03 <niklasl> +1
14:35:03 <gkellogg> +1
14:35:04 <manu1> +1
14:35:04 <MacTed> +1
14:35:07 <scor> scor: +1
14:35:08 <ShaneM> +1
14:35:11 <ivan> +1
14:35:13 <Steven> +1
14:35:17 <manu1> RESOLVED: Fix the inconsistency in the RDFa Core 1.1 between processing rules and explanatory text regarding @typeof and @about usage by adopting language that effectively achieves what Gregg has proposed.
14:35:59 <scor> ivan: I have made the changes already but only locally. I'd appreciate if someone could look at the text before I commit
14:36:23 <scor> gkellogg: ok, I'll do that
14:36:20 <manu1> Topic: Responses to Henri Sivonen
14:36:29 <manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Mar/0081.html
14:36:36 <manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Mar/0082.html
14:37:24 <scor> manu1: the overall agreement we came to for ISSUE-130 and ISSUE-132 is that it's up to the host language to decide how RDFa is integrated in that host language - this has always been the case.
14:37:35 <scor> ... Henri has both agreed with some of the changes and disagreed with other ones.
14:37:42 <scor> ... I think my response to him was not clear enough regarding where the substantive changes were made (HTML+RDFa) and where the non-substantive changes were made (RDFa Core).
14:38:08 <scor> ... there were substantive changes, but these applied to HTML5+RDFa, specifically
14:38:26 <scor> ... but the changes we made to Core were not substantive, they just clarified what was already understood.
14:38:42 <scor> ... we put the word "optional" beside the @src attribute to make it more clear, thus, no substantive change.
14:39:26 <scor> ... does anybody believe that we made a substantive change to RDFa Core in either ISSUE-130 or ISSUE-132?
14:40:09 <scor> niklasl: there was not actionable outcome due to this change, in the spec, so no. My processor didn't change at all.
14:40:09 <scor> Discussion and agreement that no substantive change was made to RDFa Core 1.1 and XHTML+RDFa 1.1 based based on the outcome to ISSUE-132 and ISSUE-130. Agreement that substantive changes were made to HTML+RDFa 1.1 and that it will require another Last Call.
14:49:08 <scor> manu1: Henri doesn't agree with the use of @rel and @rev everywhere. The group felt this was necessary to reduce divergence between XHTML+RDFa and HTML+RDFa and also because @rel and @rev exists in HTML markup today.
14:49:08 <scor> manu1: Going through Henri's responses one by one to make sure we covered everything...
14:49:35 <scor> manu1: He agrees with our changes to the spec text based on the resolution to ISSUE-132. He disagrees that it was not a substantive change. The Working Group disagrees with Henri that it was a substantive change to RDFa Core 1.1 and notes three things: 1) That RDFa Core does not talk about what the content model of other languages should be, that is up to the Host Language, 2) @src has always been an optional attribute and was placed into the RDFa 1.0 specification because it was targeted at XHTML1, once it was split out into Core, @src became an optional attribute for the Host Language to include if it deemed appropriate, and 3) a substantive change was made to HTML+RDFa to only allow @href and @src on elements where it was already allowed by HTML5.
14:49:55 <scor> manu1: Regarding ISSUE-130, he agrees that it should be up to the Host Language to specify which RDFa attributes to support and where. He disagrees that @rel and @rev should be allowed everywhere from a legacy RDFa 1.0 document conformance standpoint, although it seems that he would be okay with the processor rules not changing. He agrees with the @src and @href change to HTML+RDFa, but did not see spec text that achieves this. This is on my plate and I will make sure it gets into the HTML+RDFa specification. He disagrees that the use of @rel and @rev everywhere cannot be removed without cutting two of the more useful features of RDFa - namely forward chaining and reverse chaining. Doing so would unnecessarily limit the flexibility of the language. It is not clear why he disagrees, but the WG feels that removing @rel and @rev everywhere would 1) make it impossible to express certain types of markup patterns, as previously explained, from being expressible and 2) lead to a needless difference between XHTML+RDFa and HTML+RDFa. So, the Working Group still feels that @rel and @rev should still be allowed everywhere in HTML+RDFa and disagrees with Henri. Finally, Henri disagrees that these changes were not substantive. We should clarify that the group feels that the changes were substantive for the HTML+RDFa specification, but were not substantive to RDFa Core.
14:50:14 <manu1> PROPOSAL: Regarding ISSUE-130 and ISSUE-132, the Working Group agrees that substantive changes were made to the HTML+RDFa specification. Substantive changes were NOT made to the RDFa Core specification.
14:50:25 <gkellogg> +1
14:50:26 <manu1> +1
14:50:27 <scor> scor: +1
14:50:28 <ivan> +1
14:50:31 <niklasl> +1
14:50:33 <Steven> +1
14:50:37 <ShaneM> +1
14:50:38 <MacTed> +1
14:50:45 <manu1> RESOLVED: Regarding ISSUE-130 and ISSUE-132, the Working Group agrees that substantive changes were made to the HTML+RDFa specification. Substantive changes were NOT made to the RDFa Core specification.
14:51:07 <manu1> Topic: xhv:license vs. cc:license
14:52:33 <scor> ivan: users of RDFa would expect the cc:license when using license in HTML, not the xhv:license
14:53:09 <manu1> q+
14:53:11 <scor> .. if we change to cc: we have to change the tests and a backward incompatibility
14:53:34 <niklasl> q+
14:53:52 <scor> manu1: I agree with you, but I'm concerned it would have a disruptive effect in the short term (though a good change in the long term)
14:53:55 <scor> q+
14:54:53 <manu1> ack manu1
14:54:59 <manu1> scor: Want me to crawl the data?
14:55:13 <manu1> manu1: That would be useful - to figure out which is used more - although, we shouldn't read too much into that.
14:55:17 <ShaneM> I am stuck on this call, but my opinion is that we should use xvh:license and that it should resolve to cc:license.  I think.
14:55:18 <manu1> ack niklasl
14:55:36 <gkellogg> q+ can we add owl:sameAs to vocab doc?
14:55:53 <scor> niklasl: I agree with ivan but wonder if that change is necessary - maybe best for people to be explicit and use a prefix
14:56:04 <manu1> ack scor
14:56:12 <manu1> scor: Would it be possible to generate two triples?
14:56:23 <manu1> Ivan: Not without changing the processing rules. I don't think we should go there.
14:56:57 <scor> ivan: Gregg, do we have a vocabulary document?
14:57:00 <scor> gkellogg: no
14:57:33 <gkellogg> q+
14:58:14 <scor> gkellogg: we discussed the in November: were there not some consideration about using xhv in XHTML and not in Core?
14:58:37 <scor> manu1: that would bring some inconsistencies between the triples generated depending on the host language
14:59:00 <scor> ivan: you are right, we don't have this split, best not to have it
14:59:14 <manu1> PROPOSAL: The "license" term should continue to point to the xhv:license URL.
14:59:18 <ivan> +1
14:59:19 <niklasl> +1
14:59:20 <manu1> +1
14:59:21 <scor> scor: +1
14:59:23 <gkellogg> +0
14:59:38 <Steven> +1
14:59:39 <MacTed> +1
14:59:39 <ShaneM> +1
14:59:54 <manu1> RESOLVED: The "license" term should continue to point to the xhv:license URL.
15:01:28 <manu1> Topic: Proposed Recommendation Preparation
15:01:25 <scor> manu1: Ivan, what do we need to do for the next phase for Proposed Recommendation?
15:01:35 <Zakim> -Steven
15:01:41 <Zakim> -ShaneM
15:02:15 <manu1> Ivan: We need to get the implementation report together, which we pretty much have with the EARL reports.
15:02:27 <manu1> Ivan: We have enough implementations to go to PR right now, which is great.
15:02:38 <scor> ivan: We may want to list partial implementations, like any23
15:02:49 <Zakim> -MacTed
15:03:12 <manu1> Ivan: I am not worried about meeting PR... to meet transition we need member votes. WBS form going out to AC - yes/no for RDFa 1.1. We need to talk with organizations and see if they intend to vote on RDFa.
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000213