13:12:26 RRSAgent has joined #rdfa 13:12:26 logging to http://www.w3.org/2011/09/15-rdfa-irc 13:12:28 RRSAgent, make logs world 13:12:28 Zakim has joined #rdfa 13:12:30 Zakim, this will be 7332 13:12:30 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 48 minutes 13:12:31 Meeting: RDF Web Applications Working Group Teleconference 13:12:31 Date: 15 September 2011 13:13:19 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 has joined #rdfa 13:19:27 ShaneM has joined #rdfa 13:19:43 ShaneM has left #rdfa 13:37:16 MacTed has joined #rdfa 13:45:38 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Sep/0067.html 13:45:42 Chair: Manu 13:45:43 SebastianGermesin has joined #rdfa 13:55:02 SW_RDFa()10:00AM has now started 13:55:09 +??P2 13:55:17 Zakim, I am P2 13:55:17 sorry, SebastianGermesin, I do not see a party named 'P2' 13:55:30 Zakim, I am +??P2 13:55:30 sorry, SebastianGermesin, I do not see a party named '+??P2' 13:55:32 tomayac has joined #rdfa 13:55:42 Zakim, I am ??P2 13:55:42 +SebastianGermesin; got it 13:56:52 gkellogg has joined #rdfa 13:58:05 +??P6 13:58:09 zakim, I am ??P6 13:58:09 +manu1; got it 13:58:39 +??P9 13:58:47 zakim, I am ??P9 13:58:47 +gkellogg; got it 13:59:30 lindstream has joined #rdfa 13:59:40 zakim, dial ivan-voip 13:59:40 ok, ivan; the call is being made 13:59:41 +Ivan 14:00:27 ShaneM has joined #rdfa 14:00:37 +OpenLink_Software 14:00:42 Zakim, OpenLink_Software is temporarily me 14:00:42 +MacTed; got it 14:00:43 Zakim, mute me 14:00:43 MacTed should now be muted 14:01:39 +??P29 14:01:41 zakim, I am ??P29 14:01:47 +ShaneM; got it 14:02:07 +aharon 14:03:12 zakim, who is on the call? 14:03:29 On the phone I see SebastianGermesin, manu1, gkellogg, Ivan, MacTed (muted), ShaneM, aharon 14:04:02 +??P35 14:04:08 scribenick: Manu 14:04:13 zakim, I am ??P35 14:04:24 Manu: Any updates/changes to Agenda? 14:04:26 +lindstream; got it 14:04:45 Manu: Anything new that's happening that we should be aware of? 14:05:02 zakim, who is on the call? 14:05:02 zakim, aharon is tomayac 14:05:03 On the phone I see SebastianGermesin, manu1, gkellogg, Ivan, MacTed (muted), ShaneM, aharon, lindstream 14:05:05 +tomayac; got it 14:06:34 +Steven 14:07:07 Steven has joined #rdfa 14:08:39 We have received comments from a large industry concerning schema.org and their frustration with the entire launch process. 14:10:43 zakim, who is on the call? 14:10:43 On the phone I see SebastianGermesin, manu1, gkellogg, Ivan, MacTed (muted), ShaneM, tomayac, lindstream, Steven 14:10:58 + +20592aaaa 14:11:08 zakim, aaaa is me 14:11:08 +Steven; got it 14:11:39 Topic: ISSUE-106: Ordered Lists 14:11:48 http://www.w3.org/2010/02/rdfa/track/issues/106 14:12:24 -Steven 14:12:24 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 Ivan: I think we could have a formal resolution that the group in principle wants to have ordered list syntax. 14:13:03 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 has joined #rdfa 14:13:15 +scor 14:13:23 Ivan: Gregg's implementation notes describe how to change the processing rules to include list support. 14:13:42 Ivan: We should treat those two things separately. 14:14:17 Manu: Any concerns about list support in RDFa? 14:14:25 Steven: What about backwards compatibility? 14:14:41 http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Sep/0068.html 14:14:42 Link to List description: http://www.w3.org/2010/02/rdfa/wiki/Lists 14:14:55 Ivan: With the new version, order may generate different triples from RDFa 1.0 14:15:27 Steven: Not against lists - just concerned about backwards compatibility. 14:16:27 q+ 14:16:50 Manu: Are lists absolutely required? Gregg seems to be the only person with a pretty solid use case. 14:16:59 ordered lists can be useful for modeling events => e.g. lineups of festivals 14:17:07 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 Ivan: Bibliographic data - article lists, library catalog, anything like that - co-authors order is very important. 14:17:43 ... bibo:authorList 14:18:09 q+ to ask about how we access lists in RDF. 14:18:13 ack lindstream 14:18:26 order is important in other credits also -- e.g., movie credits, play and other performer billing order 14:18:28 q+ 14:18:32 lindstream: The final use case is for OWL constructs - unionOf in range... we should have support for lists. 14:18:35 ack manu1 14:18:35 manu1, you wanted to ask about how we access lists in RDF. 14:19:09 q+ 14:19:26 ack gkellogg 14:19:42 Manu: I'm not convinced that this is going to help people - RDF lists are /very/ difficult to work with. 14:19:49 q+ 14:19:56 Zakim, unmute me 14:19:56 MacTed should no longer be muted 14:19:57 q+ to mention list problems 14:20:38 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 ack ivan 14:20:46 q- 14:20:49 ack MacTed 14:21:32 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 q+ to ask about SAX-based processors. 14:21:47 Zakim, mute me 14:21:47 MacTed should now be muted 14:21:51 ack lindstream 14:21:51 lindstream, you wanted to mention list problems 14:22:56 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 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 ack manu1 14:23:21 manu1, you wanted to ask about SAX-based processors. 14:23:47 Manu: What state has to be stored? Does it work well with SAX-based processors? 14:25:01 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 q+ 14:25:22 Gregg: I found it more convenient to explain it like I did. It could be done in another way. 14:25:25 ack Ivan 14:26:13 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 q+ 14:26:17 ack manu1 14:26:21 ack manu1 14:27:11 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 Ivan: We're not talking about a large amount of data here... just small elements of the page. 14:27:50 FWIW, I'm pro adding ordered lists 14:28:08 PROPOSAL: Add ordered list support to RDFa 1.1. 14:28:12 +1 14:28:13 +1 14:28:13 +1 14:28:13 +1 14:28:13 +1 14:28:14 rdf:List using rdf:first, rdf:next, rdf:nil 14:28:15 +1 14:28:17 +1 14:28:17 +1 14:28:19 +1 14:28:24 -tomayac 14:28:27 +1 14:28:32 RESOLVED: Add ordered list support to RDFa 1.1. 14:28:52 Manu: Do we want to have the technical discussion on the call today? 14:29:12 Ivan: We already had technical discussion on the list - Gregg's algorithm already has 2 independent implementations. 14:29:24 Ivan: Why don't we go w/ Gregg's proposal and see what the community says? 14:30:08 q+ 14:30:08 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 ack ivan 14:30:51 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 Ivan: The graph that is generated with the new markup will be different from RDFa 1.0 processor. 14:31:18 <> dc:creator ( ) VS. <> dc:creator , , 14:31:33 Ivan: We need to acknowledge the backwards-compat issue... I think that we could live with it. 14:31:51 q+ 14:31:53 Ivan: The graph, semantically, is close to the RDFa 1.1 version - I think we can live with this. 14:31:54 q+ to talk about backward compat 14:32:05 http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Sep/0068.html 14:32:15 lindstream: I wonder if we should raise separate issues for this? 14:32:30 ack lindstream 14:33:22 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 .. @version? 14:33:48 q+ 14:33:50 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 Ivan: I agree with Shane. 14:33:56 ack Shanem 14:33:56 ShaneM, you wanted to talk about backward compat 14:33:58 ack ShaneM 14:34:00 ack lindstream 14:34:15 q+ 14:34:17 lindstream: I agree w/ Ivan - it's important to notice this, but the effect is fine. 14:34:18 http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#major-differences-with-rdfa-syntax-1.0 14:34:20 ack Ivan 14:34:49 onlist 14:35:01 .. or "listitem" or "inlist". 14:35:05 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 I don't really like onlist... 14:35:13 it's not English 14:35:36 q+ 14:35:37 listitem sounds like a microdata attribute 14:35:41 Manu: Don't like @onlist either... @listitem is nice. 14:35:49 @inlist 14:36:21 listmember 14:36:34 q+ 14:36:39 ack lindstream 14:36:46 Ivan: I'd like to resolve this soon. 14:37:18 q+ 14:37:26 can't we choose a name now and eventually change it later? (it's just a string replace) 14:37:42 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 ack gkellogg 14:38:05 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 +1 for inlist 14:38:19 lindstream: We should decide on something that everybody understands. 14:38:39 ok 14:38:45 Manu: Lots of support for @inlist. 14:38:51 ... let's do that. 14:38:58 Ivan: What was the 3rd issue? 14:39:35 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 lindstream: One thing that bugs me is that normally this... 14:40:04 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 inlist="inlist" 14:40:08 inlist="" 14:40:28 lindstream: If the last one is the way it will work, I'm fine with it. 14:40:36 Ivan: The processing steps don't care about @inlist attribute. 14:40:44 in XML inlist="" is legitimate 14:40:47 Ivan: They disregard the value. 14:41:20 q+ to answer Nicklaus 14:41:29 lindstream: I heard that empty attributes should be expressed as checked="checked" ... is that true? 14:41:33 ack lindstream 14:41:35 ack shanem 14:41:35 ShaneM, you wanted to answer Nicklaus 14:41:53 ShaneM: The reason XHTML did checked="checked" is because SGML did that... 14:42:08 ShaneM: There is no rule in XML for it and there is no rule in M12N for it. 14:42:25 Niklas: Ok, that works for me. 14:42:26 q+ 14:42:30 Manu: So, what's the guidance. 14:42:35 #IMPLIED 14:42:51 ShaneM: It's value is #IMPLIED - it has no value list... "" is perfectly legitimate. 14:43:16 Manu: So in HTML5 it'll be inlist 14:43:48 ShaneM: And in XHTML it'll be inlist="" 14:44:17 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 Gregg: I think we can leave it off in practice, but we should not promote it. 14:44:54 Wiki at http://www.w3.org/2010/02/rdfa/wiki/Lists 14:45:40 Actually, the second part of that Wiki 14:46:02 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 +1 14:46:07 +1 14:46:08 +1 14:46:09 +0 14:46:09 +1 14:46:10 +1 14:46:12 +1 14:46:22 +0 Only because I haven't had time to review it. 14:46:45 +1 14:46:53 +1 14:47:07 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 Ivan Rocks 14:48:08 I'll add examples to the test suite 14:48:15 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 Cool! 14:48:40 Ivan: We should send a formal reply to Jeni. 14:49:00 ACTION: Respond to Jeni about ISSUE-106 - that we added ordered list support to RDFa 1.1 14:49:00 Sorry, couldn't find user - Respond 14:49:02 Note: I went through and cleared out my old action items that were complete. everyone should do this 14:49:05 ACTION: Manu to respond to Jeni about ISSUE-106 - that we added ordered list support to RDFa 1.1 14:49:05 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 Topic: ISSUE-107: @src attribute as object 14:49:29 http://www.w3.org/2010/02/rdfa/track/issues/107 14:49:54 Ivan: This came up via Jeni and earlier with people realizing that @src creates a lot of problems in practice. 14:50:15 Ivan: From a technical point of view, @src would behave exactly like @href and @resource... and not like @about. 14:50:46 Ivan: Doing that in terms of changing the processing steps is very easy - 5 minutes of work. 14:51:55 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 ...tutorials can change. 14:52:08 Ivan: unfortunately, I don't know if the charter allows us to make this change. 14:52:55 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 q+ 14:53:21 ack gkellogg 14:53:24 ack lindstream 14:53:31 Manu: Any objections to changing @src to behave like @href? 14:53:39 lindstream: I'm very supportive of this change. 14:54:01 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 Charter says: 14:54:16 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 to this rule, is the default XML Literal generation. 14:55:03 Ivan: What worries me is the charter text - we may break the charter with this change. 14:55:16 q+ to ask about @version 14:56:14 Manu: We should not allow the charter to block a good technical improvement. 14:56:19 ack lindstream 14:56:19 lindstream, you wanted to ask about @version 14:56:26 version="XHTML+RDFa 1.0" 14:56:32 Steven_ has joined #rdfa 14:56:33 version="XHTML+RDFa 1.1" 14:56:58 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 you mean HTML* 14:57:24 ;) 14:58:05 http://www.w3.org/TR/rdfa-syntax/#docconf 14:59:19 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 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 +1 15:00:10 +1 15:00:13 +1 15:00:14 +1 15:00:31 +1 15:00:31 +1 15:00:33 +1 15:00:40 +1 15:00:42 +0 15:01:19 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 Ivan: I won't be here for next two meetings... schema.org meeting is next week. 15:02:20 -MacTed 15:03:00 -scor 15:03:04 -ShaneM 15:03:19 MediaWiki:Sidebar (google helps indeed...) 15:03:36 -Steven.a 15:03:38 -SebastianGermesin 15:03:40 -manu1 15:03:44 -gkellogg 15:03:46 -lindstream 15:04:06 -Ivan 15:04:08 SW_RDFa()10:00AM has ended 15:04:12 Attendees were SebastianGermesin, manu1, gkellogg, Ivan, MacTed, ShaneM, lindstream, tomayac, Steven, +20592aaaa, scor 15:05:16 lindstream has left #rdfa 16:29:45 ShaneM has left #rdfa 17:00:49 Zakim has left #rdfa 17:32:07 trackbot has joined #rdfa