13:56:52 RRSAgent has joined #rdfa 13:56:52 logging to http://www.w3.org/2011/05/12-rdfa-irc 13:56:54 RRSAgent, make logs world 13:56:54 Zakim has joined #rdfa 13:56:56 Zakim, this will be 7332 13:56:56 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 4 minutes 13:56:57 Meeting: RDF Web Applications Working Group Teleconference 13:56:57 Date: 12 May 2011 13:58:25 I am special stupid. I managed to schedule a customer meeting on top of this meeting. I am so sorry. the whole meeting was for issues I care about! 13:59:40 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011May/0058.html 13:59:59 I will wrap up as soon as I can. 14:00:07 (maybe they won't show) 14:00:58 zakim, who is on the call? 14:00:58 SW_RDFa()10:00AM has not yet started, manu 14:00:59 On IRC I see RRSAgent, ShaneM, tomayac, MacTed, webr3, ivan, manu, manu1, trackbot 14:01:11 zakim, dial ivan-voip 14:01:11 ok, ivan; the call is being made 14:01:36 zakim, who is here? 14:01:36 SW_RDFa()10:00AM has not yet started, ivan 14:01:37 On IRC I see RRSAgent, ShaneM, tomayac, MacTed, webr3, ivan, manu, manu1, trackbot 14:01:52 zakim, I am ??manu 14:01:53 sorry, manu, I do not see a party named '??manu' 14:06:51 Benjamin has joined #rdfa 14:07:53 Zakim, code? 14:07:53 the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), MacTed 14:08:10 Zakim, this is 7332 14:08:10 ok, MacTed; that matches SW_RDFa()10:00AM 14:08:11 zakim, who is on the phone 14:08:12 I don't understand 'who is on the phone', Benjamin 14:08:14 Zakim, who's here? 14:08:14 On the phone I see hta, ??P13, Ivan, ??P28, OpenLink_Software 14:08:16 On IRC I see Benjamin, Zakim, RRSAgent, ShaneM, tomayac, MacTed, webr3, ivan, manu, manu1, trackbot 14:08:22 Zakim, OpenLink_Software is temporarily me 14:08:22 +MacTed; got it 14:08:24 Zakim, mute me 14:08:24 MacTed should now be muted 14:09:00 Zakim, who's noisy? 14:09:11 MacTed, listening for 10 seconds I heard sound from the following: ??P28 (91%) 14:09:20 Zakim, ??p28 is Benjamin 14:09:20 +Benjamin; got it 14:09:24 Zakim, mute Benjamin 14:09:25 zakim, I am ??P13 14:09:26 :-) 14:09:26 Benjamin should now be muted 14:09:28 +manu; got it 14:10:07 zakim, unmute me 14:10:07 Benjamin should no longer be muted 14:10:15 zakim, mute me 14:10:15 Benjamin should now be muted 14:12:59 scribenick: ivan 14:13:47 topic: congrats 14:14:09 manu: we had a good publication, and also a semanticweb.com piece on the documents 14:14:10 http://semanticweb.com/on-various-rdf-api-s%E2%80%A6_b19815 14:14:40 Thank you Ivan for writing this article !!! 14:15:45 manu: ivan, you sent an email that there is a publishing moratorium next week 14:16:07 ... it gives us a little bit more time to review ben's document on rdf api 14:16:15 zakim, unmute me 14:16:15 Benjamin should no longer be muted 14:16:15 ... speaking of... 14:16:18 Topic: Update on spec progress 14:17:01 Benjamin: I fixed the examples, changed the environment to 'Data' 14:17:06 ... I fixed webidl 14:17:13 ... otherwise I did not do much 14:17:14 http://www.w3.org/2010/02/rdfa/sources/rdf-api/ 14:17:14 fwiw, headsets usually work far better than onboard microphones/speakers 14:17:26 ... what is left: language has to be fixed, 14:17:37 ... we have to discuss the projection, based on the email discussion 14:17:55 Benjamin: I added the set method to the projection 14:18:00 ... there are some issues on that 14:18:25 oopen issues on projections are: 14:18:32 s/oopen/open/ 14:18:37 nested projections 14:19:11 q+ 14:19:27 zakim, mute me 14:19:27 Benjamin should now be muted 14:19:36 ack ivan 14:19:51 Manu: The reason we did this was... 14:20:02 Ivan: Doing automatic projection generation is not a good idea, for all the reasons that Manu said. 14:20:40 Ivan: Niklas wanted one more method where when one looks at a triple w/ a URIRef, then what you get back is a Projection for that object being the subject. It's strictly a one-step indirection. 14:20:55 ... it may help to get over the situation where you have the duality of string vs. object. 14:21:15 ... it helps to overcome that and this is a fairly natural thing to do. It's fairly natural when the object in question is a blank node. 14:21:16 e.g., ben = ivan.getRel("foaf:knows") 14:21:42 Manu: What's the return type? 14:21:47 sequence of Projections or Projection? 14:22:02 q+ do we really need this? 14:22:47 q+ 14:22:47 manu: we had a choice on to get the 'first' or all in a sequence 14:22:50 ack Benjamin 14:22:51 ... maybe that is what we need 14:22:54 zakim, unmute me 14:22:54 Benjamin was not muted, Benjamin 14:23:00 get() vs. getAll() 14:23:03 Benjamin: I do not really we need 14:23:16 ... it is not a big deal to do it manually 14:23:36 ... even in the case of a blank node you get... 14:23:37 _:bnode1 14:23:56 manu: uri for a blank node? 14:24:02 ... we get only strings 14:24:15 ... the projections are not for low level objects 14:24:34 ... we cannot get the difference between an iriref and a string 14:24:47 ... if we were able to get the difference, then you are right, it does not matter 14:24:58 ... the reason we might want to have that 14:25:06 is it an issue in practice? we had this in the json discussions as well. some serializations cared, most simply didn't... 14:25:08 ... is that we cannot make the difference 14:25:23 var knows = ivan.get("foaf:knows"); 14:25:36 knows == "http://manu.sporny.org/webid" 14:26:01 ivan.get( "http://manu.sporny.org/webid") would work 14:26:10 data.getProjection("http://manu.sporny.org/webid") 14:26:49 manu: in that case we really do not need it 14:27:06 The blank node issue... 14:27:09 manu: for a blank node 14:27:13 knows == "_:bnode2" 14:27:26 data.getProjection("_:bnode2") ?? 14:27:28 why not: 14:27:28 _:bnode1 = ivan.get("foaf:knows") 14:27:28 ben = data.getProjection(_:bnode1) 14:27:36 q+ 14:28:01 manu: the reason I am afraid is when you merge multiple graph together then... 14:28:11 ... what happens then to the bnodes 14:28:57 ... the two graphs that are merged then things may go wrong because _:bnode1 may not point at the data you are thinking about 14:29:03 ack ivan 14:29:11 Ivan: That's the same issue I have w/ this. 14:29:24 Ivan: If we have bnodes, we are going to have to deal with them... 14:29:37 Zakim, unmute me 14:29:37 MacTed should no longer be muted 14:29:42 Ivan: It's a potentially dangerous thing to do. 14:29:56 Ted: It's a guidance question... 14:30:14 MacTed: blank nodes exist, but if we say if you can avoid using bnodes, do so 14:30:15 q+ 14:30:21 ack Ivan 14:30:28 Ivan: I don't disagree with that, Ted 14:30:43 q+ to ask if getRel and getRev really solve this? 14:31:03 Ivan: However, if we keep to the example of FOAF, the semantic web is full of bnodes... it's an issue that will be widespread - we should try to be as fool-proof as we can. 14:31:07 ack Benjamin 14:31:07 Benjamin, you wanted to ask if getRel and getRev really solve this? 14:31:37 Benjamin: if we have a subject and an object as bnodes 14:31:43 ... it is just the same... 14:31:45 q+ 14:31:50 ack ivan 14:31:51 maybe stupid idea: if we have a bnode, serialize it as a JSON-LD object, run a hash function over the JSON.stringified version of it, and give the bnode a uri at fixed.example.org/.well-known/{hash_result} 14:32:05 q+ to wonder whether or not "it's the same problem w/ JavaScript" 14:32:27 this would allow us to compare bnodes easily 14:33:06 Ivan: Maybe everything will be renumbered at runtime... you can never rely on a bnode ID after a graph merge, etc. 14:33:21 Ivan: The only thing you can ask is "is this a bnode" and "are these two bnodes the same"? 14:34:17 Benjamin: the only time this is an issue is at the parse, 14:34:28 zakim, mute me 14:34:28 Benjamin should now be muted 14:34:36 manu: but at the lower level we do a bunch of graph merge 14:34:57 Benjamin: I think we can put a warning in the document on the .parse() method because that's when this becomes an issue. 14:35:55 Ivan: I can see that if we put a warning in the document working... this may be something we learn more about in implementations. 14:35:57 ack manu 14:35:57 manu, you wanted to wonder whether or not "it's the same problem w/ JavaScript" 14:36:26 manu: getRel mechanism could solve this problem, even if you do a graph merge 14:36:36 ... if you had a programming language that was operated on references 14:37:07 ... if you do a graph merge, the references will still be fine 14:37:13 q+ 14:37:47 Manu: .getRel() could work across graph merges if we deal with languages that operate on references. 14:38:10 Ivan: Forget about blank nodes for a while - if I have a graph and ask for a Projection, that projection is all the triples that have a common subject. 14:38:48 ... I have a reference... then I do a merge. Will the projection have to be updated? Does it give me a current snapshot into the graph, or does it give me an auto-updated item. 14:39:25 Manu: If we deal w/ reference-based languages - we get an auto-updated item. 14:39:35 Ivan: When we deal with things that aren't just snapshots, that's when we get in trouble. 14:40:00 Ivan: If it is a snapshot, an implementation can optimize for it. If it's not a snapshot, every request on a projection has to go down to the graph and do a query. 14:41:27 manu: there is a middle ground, (a) snapshot, nothing changes (b) snapshot, number triples do not change, but the values do (c) it is not a snapshot, everything can change 14:41:27 q+ to say it has to be a snapshot. 14:41:58 manu: third option may become very complicated 14:42:17 ack ivan 14:42:54 zakim, unmute me 14:42:54 Benjamin should no longer be muted 14:42:58 Ivan: We agree on option #3 and option #1, not on option #2 14:43:13 Benjamin: if it is not a snapshot, then we have to solve racing conditions 14:43:14 Benjamin: if it is not a snapshot, we will have to deal with any sort of "waiting" condition. 14:43:26 ivan: yes, good point 14:43:45 Ivan: This has to be very clearly documented... 14:43:58 +??P36 14:44:11 zakim, ??P36 is ShaneM 14:44:11 +ShaneM; got it 14:44:13 zakim, mute me 14:44:13 Benjamin should now be muted 14:44:19 zakim, unmute me 14:44:19 Benjamin should no longer be muted 14:44:38 zakim, mute me 14:44:38 Benjamin should now be muted 14:44:45 zakim, unmute me 14:44:45 Benjamin should no longer be muted 14:44:47 Result of the discussion: projections are snapshots, and we do not need getRels 14:45:00 webr3 has joined #rdfa 14:45:06 zakim, mute me 14:45:06 Benjamin should now be muted 14:45:11 Topic: Term vs. Alias 14:45:14 q+ 14:45:17 ack Benjamin 14:45:18 http://www.w3.org/2010/02/rdfa/track/issues/89 14:45:18 Benjamin, you wanted to say it has to be a snapshot. 14:45:31 Zakim, mute Benjamin 14:45:31 Benjamin should now be muted 14:45:37 :-) 14:46:43 Topic: term vs. alias ? 14:46:47 Topic: Term vs. Alias 14:46:53 http://www.w3.org/2010/02/rdfa/track/issues/89 14:47:00 issue-89? 14:47:02 ISSUE-89 -- Decide what word we want to use to refer to the concept of RDFa terms - 'term' or 'alias' -- open 14:47:02 http://www.w3.org/2010/02/rdfa/track/issues/89 14:47:27 manu: this came up because nathan used 'alias' in the last interface 14:47:50 ... as ivan said we would have to change lots of documents if we wanted to use alias 14:48:04 ... and, if we decide to change, how to do that 14:48:06 q+ 14:48:15 +1 term 14:48:22 ShaneM: we should continue to use terms 14:48:48 ... it has a mind share, it is already in use in the area activity as well, i do not want to reeducate them, i do no see the advantage 14:49:04 ... alias is computer science, and term is more linguistic 14:49:10 +1 for term, fwiw 14:49:11 ... term seesm to fit in that 14:49:20 s/seesm/seems/ 14:49:25 ack ivan 14:49:53 Ivan: I am a bit afraid that we're going to have to change all the docs/implementations/blog posts... 14:49:59 Oh yeah! And datatypes, XHTML M12N, etc. ick 14:50:07 Ivan: There doesn't seem to be a very big advantage for making the change... it's a bit too late to make this change. 14:50:09 q+ 14:50:23 Ivan: Keep terms. 14:50:32 ack ivan 14:50:37 manu: I had a different view on this 14:50:46 ... last time I felt strongly to move to alias 14:51:10 ... people would understand what alias is for, better than a term 14:51:16 ... after all this is what we do 14:51:30 ... it invokes more an alias than a term 14:51:33 q+ 14:51:36 ack manu 14:51:47 q+ to discuss what a term really is 14:51:48 manu: this is the strongest argument I have 14:52:03 ack ivan 14:52:07 ack ivan 14:52:26 Ivan: If we had this discussion a year ago, I would fully agree with you. 14:52:45 Ivan: The argument resonates with me - it's a bit too late. We need a stronger argument now. 14:52:48 ack ShaneM 14:52:48 ShaneM, you wanted to discuss what a term really is 14:53:02 ShaneM: you said something I may not agree with 14:53:22 ... it is true internally that we have a mechanism to take a string and map it to a uri 14:53:34 ... but that is not how I explain things to people 14:53:45 .. it is a component of a vocabulary 14:54:07 ... it is a term. it expands to a uri, but for our audience 'you can use this word, and means _this_' 14:54:21 ... we would like to attract the microformat community with this 14:54:28 ... they not care about uris 14:54:36 PROPOSAL: keep terms 14:54:45 +1 14:54:50 +1 14:54:51 +1 14:54:58 +1 14:55:02 +1 14:55:16 RESOLVED: Keep the word 'term' - do not use the word 'alias'. 14:55:17 +1 14:55:55 Topic: Formulation on fragid in RDFa Core 14:56:06 http://www.w3.org/2010/02/rdfa/track/issues/94 14:56:10 manu: this boils down removing 2 words from the spec 14:56:35 ... the issue the tag / j rees had with the spec is that we say the word 'at present', and we should not say it 14:56:50 ... if we do that, they are happy 14:58:17 PROPOSAL: Remove the words "at present" when discussing fragment identifiers. The editor will create language that is in line with the TAG's request. 14:58:20 +1 14:58:22 +1 14:58:25 +1 14:58:26 +1 14:58:34 +1 14:58:40 RESOLVED: Remove the words "at present" when discussing fragment identifiers. The editor will create language that is in line with the TAG's request. 14:59:32 +1 :-) 14:59:55 ACTION: Manu to do official 2nd LC response to ISSUE-94. 15:00:03 Created ACTION-77 - Do official 2nd LC response to ISSUE-94. [on Manu Sporny - due 2011-05-19]. 15:00:05 Topic: IRI vs. URI References 15:00:33 http://www.w3.org/2010/02/rdfa/track/issues/87 15:00:37 ISSUE-87? 15:00:38 ISSUE-87 -- IRIs vs URI References -- open 15:00:38 http://www.w3.org/2010/02/rdfa/track/issues/87 15:00:54 manu: misha asked us to use the same terminology than the rest of the document 15:01:05 ... ShaneM explained the reasoning on the mailing list 15:03:11 I have to jump to another call... so make good decisions! :-) 15:03:14 -MacTed 15:04:17 http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Mar/0069.html 15:05:58 http://www.résumé.org 15:06:13 Shane responded: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Mar/0067.html 15:06:25 Mischa's response to Shane's response: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Mar/0069.html 15:06:40 xsn--???? 15:07:18 xn--rsum-bpad.org 15:07:56 manu, depends on your browser 15:08:00 some show it, some hide it 15:08:10 in the background they punicode it 15:08:43 So for: www.zürich.com does RDFa output that? Or does it output: www.xn--zrich-kva.com 15:10:21 Can RDFa output the following: ? for a subject? 15:13:15 we have problems with e.g. ntriples, which only allow ascii, rdfa has no problem with it 15:14:24 tomayac: ahh 15:15:53 ACTION: Manu to write e-mail to RDF WG chairs about ISSUE-87 - we can't go to CR without this being resolved. 15:15:53 Created ACTION-78 - Write e-mail to RDF WG chairs about ISSUE-87 - we can't go to CR without this being resolved. [on Manu Sporny - due 2011-05-19]. 15:17:15 http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0469.html 15:18:16 shouldn't we default to punycoding all IRIs, so treat them always the same. least common multiple... 15:23:29 Section 6 says "The lexical space of a CURIE is as defined in curie below. The value space is the set of URIs." 15:24:00 -Benjamin 15:24:19 bye 15:27:40 href="http://www.сделат картинки.com/example" is what in the DOM within a browser? 15:27:56 ShaneM: No, that's not in the DOM 15:28:29 http://www.xn--zrich-kva.de/ 15:30:12 Schweizer Küche 15:34:16 Schweizer Küche 15:34:39 check this: http://www.aptest.com/iri.html 15:34:44 my irc client punycodes... the 2nd link had a ü in it 15:35:48 RDFa processors should allow: Schweizer Küche 15:36:48 hmmm, personally i expect the rdfa processors to punycode. just sayin'... 15:45:04 -Ivan 15:45:05 -ShaneM 15:45:05 -hta 15:45:07 SW_RDFa()10:00AM has ended 15:45:10 Attendees were hta, Ivan, MacTed, Benjamin, manu, ShaneM 15:48:06 we kinda have this issue already: http://dbpedia.org/page/Tie_%28draw%29 is NOT the same as http://dbpedia.org/page/Tie_(draw), where http://en.wikipedia.org/wiki/Tie_(draw) is the same as http://en.wikipedia.org/wiki/Tie_%28draw%29 16:10:12 tomayac, true - but I'm wondering if the decision we make would make that case even worse? or better? 16:10:39 better imho, as we define a rule everyone has to accept 16:10:42 and for that matter - what is "worse" or "better" 16:10:58 we can also make the rule that everyone has to uplift (de-punycodify) their uris 16:11:17 i dont really care, however, tend to downlift, as this is what browsers do 16:11:18 does that mean punycoding? How do you think people in Japan, China, Middle East will feel if all of their domain names can't be expressed in the natural language? 16:11:44 meaning, non-ascii is a second-class citizen in RDF? 16:11:51 i agree! fair argument 16:12:06 I do agree w/ you that it would be good to have one rule that everyone follows. 16:12:21 but i'd say: it's mainly a perception thing. just as people dont look at the bits in http... 16:12:27 I do also think that N-Triples is wrong, and so are the way that Internationalized Domain Name identifiers were done. 16:12:29 ...people dont directly look at triples 16:13:04 sure, /some/ people don't look at triples... but I'm concerned about the developers that do look at triples. 16:13:10 whatever way we choose, let's choose one and make it a rule everyone has to obey to 16:13:40 devs will write an abstraction layer on top that allows them to see nice triples 16:13:45 my other concern is that we can tell people to "obey this rule", but if it doesn't affect implementations (de-punycoding values)... then I don't think people will listen. 16:13:52 or they think binary anyways ;-) 16:13:59 heh 16:14:06 I think some developers will and some developers won't 16:14:09 how about a SHOULD 16:14:23 I'm fine w/ a MUST 16:14:27 but I don't think people will listen 16:14:43 and rdfa distillers (de)punycode silently (up or downlift, whatever we decide for) 16:14:49 (or rather, 80% will listen, but others will not) 16:15:01 ^^ 16:15:12 and that will lead to diverging implementations... 16:15:30 so, are you saying that RDFa Processors, if upon seeing a punycoded value, will de-punycode the value? 16:15:45 before emitting the triple? 16:15:56 or the other way round, yepp. so "incorrect" triples would be auto-corrected 16:16:18 ok, so what happens when the author intended to have the value 'punycoded' due to a reason that we cannot forsee. 16:16:38 Their systems team has some strange requirement that "all IDNs must be punycoded" and they end up creating identifiers w/ punycoded values? 16:16:59 (my underlying argument is that whether or not to punycode should be a decision made by the developers - not us.) 16:17:29 ok, but then we live with uncertainty whether people are talking about the same, or not 16:17:37 but fair point of course! 16:17:40 yes, but it's their mistake to make :) 16:18:02 I don't see how we could do either, without screwing someone up somewhere in the world. 16:18:17 and ultimately, we've always settled on: Give the power to the authors. 16:18:25 the best compromises are those where no one is happy 16:18:32 but everyone can live with ;-) 16:18:33 haha :) 16:18:49 maybe the problem isnt that big 16:19:02 a couple of owl:sameAsses here and there 16:19:06 sure, if it were up to me I'd go back to the IDN people and tell them that they should've fixed their broken-ass system instead of introducing punycoded values. 16:19:33 the IDN punycoded stuff is a non-solution. 16:19:52 ... and I'd tell the N-Triples people to upgrade their spec to support UTF-8 16:20:00 well, we call this legacy ;-) 16:20:10 Down with legacy! 16:21:33 More seriously - I think the decisions that we make with RDFa should be forward-looking... not attempting to shoe-horn some badly designed legacy hack into RDFa. 16:21:58 as i said, i can live with the up-lifting rule 16:22:05 we just need to make it 16:22:41 What I'd be happy with is "don't touch the sequence of characters, except when canonicalizing." 16:26:04 "be liberal in what you accept, be conservative in what you generate..." 16:26:35 (I think this is the first time I've encountered "punycode" ... what's that mean?) 16:27:25 A legacy hack: http://en.wikipedia.org/wiki/Punycode 16:27:59 The only reason the hack was put in there was so that DNS could express Internationalized names. 16:28:12 so, rather than requiring that DNS systems upgrade to allow UTF-8 16:28:43 they put a hack in there that is now generating these awful URLs that nobody can read 16:29:05 it's also lead to a number of phishing attacks in browsers that don't de-punycode values before putting them in the address bar. 16:29:43 well... URLs *are* supposed to be considered opaque -- so readability *should* be a null argument 16:29:54 wrt to phising: this still is a problem if utf-8 were supported directly 16:30:14 tomayac: true - but now we have 2 phising vectors instead of just 1 16:30:40 ok, so punycode is not so different from percent-encoding/URL-encoding ... 16:30:41 we see this in ads as well where people try to re-write iPhone with look-alike chars to trick the trademark filters... 16:31:00 MacTed: Yes, it's just another way to do percent-encoding/URL-encoding 16:31:04 it's an rfc actually: http://tools.ietf.org/html/rfc3492 16:31:48 and we're down again to lexic vs syntactic vs semantic equivalence 16:32:52 1 == true 16:32:52 true 16:32:52 1 === true 16:32:53 false 16:33:14 we need owl:reallySameAs ;-) 16:33:28 *supposedly* there is only one valid string for each URI, which includes all required percent encoding and no more ... but because tools have been badly behaved for a long time, nobody's really quite sure what that string is for any complex URI 16:33:59 owl:sameAs is perfectly fine as it is -- even when used incorrectly 16:34:33 ask harry halpin this question 16:34:47 nameA owl:sameAs nameB 16:34:48 well, you didn't ask a question 16:34:56 two names for same thing 16:35:25 yeah, this is what i was saying above. maybe a couple of owl:sameAs between punycode uri and non-punycode uri can fix the world 16:35:28 like "Ted" and "Theodore" and "Teddy" ... within a namespace 16:36:18 such would help fix the world, for sure ... given good reasoning engines 16:36:39 +1 16:36:54 "given good reasoning engines" being the operative phrase. 16:36:59 Know of any good ones :P 16:37:31 where good == performant, open source, good documentation 16:37:41 hooray for the web of data as one, single database ;-) 16:39:38 I like Virtuoso.... ;-) 16:39:57 hehe :) 16:45:38 ShaneM has left #rdfa 17:00:46 Zakim has left #rdfa 18:37:53 ShaneM has joined #rdfa 18:37:55