14:15:32 RRSAgent has joined #rdfa 14:15:32 logging to http://www.w3.org/2011/02/01-rdfa-irc 14:15:34 RRSAgent, make logs world 14:15:34 Zakim has joined #rdfa 14:15:36 Zakim, this will be 7332 14:15:36 ok, trackbot; I see SW_RDFa(RFDaWG)10:00AM scheduled to start in 45 minutes 14:15:37 Meeting: RDFa Working Group Teleconference 14:15:37 Date: 01 February 2011 14:16:05 Chair: Manu 14:28:10 Present: Ivan, Nathan, Knud, Manu, MarkB, ShaneM 14:45:11 Do we have an agenda for this? 14:45:39 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0156.html 14:59:33 Knud has joined #rdfa 14:59:50 zakim, code? 14:59:50 the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), manu 15:00:03 SW_RDFa(RFDaWG)10:00AM has now started 15:00:08 + +1.540.961.aaaa 15:00:13 zakim, I am aaaa 15:00:13 +manu; got it 15:00:41 ShaneM has joined #rdfa 15:02:03 +Knud 15:02:16 "all circuits are busy now" :-( 15:03:16 I'll try again in 5.. No doubt some people wiill be disconnecting soonish. 15:04:43 scribenick: manu 15:04:47 Scribe: Manu 15:05:58 Topic: Call Start-up 15:06:09 +ShaneM 15:06:11 Knud: We should have a 5 minute break, halfway through the call. 15:07:49 Knud: What are we hoping to get through on the call today? 15:08:06 Manu: Hopefully, everything - next step for all issues should be an official WG response. 15:08:13 zakim, dial ivan-voip 15:08:13 ok, ivan; the call is being made 15:08:14 +Ivan 15:09:16 I still can't get on call. Will keep trying and participate IRC only for now. 15:09:25 Topic: ISSUE-71: RDFa Core 1.1 LC comments from Shelley Powers 15:09:33 Could you skip over the issues I was triaging until I can get on? 15:10:11 Toby: http://www.w3.org/2006/tools/wiki/Zakim-SIP 15:10:24 Hi guys. I'm going to have a real problem this afternoon, I'm afraid. We have a release scheduled for tomorrow, and I need to be doing a lot of talking with other people. Would it be possible to keep an eye on IRC, and call in only if needed? That way I can still talk to people here. :) 15:11:06 (Yesterday we were ahead of schedule...today we are behind. :( ) 15:11:27 http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0137.html 15:14:13 Shane: What about the accessibility issues? 15:14:58 Manu: We just need to make sure we're not doing anything wrong from an a11y standpoint. 15:21:00 http://cmsmcq.com/mib/?p=1113 15:21:32 Shane: What about linking to triples? 15:22:06 Manu: It would be nice to forward-link to RDF-specific terms in all sections before section 3. 15:25:58
15:26:00
15:26:01 15:26:03 15:26:05
15:26:07
15:26:42
Albert Einstein was a 15:26:44
citizen of the 15:26:45 German Empire and the 15:26:47 United States. 15:26:48
15:26:50
15:27:41 Shane: Ok, all looks good. 15:28:03 Manu: I will write the official response, then. 15:30:09 Topic: ISSUE-63: Case-insensitive term matching is non-deterministic at times 15:30:15 http://www.w3.org/2010/02/rdfa/track/issues/63 15:30:45 Manu: Shane's wording was: 'In the event that multiple terms are defined that differ only in case, it is undefined which term is matched when a reference is made which does NOT match case-sensitively.' 15:31:29 tinkster, any issue with the wording that shane proposed for ISSUE-63? 15:32:15 fine by me. 15:32:26 I put this in:

In the event that multiple terms are defined that differ only in case (e.g., 'Agent', 'agent', and 'AGENT'), if a reference is made which DOES NOT match case-sensitively (e.g., typeof='AGENt'), the results are UNSPECIFIED.

15:33:42 Ivan: This is an issue where nobody will be completely happy, the text looks good, lets use it and move on from there. 15:33:56 Manu: Sounds good to me, let's move on. 15:34:14 Shane: I put this in the document already. 15:34:18 Ivan: This issue is DONE! 15:34:55 Topic: ISSUE-46: Should plain literals that match fully qualified IRIs be automatically converted to IRIs 15:35:02 ISSUE-46? 15:35:02 ISSUE-46 -- Should plain literals that match fully qualified IRIs be automatically converted to IRIs -- open 15:35:02 http://www.w3.org/2010/02/rdfa/track/issues/46 15:35:10 http://www.w3.org/2010/02/rdfa/track/issues/46 15:35:46 Ivan: It came back up when handling Harry Halpin's LC comment: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0121.html 15:36:22 Manu: People wanted to know if they could do this 15:36:24 -ShaneM 15:36:30 +??P0 15:36:36 Zakim, I am ?? 15:36:36 +webr3; got it 15:36:46 SIP seems to be working. Sound on my computer is not though. (Or at least input audio.) 15:37:05 zakim, who is on the call? 15:37:05 On the phone I see manu, Knud, Ivan, webr3 15:37:06 +??P7 15:37:16 zakim, I am P7 15:37:16 sorry, ShaneM, I do not see a party named 'P7' 15:37:18 shane, another pointer for colours: http://www.visionaustralia.org.au/info.aspx?page=628 15:37:22 zakim, I am ??P7 15:37:22 +ShaneM; got it 15:38:42 Manu: The people that we've been talking with have said that this is not a big issue for them. 15:39:07 I'd assert: "people know what to expect by understanding what the property means" (which is how sem web should be, also) 15:40:16 15:40:22 Ivan: Ok, let's get a few more arguments on the table. 15:42:15 I have looked at a lot of implementations of Open Graph Protocol and they nearly *all* just search for the XPath //head/meta[property="og:foo"] (or its equivalent via DOM crawling) 15:42:44 tinkster, likewise, true of almost every "curie" I've ever seen used outside semweb 15:44:07 toby, are you saying that they are looking for a literal string? 15:44:24 yup 15:44:28 wow 15:45:09 ShaneM, that's v common.. from RDF to atom to opengraph and beyond 15:45:24 rss* not rdf lol 15:45:46 "dc:title" as a string token, not a qname/curie etc 15:45:55 Manu: ok, well I'll prepare a response to Harry on ISSUE-46 15:46:07 ACTION: Manu to prepare official WG response to Harry on ISSUE-46 15:46:07 Created ACTION-50 - Prepare official WG response to Harry on ISSUE-46 [on Manu Sporny - due 2011-02-08]. 15:51:46 Nathan: I have a general concern about how this stuff is used in the field - don't people use IRIs in plain literals? 15:55:43 People do have valid reasons for putting IRIs (and things that look like they might be IRIs but might not be really) in plain literals. I've said before and I'll say it again, that Facebook's property takes a literal value quite sensibly. 15:56:32 if you have http://example.org/foo in the wild, in @content an element, anywhere, people /expect/ it to be treated as a uri/url/iri 15:58:48 Maybe, but do they expect it to be treated as or as "http://example.org/foo"^^xsd:anyURI? They're different things - the latter is not just a funny way of saying the former. 15:59:50 I think not only were spaces the problem, but also different IRI schemes. Pretty much anything /(.*?):(.*?)/ can be an IRI. 16:00:54 "fb:me" matches that 16:01:14 note that 'shane' is also an IRI 16:01:41 ":-)" matches that. 16:02:32 heh. http://www.w3.org/TR/xmlschema-2/#anyURI 16:03:17 there were suggestions to only accept certain IRI schemes, but I think people didn't like that back then. 16:03:34 knud, you are right. 16:05:09 Ivan: I think it was good that this issue was raised again, we cannot determininistically see whether or not something is an IRI - there is no way of doing that. 16:05:27 Manu: Also, keep in mind that there are other solutions to this problem, such as type coercion. 16:07:44 PROPOSAL: Response to ISSUE-46 should point out that there is no algorithm to deterministically identify IRIs. 16:07:52 +1 16:07:53 +1 16:07:55 +1 16:07:56 +1 16:07:57 +1 16:08:05 RESOLVED: Response to ISSUE-46 should point out that there is no algorithm to deterministically identify IRIs. 16:08:15 [Five minute break] 16:08:21 -webr3 16:08:43 -Knud 16:09:34 -ShaneM 16:09:47 zakim, who is on the call? 16:09:47 On the phone I see manu, Ivan 16:10:34 -manu 16:10:57 +??P2 16:10:58 -??P2 16:10:58 +??P2 16:11:02 zakim, I am ??P2 16:11:02 +manu; got it 16:14:36 +??P0 16:14:44 zakim, ??P0 is ShaneM 16:14:44 +ShaneM; got it 16:14:47 If there is a deterministic way to determine an IRI, then our argument falls. 16:14:54 No, :-) doesn't match IRI - it just matches Knud's expression. (His regular expression, not necessarily his facial one.) 16:14:55 zakim, who is on the call? 16:14:56 On the phone I see Ivan, manu, ShaneM 16:15:05 toby, lol 16:15:12 That may be his current facial expression - hard to know. 16:15:27 +[IPcaller] 16:15:34 Zakim, i am IPcaller 16:15:34 ok, webr3, I now associate you with [IPcaller] 16:16:56 +Knud 16:18:19 + +44.785.583.aabb 16:18:22 - +44.785.583.aabb 16:18:32

http://whatever

16:18:58 + +44.785.583.aacc 16:19:04 Zakim, aacc is me 16:19:04 +tinkster; got it 16:19:08 Zakim, mute me 16:19:08 tinkster should now be muted 16:19:26

http://whatever

16:19:30

http://whatever/

=> <> myurl 16:19:53

http://whate4ver

16:20:12 href="a" 16:21:20 manu: only a deterministic way of determining an IRI would save us 16:22:44 Agent/agent vs aGenT. 16:23:03 PROPOSAL: ISSUE-63 official WG response should refer to the official draft spec text on how to handle case-insensitive term matching. 16:23:28 PROPOSAL: ISSUE-63 official WG response should refer to the editors draft spec text on how to handle case-insensitive term matching. 16:23:48 refer to versioned URI? 16:24:20 ivan: cannot refer to draft spec, because that changes all the time 16:24:54 PROPOSAL: ISSUE-63 - case-insensitive term matching is non-deterministic. 16:24:57 +1 happy with that. Implementors can always try to agree on a strategy later. 16:25:03 + 16:25:04 +1 16:25:07 +1 16:25:07 +1 16:25:10 +1 16:25:16 RESOLVED: ISSUE-63 - case-insensitive term matching is non-deterministic. 16:25:16 for the records: the proposed text is: >In the event that multiple terms are defined that differ only in case (e.g., 'Agent', 'agent', and 'AGENT'), if a reference is made which DOES NOT match case-sensitively (e.g., typeof='AGENt'), the results are UNSPECIFIED. 16:25:49 PROPOSAL: Editorial suggestions in ISSUE-71 draft response is fine, send official response to Shelley Powers. 16:26:03 +1 16:26:10 +1 16:26:13 +1 16:26:16 +1 16:26:18 +1 16:26:29 +1 16:26:31 RESOLVED: Editorial suggestions in ISSUE-71 draft response is fine, send official response to Shelley Powers. 16:26:56 ISSUE-65? 16:26:56 ISSUE-65 -- Feedback from Michael Hausenblas on RDFa Core 1.1 -- open 16:26:56 http://www.w3.org/2010/02/rdfa/track/issues/65 16:26:58 Topic: ISSUE-65: Last Call feedback from Michael Hausenblas 16:27:00 http://www.w3.org/2010/02/rdfa/track/issues/65 16:27:25 http://www.w3.org/2010/02/rdfa/meetings/2011-01-13#ISSUE__2d_65__3a__Michael_Hausenblas__27__LC_Comments 16:28:16 manu: we want an official WG LC response for each issue 16:28:37 shane: I'll do that 16:29:01 ivan: I added the diagram to the document 16:29:11 ACTION: Shane to write official response to Michael Hausenblas for ISSUE-65 16:29:11 Created ACTION-51 - Write official response to Michael Hausenblas for ISSUE-65 [on Shane McCarron - due 2011-02-08]. 16:29:33 ISSUE-67? 16:29:33 ISSUE-67 -- RDFa Core 1.1 LC comments from Henri Sivonen -- open 16:29:33 http://www.w3.org/2010/02/rdfa/track/issues/67 16:29:34 Topic: ISSUE-67: RDFa Core 1.1 LC comments from Henri Sivonen 16:29:52 http://www.w3.org/2010/02/rdfa/track/issues/67 16:30:27 : http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0140.html 16:30:34 Zakim, unmute me 16:30:34 tinkster should no longer be muted 16:31:02 tinkster: Henry doesn't want CURIEs in RDFa at all 16:31:16 s/Henry/Henri 16:31:28 … : we cannot really do that 16:31:53 (going through the editorial changes proposed) 16:32:07 -> HS: The concept of "processor graph" seems to be an open-ended loophole of non-interoperability. - issue 16:34:48 "foo: http://" valid, "foo: http://" invalid? 16:36:17 (going over to the "won't fix" section) 16:38:11 ivan: I have no comments on the won't fix section 16:38:49 Manu: Looks good to me. 16:38:53 … : Toby's answers are good 16:39:33 tinkster: some editorial changes have not been addressed yet 16:42:01 "The concept of "processor graph" seems to be an open-ended loophole of non-interoperability." 16:42:22 manu: we don't really say exactly what is in the pg 16:43:04 … : we could respond by saying that the WG will have a test suite that will clarify this 16:43:23 tinkster: we could define a vocabulary, but not insist that it is being used 16:43:48 ivan: we talked about a vocab before, I had a proposal, but that was rejected 16:44:18 manu: there were objections because it might take us too long to agree on a vocab (by mark?) 16:44:24 q+ 16:44:37 ivan: I had a wiki page with a proposal 16:44:38 Zakim, I am IPcaller 16:44:38 ok, webr3, I now associate you with [IPcaller] 16:45:11 ack webr3 16:45:14 ack webr3 16:45:32 manu: we could say: we are having a PG graph vocab on a wiki and we will have examples in the test suite 16:46:23 ivan: the spec defines error conditions, but not how errors should be raised 16:46:25 http://www.w3.org/TR/rdfa-core/#accessing-the-processor-graph 16:47:32 and also http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#dfn-processor_graph 16:48:59 q+ to talk about appendix B 16:49:37 q+ 16:49:43 ack shanem 16:49:43 ShaneM, you wanted to talk about appendix B 16:49:50 q- 16:49:57 v 16:49:57 tinkster: we require a PG, but we say very little regarding what should be in it 16:50:02 http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#vocabulary 16:51:11 ShaneM: the reference to "processor graph" here confuses me 16:51:21 manu: this should read "profile" 16:52:24 ack ivan 16:52:33 manu: there are several use cases for the PG 16:52:41 http://www.w3.org/2010/02/rdfa/wiki/Processor_Graph_Vocabulary 16:53:08 ivan: that's the link to my PG vocabulary proposal 16:54:29 … : we could say the implementation SHOULD use this vocabulary and MAY add any other triples it likes 16:55:11 Zakim, mute me 16:55:11 tinkster should now be muted 16:55:40 Zakim, unmute me 16:55:40 tinkster should no longer be muted 16:56:50 Nathan: happy with this proposal. Will look at the proposed vocabulary. 16:57:49 tinkster: just because there are use cases for a PG, we don't have to require it 17:00:00 An ERROR must be generated when the document fails to be fully processed as a result of non-conformant host language markup. An ERROR must be generated when a referenced RDFa Profile is not recognized, as described in RDFa Profiles. A WARNING must be generated when a CURIE prefix fails to be resolved. A WARNING must be generated when a Term fails to be resolved. 17:00:23 ivan: these are all the error conditions we have 17:00:59 … : this is necessary to get back to the user - how can we guarantee that other than with a PG? 17:01:22 ERROR states are full failures yes? can't continue processing? 17:01:27 tinkster: should be left application-specific. Could also be a callback function, etc. 17:01:40 webr3: no I dont think so 17:02:04 ACTION: Ivan to update and integrate Processor Graph Vocabulary into the RDFa Core spec: http://www.w3.org/2010/02/rdfa/wiki/Processor_Graph_Vocabulary 17:02:05 Created ACTION-52 - Update and integrate Processor Graph Vocabulary into the RDFa Core spec: http://www.w3.org/2010/02/rdfa/wiki/Processor_Graph_Vocabulary [on Ivan Herman - due 2011-02-08]. 17:03:03 ACTION: Ivan to modify RDFa Core 7.6.1 to make Processor Graph support optional, but if Processor Graph support is included, the Processor Graph Vocabulary MUST be used. 17:03:04 Created ACTION-53 - Modify RDFa Core 7.6.1 to make Processor Graph support optional, but if Processor Graph support is included, the Processor Graph Vocabulary MUST be used. [on Ivan Herman - due 2011-02-08]. 17:04:23 PROPOSAL: RDFa Core should include a Processor Graph Vocabulary and make Processor Graph support optional. 17:04:29 +1 17:04:30 +1 17:04:37 +1 17:04:47 +1 17:04:47 +1 17:04:53 RESOLVED: RDFa Core should include a Processor Graph Vocabulary and make Processor Graph support optional. 17:04:56 OKK. 17:04:58 +1 (and if processor graph is present, must use grpah vocab) 17:05:44 Topic: Default Graph 17:05:59 manu: I agree with your proposal, we will discuss this here on the call 17:06:07 -> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0160.html Ivan's proposal 17:06:12 ACTION: Introduce a definition for the PREFIX datatype that is referenced in the schema implementation of XHTML+RDFa 17:06:12 Sorry, couldn't find user - Introduce 17:06:24 zakim, drop me 17:06:24 Ivan is being disconnected 17:06:24 ACTION: Shane Introduce a definition for the PREFIX datatype that is referenced in the schema implementation of XHTML+RDFa 17:06:24 Created ACTION-54 - Introduce a definition for the PREFIX datatype that is referenced in the schema implementation of XHTML+RDFa [on Shane McCarron - due 2011-02-08]. 17:06:25 -Ivan 17:06:59 topic: ISSUE-67 17:08:25 manu: is there some DOM spec that supresses whitespace? 17:11:19 http://www.w3.org/TR/xmlschema-1/#d0e1654 17:12:10 shane: in XHTML whitespace must be preserved, in XML whitespace collapsing is permissable 17:14:40 "white space preservation is defined by the host language"? 17:15:09 tinkster: we should point that out in the spec, preferably with a reference (as manu put in) 17:15:26 -tinkster 17:16:05 ACTION: Toby to draft official RDFa WG response for ISSUE-67 17:16:05 Created ACTION-55 - Draft official RDFa WG response for ISSUE-67 [on Toby Inkster - due 2011-02-08]. 17:16:05 ACTION: Nathan Rixham review http://www.w3.org/2010/02/rdfa/wiki/Processor_Graph_Vocabulary and give Ivan feedback 17:16:05 Created ACTION-56 - Rixham review http://www.w3.org/2010/02/rdfa/wiki/Processor_Graph_Vocabulary and give Ivan feedback [on Nathan Rixham - due 2011-02-08]. 17:16:29 Topic: ISSUE-73 17:16:32 http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0160.html Ivan's proposal 17:18:10 see-also: ACTION-511 TAG 17:21:20 http://w3.org/rdf-profiles/2010 17:21:50 http://w3.org/rdf-profiles/2014-rdfa 17:23:22 "the rdfa profile may be updated in the future" ? 17:26:56 Every time you remove a profile, Shane kills a triple. 17:30:17 http://w3.org/rdf-profile 17:31:00 webr3: The main problem is removing definitions from a profile, regardless of its URI or if we use a new default profile. 17:31:24 17:31:32 that's the only way to be sure 17:31:53 … : People in their documents need to reference a stable profile 17:36:50 Manu: You can't remove or change any prefixes or terms in a profile at a particular URL. Appending is fine. If you have to change a URL, it MUST be backwards-compatible. 17:42:15 RDFa Core 1.1 => http://w3.org/rdf/profiles/2010 17:42:18 RDFa Core 1.1 => http://w3.org/rdf/profiles/2011 17:42:40 youre not missing much 17:42:57 RDFa Core 1.1 => http://w3.org/rdf/profiles 17:43:15 RDFa Core 1.1 => http://w3.org/rdf/profiles/2011 17:43:23 The latest working prefixes/terms => http://w3.org/rdf/profiles 17:43:43 Nobody would ever use: http://w3.org/rdf/profiles - except for discussion on what the latest prefixes/terms should be. 17:43:54 RDFa processor implementations would ALWAYS use the dated URI 17:44:15 Nathan: We could just not define: http://w3.org/rdf/profiles 17:44:23 if I understand things right I do not agree. An implementation that is caching would always use a non-dated URI 17:44:49 dated uri for a default profile makes only sense if you want to keep to 'history' 17:45:03 ivan - you are missing too much context 17:45:09 sorry...:-( 17:48:20 http://w3.org/rdf-default-profile 17:50:20 lots of discussion on approaches 17:52:21 http://prefix.cc/dc 17:55:05 I assert that "dc" can't go in the default profile, because it is ambigous 17:55:17 Why do you think it's ambiguous? 17:55:27 webr3: this is something the DCMI people have to tell us 17:55:42 -> http://prefix.cc/dc 17:55:59 it's not what dcmi say, it's how the web population uses the string "dc" 17:56:04 web3: this is based on how the prefix "dc" is actually used 17:56:30 xmlns:dc 17:56:58 but what do we set it to in the profile? 17:57:10 yes, what Knud said 17:57:47 this is something that the dcmi community have to tell us 17:58:03 dcmi community -> DCMI as a holder of that vocabulary 17:58:21 "dc:title" 17:59:35 but webr3, if dc is so ambiguous, then we just cannot include it in the default profile at all 17:59:47 yes, what Kund said again :) 18:00:06 s/kund/Kund (sorry) 18:00:32 -ShaneM 18:01:54 Nathan: We need a default profile that processors should implement, if people want it to be stable, they must reference it directly. 18:02:04 so this is not a technical problem we can solve, it's a social problem? 18:03:03 we should encourage people to reference a stable profile if they want stability, and not /rely/ on the default profile 18:03:09 what Nathan says sounds as though we should not have a default profile after all 18:03:34 then the default profile is useless 18:03:35 zakim, dial ivan-voip 18:03:35 ok, ivan; the call is being made 18:03:37 +Ivan 18:03:44 as in, the default profile we provide for peopel to reference, not for people to depend on as having unambigous forever meaning (mapping of string to uris, we can't promise that, for social reasons) 18:04:53 should I write it all up in a mail to the list? 18:05:54 bye! 18:06:04 -Knud 18:17:14 foaf2 18:17:16 foaf3 18:19:13 zakim, drop me 18:19:13 Ivan is being disconnected 18:19:14 -Ivan 18:20:07 -manu 18:20:09 -[IPcaller] 18:20:09 SW_RDFa(RFDaWG)10:00AM has ended 18:20:11 Attendees were +1.540.961.aaaa, manu, Knud, ShaneM, Ivan, webr3, [IPcaller], +44.785.583.aabb, +44.785.583.aacc, tinkster 20:23:53 ShaneM has left #rdfa 20:27:29 Zakim has left #rdfa