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