Chatlog 2011-10-27

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

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:07:11 <manu1> scribenick: gkellogg
14:07:34 <manu1> Topic: RDFa Lite 1.1 as Editors Draft?
14:07:34 <manu1> Guest: Niklas (lindstream) Lindström
14:07:34 <manu1> Guest: Dan (danbri) Brickley
14:07:42 <manu1> http://manu.sporny.org/rdfa/lite/
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> … It's as a subset of RDFa 1.1 - but written in a way to bring out the simplicity of RDFa and make it easily accessible for beginners.
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 introduction, 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, so maybe this can be a trial run.
14:12:37 <manu1> ack shanem
14:12:37 <Zakim> ShaneM, you wanted to ask about conformance requirements
14:13:09 <gkellogg> shanem: We 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:09 <gkellogg> manu1: That is the intent - there is no subset of RDFa 1.1 processors, just a subset of the language that holds together cohesively.
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 in that regard.
14:14:33 <niklasl> q+ to ask about partial implementation
14:14:39 <gkellogg> … an extra RDFa 1.1 Lite 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: I 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. I wonder if there is some way to write it so that we can give advice to subset implementations. "a skimming parser"
14:16:14 <Zakim> +manu1
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:23 <niklasl> q+
14:18:27 <gkellogg> manu: I don't think we need to say anything more about implementing non-conformant processors.
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 snippet recipes.
14:19:55 <gkellogg> … 98% of schema.org implementations 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 stephane - we don't need to go into detail about what you can and can't do with RDFa Lite.
14:21:38 <danbri> Manu said "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." - that is correct.
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? We 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... but changes to RDFa Core 1.1 and a W3C Note about RDFa Lite may be enough.
14:23:50 <niklasl> q+
14:24:05 <manu1> ack niklasl
14:24:43 <gkellogg> niklasl: If critics have the opinion that @rel is _too_ much power, we still may get objections.
14:25:22 <gkellogg> manu: I 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 a pretty good job parsing if prefixes are specified. It's definitely more than RDFa Lite. They want to promote simplicity 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 <scor> +1
14:27:28 <gkellogg> gkellogg: +1
14:27:29 <ShaneM> +1
14:27:36 <niklasl> +1
14:27:42 <ShaneM> Note that the published 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. It adds complexity.
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 each 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 concerned so much about mis-use, as confusion; 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 RDFa doesn't need something like 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 rule changes I'm proposing, however, we are more or less 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 as 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> manu1: Gregg's proposal can really be broken into two parts. The first is allowing @property to apply to @href and @src if @rel isn't on the same element. The second is allowing @property to kick-start chaining, which is a little more controversial.
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:48:16 <gkellogg> scribenick: gkellogg
14:46:56 <gkellogg> … we have the choice of making their changes, or ignoring the changes if there is no data to backup the request for changes.
14:47:29 <gkellogg> niklasl: can they really say they won't support RDFa now?
14:47:43 <gkellogg> manu: We should assume that 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... that should be our focus.
14:48:40 <gkellogg> … if Gregg's proposal helps, based on a data analysis, we should move forward with it.
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 a 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 Henri Sivonen's email about breaking backwards compat based on implementation experience:
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: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 on literal processing 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 does 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 an application specific structure.
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 something about @property, but we could indicate that the group has interest in the change.
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> 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 <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's call 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:50:10 <ShaneM> ShaneM has left #rdfa
17:15:45 <Zakim> Zakim has left #rdfa
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000183