13:46:49 <RRSAgent> logging to http://www.w3.org/2011/05/19-rdfa-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2011/05/19-rdfa-irc ←
13:46:51 <trackbot> RRSAgent, make logs world
Trackbot IRC Bot: RRSAgent, make logs world ←
13:46:53 <trackbot> Zakim, this will be 7332
Trackbot IRC Bot: Zakim, this will be 7332 ←
13:46:53 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 14 minutes
Zakim IRC Bot: 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
(No events recorded for 10 minutes)
Zakim IRC Bot: SW_RDFa()10:00AM has now started ←
13:57:38 <Zakim> +??P8
Zakim IRC Bot: +??P8 ←
13:57:49 <ShaneM> zakim, I am ??P8
Shane McCarron: zakim, I am ??P8 ←
13:57:49 <Zakim> +ShaneM; got it
Zakim IRC Bot: +ShaneM; got it ←
13:58:23 <manu1> zakim, I am ??P10
Manu Sporny: zakim, I am ??P10 ←
13:58:24 <Zakim> +manu1; got it
Zakim IRC Bot: +manu1; got it ←
14:01:42 <Steven> zakim, dial steven-617
Steven Pemberton: zakim, dial steven-617 ←
14:01:42 <Zakim> ok, Steven; the call is being made
Zakim IRC Bot: ok, Steven; the call is being made ←
14:01:43 <Zakim> +Steven
Zakim IRC Bot: +Steven ←
14:04:07 <Zakim> +hta
Zakim IRC Bot: +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
(No events recorded for 5 minutes)
(Scribe set to Thomas Steiner)
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?
zakim, who is on the call? ←
14:09:35 <Zakim> On the phone I see ShaneM, manu1, Steven, hta
Zakim IRC Bot: 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!
Manu Sporny: 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!
Manu Sporny: 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
Steven Pemberton: 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!
Manu Sporny: NYT rNews gets a lot of coverage in the press. Recursion FTW! ←
14:11:21 <tomayac> Manu: any other news?
Manu Sporny: 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
Manu Sporny: 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?
Manu Sporny: 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
Manu Sporny: 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
Manu Sporny: 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.
Shane McCarron: 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.
Manu Sporny: 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.
Thomas Steiner: i can perfectly live with this decision NOT to punycode. ←
14:21:08 <tomayac> Manu: we need to do path normailzation.
Manu Sporny: we need to do path normailzation. ←
14:21:22 <tomayac> Shane: i can live with not punycoding.
Shane McCarron: i can live with not punycoding. ←
14:21:55 <tomayac> Manu: there are different variants of comparing IRIs
Manu Sporny: there are different variants of comparing IRIs ←
14:22:08 <tomayac> Shane: hostnames and schemes should always be lower-cased
Shane McCarron: hostnames and schemes should always be lower-cased ←
14:22:24 <tomayac> Shane: is this defined in the RFC? Yes it is!
Shane McCarron: is this defined in the RFC? Yes it is! ←
14:22:25 <ShaneM> http://tools.ietf.org/html/rfc3986#section-6
Shane McCarron: http://tools.ietf.org/html/rfc3986#section-6 ←
14:23:00 <tomayac> Manu: Shane was looking at URI, Manu was looking at IRI
Manu Sporny: 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
Shane McCarron: we need to clarify if we use URI or IRI ←
14:24:14 <ShaneM> http://tools.ietf.org/html/rfc3987#section-5
Shane McCarron: 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
Steven Pemberton: 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?
Shane McCarron: should we leave IRIs alone? ←
14:25:07 <tomayac> steven: in the rdf, it's all syntactic psace, not value space.
Steven Pemberton: in the rdf, it's all syntactic psace, not value space. ←
14:26:42 <tomayac> Manu: it should be IRI
Manu Sporny: 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.
Shane McCarron: 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
Manu Sporny: 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
Manu Sporny: trying to avoid going thru another LC ←
14:28:40 <tomayac> Shane: we can do a global replace of uri with iri
Shane McCarron: 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.
Shane McCarron: 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.
Manu Sporny: we don't need to change anything. ←
14:29:29 <tomayac> Shane: does it say we should not say URI in the spec?
Shane McCarron: does it say we should not say URI in the spec? ←
14:29:43 <tomayac> Manu: yes
Manu Sporny: yes ←
14:29:46 <tomayac> Steven: yes
Steven Pemberton: yes ←
14:30:15 <ShaneM> Action: Shane to update spec to talk about IRIs when we really mean IRIs
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].
Trackbot IRC Bot: 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
Manu Sporny: all good, we dont need to change ←
14:32:23 <tomayac> Manu: in the rdfa processor we don't need to compare anywhere.
Manu Sporny: in the rdfa processor we don't need to compare anywhere. ←
14:32:38 <tomayac> Shane: the problem is the relative uri problem
Shane McCarron: the problem is the relative uri problem ←
14:33:01 <tomayac> Shane: i think the consumer should not have to deal with normalization
Shane McCarron: 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?
Manu Sporny: when you say normalized, which definition do you refer to? ←
14:34:18 <tomayac> Steven: still not convinced we need to worry about htis
Steven Pemberton: still not convinced we need to worry about htis ←
14:34:48 <tomayac> Steven: the data publisher need to deal with this
Steven Pemberton: the data publisher need to deal with this ←
14:35:20 <tomayac> Shane: sometimes i use absolute uris in content, especially in templates
Shane McCarron: sometimes i use absolute uris in content, especially in templates ←
14:35:32 <tomayac> Shane: so wherever they get included, they're correct
Shane McCarron: 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
Shane McCarron: 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
Shane McCarron: 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
Shane McCarron: 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
Manu Sporny: 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" ?
Shane McCarron: 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
Manu Sporny: no, because processors would generate different triples ←
14:38:09 <ShaneM> *rats*
Shane McCarron: *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
Steven Pemberton: 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?
Shane McCarron: doesnt the rdfa api allow for comparison? ←
14:38:58 <tomayac> Manu: yes, it does
Manu Sporny: yes, it does ←
14:39:37 <tomayac> Manu: if the rdfa processors implement normalization, they become incredibly complicated
Manu Sporny: 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
Shane McCarron: 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
Manu Sporny: fear that it might be easy to get it wrong ←
14:40:22 <tomayac> Manu: normalization algorithms are complex
Manu Sporny: 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
Manu Sporny: 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
Manu Sporny: looking at the IRI spec ←
14:41:43 <tomayac> Manu: but it doesnt say which is the normalization you should normalize to
Manu Sporny: but it doesnt say which is the normalization you should normalize to ←
14:42:01 <tomayac> Manu: order is unclear
Manu Sporny: order is unclear ←
14:42:16 <tomayac> Shane: order wouldn't matter
Shane McCarron: order wouldn't matter ←
14:42:31 <tomayac> Manu: right, probably not
Manu Sporny: right, probably not ←
14:42:59 <tomayac> Shane: it gets worse
Shane McCarron: it gets worse ←
14:43:34 <tomayac> Manu: still from the IRI spec: if IRIs are gonna be passed, no processing shall be done
Manu Sporny: 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
Manu Sporny: looking at percent encoding ←
14:44:16 <tomayac> Manu: only to be applied for local processing
Manu Sporny: only to be applied for local processing ←
14:44:44 <tomayac> Manu: you should only do this processing, when you need to compare
Manu Sporny: you should only do this processing, when you need to compare ←
14:45:36 <tomayac> Manu: equivalence of IRIs must rely on unnormalized IRIs
Manu Sporny: equivalence of IRIs must rely on unnormalized IRIs ←
14:45:55 <tomayac> Shane: what about case normalization?
Shane McCarron: what about case normalization? ←
14:46:27 <tomayac> Manu: case normalization is a touchy thing
Manu Sporny: case normalization is a touchy thing ←
14:46:50 <tomayac> Manu: the more i read, the more i think we shouldnt do it
Manu Sporny: the more i read, the more i think we shouldnt do it ←
14:47:06 <tomayac> Manu: except for path based normalization
Manu Sporny: except for path based normalization ←
14:47:11 <ShaneM> 5.3.2.4. Path Segment Normalization
Shane McCarron: 5.3.2.4. Path Segment Normalization ←
14:47:26 <tomayac> Manu: correction: except for path segment normalization
Manu Sporny: correction: except for path segment normalization ←
14:47:38 <tomayac> Manu: we can't do scheme-based normalization
Manu Sporny: we can't do scheme-based normalization ←
14:47:53 <tomayac> Manu: we can't add all schemes to each processor
Manu Sporny: 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
Manu Sporny: 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
Shane McCarron: 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.
Manu Sporny: 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
Thomas Steiner: 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)
Manu Sporny: (looking at his processor to check whether it normalizes) ←
14:52:05 <tomayac> Shane: (looking at his processor) pretty sure i have a normalization
Shane McCarron: (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)
Manu Sporny: 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
Manu Sporny: i don't have normalization, even if I thought i had ←
14:53:12 <tomayac> Manu: shane, you're right
Manu Sporny: shane, you're right ←
14:53:24 <tomayac> Shane: then let's not normlaize
Shane McCarron: then let's not normlaize ←
14:53:35 <tomayac> Steven: no concerns with that
Steven Pemberton: 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.
PROPOSED: 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
Manu Sporny: +1 ←
14:56:37 <tomayac> Tom: +1
Thomas Steiner: +1 ←
14:56:51 <ShaneM> +1
Shane McCarron: +1 ←
14:56:56 <Steven> +1
Steven Pemberton: +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.
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
Manu Sporny: http://www.w3.org/2010/02/rdfa/track/issues/90 ←
14:58:18 <manu1> Create prefix for 'http'
Manu Sporny: Create prefix for 'http' ←
14:58:21 <tomayac> Manu: the idea here is someone created a curie "http"
Manu Sporny: the idea here is someone created a curie "http" ←
14:58:38 <manu1> http => http://www.w3.org/2006/http#
Manu Sporny: http => http://www.w3.org/2006/http# ←
14:59:01 <tomayac> http://www.w3.org/TR/HTTP-in-RDF10/
http://www.w3.org/TR/HTTP-in-RDF10/ ←
14:59:22 <tomayac> Namespace prefix Namespace URI
Namespace prefix Namespace URI ←
14:59:22 <tomayac> http http://www.w3.org/2011/http#
http http://www.w3.org/2011/http# ←
14:59:41 <tomayac> Steven: while it's not a bad idea, it's allowed
Steven Pemberton: while it's not a bad idea, it's allowed ←
14:59:52 <manu1> The problem also being "sip"
Manu Sporny: The problem also being "sip" ←
15:00:02 <tomayac> Steven: correction: while it's not a GOOD idea, it's allowed
Steven Pemberton: 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
Steven Pemberton: 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.
PROPOSED: RDFa Core will not limit the syntactic space of CURIEs to reduce the possibility of collisions. ←
15:02:27 <ShaneM> +1
Shane McCarron: +1 ←
15:02:29 <manu1> +1
Manu Sporny: +1 ←
15:02:29 <manu1> Steven: +1
Steven Pemberton: +1 [ Scribe Assist by Manu Sporny ] ←
15:02:30 <tomayac> Tom: +1
Thomas Steiner: +1 ←
15:02:43 <manu1> RESOLVED: RDFa Core will not limit the syntactic space of CURIEs to reduce the possibility of collisions.
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'
Manu Sporny: Strongest points being: It would break backwards compatibility and it wouldn't work for schemes like 'sip' ←
15:03:30 <Zakim> -Steven
Zakim IRC Bot: -Steven ←
15:03:31 <Zakim> -manu1
Zakim IRC Bot: -manu1 ←
15:03:31 <Zakim> -ShaneM
Zakim IRC Bot: -ShaneM ←
15:03:32 <Zakim> -hta
Zakim IRC Bot: -hta ←
15:03:32 <Zakim> SW_RDFa()10:00AM has ended
Zakim IRC Bot: SW_RDFa()10:00AM has ended ←
15:03:34 <Zakim> Attendees were ShaneM, manu1, Steven, hta
Zakim IRC Bot: Attendees were ShaneM, manu1, Steven, hta ←
15:03:45 <tomayac> zakim, hta is me
zakim, hta is me ←
15:03:47 <Zakim> sorry, tomayac, I do not recognize a party named 'hta'
Zakim IRC Bot: sorry, tomayac, I do not recognize a party named 'hta' ←
Formatted by CommonScribe
This revision (#1) generated 2011-05-19 15:29:22 UTC by 'msporny', comments: 'Minor fixups to the minutes.'