Chatlog 2010-08-26

From RDFa Working Group Wiki
Jump to: navigation, search

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

14:01:52 <RRSAgent> RRSAgent has joined #rdfa
14:01:52 <RRSAgent> logging to
14:01:53 <csarven> csarven has joined #rdfa
14:01:54 <trackbot> RRSAgent, make logs world
14:01:54 <Zakim> Zakim has joined #rdfa
14:01:56 <trackbot> Zakim, this will be 7332
14:01:56 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start now
14:01:57 <trackbot> Meeting: RDFa Working Group Teleconference
14:01:57 <trackbot> Date: 26 August 2010
14:02:00 <manu> zakim, code?
14:02:00 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+ tel:+44.203.318.0479), manu
14:02:06 <Steven> zakim, dial steven-617
14:02:11 <Zakim> ok, Steven; the call is being made
14:02:13 <Zakim> SW_RDFa()10:00AM has now started
14:02:17 <Zakim> +Steven
14:02:24 <Steven> zakim, who is here?
14:02:37 <Zakim> On the phone I see Steven
14:02:45 <manu> uhh... I'm pretty sure I joined too?
14:02:53 <Zakim> On IRC I see csarven, RRSAgent, Benjamin, manu, kennyluck, Steven, ivan, trackbot
14:02:59 <Zakim> +manu
14:03:01 <ivan> zakim, dial ivan-voip
14:03:05 <kennyluck> kennyluck has left #rdfa
14:03:12 <Zakim> ok, ivan; the call is being made
14:03:16 <Zakim> +Ivan
14:04:09 <Benjamin> argh, the french number doesn't work
14:05:12 <manu> manu has changed the topic to: RDFa telecon Agenda: (manu)
14:05:28 <manu> zakim, who is on the call?
14:05:28 <Zakim> On the phone I see Steven, manu, Ivan
14:05:42 <Benjamin> uk number is busy
14:06:22 <Steven> zakim, ports?
14:06:22 <Zakim> I see 92 ports in service, 51 ports idle
14:07:05 <Benjamin> Strange, the connection to the french number breaks after a few seconds. 
14:07:34 <Zakim> +??P37
14:08:01 <manu> zakim, who is on the call?
14:08:01 <Zakim> On the phone I see Steven, manu, Ivan, ??P37
14:08:03 <Zakim> +ShaneM
14:08:03 <ShaneM> ShaneM has joined #rdfa
14:08:07 <Benjamin> zakim, ??P37 is Benjamin
14:08:07 <Zakim> +Benjamin; got it
14:08:59 <ShaneM> zakim, who is here?
14:08:59 <Zakim> On the phone I see Steven, manu, Ivan, Benjamin, ShaneM
14:09:00 <Zakim> On IRC I see ShaneM, Zakim, csarven, RRSAgent, Benjamin, manu, Steven, ivan, trackbot
14:09:25 <ivan> scribe: ivan
14:09:31 <ivan> scribenick: ivan
14:09:35 <manu> Agenda:
14:10:33 <ivan> manu: any addition to the agenda?
14:10:39 <ivan> (stunned silence...)
14:10:43 <ivan> Topic: ISSUE-28: Nathan's reported RDFa API Errors and Omissions
14:10:53 <manu>
14:11:08 <ivan> manu: we went over the first 1 1/2 emails
14:11:10 <manu>
14:11:13 <ivan> ... pick up where we left off
14:11:31 <ivan> ... we got through the set mapping call comment
14:11:47 <ivan> ... we disagreed with him, we want the js interface to pass around strings most of the time
14:12:09 <manu> DataContext ::setMapping ("foaf", "");
14:12:17 <manu> DataContext ::setMapping ("foaf", new IRI(""));
14:12:20 <ivan> nathan wanted to do the second
14:12:47 <manu> DataContext ::setMapping ("foaf",""));
14:12:49 <ivan> manu: we got complaints from people that creating IRIs that way is a bad idea
14:12:53 <manu> DataContext ::setMapping ("foaf", "");
14:12:58 <ivan> so we have to change to something like the one above
14:13:12 <ivan> manu: so we would prefer to stick with what is in the spec
14:13:21 <ivan> (no disagreements)
14:13:50 <ivan> manu: the other issue is in one of the webidl desc we have to pass a string (iterate call)
14:14:07 <manu>
14:14:24 <ivan> this is the email response to nathan
14:14:44 <manu>
14:15:08 <ivan> manu: we actually changed the iterator to a completely different pattern, so actually that is a non-issue for now
14:15:30 <ivan> ... which benjamin, mark and I have discussed
14:15:34 <ivan> ... but no response on that yet
14:15:39 <Benjamin> +1
14:16:06 <ivan> 0
14:16:14 <Steven> 0
14:16:41 <ivan> manu: nathan's last comment that the type of the parser cannot be set
14:17:08 <ivan> ... we had some discussions about that, we think that the data parser interface needs a hasfeature call
14:17:35 <manu>
14:17:45 <ivan> ... this is now tracked separately in that issue 43
14:17:51 <ivan> ... so we can move on
14:18:00 <manu>
14:18:10 <ivan> (next email of nathan)
14:18:33 <ivan> manu: he thinks that it should not be restricted to the dom
14:18:43 <ivan> ... we have concensus that this is what we try to do
14:18:54 <ivan> ... ie, that the the api can be implemented in a non-dom environment
14:18:55 <ivan> q+
14:19:10 <ivan> ... this came up at the SWCG call yesterday
14:19:35 <manu> ack ivan
14:19:38 <ivan> ... they would like to see the RDFa api be more general, because it can be used in more general setting, too
14:21:11 <ivan> ivan: the webidl document has mapping on javascript and java only
14:21:25 <ivan> ... what about python, for example?
14:21:57 <manu> Ivan: I'm concerned that WebIDL doesn't have a mapping to Python
14:22:13 <manu> Ivan: it's not clear how to map the indexed setter/getter WebIDL stuff to Python.
14:22:29 <manu> Ivan: We could implement it in Python, but it's fuzzy.
14:22:47 <manu> Ivan: I think we should simply say that we will not necessarily seek implementations in languages other than Java and Javascript.
14:23:02 <manu> Ivan: We can only specify this for languages that have WebIDL mappings.
14:23:23 <manu> Ivan: I don't think that what Sandro said was that we should have a general API for all RDF languages... that's way beyond what we could/should do.
14:23:46 <manu> Ivan: He said, if I am a Javascript programmer, then the API in our document should be general enough to know what I should do in Javascript.
14:24:04 <manu> Ivan: We may not need to think about Scala, Ruby, etc.
14:24:23 <ivan> ShaneM: it was my impression that webidl is only an expansion of omg's idl
14:24:35 <manu> Shane: It was my impression that WebIDL is just an expansion of OMG of IDL... so I was under the impression that anybody that could map anything... it's an abstraction.
14:24:41 <manu> Shane: It's more guidance than anything.
14:24:42 <ivan> ... i got the impression that there is no need for an official lang binding
14:24:58 <ivan> ... having said that I do not know how we will test this, i am not sure i care
14:25:05 <manu> Shane: Having said that, I don't really care... it's going to be difficult to test it in Javascript
14:25:11 <ivan> ... so rely on what they do there
14:25:27 <Benjamin> How is the DOM API implemented in the different languages?
14:25:33 <ivan> ... we use webidl normatively
14:25:39 <ivan> ... and we have a process question
14:26:01 <manu> ACTION: Ivan to find out if we can use WebIDL normatively.
14:26:02 <trackbot> Created ACTION-36 - Find out if we can use WebIDL normatively. [on Ivan Herman - due 2010-09-02].
14:26:43 <ivan> manu: what is the concensus on this now?
14:27:01 <ivan> ... we use webidl is because we want to have portable javascript implementations?
14:27:21 <ivan> ... if there are interoperability issues with python, then please send the comments to the group
14:30:47 <ShaneM> I think we need to idenitfy all of the ecmascript interface signatures so we can write tests.
14:31:31 <ivan> manu: feedback to the community: do your best, and if a mapping is unclear, contact the group...
14:32:01 <ivan> ivan: we should decide whether we will test in javascript _and_ in java or only javascript
14:32:10 <ivan> manu: I would prefer to focus on Javascript only
14:32:13 <ivan> ivan: agreed
14:32:18 <manu>
14:32:30 <ivan> (yet another mail of nathan)
14:32:52 <ivan> the subject/origin concern
14:32:59 <ivan> manu: we changed the the api now
14:33:05 <manu> 3) ISSUE-29: DOM origin generalization (on Manu)
14:33:33 <ivan> but there is a separate issue on that one
14:33:54 <manu>
14:34:21 <manu> reponse to that e-mail:
14:35:29 <ShaneM> Note - There is an OMG IDL to Python mapping at
14:36:18 <ivan> manu: go through the points of nathan
14:36:36 <ivan> ... 1st issue is a typo, clear
14:36:52 <ivan> ... 2nd on curie resolution, question is how the api resolves curies
14:37:12 <ivan> ... the document has a default context and when a curie is resolved this is what is used
14:37:25 <ivan> ... but we did not allow the context to be changed, but we do that now
14:38:27 <ivan> ... 3rd for registered type conversion, the same issue, same answer...
14:39:10 <ivan> ... also, there was also no way to programatically resolve a curie, that was an oversight on our side
14:39:17 <manu>
14:39:25 <ivan> ShaneM: that can only be used in a context
14:39:30 <ivan> manu: exactly
14:40:31 <ivan> ... 3rd for typed literal converter, and you really have to know webidl to really make things understood
14:40:53 <ivan> ... benjamin would go through the document to add some examples on how to do to conversion properly
14:41:05 <ivan> benjamin: I can do that
14:41:41 <manu>
14:42:59 <manu>"xsd:integer", function (value, targetType) { doSomething(); });
14:43:21 <ivan> (example to register a type conversion method)
14:43:52 <ivan> manu: 4th was a bug on the create store method
14:44:11 <ivan> ... the bug was that the parameter should have been optional
14:44:27 <ivan> ... and text was added as an explanation
14:44:41 <ivan> ... to be able to specify the type of store
14:45:04 <ivan> 5th issue, shouldn't a iri be used or a curie
14:45:17 <ivan> ... the answer was no, we wanted to have just an easy string based mechanism
14:45:40 <manu>
14:45:41 <ivan> manu: 6th issue is how to create a new document data instance
14:45:57 <ivan> ... we have now a create mechanism, too, in the new version
14:46:00 <manu>
14:46:31 <ivan> (the last entry has the extra call definition)
14:46:40 <ivan> manu: nathan is happy with the responses
14:46:49 <ivan> ... we can then close the issue
14:46:52 <ivan> ... thoughts?
14:46:57 <ivan> (stunned silence again)
14:47:13 <ivan> (everybody is happy... probably...)
14:47:17 <manu> PROPOSED: Close ISSUE-28, the WG has reviewed and accepts all changes that have been made to the RDFa API document.
14:47:22 <ivan> +1
14:47:25 <Benjamin> +1
14:47:27 <manu> +1
14:47:48 <ShaneM> +1
14:47:50 <Steven> +1
14:48:33 <manu> RESOLVED: Close ISSUE-28, the WG has reviewed and accepts all changes that have been made to the RDFa API document.
14:48:52 <ivan> Topic: ISSUE-29: RDFa API .origin property needs to be more carefully specified
14:49:00 <manu>
14:49:23 <ivan> manu: we need to be more careful about origin
14:49:33 <manu>
14:49:34 <ivan> ivan: we were trying to put extra weight on the basic objects
14:49:53 <ivan> manu: current version do not have any reference to the origin
14:50:20 <ivan> ... we've taken the origin off there
14:50:25 <ivan> ... we put it on the property group object
14:50:31 <manu>
14:51:08 <ivan> ... property group has the generic 'info' object
14:52:03 <ivan> .. .the general idea is that you can query in the property group, if it is dom aware, the associated dom node
14:52:17 <ivan> ... the properties would have the source dom node in the group
14:52:37 <manu> var pg =;
14:52:55 <manu>"foaf:name", "source");
14:53:18 <manu>"foaf:name", "source")[0];
14:53:19 <manu>"foaf:name", "source")[1];
14:53:41 <ivan> q+
14:55:25 <manu> ack ivan
14:55:39 <Benjamin> q+ to give an example
14:55:48 <manu> Ivan: Why do we have property groups again? I can get triples, I can filter those triples... what is the usage for property groups.
14:55:51 <manu> ack benjamin
14:55:51 <Zakim> Benjamin, you wanted to give an example
14:58:19 <manu> var name = person.get("foaf:name");
14:59:36 <manu>  // creates a PropertyGroup for the given subject
14:59:38 <manu> var person = document.getItemsBySubject("#bob");
14:59:39 <manu> // Access the property group attribute via complete IRI
14:59:41 <manu> var name = person.get("");
14:59:42 <manu> // Access the property group attribute via CURIE
14:59:44 <manu> var name = person.get("foaf:name");
15:00:07 <manu> var name =;
15:01:37 <Benjamin> It can contain more than a single person, or?
15:02:10 <manu> var person = document.getItemsBySubject("#bob")[0];
15:03:08 <manu> <--- that is a dictionary
15:03:21 <manu>"foaf:name")
15:03:29 <manu>"foaf:name") <---- indexed by property
15:03:56 <manu>"foaf:name") ----> this would/could return an array
15:04:07 <Benjamin> q+
15:04:12 <manu>"foaf:name", "source") ----> this would/could return an array
15:04:35 <manu>"foaf:name", "source")[0] ----> this would/could return the DOM Node
15:04:44 <manu> ack benjamin
15:04:48 <ivan> q+
15:06:00 <manu> ack ivan
15:06:04 <manu> attribute Object info;
15:06:44 <ShaneM> how about a presentation style that distinguishes a triple *object* from an IDL object?
15:07:04 <manu> that might work, Shane.
15:09:45 <Zakim> -Benjamin
15:11:45 <Zakim> -ShaneM