14:03:18 <RRSAgent> RRSAgent has joined #rdfa
14:03:18 <RRSAgent> logging to http://www.w3.org/2011/10/27-rdfa-irc
14:03:21 <gkellogg> zakim, I am ??P11 
14:03:22 <Zakim> +gkellogg; got it
14:03:41 <Zakim> +Steven
14:04:43 <Zakim> +scor
14:05:13 <manu1> zakim, who is on the call?
14:05:17 <Zakim> On the phone I see ShaneM, gkellogg, manu1, niklasl, Steven, scor
14:05:46 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Oct/0115.html
14:06:56 <Steven> did I get dropped?
14:07:11 <manu1> scribenick: gkellogg
14:07:34 <manu1> Topic: RDFa Lite 1.1 as Editors Draft?
14:07:42 <manu1> http://manu.sporny.org/rdfa/lite/
14:07:43 <Steven> Sorry. I'll redial. ANyway, what I was saying is that I have builders in the house, so I can't guarantee that I will be available for every minuite, so scribing is a bad idea for me today
14:07:50 <Zakim> -Steven
14:08:46 <Zakim> +Steven
14:10:38 <gkellogg> manu: do we want to publish RDFa 1.1 Lite as an Editor's Draft to signal to the broader community that we're working on it.
14:11:09 <gkellogg> … they way it's written is as a subset of RDFa 1.1, but re-written in a way to seem simpler.
14:11:21 <niklasl> q+
14:11:27 <manu1> ack niklasl
14:11:56 <gkellogg> niklasl: seems like a good idea. Like the insight that people can be overwhelmed by reading a full spec.
14:12:13 <ShaneM> q+ to ask about conformance requirements
14:12:35 <gkellogg> manu: over the years, people have asked for a simpler cheat-sheet, but we've said it's not the W3C's job, but that of other sites. But W3C's getting more and more such demands.
14:12:37 <manu1> ack shanem
14:12:37 <Zakim> ShaneM, you wanted to ask about conformance requirements
14:13:09 <gkellogg> shanem: want to be sure of conformance requirements. The doc reads like a rec-track spec, but in my mind a conforming processor must support all of RDFa 1.1
14:13:50 <manu1> gkellogg: I don't think Facebook/Google quite care about the conformance aspect?
14:14:18 <gkellogg> scor: even if there is a full spec, Google and Facebook will only implement what they need, and we can't force them to. Publishing RDFa Lite won't make a difference.
14:14:33 <niklasl> q+ to ask about partial implementation
14:14:39 <gkellogg> … an extra document needs more work, but it seems like it's pretty close to being ready.
14:14:43 <manu1> q+ to talk about the size of the RDFa Lite document
14:14:48 <manu1> ack niklasl
14:14:48 <Zakim> niklasl, you wanted to ask about partial implementation
14:15:37 <gkellogg> niklasl: agree that it shouldn't be a spec indicating that implementing a subset is acceptable. It might be interesting to see if there is some amount of detail that is required, so that people implementing a subset might be on reasonable ground.
14:15:47 <Zakim> -manu1
14:16:12 <gkellogg> … important that they support chaining. wonder's if there is some way to write it so that we can give advice to subset implementations. "a scheming parser"
14:16:14 <Zakim> +manu1
14:16:31 <niklasl> s/scheming/skimming/
14:17:06 <gkellogg> manu: don't know if we can write a spec in that way. If Google only implements half the spec, they should understand that they could mess something up.
14:17:19 <gkellogg> … don't need to call out in the spec, but may broadcast on the mailing list.
14:17:36 <gkellogg> … nothing we can really do to require them to do a complete implementation.
14:18:08 <gkellogg> … Google's main issue right now is in the complexity of authoring, not in their ability to parse. They care about simplified markup for authors more then implementation.
14:18:13 <gkellogg> … don
14:18:13 <gkellogg> '
14:18:23 <niklasl> q+
14:18:27 <gkellogg> manu: don't think we need to say anything more about that.
14:18:44 <gkellogg> … want to keep document about current length, but should probably add some examples.
14:18:45 <manu1> ack manu
14:18:45 <Zakim> manu, you wanted to talk about the size of the RDFa Lite document
14:18:48 <manu1> ack niklasl
14:19:16 <gkellogg> niklasl: we might want to indicate that @rel has more power than is realized.
14:19:16 <manu1> q+ to say we don't need to say everything about RDFa.
14:19:44 <gkellogg> scor: disagree, most people won't care about power. They're go on Google WebMaster/Rich Snippet to get recipes.
14:19:55 <gkellogg> … 98% of web will just follow Google documentation.
14:20:15 <gkellogg> … people who are hard core will read the full spec.
14:20:18 <manu1> ack manu
14:20:18 <Zakim> manu, you wanted to say we don't need to say everything about RDFa.
14:20:46 <gkellogg> manu: agree with score: don't need to go into detail about what you can and can't do with RDFa Lite
14:21:38 <danbri> 16:18 gkellogg: … Google's main issue right now is in the complexity of authoring, not in their ability to parse. They care about simplified markup for authors more then implementation. 
14:21:39 <danbri> yup
14:21:47 <gkellogg> niklasl: Indicating from Lite that more features are available in the full Core spec would probably be adequate.
14:22:09 <danbri> (I've been watching the usability videos made around microdata; simplicity for authors is the main concern. Google know how to parse stuff)
14:22:22 <gkellogg> manu: is this rec-track, or a note? Don't know right now.
14:22:39 <gkellogg> … If Google is really adamant about it being a rec-track, we should figure out how to do it.
14:23:30 <gkellogg> manu: it might be good enough for suggested changes to @property to go into RDFa core.
14:23:50 <niklasl> q+
14:24:05 <manu1> ack niklasl
14:24:43 <gkellogg> nilkasl: If critics have the opinion that @rel is _too_ much power, we still may get objections.
14:25:22 <gkellogg> manu: haven't seen them objecting to the existence of more advanced features, just the use of them.
14:26:21 <gkellogg> scor: it seems that the do pretty good parsing if namespaces are specified. It's definitely more than RDFa Lite. They want to promote it for authors.
14:26:46 <gkellogg> manu: ideal case is that RDFa 1.1 core is completely implemented.
14:27:02 <gkellogg> manu: any opposition to publishing as an editor's draft?
14:27:23 <manu1> PROPOSAL: Publish RDFa Lite 1.1 as an Editors Draft in W3C-space.
14:27:24 <Steven> +1
14:27:25 <manu1> +1
14:27:28 <manu1> scor: +1
14:27:28 <gkellogg> +1
14:27:29 <ShaneM> +1
14:27:36 <niklasl> +1
14:27:42 <ShaneM> note that the space should be rdfa/drafts/2011...
14:27:50 <manu1> RESOLVED: Publish RDFa Lite 1.1 as an Editors Draft in W3C-space.
14:28:02 <manu1> ACTION: Manu to publish RDFa Lite 1.1 as an Editors Draft.
14:28:06 <danbri> yay :)
14:28:27 <manu1> Topic: Gregg's @property proposal
14:28:37 <manu1> http://www.w3.org/2010/02/rdfa/wiki/RDFaLiteWithProperty
14:28:41 <manu1> scribenick: manu1
14:29:04 <manu1> Gregg: I've been working a good bit w/ Microdata  and convergence - got familiar w/ processing rules.
14:29:41 <manu1> Gregg: I use the Microdata API extensively - Microdata can use @itemprop for literals and URIs - in their case, they do it by knowing exactly which HTML attributes matter (href, data, src, etc.)
14:30:18 <manu1> Gregg: My proposal is to have @property do effectively the same thing - if there is an element that has @property and src, href or data, it would generate an IRI ref, otherwise, it would pick up the literal.
14:30:35 <manu1> Gregg: If there is a @rel and @property on the same element, it acts as it does in RDFa 1.0 now
14:31:10 <manu1> Gregg: A separate part of the proposal is to allow chaining via: @about or @typeof + @property - explicit chaining... vs. the implicit chaining in @rel
14:31:56 <Steven> q+
14:32:07 <manu1> Gregg: We could come to a 1-to-1 equivalence w/ RDFa and Microdata with this approach - it gets rid of much of the rationale for Microdata.
14:32:15 <manu1> Steven: This makes RDFa less simple than more simple.
14:32:23 <niklasl> q+ to ask about itemscope
14:32:57 <manu1> Steven: All of a sudden, a different attribute does different things based on context... I like the simplicity of @property and @rel - they do one job and one job well. If there is a 1-to-1 mapping between MD and RDFa, then you could make the counter point - why have RDFa?
14:33:10 <manu1> Gregg: Well, not one to one - RDFa is a strict superset of Microdata.
14:33:42 <manu1> Gregg: If we were to do RDFa again - we'd probably not use @rel.
14:34:09 <manu1> Gregg: Danbri has made the point that people misuse @rel. I've also said that people get confused with @rel when used with @about.
14:34:18 <manu1> ack Steven
14:34:26 <manu1> ack niklasl
14:34:26 <Zakim> niklasl, you wanted to ask about itemscope
14:34:39 <manu1> niklasl: Do you need itemscope for chaining in Microdata?
14:34:41 <manu1> Gregg: yes, you do.
14:34:46 <danbri> (not so much mis-use, as confuse; if I go a few months without writing RDFa, I'm guaranteed to mix the two attributes up)
14:34:51 <manu1> niklasl: Well, that's a difference from this suggestion.
14:35:27 <manu1> Gregg: you could remove itemscope and get the same results - it is a difference, but we don't need itemscope.
14:36:16 <manu1> Gregg: Microdata does have a different processing model - it's not a graph, it produces items. Things aren't coalesced like they are in RDFa. With the processing rules we are functionally equivalent.
14:36:23 <manu1> niklasl: I wasn't thinking of adding itemscope
14:36:45 <manu1> niklasl: One could view this change as more complex - you could argue that it's not as complex in Microdata because you don't need @itemscope.
14:37:06 <manu1> scor: I echo gregg's comment - people get @property and @rel mixed up.
14:38:28 <manu1> manu explains multiple proposals of Gregg
14:43:59 <niklasl> q+
14:46:06 <manu1> ack niklasl
14:46:33 <gkellogg> scor: If we look at the big picture, we should be happy Google's still considering RDfa.
14:46:37 <manu1> Manu: I'm concerned that we make a bunch of semi-complex changes to RDFa and then Google decides to not adopt it anyway.
14:46:56 <gkellogg> … we have the choice of suggesting their changes, or ignore and hope they don't go away.
14:47:29 <gkellogg> niklasl: can they really say they won't support RDFa now?
14:47:43 <gkellogg> manu: Google has the best interest of developers in mind.
14:48:15 <niklasl> q+ on the nature/direction of a smarter @property
14:48:16 <gkellogg> manu: we should do everything we can to address developer concerns.
14:48:40 <gkellogg> … if gkellogg's proposal helps, based on a data analysis, we should move forward.
14:49:16 <gkellogg> … Depends on if Google is committed to adopting RDFa 1.1 Lite, if they want more changes, it needs to be backed up by data, based on markup in the wild.
14:49:37 <danbri> re "I'm concerned that we make a bunch of semi-complex changes to RDFa and then Google decides to not adopt it anyway.", best thing is to get a clear target for review written down asap.  http://manu.sporny.org/rdfa/lite/ is excellent start imho.
14:49:48 <gkellogg> … if we can point to a dataset that would be objectively improved with the @property changes, we should move forward.
14:50:29 <danbri> (for non-google web crawl data, perhaps http://www.commoncrawl.org/ is worth a look? I know nothing beyond having found the link this week...)
14:50:31 <gkellogg> scor: please read hsivonen's email (link?)
14:51:10 <manu1> Henri's e-mail: http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0266.html
14:51:34 <manu1> niklasl: I'm not opposed to the @property change - it does make RDFa more about figuring out what the author means...
14:51:35 <gkellogg> niklasl: it does complicate processing, but it makes @property smarter, which gets closer to user's meaning.
14:51:48 <niklasl> .. <meta property="foaf:homepage" content="http://example.org/about-me">
14:51:51 <manu1> scribenick: gkellogg
14:52:11 <gkellogg> … if it's a good way to go...
14:52:49 <gkellogg> niklasl: if property is made smarter, should we also make @content smarter: figure out if it's a link, date, etc.
14:52:57 <gkellogg> q+
14:53:07 <manu1> ack niklasl
14:53:07 <Zakim> niklasl, you wanted to comment on the nature/direction of a smarter @property
14:53:09 <manu1> ack gkellogg
14:53:58 <manu1> gkellogg: @datetime going away in favor of something else - explicit datatyping of literals is a problem as well - people expect to get it out of their vocabs. There is some chance that you can do a part of that via post-processing.
14:54:24 <manu1> gkellogg: You can't know if it is rdf:XMLLiteral - perhaps having some rules in @content where you do lexical analysis might be useful.
14:54:30 <manu1> q+ to talk about lexical analysis.
14:55:03 <gkellogg> niklasl: argument against implicit processing is the title "1984" as a novel, not a number.
14:55:03 <manu1> niklasl: Lexical analysis in @content would be okay?
14:55:08 <manu1> ack manu
14:55:09 <Zakim> manu, you wanted to talk about lexical analysis.
14:55:45 <gkellogg> manu: previous discussions had a pretty strong feeling against this, and nothing's really changed.
14:56:08 <gkellogg> … these things tend to be application dependent, and the application do do this if they need to.
14:56:47 <gkellogg> … there is a desire for automatic data typing, but it seems to be worth separating this into application specific.
14:57:19 <gkellogg> … considering recipes, e.g., temperatures use different units in different parts of the world.
14:57:29 <niklasl> q+
14:57:41 <gkellogg> … specifying the units in the vocabulary creates problems.
14:58:11 <gkellogg> … we decided before not to do lexical analysis and really shouldn't re-visit.
14:58:22 <manu1> ack niklasl
14:58:53 <niklasl> .. <meta property="og:type" content="recipebox:recipe" /> 
14:58:53 <gkellogg> niklasl: would like to revisit lexical analysis on mailing list.
14:59:24 <gkellogg> … meta processing is an example, as this represents a type, not a string.
15:00:17 <gkellogg> manu: we might want to say about @property, but we could indicate that the group has interest in the change.
15:00:29 <ShaneM> +0
15:00:56 <gkellogg> niklasl: if there's imperial evidence, we should do it, otherwise not.
15:01:22 <manu1> PROPOSAL: If there is empirical evidence that we should support @property applying to @href, and @src if there is no @rel on the element, then we should think very strongly about doing it.
15:01:27 <gkellogg> +1
15:01:29 <manu1> +1
15:01:35 <Steven> +0
15:01:37 <niklasl> +1
15:01:43 <ShaneM> +0
15:02:19 <manu1> scor: +1
15:02:23 <manu1> RESOLVED: If there is empirical evidence that we should support @property applying to @href, and @src if there is no @rel on the element, then we should think very strongly about doing it.
15:03:47 <gkellogg> manu: next week is 1 hour earlier for EU, which is going on DST.
15:03:52 <Zakim> -ShaneM
15:03:56 <Zakim> -Steven
15:03:58 <Zakim> -scor
15:04:02 <Zakim> -manu1
15:04:03 <Zakim> -niklasl
15:04:12 <niklasl> niklasl has left #rdfa
15:04:32 <Zakim> -gkellogg
15:04:33 <Zakim> SW_RDFa()10:00AM has ended
15:04:36 <Zakim> Attendees were manu1, ShaneM, niklasl, gkellogg, Steven, scor
15:05:04 <Steven> Steven has left #rdfa
15:08:52 <Steven> Steven has joined #rdfa
15:15:29 <Steven> Steven has joined #rdfa
15:17:43 <manu1> rrsagent, make logs public
15:50:10 <ShaneM> ShaneM has left #rdfa
17:15:45 <Zakim> Zakim has left #rdfa