Chatlog 2011-09-15

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

13:12:26 <RRSAgent> RRSAgent has joined #rdfa
13:12:26 <RRSAgent> logging to http://www.w3.org/2011/09/15-rdfa-irc
13:12:28 <trackbot> RRSAgent, make logs world
13:12:28 <Zakim> Zakim has joined #rdfa
13:12:30 <trackbot> Zakim, this will be 7332
13:12:30 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 48 minutes
13:12:31 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:12:31 <trackbot> Date: 15 September 2011
13:13:19 <ivan> ivan has changed the topic to: Meeting Agenda, Sept. 15: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Sep/0067.html
13:13:54 <tinkster> tinkster has joined #rdfa
13:19:27 <ShaneM> ShaneM has joined #rdfa
13:19:43 <ShaneM> ShaneM has left #rdfa
13:37:16 <MacTed> MacTed has joined #rdfa
13:45:38 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Sep/0067.html
13:45:42 <manu1> Chair: Manu
13:45:42 <manu1> Guest: Niklas (lindstream) Lindström
13:45:42 <manu1> Guest: Toby (tinkster) Inkster
13:45:43 <SebastianGermesin> SebastianGermesin has joined #rdfa
13:55:02 <Zakim> SW_RDFa()10:00AM has now started
13:55:09 <Zakim> +??P2
13:55:17 <SebastianGermesin> Zakim, I am P2
13:55:17 <Zakim> sorry, SebastianGermesin, I do not see a party named 'P2'
13:55:30 <SebastianGermesin> Zakim, I am +??P2
13:55:30 <Zakim> sorry, SebastianGermesin, I do not see a party named '+??P2'
13:55:32 <tomayac> tomayac has joined #rdfa
13:55:42 <SebastianGermesin> Zakim, I am ??P2
13:55:42 <Zakim> +SebastianGermesin; got it
13:56:52 <gkellogg> gkellogg has joined #rdfa
13:58:05 <Zakim> +??P6
13:58:09 <manu1> zakim, I am ??P6
13:58:09 <Zakim> +manu1; got it
13:58:39 <Zakim> +??P9
13:58:47 <gkellogg> zakim, I am ??P9
13:58:47 <Zakim> +gkellogg; got it
13:59:30 <lindstream> lindstream has joined #rdfa
13:59:40 <ivan> zakim, dial ivan-voip
13:59:40 <Zakim> ok, ivan; the call is being made
13:59:41 <Zakim> +Ivan
14:00:27 <ShaneM> ShaneM has joined #rdfa
14:00:37 <Zakim> +OpenLink_Software
14:00:42 <MacTed> Zakim, OpenLink_Software is temporarily me
14:00:42 <Zakim> +MacTed; got it
14:00:43 <MacTed> Zakim, mute me
14:00:43 <Zakim> MacTed should now be muted
14:01:39 <Zakim> +??P29
14:01:41 <ShaneM> zakim, I am ??P29
14:01:47 <Zakim> +ShaneM; got it
14:02:07 <Zakim> +aharon
14:03:12 <manu1> zakim, who is on the call?
14:03:29 <Zakim> On the phone I see SebastianGermesin, manu1, gkellogg, Ivan, MacTed (muted), ShaneM, aharon
14:04:02 <Zakim> +??P35
14:04:08 <manu1> scribenick: Manu
14:04:13 <lindstream> zakim, I am ??P35
14:04:24 <manu1> Manu: Any updates/changes to Agenda?
14:04:26 <Zakim> +lindstream; got it
14:04:45 <manu1> Manu: Anything new that's happening that we should be aware of?
14:05:02 <lindstream> zakim, who is on the call?
14:05:02 <manu1> zakim, aharon is tomayac
14:05:03 <Zakim> On the phone I see SebastianGermesin, manu1, gkellogg, Ivan, MacTed (muted), ShaneM, aharon, lindstream
14:05:05 <Zakim> +tomayac; got it
14:06:34 <Zakim> +Steven
14:07:07 <Steven> Steven has joined #rdfa
14:08:39 <manu1> We have received comments from a large industry concerning schema.org and their frustration with the entire launch process.
14:10:43 <manu1> zakim, who is on the call?
14:10:43 <Zakim> On the phone I see SebastianGermesin, manu1, gkellogg, Ivan, MacTed (muted), ShaneM, tomayac, lindstream, Steven
14:10:58 <Zakim> + +20592aaaa
14:11:08 <Steven> zakim, aaaa is me
14:11:08 <Zakim> +Steven; got it
14:11:39 <manu1> Topic: ISSUE-106: Ordered Lists
14:11:48 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/106
14:12:24 <Zakim> -Steven
14:12:24 <manu1> Ivan: We had a discussion last week - we didn't feel like doing a formal resolution. I sent out an e-mail to the mailing list asking if there was general support.
14:12:40 <manu1> Ivan: I think we could have a formal resolution that the group in principle wants to have ordered list syntax.
14:13:03 <manu1> Ivan: What exactly it should look like is a separate issue. There has been some technical discussion - outlined on the wiki.
14:13:06 <scor> scor has joined #rdfa
14:13:15 <Zakim> +scor
14:13:23 <manu1> Ivan: Gregg's implementation notes describe how to change the processing rules to include list support.
14:13:42 <manu1> Ivan: We should treat those two things separately.
14:14:17 <manu1> Manu: Any concerns about list support in RDFa?
14:14:25 <manu1> Steven: What about backwards compatibility?
14:14:41 <lindstream> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Sep/0068.html
14:14:42 <gkellogg> Link to List description: http://www.w3.org/2010/02/rdfa/wiki/Lists
14:14:55 <manu1> Ivan: With the new version, order may generate different triples from RDFa 1.0
14:15:27 <manu1> Steven: Not against lists - just concerned about backwards compatibility.
14:16:27 <lindstream> q+
14:16:50 <manu1> Manu: Are lists absolutely required? Gregg seems to be the only person with a pretty solid use case.
14:16:59 <tomayac> ordered lists can be useful for modeling events => e.g. lineups of festivals
14:17:07 <manu1> Ivan: It's not that something cannot be achieved w/o them... it's that lists are absolutely awful to do in RDFa 1.0.
14:17:37 <manu1> Ivan: Bibliographic data - article lists, library catalog, anything like that - co-authors order is very important.
14:17:43 <lindstream> ... bibo:authorList
14:18:09 <manu1> q+ to ask about how we access lists in RDF.
14:18:13 <manu1> ack lindstream
14:18:26 <MacTed> order is important in other credits also -- e.g., movie credits, play and other performer billing order
14:18:28 <gkellogg> q+
14:18:32 <manu1> lindstream: The final use case is for OWL constructs - unionOf in range... we should have support for lists.
14:18:35 <manu1> ack manu1
14:18:35 <Zakim> manu1, you wanted to ask about how we access lists in RDF.
14:19:09 <ivan> q+
14:19:26 <manu1> ack gkellogg
14:19:42 <manu1> Manu: I'm not convinced that this is going to help people - RDF lists are /very/ difficult to work with.
14:19:49 <MacTed> q+
14:19:56 <MacTed> Zakim, unmute me
14:19:56 <Zakim> MacTed should no longer be muted
14:19:57 <lindstream> q+ to mention list problems
14:20:38 <manu1> Gregg: schema.org is difficult w/o lists... linked list concept is very difficult... SPARQL deals w/ lists more intelligently. Also, I think people that do stuff w/ HTML expect document order. Complains people have about RDFa don't relate to processing steps... they relate to the complex rules of markup.
14:20:44 <manu1> ack ivan
14:20:46 <ivan> q-
14:20:49 <manu1> ack MacTed
14:21:32 <manu1> MacTed: Difficulty in current use does not stand against something that makes later use better. People don't use ordered lists right now because they're a nightmare. If we make it easier to markup, more people will use them.
14:21:39 <manu1> q+ to ask about SAX-based processors.
14:21:47 <MacTed> Zakim, mute me
14:21:47 <Zakim> MacTed should now be muted
14:21:51 <manu1> ack lindstream
14:21:51 <Zakim> lindstream, you wanted to mention list problems
14:22:56 <manu1> lindstream: There is a conceptual problem w/ lists in graph information theory - lists in JSON don't necessarily indicate order - the way the order is derived is not apparent. Most things are not naturally ordered, we use ordering based on the predicates in a set - ordering alphabetically or by date. There is a very distinct use of sets in RDF and the use of lists in RDF.
14:23:18 <manu1> lindstream: This is not apparent to users. I support lists, but we should add something about this conceptual difference between sets and lists.
14:23:20 <manu1> ack manu1
14:23:21 <Zakim> manu1, you wanted to ask about SAX-based processors.
14:23:47 <manu1> Manu: What state has to be stored? Does it work well with SAX-based processors?
14:25:01 <manu1> Gregg: There is extra state that is stored in the evaluation context... it could be passed through an incomplete triple mapping. Ivan's mechanism doesn't require that. State transfer is not particularly difficult to implement. The current algorithm is tail-recursive - this new version has a step after the tail-recursive mechanism. You may generate a list after the tail-recursive mechanism.
14:25:07 <ivan> q+
14:25:22 <manu1> Gregg: I found it more convenient to explain it like I did. It could be done in another way.
14:25:25 <manu1> ack Ivan
14:26:13 <manu1> Ivan: I did not think through the whole thing in this sense. I agree w/ Gregg. The way the algorithm is described now is pretty clear. You could pile everything up as you go. You don't need this last step at every element. At end of processing, you could generate the list triples. That may be better for a SAX-based implementation.
14:26:15 <manu1> q+
14:26:17 <manu1> ack manu1
14:26:21 <ivan> ack manu1 
14:27:11 <manu1> Manu: I'm just concerned about the size of the state information and that we don't have to jump around the DOM.
14:27:25 <manu1> Ivan: We're not talking about a large amount of data here... just small elements of the page.
14:27:50 <tomayac> FWIW, I'm pro adding ordered lists
14:28:08 <manu1> PROPOSAL: Add ordered list support to RDFa 1.1.
14:28:12 <gkellogg> +1
14:28:13 <manu1> Manu: +1
14:28:13 <tomayac> +1
14:28:13 <ivan> +1
14:28:13 <MacTed> +1
14:28:14 <lindstream> This is what we generate - rdf:List using rdf:first, rdf:next, rdf:nil
14:28:15 <lindstream> +1
14:28:17 <SebastianGermesin> +1
14:28:17 <ShaneM> +1
14:28:19 <scor> +1
14:28:24 <Zakim> -tomayac
14:28:27 <Steven> +1
14:28:32 <manu1> RESOLVED: Add ordered list support to RDFa 1.1.
14:28:52 <manu1> Manu: Do we want to have the technical discussion on the call today?
14:29:12 <manu1> Ivan: We already had technical discussion on the list - Gregg's algorithm already has 2 independent implementations.
14:29:24 <manu1> Ivan: Why don't we go w/ Gregg's proposal and see what the community says?
14:30:08 <ivan> q+
14:30:08 <manu1> Ivan: Gregg's implementation is the minimal syntax addition that we'd need to support lists - let's just go with that.
14:30:15 <manu1> ack ivan
14:30:51 <manu1> Ivan: The current one, from a user point of view - it's pretty simple. You just add something simple "member". The more serious issue is the backwards compatibility issue.
14:31:13 <manu1> Ivan: The graph that is generated with the new markup will be different from RDFa 1.0 processor.
14:31:18 <lindstream> <> dc:creator (<a> <b> <c>)  VS. <> dc:creator <a>, <b>, <c>
14:31:33 <manu1> Ivan: We need to acknowledge the backwards-compat issue... I think that we could live with it.
14:31:51 <lindstream> q+
14:31:53 <manu1> Ivan: The graph, semantically, is close to the RDFa 1.1 version - I think we can live with this.
14:31:54 <ShaneM> q+ to talk about backward compat
14:32:05 <lindstream> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Sep/0068.html
14:32:15 <manu1> lindstream: I wonder if we should raise separate issues for this?
14:32:30 <manu1> ack lindstream
14:33:22 <manu1> ShaneM: My question is wrt to backward compatibility - don't we have other features that screw w/ RDFa 1.0 - we have @vocab and @prefix... I think we don't have a proper announcement mechanism, we're going to have issues like this. 
14:33:26 <lindstream> .. @version?
14:33:48 <lindstream> q+
14:33:50 <manu1> ShaneM: We have an appendix that tells people how to publish data that works with both RDFa 1.0 and RDFa 1.1 - we could add something to that section.
14:33:54 <manu1> Ivan: I agree with Shane.
14:33:56 <manu1> ack Shanem
14:33:56 <Zakim> ShaneM, you wanted to talk about backward compat
14:33:58 <ivan> ack ShaneM 
14:34:00 <manu1> ack lindstream
14:34:15 <ivan> q+
14:34:17 <manu1> lindstream: I agree w/ Ivan - it's important to notice this, but the effect is fine.
14:34:18 <ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#major-differences-with-rdfa-syntax-1.0
14:34:20 <manu1> ack Ivan
14:34:49 <ivan> onlist
14:35:01 <lindstream> .. or "listitem" or "inlist".
14:35:05 <manu1> Ivan: The first issue that Niklas raised is a small thing - the attribute name that we should use - for historical reasons, we said @member... perhaps we should have @onlist? @onlist seems intuitive?
14:35:06 <ShaneM> I don't really like onlist...
14:35:13 <ShaneM> it's not English
14:35:36 <lindstream> q+
14:35:37 <ShaneM> listitem sounds like a microdata attribute
14:35:41 <manu1> Manu: Don't like @onlist either... @listitem is nice.
14:35:49 <tinkster> @inlist
14:36:21 <ShaneM> listmember
14:36:34 <gkellogg> q+
14:36:39 <manu1> ack lindstream
14:36:46 <manu1> Ivan: I'd like to resolve this soon.
14:37:18 <lindstream> q+
14:37:26 <scor> can't we choose a name now and eventually change it later? (it's just a string replace)
14:37:42 <manu1> Gregg: I think I agree with Ivan - we have discussed this quite a bit, still some details - if there are issues with specific naming, we should proceed with something @onlist or @inlist, and we can change it at a later date. Let's get the processing steps down. Send a message to say that RDFa supports lists.
14:37:44 <manu1> ack gkellogg
14:38:05 <manu1> lindstream: I agree that we should decide on something and carry on - we should remember how we've been criticized for unintuitive names.
14:38:15 <ShaneM> +1 for inlist
14:38:19 <manu1> lindstream: We should decide on something that everybody understands.
14:38:39 <SebastianGermesin> ok
14:38:45 <manu1> Manu: Lots of support for @inlist.
14:38:51 <manu1> ... let's do that.
14:38:58 <manu1> Ivan: What was the 3rd issue?
14:39:35 <manu1> lindstream: Should we support @rel and @property with @member - if nobody else has issues, I have no solution that works with subsequent related problems. Everyone should think about it and we should raise an issue if it becomes a problem.
14:40:03 <manu1> lindstream: One thing that bugs me is that normally this...
14:40:04 <tinkster> As I'm currently not a WG member, I hereby disclaim all trademarks, patents, and other legal and moral rights over the use of @inlist.
14:40:05 <lindstream> inlist="inlist"
14:40:08 <lindstream> inlist=""
14:40:28 <manu1> lindstream: If the last one is the way it will work, I'm fine with it. 
14:40:36 <manu1> Ivan: The processing steps don't care about @inlist attribute.
14:40:44 <ShaneM> in XML inlist="" is legitimate
14:40:47 <manu1> Ivan: They disregard the value.
14:41:20 <ShaneM> q+ to answer Niklas
14:41:29 <manu1> lindstream: I heard that empty attributes should be expressed as checked="checked" ... is that true?
14:41:33 <manu1> ack lindstream
14:41:35 <manu1> ack shanem
14:41:35 <Zakim> ShaneM, you wanted to answer Nicklaus
14:41:53 <manu1> ShaneM: The reason XHTML did checked="checked" is because SGML did that...
14:42:08 <manu1> ShaneM: There is no rule in XML for it and there is no rule in M12N for it.
14:42:25 <manu1> Niklas: Ok, that works for me.
14:42:26 <gkellogg> q+
14:42:30 <manu1> Manu: So, what's the guidance.
14:42:35 <ShaneM> #IMPLIED
14:42:51 <manu1> ShaneM: It's value is #IMPLIED - it has no value list... "" is perfectly legitimate.
14:43:16 <manu1> Manu: So in HTML5 it'll be inlist
14:43:48 <manu1> ShaneM: And in XHTML it'll be inlist=""
14:44:17 <manu1> Gregg: This is just like @typeof... which doesn't need to have a value. With respect to the test suite, we should do inlist=""
14:44:32 <manu1> Gregg: I think we can leave it off in practice, but we should not promote it.
14:44:54 <gkellogg> Wiki at http://www.w3.org/2010/02/rdfa/wiki/Lists
14:45:40 <gkellogg> Actually, the second part of that Wiki
14:46:02 <manu1> PROPOSAL: Adopt Gregg's List proposal at http://www.w3.org/2010/02/rdfa/wiki/Lists with the list-triggering attribute as @inlist.
14:46:07 <gkellogg> +1
14:46:07 <ShaneM> +1
14:46:08 <lindstream> +1
14:46:09 <manu1> Manu: +0 Only because I haven't had time to review it.
14:46:09 <MacTed> +1
14:46:10 <Steven> +1
14:46:12 <ivan> +1
14:46:45 <SebastianGermesin> +1
14:46:53 <scor> +1
14:47:07 <manu1> RESOLVED: Adopt Gregg's List proposal at http://www.w3.org/2010/02/rdfa/wiki/Lists with the list-triggering attribute as @inlist.
14:47:43 <ShaneM> Ivan Rocks
14:48:08 <gkellogg> I'll add examples to the test suite
14:48:15 <manu1> Ivan: I have just committed the source version - it's in the spec. Shane still has to verify that it's valid text. I also updated the Primer to have an example.
14:48:19 <lindstream> Cool!
14:48:40 <manu1> Ivan: We should send a formal reply to Jeni.
14:49:02 <ShaneM> Note - I went through and cleared out my old action items that were complete.  everyone should do this
14:49:05 <manu1> ACTION: Manu to respond to Jeni about ISSUE-106 - that we added ordered list support to RDFa 1.1
14:49:05 <trackbot> Created ACTION-94 - Respond to Jeni about ISSUE-106 - that we added ordered list support to RDFa 1.1 [on Manu Sporny - due 2011-09-22].
14:49:21 <manu1> Topic: ISSUE-107: @src attribute as object
14:49:29 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/107
14:49:54 <manu1> Ivan: This came up via Jeni and earlier with people realizing that @src creates a lot of problems in practice. 
14:50:15 <manu1> Ivan: From a technical point of view, @src would behave exactly like @href and @resource... and not like @about.
14:50:46 <manu1> Ivan: Doing that in terms of changing the processing steps is very easy - 5 minutes of work.
14:51:55 <manu1> Ivan: This is clearly a break in backwards compatibility - I sent around an e-mail asking if this would create a problem for people. I asked both Mark and Ben to comment, since they supported this the most strongly. All answers were that they agree with the change. The only thing that did come up show a number of tutorial that show how to use @src as @about - which is not good, but those...
14:51:57 <manu1> ...tutorials can change.
14:52:08 <manu1> Ivan: unfortunately, I don't know if the charter allows us to make this change.
14:52:55 <manu1> Ivan: I propose that we discuss whether we agree to make this change - in case we agree, we don't implement it in the document, but we can go back to W3C Process Guardians to see if they have a major problem with this change and we'll go from there.
14:53:11 <lindstream> q+
14:53:21 <manu1> ack gkellogg
14:53:24 <manu1> ack lindstream
14:53:31 <manu1> Manu: Any objections to changing @src to behave like @href?
14:53:39 <manu1> lindstream: I'm very supportive of this change.
14:54:01 <manu1> lindstream: I'm a bit wary of some kind of hidden usage somewhere that may bite us - we should monitor the effects on the community.
14:54:13 <ivan> Charter says: 
14:54:16 <ivan> Backwards compatibility with RDFa 1.0 is of great importance. That means, in general, that all triples that are produced via the October 2008 version of RDFa, should still be generated in the new version. For each new feature, if there is doubt or a perceived problem with respect to this, the guideline should be to not include the feature in the set of modifications. The only minor feature the Working Group has identified and which may constitute a possible exceptio
14:54:17 <ivan> to this rule, is the default XML Literal generation.
14:55:03 <manu1> Ivan: What worries me is the charter text - we may break the charter with this change.
14:55:16 <lindstream> q+ to ask about @version
14:56:14 <manu1> Manu: We should not allow the charter to block a good technical improvement.
14:56:19 <manu1> ack lindstream
14:56:19 <Zakim> lindstream, you wanted to ask about @version
14:56:26 <lindstream> version="XHTML+RDFa 1.0"
14:56:32 <Steven_> Steven_ has joined #rdfa
14:56:33 <lindstream> version="XHTML+RDFa 1.1"
14:56:58 <manu1> lindstream: Could we leverage that and say that @src is interpreted as @href if the @version is not given or is version="XHTML+RDFa 1.1"
14:57:23 <lindstream> you mean HTML*
14:57:24 <lindstream> ;)
14:58:05 <lindstream> http://www.w3.org/TR/rdfa-syntax/#docconf
14:59:19 <manu1> Manu: Couldn't we do that - if you have version="XHTML+RDFa 1.0" - @src is interpreted as it always has been... if it's not specified, or if it is 1.1, then use the new processing rules for @src.
15:00:05 <manu1> PROPOSAL: Change @src in RDFa 1.1 such that it is interpreted like @href and @resource (that is, it specifies an object).
15:00:07 <manu1> Manu: +1
15:00:10 <gkellogg> +1
15:00:13 <ShaneM> +1
15:00:14 <lindstream> +1
15:00:31 <MacTed> +1
15:00:31 <SebastianGermesin> +1
15:00:33 <ivan> +1
15:00:40 <scor> +1
15:00:42 <Steven_> +0 (was against @src as @about in the first place, but now that it's there, hesitant to change it)
15:01:19 <manu1> RESOLVED: Change @src in RDFa 1.1 such that it is interpreted like @href and @resource (that is, it specifies an object).
15:01:55 <manu1> Ivan: I won't be here for next two meetings... schema.org meeting is next week.
15:02:20 <Zakim> -MacTed
15:03:00 <Zakim> -scor
15:03:04 <Zakim> -ShaneM
15:03:38 <Zakim> -SebastianGermesin
15:03:40 <Zakim> -manu1
15:03:44 <Zakim> -gkellogg
15:03:46 <Zakim> -lindstream
15:04:06 <Zakim> -Ivan
15:04:08 <Zakim> SW_RDFa()10:00AM has ended
15:04:12 <Zakim> Attendees were SebastianGermesin, manu1, gkellogg, Ivan, MacTed, ShaneM, lindstream, tomayac, Steven, +20592aaaa, scor
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000299