Chatlog 2011-05-12

See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.

13:56:52 <RRSAgent> RRSAgent has joined #rdfa
13:56:52 <RRSAgent> logging to http://www.w3.org/2011/05/12-rdfa-irc
13:56:54 <trackbot> RRSAgent, make logs world
13:56:54 <Zakim> Zakim has joined #rdfa
13:56:56 <trackbot> Zakim, this will be 7332
13:56:56 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 4 minutes
13:56:57 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:56:57 <trackbot> Date: 12 May 2011
13:59:40 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011May/0058.html
13:59:45 <manu> Present: Manu, Benjamin, Shane, Thomas, Ted, Ivan
14:00:58 <manu> zakim, who is on the call?
14:00:58 <Zakim> SW_RDFa()10:00AM has not yet started, manu
14:00:59 <Zakim> On IRC I see RRSAgent, ShaneM, tomayac, MacTed, webr3, ivan, manu, manu1, trackbot
14:01:11 <ivan> zakim, dial ivan-voip
14:01:11 <Zakim> ok, ivan; the call is being made
14:01:36 <ivan> zakim, who is here?
14:01:36 <Zakim> SW_RDFa()10:00AM has not yet started, ivan
14:01:37 <Zakim> On IRC I see RRSAgent, ShaneM, tomayac, MacTed, webr3, ivan, manu, manu1, trackbot
14:01:52 <manu> zakim, I am ??manu
14:01:53 <Zakim> sorry, manu, I do not see a party named '??manu'
14:06:51 <Benjamin> Benjamin has joined #rdfa
14:07:53 <MacTed> Zakim, code?
14:07:53 <Zakim> 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 <MacTed> Zakim, this is 7332
14:08:10 <Zakim> ok, MacTed; that matches SW_RDFa()10:00AM
14:08:11 <Benjamin> zakim, who is on the phone
14:08:12 <Zakim> I don't understand 'who is on the phone', Benjamin
14:08:14 <MacTed> Zakim, who's here?
14:08:14 <Zakim> On the phone I see Tom, ??P13, Ivan, ??P28, OpenLink_Software
14:08:16 <Zakim> On IRC I see Benjamin, Zakim, RRSAgent, ShaneM, tomayac, MacTed, webr3, ivan, manu, manu1, trackbot
14:08:22 <MacTed> Zakim, OpenLink_Software is temporarily me
14:08:22 <Zakim> +MacTed; got it
14:08:24 <MacTed> Zakim, mute me
14:08:24 <Zakim> MacTed should now be muted
14:09:00 <MacTed> Zakim, who's noisy?
14:09:11 <Zakim> MacTed, listening for 10 seconds I heard sound from the following: ??P28 (91%)
14:09:20 <MacTed> Zakim, ??p28 is Benjamin
14:09:20 <Zakim> +Benjamin; got it
14:09:24 <MacTed> Zakim, mute Benjamin
14:09:25 <manu> zakim, I am ??P13
14:09:26 <Zakim> Benjamin should now be muted
14:09:28 <Zakim> +manu; got it
14:10:07 <Benjamin> zakim, unmute me
14:10:07 <Zakim> Benjamin should no longer be muted
14:10:15 <Benjamin> zakim, mute me
14:10:15 <Zakim> Benjamin should now be muted
14:12:59 <ivan> scribenick: ivan
14:13:47 <ivan> topic: RDF Interfaces publication
14:14:09 <ivan> manu: we had a good publication, and also a semanticweb.com piece on the documents
14:14:10 <manu> http://semanticweb.com/on-various-rdf-api-s%E2%80%A6_b19815
14:14:40 <Benjamin> Thank you Ivan for writing this article !!!
14:15:45 <ivan> manu: ivan, you sent an email that there is a publishing moratorium next week
14:16:07 <ivan> ... it gives us a little bit more time to review Ben's document on RDF API
14:16:15 <Benjamin> zakim, unmute me
14:16:15 <Zakim> Benjamin should no longer be muted
14:16:15 <ivan> ... speaking of...
14:16:18 <manu> Topic: Update on spec progress
14:17:01 <ivan> Benjamin: I fixed the examples, changed the environment to 'Data'
14:17:06 <ivan> ... I fixed the WebIDL
14:17:13 <ivan> ... otherwise I did not make many changes
14:17:14 <manu> http://www.w3.org/2010/02/rdfa/sources/rdf-api/
14:17:26 <ivan> ... what is left: prose/flow has to be fixed,
14:17:37 <ivan> ... we have to discuss the projection, based on the email discussion
14:17:55 <ivan> Benjamin: I added the set method to the projection
14:18:00 <ivan> ... there are some issues on that
14:18:25 <Benjamin> open issues on projections are:
14:18:37 <Benjamin> nested projections
14:19:11 <ivan> q+
14:19:27 <Benjamin> zakim, mute me
14:19:27 <Zakim> Benjamin should now be muted
14:19:36 <manu> ack ivan
14:19:51 <manu> Manu: The reason we do not allow nested projections is that it is difficult to figure out where top stop travelling down the nested tree. If you have a graph with a billion triples and you build a projection for a subject, do you include all 500 million links? If you nest them, how do you do so (depth-first vs. breadth first)? These raise very complicated implementation questions that will inevitably make the spec more complicated than necessary. Let's not include the ability to do multiple-levels of projections. If a developer wants to get a relationship, they can just perform another query and build another Projection.
14:20:02 <manu> Ivan: Doing automatic projection generation is not a good idea, for all the reasons that Manu said.
14:20:40 <manu> 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 <manu> ... it may help to get over the situation where you have the duality of string vs. object.
14:21:15 <manu> ... 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 <Benjamin> e.g., ben = ivan.getRel("foaf:knows")
14:21:42 <manu> Manu: What's the return type?
14:21:47 <manu> sequence of Projections or Projection? I think it's a sequence.
14:22:02 <Benjamin> q+ do we really need this?
14:22:47 <Benjamin> q+
14:22:47 <ivan> manu: we had a choice on to get the 'first' or all in a sequence.. that's why we have .get() vs. .getAll(). The same should apply to .getRel() or .getRels()?
14:22:50 <manu> ack Benjamin
14:22:51 <ivan> ... maybe that is what we need?
14:22:54 <Benjamin> zakim, unmute me
14:22:54 <Zakim> Benjamin was not muted, Benjamin
14:23:03 <ivan> Benjamin: I do not think we really we need this feature
14:23:16 <ivan> ... it is not a big deal to do it manually
14:23:36 <ivan> ... even in the case of a blank node you get what you were looking for.
14:23:37 <manu> What about _:bnode1?
14:23:56 <ivan> manu: How do we express the uri for a blank node? 
14:24:02 <ivan> ... we get only strings and native datatypes back from a projection
14:24:15 <ivan> ... the projections are not for low level objects
14:24:34 <ivan> ... we cannot get the difference between an IRI reference and a string
14:24:47 <ivan> ... if we were able to get the difference, then you are right, it does not matter
14:24:58 <ivan> ... not being able to determine the type of an object is a reason that we may want to have getRel()...
14:25:06 <tomayac> is it an issue in practice? we had this in the JSON discussions as well. some serializations cared, most simply didn't...
14:25:23 <manu> var knows = ivan.get("foaf:knows");
14:25:36 <manu> knows == "http://manu.sporny.org/webid"
14:26:10 <manu> data.getProjection("http://manu.sporny.org/webid")
14:26:49 <ivan> manu: Nevermind, thinking through it - we can just use strings. I now agree with Benjamin, we really do not need getRel() when dealing with IRIs.
14:27:06 <manu> Now, what about blank nodes?
14:27:09 <ivan> manu: for a blank node
14:27:13 <manu> knows == "_:bnode2"
14:27:26 <manu> data.getProjection("_:bnode2") ?? Is this what we should do?
14:27:28 <Benjamin> why not: bnode1 = ivan.get("foaf:knows")
14:27:28 <Benjamin> ben = data.getProjection(bnode1)
14:27:36 <ivan> q+
14:28:01 <ivan> manu: the reason I am concerned is because the blank node names change when you merge multiple graph together...
14:28:11 <ivan> ... what happens then to the bnodes?
14:28:57 <ivan> ... 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 <manu> ack ivan
14:29:11 <manu> Ivan: That's the same issue I have w/ this.
14:29:24 <manu> Ivan: If we have bnodes, we are going to have to deal with them...
14:29:37 <MacTed> Zakim, unmute me
14:29:37 <Zakim> MacTed should no longer be muted
14:29:42 <manu> Ivan: It's a potentially dangerous thing to do.
14:29:56 <manu> Ted: I think that this is a guidance question...
14:30:14 <ivan> MacTed: blank nodes exist, but if we say if you can avoid using bnodes, do so
14:30:15 <ivan> q+
14:30:21 <manu> ack Ivan
14:30:28 <manu> Ivan: I don't disagree with that, Ted
14:30:43 <Benjamin> q+ to ask if getRel and getRev really solve this?
14:31:03 <manu> Ivan: However, if we keep to the examples 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 <manu> ack Benjamin
14:31:07 <Zakim> Benjamin, you wanted to ask if getRel and getRev really solve this?
14:31:37 <ivan> Benjamin: if we have a subject and an object as bnodes
14:31:43 <ivan> ... it is just the same problem...
14:31:45 <ivan> q+
14:31:50 <manu> ack ivan
14:31:51 <tomayac> 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 <manu> q+ to wonder whether or not "it's the same problem w/ JavaScript"
14:32:27 <tomayac> this would allow us to compare bnodes easily
14:32:30 <manu> Yes, but I don't think this is a bnode comparison problem, is it? It's a "oh crap, I lost the reference to the bnode because it was renamed" problem...
14:33:06 <manu> Ivan: Maybe everything will be renumbered at runtime... you can never rely on a bnode ID after a graph merge, etc.
14:33:21 <manu> Ivan: The only thing you can ask is "is this a bnode" and "are these two bnodes the same"?
14:34:17 <ivan> Benjamin: the only time this is an issue is at parse-time
14:34:28 <Benjamin> zakim, mute me
14:34:28 <Zakim> Benjamin should now be muted
14:34:36 <ivan> manu: but at the lower level we do a bunch of graph merges, it's not just a parse-time issue.
14:34:57 <manu> 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 <manu> 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 <manu> ack manu
14:35:57 <Zakim> manu, you wanted to wonder whether or not "it's the same problem w/ JavaScript"
14:36:26 <ivan> manu: JavaScript could solve this problem, even if you do a graph merges
14:36:36 <ivan> ... if you had a programming language that uses pure references
14:37:07 <ivan> ... if you do a graph merge, the references will still be fine after the merge. However, this is relying on a language feature that is not universally available
14:37:13 <ivan> q+
14:37:47 <manu> Manu: .getRel() could work across graph merges if we deal with languages that operate on references.
14:38:10 <manu> 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 <manu> ... 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> Manu: If we deal w/ reference-based languages - we get an auto-updated item.
14:39:35 <manu> Ivan: When we deal with things that aren't just snapshots, that's when we get in trouble.
14:40:00 <manu> 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 <ivan> manu: there is a middle ground, (a) snapshot, nothing changes (b) snapshot, number triples do not change, but the values do because they are pure references (c) it is not a snapshot, everything can change triples and values
14:41:27 <Benjamin> q+ to say it has to be a snapshot.
14:41:58 <ivan> manu: third option may become very complicated
14:42:17 <manu> ack ivan
14:42:54 <Benjamin> zakim, unmute me
14:42:54 <Zakim> Benjamin should no longer be muted
14:42:58 <manu> Ivan: We agree on option #3 and option #1, not on option #2
14:43:13 <ivan> Benjamin: if it is not a snapshot, then we have to solve race conditions, we will have to deal with any sort of "waiting" condition.
14:43:26 <ivan> ivan: yes, good point
14:43:45 <manu> Ivan: This has to be very clearly documented... seems like we think that getRel() is not necessary and that bnodes can be kicked out from under you during parsing and graph merges.
14:43:58 <Zakim> +??P36
14:44:11 <ivan> zakim, ??P36 is ShaneM 
14:44:11 <Zakim> +ShaneM; got it
14:44:13 <Benjamin> zakim, mute me
14:44:13 <Zakim> Benjamin should now be muted
14:44:19 <Benjamin> zakim, unmute me
14:44:19 <Zakim> Benjamin should no longer be muted
14:44:38 <Benjamin> zakim, mute me
14:44:38 <Zakim> Benjamin should now be muted
14:44:45 <Benjamin> zakim, unmute me
14:44:45 <Zakim> Benjamin should no longer be muted
14:44:47 <ivan> Result of the discussion: projections are snapshots (option a), bnodes can disappear during parsing/merges, and we do not need getRel()
14:45:00 <webr3> webr3 has joined #rdfa
14:45:06 <Benjamin> zakim, mute me
14:45:31 <MacTed> Zakim, mute Benjamin
14:45:31 <Zakim> Benjamin should now be muted
14:46:47 <manu> Topic: ISSUE-89: Term vs. Alias
14:46:53 <manu> http://www.w3.org/2010/02/rdfa/track/issues/89
14:47:27 <ivan> manu: this came up because nathan used 'alias' in the last RDF interface document.
14:47:50 <ivan> ... as Ivan said we would have to change lots of documents if we wanted to use alias
14:48:04 <ivan> ... and, if we decide to change, how to do that
14:48:06 <ivan> q+
14:48:15 <MacTed> +1 term
14:48:22 <ivan> ShaneM: we should continue to use terms
14:48:48 <ivan> ... it has a mind share, it is already in use in the area activity as well, i do not want to re-educate them, i do no see the advantage
14:49:04 <ivan> ... alias is computer science, and term is more linguistic... RDFa attempts to be more linguistic than computer-sciencey
14:49:10 <tomayac> +1 for term, fwiw
14:49:11 <ivan> ... term seems to fit better than alias
14:49:25 <manu> ack ivan
14:49:53 <manu> Ivan: I am a bit afraid that we're going to have to change all the docs/implementations/blog posts...
14:49:59 <ShaneM> Oh yeah! And datatypes, XHTML M12N, etc.  ick
14:50:07 <manu> 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 <manu> q+
14:50:23 <manu> Ivan: Keep terms.
14:50:32 <manu> ack ivan
14:50:37 <ivan> manu: I had a different view on this
14:50:46 <ivan> ... I had just come to the conclusion that we should move to alias
14:51:10 <ivan> ... English-speaking people would understand what 'alias' means faster than they would understand 'term', IMHO
14:51:16 <ivan> ... after all this is what we do, we 'alias' a URI. We don't 'term' a URI.
14:51:30 <ivan> ... it invokes more of what an alias is than what a term is.
14:51:33 <ivan> q+
14:51:36 <ivan> ack manu 
14:51:47 <ShaneM> q+ to discuss what a term really is
14:51:48 <ivan> manu: this is the strongest argument I have, and it's not really that strong of an argument.
14:52:03 <manu> ack ivan
14:52:07 <ivan> ack ivan
14:52:26 <manu> Ivan: If we had this discussion a year ago, I would fully agree with you.
14:52:45 <manu> Ivan: The argument resonates with me - it's a bit too late. We need a stronger argument now.
14:52:48 <manu> ack ShaneM
14:52:48 <Zakim> ShaneM, you wanted to discuss what a term really is
14:53:02 <ivan> ShaneM: you said something I may not agree with
14:53:22 <ivan> ... it is true internally that we have  a mechanism to take a string and map it to a uri
14:53:34 <ivan> ... but that is not how I explain things to people
14:53:45 <ivan> .. I say that a 'term' is a component of a vocabulary, which is easier to understand.
14:54:07 <ivan> ... it is a term. it expands to a uri, but for our audience 'you can use this word, and means _this_'. How vocabularies contain terms that lead to definitions.
14:54:21 <ivan> ... we would like to attract the microformat community with this
14:54:28 <ivan> ... they not care about URIs, but they do care about terms.
14:54:36 <ivan> PROPOSAL: Keep the word 'term' - do not use the word 'alias'.
14:54:45 <ivan> Ivan: +1
14:54:50 <MacTed> +1
14:54:51 <tomayac> +1
14:54:58 <manu> +1
14:55:02 <Benjamin> +1
14:55:16 <manu> RESOLVED: Keep the word 'term' - do not use the word 'alias'.
14:55:17 <ShaneM> +1
14:55:55 <manu> Topic: ISSUE-94: Formulation on fragid in RDFa Core
14:56:06 <manu> http://www.w3.org/2010/02/rdfa/track/issues/94
14:56:10 <ivan> manu: this boils down removing 2 words from the spec
14:56:35 <ivan> ... the issue the TAG / Jonathan Rees had with the spec is that we say the word 'at present', and we should not say it
14:56:50 <ivan> ... if we do that, they are happy
14:58:17 <manu> 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 <manu> +1
14:58:22 <ivan> Ivan: +1
14:58:25 <tomayac> +1
14:58:26 <Benjamin> +1
14:58:34 <ShaneM> +1
14:59:35 <MacTed> +1  :-)
14:58:40 <ivan> 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:55 <manu> ACTION: Manu to do official 2nd LC response to ISSUE-94.
15:00:03 <trackbot> Created ACTION-77 - Do official 2nd LC response to ISSUE-94. [on Manu Sporny - due 2011-05-19].
15:00:05 <manu> Topic: ISSUE-87: IRI vs. URI References
15:00:33 <manu> http://www.w3.org/2010/02/rdfa/track/issues/87
15:00:54 <ivan> manu: Mischa asked us to use the same terminology as the rest of the RDF community
15:01:05 <ivan> ... ShaneM explained the reasoning on the mailing list
15:03:14 <Zakim> -MacTed
15:04:17 <ShaneM> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Mar/0069.html
15:05:58 <ivan> What happens when one expresses this in RDFa in @href: http://www.résumé.org/
15:06:13 <manu> Shane responded: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Mar/0067.html
15:06:25 <manu> Mischa's response to Shane's response: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Mar/0069.html
15:07:18 <tomayac> xn--rsum-bpad.org
15:07:56 <tomayac> manu, depends on your browser
15:08:00 <tomayac> some show it, some hide it
15:08:10 <tomayac> in the background they punycode it
15:08:43 <manu> So for: www.zürich.com does RDFa output that? Or does it output: www.xn--zrich-kva.com
15:10:21 <manu> Can RDFa output the following: <www.сделат картинки.com> ? for a subject?
15:13:15 <tomayac> we have problems with e.g. ntriples, which only allow ascii, rdfa has no problem with it
15:14:24 <ShaneM> tomayac: ahh
15:14:28 <ShaneM> Ivan: We need to get the RDF WG and Semantic Web Coordination group involved.
15:15:53 <manu> 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 <trackbot> 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 <ivan> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0469.html
15:18:16 <tomayac> shouldn't we default to punycoding all IRIs, so treat them always the same. least common multiple...
15:18:18 <manu> I don't think that we should do that.
15:23:29 <ShaneM> 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 <Zakim> -Benjamin
15:24:19 <Benjamin> bye
15:27:40 <ShaneM> href="http://www.сделат картинки.com/example" is what in the DOM within a browser?
15:27:56 <manu> ShaneM: No, that's not in the DOM
15:28:29 <tomayac> http://www.xn--zrich-kva.de/
15:30:12 <tomayac> <a href="http://www.xn--schweizer-kche-qsb.de/">Schweizer Küche</a>
15:34:16 <tomayac> <a href="http://www.xn--schweizer-kche-qsb.de/">Schweizer Küche</a>
15:34:39 <ShaneM> check this: http://www.aptest.com/iri.html
15:34:44 <tomayac> my irc client punycodes... the 2nd link had a ü in it
15:35:48 <manu> RDFa processors should allow: <a href="http://www.schweizer-küche.de/">Schweizer Küche</a>
15:35:48 <manu> ... lots of discussion on how to best proceed with RDFa processors and how they may affect URLs and IRIs that are generated ...
15:36:48 <tomayac> hmmm, personally i expect the rdfa processors to punycode. just sayin'...
15:45:04 <Zakim> -Ivan
15:45:05 <Zakim> -ShaneM
15:45:05 <Zakim> -Thomas
15:45:07 <Zakim> SW_RDFa()10:00AM has ended
15:45:10 <Zakim> Attendees were Thomas, Ivan, MacTed, Benjamin, manu, ShaneM
15:48:06 <tomayac> 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
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000309