13:46:49 RRSAgent has joined #rdfa 13:46:49 logging to http://www.w3.org/2011/05/19-rdfa-irc 13:46:51 RRSAgent, make logs world 13:46:51 Zakim has joined #rdfa 13:46:53 Zakim, this will be 7332 13:46:53 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 14 minutes 13:46:54 Meeting: RDF Web Applications Working Group Teleconference 13:46:54 Date: 19 May 2011 13:57:31 SW_RDFa()10:00AM has now started 13:57:38 ShaneM has joined #rdfa 13:57:38 +??P8 13:57:49 zakim, I am ??P8 13:57:49 +ShaneM; got it 13:58:17 RRSAgent, draft minutes 13:58:17 I have made the request to generate http://www.w3.org/2011/05/19-rdfa-minutes.html MacTed 13:58:19 +??P10 13:58:23 RRSAgent, make logs public 13:58:23 zakim, I am ??P10 13:58:24 +manu1; got it 14:01:42 zakim, dial steven-617 14:01:42 ok, Steven; the call is being made 14:01:43 +Steven 14:02:36 tomayac has joined #rdfa 14:04:07 +hta 14:08:36 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011May/0069 14:09:16 Chair: Manu 14:09:18 Scribe: Tom 14:09:21 Scribe: Thomas 14:09:30 scribenick: tomayac 14:09:35 zakim, who is on the call? 14:09:35 On the phone I see ShaneM, manu1, Steven, hta 14:09:53 Topic: RDFa news and updates on spec progress 14:10:13 Manu: MusicBrainz released all of their music pages with RDFa! Great news! 14:10:36 Manu: Yahoo! released their real estate mark-up as RDFa using GoodRelations. Good start! 14:10:52 We should add this all to rdfa.info 14:11:02 Manu: NYT rNews gets a lot of coverage in the press. Recursion FTW! 14:11:21 Manu: any other news? 14:15:44 Topic: IRI vs. URI References 14:15:51 http://www.w3.org/2010/02/rdfa/track/issues/87 14:17:05 Manu: Recap of the issue: should IRIs be punycoded, yes or no? 14:18:20 Manu: need to figure out if there's general agreement in the rdf community 14:18:51 http://lists.w3.org/Archives/Public/public-rdf-wg/2011May/0261.html 14:19:34 Shane: my rdf parser isn't doing anything on its own, but the underlying perl lib is. 14:20:06 Manu: overall feeling of the community is: we should not punycode! don't try to be overly smart. 14:20:52 Tom: i can perfectly live with this decision NOT to punycode. 14:21:08 Manu: we need to do path normailzation. 14:21:22 Shane: i can live with not punycoding. 14:21:55 Manu: there are different variants of comparing IRIs 14:22:08 Shane: hostnames and schemes should always be lower-cased 14:22:24 Shane: is this defined in the RFC? Yes it is! 14:22:25 http://tools.ietf.org/html/rfc3986#section-6 14:23:00 Manu: Shane was looking at URI, Manu was looking at IRI 14:23:50 Shane: we need to clarify if we use URI or IRI 14:24:14 http://tools.ietf.org/html/rfc3987#section-5 14:24:15 steven: IRIs need to be sent in the form of URIs when going over the wire 14:24:47 Shane: should we leave IRIs alone? 14:25:07 steven: in the rdf, it's all syntactic psace, not value space. 14:25:35 (sorry, coping with some local issues ... still hope to join, but may not make it) 14:26:42 Manu: it should be IRI 14:27:02 Read this... it is VERY interesting: When expanded, the resulting URI must be a syntactically valid URI [RFC3987]. For a more detailed explanation see CURIE and URI Processing. The lexical space of a CURIE is as defined in curie below. The value space is the set of URIs. 14:27:18 Manu: implementations do NOT touch the (IRI) values they get, they simply take what's there 14:27:51 Manu: trying to avoid going thru another LC 14:28:40 Shane: we can do a global replace of uri with iri 14:28:49 text from rdfa-syntax: Note that while the lexical space of a CURIE is as defined in curie above, the value space is the set of IRIs. 14:29:13 Manu: we don't need to change anything. 14:29:29 Shane: does it say we should not say URI in the spec? 14:29:43 Manu: yes 14:29:46 Steven: yes 14:30:15 Action: Shane to update spec to talk about IRIs when we really mean IRIs 14:30:15 Created ACTION-79 - Update spec to talk about IRIs when we really mean IRIs [on Shane McCarron - due 2011-05-26]. 14:30:15 Manu: all good, we dont need to change 14:32:23 Manu: in the rdfa processor we don't need to compare anywhere. 14:32:38 Shane: the problem is the relative uri problem 14:33:01 Shane: i think the consumer should not have to deal with normalization 14:33:18 Manu: when you say normalized, which definition do you refer to? 14:34:18 Steven: still not convinced we need to worry about htis 14:34:48 Steven: the data publisher need to deal with this 14:35:20 Shane: sometimes i use absolute uris in content, especially in templates 14:35:32 Shane: so wherever they get included, they're correct 14:35:48 Shane: sometimes i get lazy and refer to the same content relatively and absolutely 14:36:19 Shane: in this situation my triples are different, but after normalization would be equal 14:36:36 Shane: if we care, we need to care, if not, we#äre all set 14:37:26 Manu: argument would be: keep the processor simple 14:37:35 Can we say "a processor may apply normalization rules as defined in section 5" ? 14:38:02 Manu: no, because processors would generate different triples 14:38:09 *rats* 14:38:26 Steven: normalization necessary when we need to compare. falls back to the question whether we need to compare or not 14:38:49 Shane: doesnt the rdfa api allow for comparison? 14:38:58 Manu: yes, it does 14:39:37 Manu: if the rdfa processors implement normalization, they become incredibly complicated 14:39:59 http://en.wikipedia.org/wiki/Pogo_%28comic_strip%29#.22We_have_met_the_enemy....22 14:40:00 Manu: fear that it might be easy to get it wrong 14:40:22 Manu: normalization algorithms are complex 14:41:19 example://a/b/c/%7Bfoo%7D/rosé 14:41:21 eXAMPLE://a/./b/../b/%63/%7bfoo%7d/ros3%A9 14:41:24 Manu: looking at the IRI spec 14:41:43 Manu: but it doesnt say which is the normalization you should normalize to 14:42:01 Manu: order is unclear 14:42:16 Shane: order wouldn't matter 14:42:31 Manu: right, probably not 14:42:59 Shane: it gets worse 14:43:34 Manu: still from the IRI spec: if IRIs are gonna be passed, no processing shall be done 14:44:00 Manu: looking at percent encoding 14:44:16 Manu: only to be applied for local processing 14:44:44 Manu: you should only do this processing, when you need to compare 14:45:36 Manu: equivalence of IRIs must rely on unnormalized IRIs 14:45:55 Shane: what about case normalization? 14:46:27 Manu: case normalization is a touchy thing 14:46:50 Manu: the more i read, the more i think we shouldnt do it 14:47:06 Manu: except for path based normalization 14:47:11 5.3.2.4. Path Segment Normalization 14:47:26 Manu: correction: except for path segment normalization 14:47:38 Manu: we can't do scheme-based normalization 14:47:53 Manu: we can't add all schemes to each processor 14:48:17 Manu: if we do any normalization at all, it should be only path normalization 14:48:34 Shane: i feel we should not preclude path segment normalization 14:48:59 Manu: the only problem i have with that is that processors might generate different triples. we don't want this. 14:50:23 Tom: i would go for shane's pragmatic view and leave the publisher's data alone and not normalize at all 14:51:49 Manu: (looking at his processor to check whether it normalizes) 14:52:05 Shane: (looking at his processor) pretty sure i have a normalization 14:52:36 Manu: my processor does not normalize (with reference to the spec) 14:52:50 Manu: i don't have normalization, even if I thought i had 14:53:12 Manu: shane, you're right 14:53:24 Shane: then let's not normlaize 14:53:35 Steven: no concerns with that 14:54:43 PROPOSAL: RDFa Core and all RDFa specifications should use the term IRI. RDFa Processors MUST NOT modify IRIs provided by authors in documents. IRI normalization MUST NOT be performed by RDFa Processors. 14:55:10 +1 14:55:28 +1 14:56:26 PROPOSAL: RDFa Core and all RDFa specifications should use the term IRI. RDFa Processors MUST NOT modify IRIs provided by authors in documents. IRI normalization MUST NOT be performed by RDFa Processors. For the avoidance of doubt, this means that, in particular, punycoded IRIs must be left AS IS by RDFa Processors. 14:56:35 +1 14:56:37 +1 14:56:51 +1 14:56:56 +1 14:56:58 RESOLVED: RDFa Core and all RDFa specifications should use the term IRI. RDFa Processors MUST NOT modify IRIs provided by authors in documents. IRI normalization MUST NOT be performed by RDFa Processors. For the avoidance of doubt, this means that, in particular, punycoded IRIs must be left AS IS by RDFa Processors. 14:57:24 Topic: ISSUE-90: CURIEorURI Value Space Collisions 14:57:31 http://www.w3.org/2010/02/rdfa/track/issues/90 14:58:18 Create prefix for 'http' 14:58:21 Manu: the idea here is someone created a curie "http" 14:58:38 http => http://www.w3.org/2006/http# 14:59:01 http://www.w3.org/TR/HTTP-in-RDF10/ 14:59:22 Namespace prefix Namespace URI 14:59:22 http http://www.w3.org/2011/http# 14:59:41 Steven: while it's not a bad idea, it's allowed 14:59:52 The problem also being "sip" 15:00:02 Steven: correction: while it's not a GOOD idea, it's allowed 15:00:51 Steven: we had so many discussions about it... just leave it as is 15:02:19 PROPOSAL: RDFa Core will not limit the syntactic space of CURIEs to reduce the possibility of collisions. 15:02:27 +1 15:02:29 +1 15:02:30 +1 15:02:43 RESOLVED: RDFa Core will not limit the syntactic space of CURIEs to reduce the possibility of collisions. 15:03:01 Strongest points being: It would break backwards compatibility and it wouldn't work for schemes like 'sip' 15:03:30 -Steven 15:03:31 -manu1 15:03:31 -ShaneM 15:03:32 -hta 15:03:32 SW_RDFa()10:00AM has ended 15:03:34 Attendees were ShaneM, manu1, Steven, hta 15:03:45 zakim, hta is me 15:03:47 sorry, tomayac, I do not recognize a party named 'hta' 15:39:57 ShaneM has left #rdfa 15:59:35 ShaneM has joined #rdfa 15:59:42 ShaneM has left #rdfa 17:06:28 Zakim has left #rdfa