Chatlog 2012-11-08

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

15:03:11 <manu> scribenick: manu
15:03:11 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Nov/0001.html
15:03:43 <scor> scor has joined #rdfa
15:05:48 <niklasl> q+
15:05:54 <manu> guest: Ted (MacTed) Thibodeau, OpenLink Software
15:05:54 <manu> manu: Any additions or changes to the Agenda?
15:05:54 <gkellogg> q+
15:05:56 <manu> ack niklasl
15:06:01 <niklasl> Add new test 0312 for @property muting plain @rel: https://github.com/rdfa/rdfa-website/commit/4c4df7c8a0
15:06:45 <manu> niklasl: I added this test, text isn't in Section 3.1 isn't in there yet.
15:06:52 <manu> manu: Yep, I'll add it when we handle all the issues.
15:06:53 <manu> ack gkellogg
15:07:24 <manu> gkellogg: Regarding the the use of prefixes being too sophisticated, it's on the Agenda?
15:07:25 <manu> manu: Yep.
15:07:38 <manu> Topic: Announcements/Concerns/State of RDFa
15:07:45 <gkellogg> q+
15:07:57 <manu> ack gkellogg
15:08:08 <manu> manu: Any updates on Implementations, tools, growth or stagnation?
15:08:19 <scor> https://github.com/njh/easyrdf/tree/rdfa
15:08:27 <manu> gkellogg: Nick Humphrey is making good progress on EasyRDF implementation of RDFa. It's a PHP implementation of RDFa.
15:08:32 <gkellogg> https://github.com/njh/easyrdf/tree/rdfa
15:08:40 <manu> gkellogg: He's passing around 2/3rds of tests at this point... 86%
15:08:51 <manu> gkellogg: He's been doing this less than a week, so this is great.
15:09:01 <manu> scor: We've been missing a good RDFa library for PHP, so this is great news.
15:09:08 <manu> ivan: Any blog post on this yet?
15:09:21 <manu> gkellogg: Just tweets for now.
15:09:24 <gkellogg> https://twitter.com/njh/status/264883295974739970
15:10:13 <ivan> q+
15:11:09 <manu> Manu: We need to be doing a better job on the rdfa.info website - getting schema.org examples on rdfa.info.
15:11:18 <niklasl> q+
15:11:23 <manu> scor: They're in mercurial at W3C.
15:11:24 <manu> ack ivan
15:11:36 <scor> e.g http://dvcs.w3.org/hg/webschema/raw-file/tip/schema.org/drafts/examples/site/testcases/rdfa/sdo_eg_rdfa_1.html
15:11:49 <manu> ivan: It's easy for me to say this because somebody else will have to do it - why don't we put those examples on the Web Platform site?
15:12:01 <niklasl> .. at http://docs.webplatform.org/wiki/Main_Page
15:12:05 <manu> ivan: We should put this stuff on webplatform.org
15:12:40 <manu> ivan: I think it would be bigger visibility there... we can put them up on both sites.
15:12:47 <manu> ack niklasl
15:12:52 <manu> q+ to ask for volunteers.
15:13:25 <niklasl> .. add to the minutes that pyRDFa is merged to RDFLib main
15:14:21 <ShaneM> I am buried
15:15:06 <manu> manu: Any volunteers?
15:15:14 <manu> No volunteers, everybody is swamped.
15:17:04 <manu> scor: We should update the wikipedia page.
15:18:03 <manu> ACTION: Stephane to update the wikipedia page for RDFa
15:18:03 <trackbot> Sorry, couldn't find Stephane. You can review and register nicknames at <http://www.w3.org/2010/02/rdfa/track/users>.
15:19:11 <manu> Topic: ISSUE-126: Can use of xmlns: be reported as an error for HTML5+RDFa 1.1?
15:19:20 <manu> ivan: I had a small discussion with Mike Smith about this issue.
15:19:50 <manu> ivan: We had said last time that use of xmlns: needs to say it's an error in the HTML5 spec.
15:20:09 <manu> ivan: The answer is that, in general, in HTML5 - any attribute usage that is not defined in the HTML5 standard is an error.
15:20:34 <manu> ivan: This will raise an error in the validator. In HTML5, xmlns: has no meaning, it's just a normal attribute (that is unknown)
15:20:34 <Steven> Are you sure it's an error?
15:20:42 <Steven> I thought at best it could be a warning
15:20:53 <manu> Steven - I've got some spec text that I'll point to after Ivan speaks.
15:20:59 <Steven> HTML5 says an unknown attribute is left in the DOM
15:21:02 <manu> ivan: I think we should accept that validators should raise an error, and move on.
15:21:27 <manu> http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#attributes-0
15:22:20 <manu> "No other namespaced attribute can be expressed in the HTML syntax."
15:22:30 <manu> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#attributes
15:23:29 <manu> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility
15:24:07 <manu> manu: Those links demonstrate that foo="blah" is an error. Since xmlns:foo="blah" is viewed the same in HTML5+RDFa, a conformance checker should report that as an error as well.
15:25:28 <gkellogg> q+
15:25:28 <Steven> may
15:25:41 <manu> ack manu
15:25:41 <Zakim> manu, you wanted to ask for volunteers.
15:25:57 <Steven> q+
15:26:17 <manu> ivan: What Mike asked for is that a conformance checker MUST express an error, right?
15:26:41 <manu> gkellogg: My concern with putting MUST in the RDFa spec is that it might not be possible for some implementations to do that, so I'd prefer not to say "MUST"... I'd prefer SHOULD.
15:27:03 <manu> ivan: Mike asked for MUST.
15:27:15 <manu> ack gkellogg
15:27:32 <manu> Steven: The reason Mike asked for this is that they couldn't fix their validator.
15:27:47 <manu> Steven: The question was whether they could fix their validator whether they could allow it in our case.
15:28:04 <manu> Steven: All they wanted was for them to be able to raise it as an error.
15:29:03 <MacTed> Zakim, unmute me
15:29:03 <Zakim> MacTed should no longer be muted
15:29:22 <manu> MacTed: Should allows for them to have a justification... MAY makes it way to lax.
15:29:55 <ShaneM> I agree with Steven on this one.
15:29:59 <ShaneM> May
15:30:02 <Steven> May
15:30:24 <Steven> Just do what he asks for
15:30:33 <gkellogg> should +1, may +0.5
15:30:35 <manu> What do folks want: MAY vs. SHOULD?
15:30:44 <ShaneM> MAY
15:30:46 <manu> should +0.5, may +1
15:30:49 <ivan> same as Gregg (surprise surprise)
15:30:52 <MacTed> SHOULD +1, MAY +0
15:30:54 <niklasl> should +1, may +1 (I don't care)
15:31:05 <scor> MAY
15:31:30 <manu> PROPOSAL: Change the conformance checker section to read "Conformance checkers MAY report the use of xmlns: as an error".
15:31:32 <ivan> +1
15:31:34 <manu> manu: +1
15:31:35 <gkellogg> +1
15:31:36 <ShaneM> +1
15:31:39 <niklasl> +1
15:31:58 <MacTed> +0
15:32:00 <Steven> +1
15:32:10 <scor> +1
15:32:11 <manu> RESOLVED: Change the conformance checker section to read "Conformance checkers MAY report the use of xmlns: as an error".
15:33:03 <manu> Topic: ISSUE-143: Use of prefixes is too complicated for a Web technology
15:33:09 <ivan> issue-143?
15:33:09 <trackbot> ISSUE-143 -- Use of prefixes is too complicated for a Web technology -- open
15:33:09 <trackbot> http://www.w3.org/2010/02/rdfa/track/issues/143
15:34:09 <Steven> I think this is too late
15:34:21 <manu> manu: Tab is requesting that we re-visit the prefix indirection mechanism for RDFa. He is making a slightly different request than what has been made in the past. In the past, we've been asked to drop the prefix-indirection mechanism entirely. He has proposed an alternative proposal now that seems workable /IF/ the data shows that authors and implementations are generating the errors that he says they are. In short, he has two proposals: The first is to drop prefix indirection entirely, the second is to now allow prefixes that are defined in the RDFa Initial Context to be overridden using the prefix-indirection mechanism.
15:36:06 <ivan> q+
15:36:09 <gkellogg> q+
15:36:16 <Steven> q-
15:36:32 <ShaneM> q+ to discuss prefix mappings
15:36:43 <manu> ack ivan
15:37:07 <manu> ivan: My initial reaction to this is that I'd be very uneasy to say that anything in the initial context cannot be overridden. I think the RDFa processor should issue a warning.
15:37:29 <manu> ivan: Issue a warning when people deviate from what's in the initial context. I know this is less than what he asked for, but we should try to address as many of his concerns as possible.
15:37:32 <manu> ack gkellogg
15:38:28 <manu> gkellogg: I was going to agree with Ivan - we can't disallow it because of dublin core - some folks are going to want it to point back to elements. Reporting a warning through the processor graph addresses the concern. It's pretty much equivalent to disallowing it. You could merge the two graphs and construct a query that tells a consumer that a constraint they depend upon is violated.
15:38:38 <manu> gkellogg: That is just as good as not outputting the document at all.
15:38:40 <manu> ack ShaneM
15:38:40 <Zakim> ShaneM, you wanted to discuss prefix mappings
15:40:00 <scor> http://ogp.me/
15:40:24 <manu> ShaneM: You said if this guy has any data and if he brings it up that he should let us know. We may have an existence proof with ogp - they don't notice if you remap the 'ogp' prefix.
15:40:24 <manu> manu: Yes, but that one implementer does it for one prefix is very different from it being a wide-spread problem... plus, Facebook tells authors to declare the prefix in their documentation, so they're not telling their authors to not declare the prefix.
15:40:47 <manu> gkellogg: I think if we add a warning, that that addresses that concern.
15:40:49 <manu> manu: I disagree that it addresses his concern entirely... it may help a bit, but it doesn't get rid of it.
15:40:56 <scor> it's actually quite easy to write such a test and see what the OGP linter says
15:41:23 <scor> https://developers.facebook.com/tools/debug
15:41:38 <scor> manu, I'll do the test after the call
15:42:29 <manu> gkellogg: Can we resolve this with the provision that if new data comes in, we re-open the issue?
15:42:59 <manu> manu: Yes, we can do that.
15:42:51 <manu> ivan: Let's generate a warning and go back to him and see if he is happy with that.
15:43:11 <MacTed> Zakim, mute me
15:43:11 <Zakim> MacTed should now be muted
15:43:29 <manu> manu: I don't think it will address his concern, but it is a positive step toward ensuring that people know when they override the initial context value that it might cause concerns.
15:43:46 <manu> ivan: I don't think we should go as far as allowing the 'dc' value to be overridden.
15:45:23 <manu> PROPOSAL: Remove the prefix-indirection mechanism from HTML5+RDFa 1.1.
15:45:26 <manu> -1
15:45:28 <ivan> -1
15:45:28 <gkellogg> -1
15:45:29 <niklasl> -1
15:45:30 <Steven> -1
15:45:37 <ShaneM> -1
15:46:02 <MacTed> -0
15:47:02 <manu> PROPOSAL: Keep the prefix-indirection mechanism in HTML5+RDFa 1.1.
15:47:04 <manu> manu: +1
15:47:05 <gkellogg> +1
15:47:05 <niklasl> +1
15:47:06 <ivan> +1
15:47:08 <Steven> +1
15:47:10 <ShaneM> +1
15:47:18 <MacTed> +1
15:47:19 <manu> RESOLVED: Keep the prefix-indirection mechanism in HTML5+RDFa 1.1.
15:47:50 <manu> PROPOSAL: Disallow prefixes specified in the RDFa initial context from being overridden in HTML5+RDFa 1.1.
15:47:55 <Steven> -1
15:47:56 <manu> -1
15:47:56 <gkellogg> -1
15:47:57 <ivan> -1
15:47:58 <niklasl> -1
15:48:14 <ShaneM> -1
15:48:42 <manu> PROPOSAL: Allow prefixes specified in the RDFa initial context to be overridden using the prefix-indirection mechanism HTML5+RDFa 1.1.
15:48:44 <manu> manu: +1
15:48:44 <niklasl> +1
15:48:45 <gkellogg> +1
15:48:45 <Steven> +1
15:48:47 <ivan> +1
15:48:48 <manu> +1 (from scor, on the phone)
15:48:48 <ShaneM> +1
15:49:17 <MacTed> +1
15:49:21 <manu> RESOLVED: Allow prefixes specified in the RDFa initial context to be overridden using the prefix-indirection mechanism HTML5+RDFa 1.1.
15:50:49 <manu> PROPOSAL: Generate a warning in the processor graph when a prefix declared in the RDFa initial context is overridden with an IRI that is different from the IRI specified in the RDFa Initial Context.
15:50:51 <manu> manu: +1
15:50:53 <gkellogg> +1
15:50:54 <ivan> +1
15:50:56 <ShaneM> +1
15:50:59 <niklasl> +1
15:51:00 <Steven> +1
15:51:01 <MacTed> +1
15:51:03 <manu> +1 (from scor, on the phone)
15:51:14 <manu> RESOLVED: Generate a warning in the processor graph when a prefix declared in the RDFa initial context is overridden with an IRI that is different from the IRI specified in the RDFa Initial Context.
15:51:19 <Steven> A warning MAY be generated?
15:51:27 <Steven> or SHOULD? or MUST?
15:51:36 <Zakim> -scor
15:52:03 <ShaneM> warnings are already all optional - as is the graph itself.
15:52:05 <manu> ivan: We need to add a new entry to the rdfa vocabulary for this.
15:52:46 <manu> manu: Generating a warning should be a 'SHOULD'
15:53:02 <manu> Topic: ISSUE-144: Add an @itemref-like attribute to RDFa
15:53:02 <ivan> issue-144?
15:53:02 <trackbot> ISSUE-144 -- Add an @itemref-like attribute to RDFa -- open
15:53:02 <trackbot> http://www.w3.org/2010/02/rdfa/track/issues/144
15:53:36 <gkellogg> q+
15:53:39 <niklasl> q+
15:53:43 <manu> manu: Martin Hepp has requested that we reconsider the addition of an @itemref-like attribute for RDFa. He says that @itemref is very helpful when it comes to repetitive data, which is an issue in Good Relations.
15:54:04 <manu> gkellogg: I know we visited this in the past - we elected not to do it for a variety of reasons. I think it would have been good to have Martin's input at the time.
15:54:11 <Steven> I'd like to see an example of what he's talking about.
15:54:12 <ivan> q+
15:54:30 <ivan> ack gkellogg
15:54:58 <manu> gkellogg: There are a number of advantages to this - working with EARL again, lots of duplication there, some sort of @itemref-like mechanism would be good. Martin's use case has a page of products which have all common attributes, but differ on color.
15:55:17 <manu> gkellogg: I think it might be useful, but adding it to HTML5+RDFa is too large of a processing chunk to add as an addendum.
15:55:22 <manu> ack niklasl
15:55:29 <manu> niklasl: I agree with Gregg.
15:56:19 <manu> niklasl: I think that we really need clear explanations for these usecases where @itemref is sorely needed. If you have lots of repetition for items, of course you'll want a @include for that, you can't rely on templating... but you really need to use templates if you're doing something like this. It makes it much easier to read.
15:57:05 <manu> niklasl: It might make a lot of sense that you should model the data in a better way - have a prototypical resource that can be pointed at. That should be very usable in the consumption of the data... this might be construed as an ad-hoc argument to do nothing. Maybe I'm biased.
15:57:36 <manu> niklasl: This is common in bibliographic information as well - all of this makes the data more usable... but the case in Good Relations seems to be that you have noisy data - their usage in the wild.
15:57:48 <manu> niklasl: We need examples before we should explore this further.
15:57:50 <manu> ack ivan
15:58:31 <manu> ivan: One of the reasons why we didn't pursue this back when it came up was that, anecdotally, the feedback that we got was that this was one of the features of Microdata that was very rarely used. We need data to prove that this is a feature in Microdata that is widely used.
15:58:36 <ivan> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Nov/0003.html
15:58:42 <manu> ivan: That being said, I sent this mail a few days ago.
15:59:30 <manu> ivan: I wondered if we do this, how we'd want to do this. I fully agree that touching the processing steps at this point with something like @itemref would be a recipe for disaster, we know it's complicated, adding a new feature leads to weeks of discussions and complex modifications to the processing rules.
15:59:49 <manu> ivan: We rely on RDFa Core, so adding this feature in HTML5+RDFa would be very difficult.
16:00:20 <niklasl> q+
16:00:30 <manu> ivan: However, adding a pre-processing step before the real processing that modifies the DOM tree would be possible. There may be a few cornercases, but if the cornercases exists, we shouldn't do anything. I think this could work, but I haven't implemented it.
16:00:40 <manu> q+ to say I can't implement the pre-processing step.
16:00:49 <manu> ivan: This is as far as I can go with it.
16:00:51 <manu> ack niklasl
16:01:19 <manu> niklasl: There is some merit to that, but I'm a bit wary of pre-processing because you shouldn't mutate input data in JavaScript.
16:01:20 <ShaneM> q+ to point out that dom tree manipulation doesnt really work in a sax processor
16:02:01 <manu> niklasl: I have a bit of a problem with modifying the DOM. We could discuss post-processing the triples as well.
16:02:04 <manu> ack manu
16:02:05 <Zakim> manu, you wanted to say I can't implement the pre-processing step.
16:02:22 <ShaneM> q-
16:02:27 <Zakim> -Steven
16:02:45 <niklasl> .. *or*.. one can use OWL and a full reasoner: https://gist.github.com/4039715 .. but.. well.. ;)
16:03:47 <gkellogg> q+
16:04:11 <manu> manu: I don't really like this feature as a pre-processing step.
16:04:37 <manu> gkellogg: There is a possibility here using entailment - Maybe there are some OWL rules that would allow us to do this type of mix-in?
16:04:38 <niklasl> .. gregg: look at that gist
16:04:47 <niklasl> q+
16:06:14 <manu> niklasl: I think we need to chat with Google, Bing, Yahoo about this...
16:06:21 <manu> q+ to end the telecon
16:06:51 <manu> ivan: We should not touch the processing steps at this point, I was just playing with this pre-processing idea... maybe we want to do post-processing.
16:07:02 <manu> ack gkellogg
16:07:05 <manu> ack niklasl
16:07:21 <manu> niklasl: Dan hinted at the possibility of using modelling - maybe there will be a schema.org prototype property.
16:07:56 <Zakim> -MacTed
16:07:59 <Zakim> -Shane_McCarron
16:08:00 <Zakim> -gkellogg
16:08:01 <Zakim> -??P29
16:08:03 <Zakim> -niklasl
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000271