Chatlog 2010-05-06

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

13:54:23 <RRSAgent> RRSAgent has joined #rdfa
13:54:23 <RRSAgent> logging to http://www.w3.org/2010/05/06-rdfa-irc
13:54:27 <manu> trackbot, setup meeting
13:54:27 <trackbot> Sorry, manu, I don't understand 'trackbot, setup meeting'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
13:55:51 <ivan> trackbot, prepare telcon
13:55:53 <trackbot> RRSAgent, make logs world
13:55:55 <trackbot> Zakim, this will be 7332
13:55:55 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 5 minutes
13:55:56 <trackbot> Meeting: RDFa Working Group Teleconference
13:55:56 <trackbot> Date: 06 May 2010
13:57:07 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010May/0038.html
13:57:12 <manu> Chair: Manu
13:57:34 <manu> Present: Ivan, Knud, MarkB, Toby, Benjamin, Shane, Manu
13:58:25 <Zakim> SW_RDFa()10:00AM has now started
13:58:41 <manu> zakim, code?
13:58:41 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), manu
13:58:44 <Zakim> +[MIT528]
13:58:55 <Zakim> +Toby
13:59:02 <ivan> zakim, dial ivan-voip
13:59:02 <Zakim> ok, ivan; the call is being made
13:59:03 <Zakim> +Ivan
13:59:06 <Zakim> +??P1
13:59:07 <tinkster1> zakim, who's making noise?
13:59:08 <manu> zakim, I am ??P1
13:59:08 <Zakim> +manu; got it
13:59:18 <Zakim> tinkster1, listening for 10 seconds I heard sound from the following: ??P1 (5%)
13:59:20 <ivan> zakim, who is noisy?
13:59:32 <tinkster1> zakim, mute p1.
13:59:32 <Zakim> sorry, tinkster1, I do not know which phone connection belongs to p1
13:59:36 <Zakim> ivan, listening for 14 seconds I could not identify any sounds
13:59:52 <manu> zakim, I am ?P1
13:59:52 <Zakim> sorry, manu, I do not see a party named '?P1'
13:59:59 <manu> zakim, I am ??P1
13:59:59 <Zakim> sorry, manu, I do not see a party named '??P1'
14:00:05 <ivan> zakim, who is here?
14:00:05 <Zakim> On the phone I see [MIT528] (muted), Toby, Ivan, manu
14:00:06 <Zakim> On IRC I see Knud, dongmei, trackbot, RRSAgent, Zakim, Benjamin, manu, tinkster1, markbirbeck, ivan, tinkster
14:00:12 <Zakim> +Benjamin
14:00:23 <manu> zakim, who is on the call?
14:00:23 <Zakim> On the phone I see [MIT528] (muted), Toby, Ivan, manu, Benjamin
14:01:07 <Zakim> +Knud
14:01:29 <ShaneM> ShaneM has joined #rdfa
14:01:34 <markbirbeck> zakim, code?
14:01:34 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), markbirbeck
14:02:07 <Zakim> +ShaneM
14:02:15 <Zakim> +markbirbeck
14:07:49 <tinkster> Scribenick: tinkster
14:07:55 <tinkster> Topic: High-level overview of RDFa DOM API
14:08:16 <manu> http://code.google.com/p/backplanejs/wiki/RdfaDomApi
14:10:43 <tinkster> Manu: we'll be going through Mark's proposals - high level first, then the details.
14:11:25 <tinkster> Mark: apologies to Benjamin and Manu, who have put a lot of work into this, while I've not had time to put my ideas down concretely.
14:12:50 <tinkster> ... Some of the things in my proposal are stuff we could have done with current API quite easily - e.g. using factories for creating objects.
14:14:27 <tinkster> ... Creating a Store and a Parser and parsing data into the Store is perhaps a little longwinded, but helps us understand the architecture, and makes the API extensible for other parsers to be added in.
14:14:57 <tinkster> ... Experience from XForms is that it's good to make the 'under the hood' stuff explicit.
14:16:37 <tinkster> ... There's a risk that if you make things pluggable, they become too broad, but it opens up flexibility. Would be nice to plug in HTML5 web storage as a store, say, or plug in a Microformats parser.
14:18:37 <Benjamin> q+ to comment this
14:18:57 <manu> ack benjamin
14:18:57 <Zakim> Benjamin, you wanted to comment this
14:18:57 <tinkster> Topic: High-level vs. Low-level DOM API
14:18:57 <tinkster> Manu: This architecture can be thought of as a two-level API. Most developers will probably just use the high-level stuff, but if they need to do anything complicated, they can drop down to the lower level.
14:19:59 <tinkster> Benjamin: mutliple stores and multiple parsers is something that I think should be looked at as part of the RDF Triple Stores API, not the RDFa DOM API.
14:20:11 <ivan> q+
14:20:53 <manu> ack ivan
14:21:03 <tinkster> manu: It seems like we're integrating these two ideas. Maybe we can't do a good job on the RDFa DOM API without thinking about a Triple Store API.
14:22:03 <tinkster> ivan: Let's not let the charter stop us from doing a good job on the API.
14:23:11 <tinkster> ... there seem to be two ways of getting at the data - finding a resource and then getting the triples for it; and a stripped down SPARQL-like query interface.
14:23:52 <markbirbeck> +
14:23:55 <markbirbeck> q+
14:24:18 <tinkster> Benjamin: the close relation between DOM nodes and triples is an RDFa-specific thing, so tied to the RDFa API, not a general triple store API.
14:24:34 <manu> ack markbirbeck
14:27:27 <ShaneM> I agree with Mark that it is a common data store technique.
14:27:29 <manu> q+ to say we should be too pure about this
14:27:34 <tinkster> markbirbeck: this can be thought of as a triple store which allows per-triple metadata - the metadata could be a pointer to a DOM node in the case of RDFa, or some other bit of info for other triples.
14:28:19 <markbirbeck> q+
14:28:22 <manu> ack manu
14:28:22 <Zakim> manu, you wanted to say we should be too pure about this
14:29:59 <tinkster> Manu: the idea of attaching metadata to triples is very powerful; we need to talk about it, but perhaps not right now.
14:30:04 <manu> ack markbirbeck
14:31:18 <tinkster> manu: we need to have a gentler introduction - can we at least agree on that?
14:31:34 <tinkster> ivan: no, we need to make it as tough as possible! </sarcasm>
14:32:26 <tinkster> manu: we need to keep up with facebook, etc stuff that's going on. perhaps use those vocabs in examples. we can mostly agree on that.
14:33:17 <tinkster> manu: i don't think we all agree on the need for a low-level and high-level API.
14:33:48 <tinkster> Benjamin: the lowest level should be an RDFa level - there's a DOM with some RDFa attributes scattered about.
14:34:07 <tinkster> Storing, querying and projecting should be the higher level.
14:35:16 <manu> q+ to discuss extraction vs. storage
14:35:29 <tinkster> ivan: we're looking at this from different perspectives - from an implementer vs user point of view. even in what benjamin is talking about, clearly a store and parser is needed on some kind.
14:36:03 <manu> ack manu
14:36:03 <Zakim> manu, you wanted to discuss extraction vs. storage
14:37:38 <tinkster> manu: benjamin's API looks mostly at extraction, not storage. Mark's approach is storage-oriented, in an effort to help compatibility between implementations.
14:38:41 <tinkster> markbirbeck: if you look at how HTML5 is evolving, a large part of the motivation is to nail down *exactly* how user-agents behave.
14:39:04 <ivan> q+
14:39:07 <tinkster> ... at the very least, if we're not as specific, then we'll get a lot of flack.
14:40:12 <manu> ack ivan
14:41:06 <manu> q+ to discuss implementation of current RDFa DOM API
14:41:09 <tinkster> Topic: The RDFa DOM API Lifecycle/Environment
14:41:12 <tinkster> ivan: I'm not a browser programmer, but if I look at the current RDFa API document, that document, plus the RDFa Core spec seems to be clear enough.
14:42:09 <tinkster> ... I can see there would be some issues about what data is available while the DOM is still loading, but I don't see why that justifies needing pluggable stores, etc.
14:43:14 <tinkster> manu: I've been looking at how to implement this in Firefox using the fuzz plugin based on librdfa. It looked like my implementation would have to be half C++, half Javascript. 
14:43:32 <tinkster> ... My concept of a data store seemed pretty different to Mark's.
14:44:19 <tinkster> ... Tying in triples to user data such as DOM node pointers make some things very easy; which would be difficult and probably buggy otherwise.
14:45:06 <tinkster> ivan: if I *only* want to implement support for RDFa, are all these layers still really needed?
14:46:31 <tinkster> markbirbeck: putting aside stores and parsers for a while, we're left with two kinds of methods: getElementsByType sort of stuff; and the more complex query-like stuff.
14:47:31 <tinkster> ... speaking as someone who's done a lot of Javascript, and is very interested in semweb technology, even I can't imagine using that query and triple stuff.
14:47:45 <manu> q+ to discuss triple-based API.
14:48:03 <manu> q-
14:48:13 <manu> q+ to discuss how knowing direction affects design.
14:48:15 <Benjamin> q+ 
14:48:21 <manu> ack manu
14:48:21 <Zakim> manu, you wanted to discuss how knowing direction affects design.
14:48:31 <tinkster> ... So how do we express queries to find out stuff like who foaf:knows whom without SPARQL-like complexity. getElementsByType is not enough.
14:50:14 <markbirbeck> q+
14:50:15 <manu> ack benjamin
14:50:18 <tinkster> manu: we need to give people an idea of the direction we're going. A lot of programmers and going to  be asking for things like "get me the list of things that are people on the page, I want to do something with them".
14:50:46 <ivan> q+
14:51:27 <tinkster> Benjamin: I agree that we need to provide flexible query interfaces - the filter functions are designed to solve that; I don't see what more is needed.
14:51:28 <manu> q+ to discuss Triple-based API
14:51:33 <manu> ack markbirbeck
14:51:41 <tinkster> ... RDFa is RDF-based and we shouldn't ignore RDF's data model.
14:51:59 <ShaneM> I agree with Benjamin that it is really important that the RDF data model still be available and related to the triples in the store.
14:53:36 <tinkster> markbirbeck: the RDF data model is intentionally very abstract. why would you want to reflect that in a more constrained environment? what programmers want is objects or dictionary-like items.
14:54:30 <Benjamin> q+ to quickly respond
14:54:35 <tinkster> ... RDF is a means to an end, not an end in itself.
14:55:10 <manu> ack ivan
14:56:22 <markbirbeck> q+
14:56:55 <manu> ack manu
14:56:55 <Zakim> manu, you wanted to discuss Triple-based API
14:57:17 <tinkster> ivan: I am lost. I don't see any major philosophical differences here. The current API is more or less a close equivalent to what's used everywhere already.
14:57:47 <tinkster> manu: We do need a triple-based API, and also projections.
14:58:01 <manu> ack benjamin
14:58:03 <Zakim> Benjamin, you wanted to quickly respond
14:58:42 <manu> ack markbirbeck
14:58:54 <tinkster> Benjamin: the RdfObject interface in the current document seems to do this already.
14:59:59 <tinkster> markbirbeck: RdfObject is benjamin and manu's interpretation of what I was talking about a while ago, but it doesn't go as far as I wanted to go.
15:00:05 <manu> +1 to dealing with strings by default, typing if you want to be more specific.
15:00:42 <tinkster> ... The need an API where programmers don't need to fuss about what's a resource and what's a plain literal.
15:00:43 <manu> q+ to discuss type conversion
15:01:12 <manu> q-
15:01:22 <manu> q+ to end the call (formally), but continue (informally)
15:02:10 <tinkster> ... what we want is an API that people will want to use so much that they go and add RDFa to their pages.
15:03:06 <Zakim> -Toby
15:03:08 <manu> q+ to discuss type conversion - philisophical differences aren't as big as they may seem.
15:03:21 <manu> scribenick: manu
15:03:53 <manu> Ivan: I'm confused about the argument - you're saying we shouldn't type... but then we need to use DOM Nodes?
15:04:04 <Zakim> -Knud
15:04:07 <manu> Ivan: If I'm an RDFa author, I need to know about differences between IRI and Blank Nodes.
15:04:11 <manu> ack manu
15:04:34 <Zakim> manu, you wanted to end the call (formally), but continue (informally) and to discuss type conversion - philisophical differences aren't as big as they may seem.
15:06:02 <manu> Topic: RDFa DOM API - Philosophical Design Choices
15:06:06 <manu> Manu: I don't think there are as large philosophical differences as people think.
15:06:21 <manu> Ivan: Yes
15:06:29 <manu> Benjamin: (something that sounded like sure)
15:06:37 <Benjamin> yes :)
15:06:41 <manu> Mark: Sure, so perhaps we can get into implementation details now.
15:07:05 <manu> Mark: To talk about typing, people are going to need to instantiate IRIs, and PlainLiterals, etc.
15:07:17 <manu> Ivan: Wait, where does it create a problem on the API level?
15:07:46 <manu> Mark: I'm concerned that people have to create Types before people do a query.
15:08:30 <manu> Mark: Why not just check both? Is it a literal? Is it a resource?
15:08:39 <manu> Manu: I agree that we don't need to type everything.
15:10:00 <manu> Manu: Why not allow strings as input, but proper datatyped objects back to the developer?
15:10:13 <manu> Mark: Yes, sounds good - not saying let's forget about IRIs, PlainLiterals, etc.
15:11:44 <manu> Manu: So, has your ideas about this changed a bit, Benjamin?
15:12:12 <Benjamin> http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/#rdf-triple-list
15:12:53 <manu> Benjamin: Yes, we have some concepts that are similar - RDFTripleList and Store are similar.
15:13:30 <manu> Manu: Let's spec out a Store, then...
15:13:40 <manu> Benjamin: Important to have iterators...
15:15:02 <manu> Manu: Yes, we need to have mechanisms for low-memory environments.
15:15:23 <manu> Mark: Just because you have a store doesn't mean you need to actually store everything in it.
15:17:00 <manu> Manu: Well, what I'm concerned about is spec'ing what happens when the DOM changes.
15:17:19 <manu> Mark: DOM3 XPATH has the concept of snapshots... we could use something from that.
15:18:01 <manu> Manu: So, we should have some iterator based mechanism in the DOM API.
15:18:40 <manu> Manu: What about pluggable parsers? Do we want to support that?
15:18:58 <manu> Mark: At a high level, we can say "parse the document" without specifying what happens underneath.
15:19:19 <manu> Mark: At the very least, the store has .add() method with (subject, predicate, object) - it's RDF compliant.
15:19:47 <manu> Mark: A parser does whatever it does, but you bind the parser to a store... as long as it can get to the .add() method, it can do whatever it likes - parse Microformats, Microdata, RDFa, whatever.
15:20:18 <manu> Mark: Benjamin said we don't have to talk about Microformats... but if we support this, we do that automatically.
15:20:28 <manu> Mark: So, we can allow different parsers to connect to the store.
15:20:48 <manu> Mark: I'm imagining that a lot of these low-level functions would still be there on the Store and the Parser API.
15:21:04 <manu> Benjamin: I like the idea of exposing the .add() function.
15:21:13 <manu> Benjamin: I think we should specify it only for RDFa...
15:21:46 <manu> Benjamin: We can say, this is the hook where you plug in your parser into our API. People might be clever enough to think about other languages.
15:22:02 <manu> Benjamin: I don't think there is any need to talk about that...
15:22:28 <manu> Ivan: I think there is a packaging issue here - I think there are two documents here...
15:23:15 <manu> Ivan: I think even in the technical document, it makes sense to separate beginning concepts from advanced concepts.
15:24:04 <manu> Ivan: We could talk about Microformats/Microdata in the beginning section... but we might not need to talk about that because beginning people might not care.
15:24:09 <manu> Mark: There are three levels of users...
15:24:19 <manu> Mark: Two Javascript layers, and one layer of RDF.
15:24:31 <markbirbeck> An example of use of add():
15:24:33 <Zakim> -[MIT528]
15:24:37 <markbirbeck> / Create a Google Maps geocoder object
15:24:37 <markbirbeck> var geocoder = new google.maps.Geocoder();
15:24:37 <markbirbeck> / Set up a function to geocode an address and add the lat/long to a store
15:24:37 <markbirbeck> function geocode( store, subj, address ) {
15:24:38 <markbirbeck>   geocoder.geocode( { 'address': address }, function(results, status) {
15:24:38 <markbirbeck>     if (status == google.maps.GeocoderStatus.OK) {
15:24:40 <markbirbeck>       store.add("default", subj, "http://www.w3.org/2003/01/geo/wgs84_pos#lat",
15:24:42 <markbirbeck>         results[0].geometry.location.lat());
15:24:44 <markbirbeck>       store.add("default", subj, "http://www.w3.org/2003/01/geo/wgs84_pos#long",
15:24:46 <markbirbeck>         results[0].geometry.location.long());
15:24:48 <markbirbeck>     }
15:24:50 <markbirbeck>   });
15:24:52 <markbirbeck>   return;
15:24:54 <markbirbeck> }
15:25:31 <Benjamin> q+
15:25:32 <manu> Mark: This allows people like Google to distribute Javascript libraries that add information to the Stores.
15:26:01 <manu> Mark: This'll be people like Facebook/Google/Yahoo that'll integrate this stuff in their libraries, to push data into the triplestore.
15:26:04 <manu> ack benjamin
15:26:47 <manu> Benjamin: I like this use case - working with this use case everyday. I think we should focus on the DOM.
15:29:09 <manu> Manu: What if we store it in a different graph?
15:29:37 <manu> Mark: Well, that's what I'm getting at - stores are a collection of named graphs - "default" in the example above is a named graph.
15:30:03 <manu> Mark: If I go off to twitter and get tweets from a number of people, I want to get the tweets and put them in a triple store.
15:30:20 <manu> Mark: The store is the basic library to be used for data when building web-based applications.
15:30:39 <manu> Ivan: I think we are talking about two different things here - that's the issue.
15:30:53 <manu> Ivan: Mark, you're talking about a general, generic RDF API for Javascript users - that's fine.
15:31:07 <manu> Ivan: Benjamin, what you're talking about is strictly what is needed for the RDFa DOM API.
15:31:33 <manu> Ivan: It comes back to the level of differentiation we had in the charter.
15:32:32 <manu> Ivan: Maybe this comes back to what Manu said in the beginning - this RDFa API needs to take into account the entire environment.
15:33:14 <manu> q+ to talk about what does/doesn't go in the RDFa DOM API document.
15:33:46 <manu> Mark: I'm saying that we need some of these interfaces... at the top level, I don't see how we can do this with the current API.
15:36:21 <markbirbeck> q+
15:36:52 <manu> ack manu
15:36:54 <Zakim> manu, you wanted to talk about what does/doesn't go in the RDFa DOM API document.
15:37:08 <manu> Manu: This seems to be a discussion about what to talk about in the API - we can just talk about RDFa in the RDFa DOM API
15:37:19 <Benjamin> q+
15:37:32 <manu> Manu: but it is important to think bigger - think about the environment.
15:37:51 <manu> Mark: What I was hearing from Benjamin was that we shouldn't support these things - not allow the modification of the triple store.
15:38:04 <manu> Mark: Where did this triple come from? Is it in the default graph?
15:38:18 <manu> Mark: Do we strive for making this type of functionality possible, and then solve the problems as they come up?
15:38:38 <manu> Mark: Or, do we say - our goal is simply to give people access to triples in an RDFa page.
15:38:42 <manu> Mark: I think we need to resolve that.
15:39:00 <manu> ack markbirbeck
15:39:03 <manu> ack benjamin
15:39:10 <manu> Topic: RDFa DOM API Document Structure
15:39:13 <manu> Benjamin: I would recommend to make both, but in separate documents.
15:39:45 <manu> Benjamin: I think your approach is good, but it's not part of the RDFa DOM API - let's publish what you're talking about as the RDF Triplestore API and publish them both.
15:40:21 <manu> Manu: if that's where consensus is, then I'm fine with it.
15:40:53 <ivan> q+
15:40:54 <manu> Mark: I think it would be a shame to do that... but I could live with it.
15:40:57 <manu> ack ivan
15:41:10 <manu> Ivan: If we separate these two things, it gives us more freedom.
15:41:28 <manu> Ivan: If we look at what I can an RDF API, then we can/should add features that RDF power-users would use as well.
15:42:39 <ivan> q+
15:43:19 <manu> Manu: Let's keep this all in the same document for now... split it later if needed.
15:43:45 <manu> Ivan: I think there are things that are good to separate - by separating the RDF API into a separate document, we can ask the SemWeb community about it.
15:44:42 <ivan> zakim, drop me
15:44:42 <Zakim> Ivan is being disconnected
15:44:44 <Zakim> -Ivan
15:44:51 <ivan> zakim, dial ivan-voip
15:44:51 <Zakim> ok, ivan; the call is being made
15:44:53 <Zakim> +Ivan
15:45:36 <manu> Ivan: So, by separating the document into something that is clearly RDF specific, there are a number of communities that we need to discuss this with - TimBL will want to give input on this.
15:46:00 <manu> Ivan: The RDF Storage API isn't even Javascript specific...
15:46:50 <manu> Manu: So, we go forward with all of this in the same document and split it into two documents in the future.
15:49:06 <manu> Manu: So it sounds like we have a general direction that we agree with...
15:52:52 <ShaneM> q+ to talk about documentation integration
15:53:57 <manu> Manu: How are we going to do the merge?
15:54:09 <ShaneM> zakim, ack me
15:54:09 <Zakim> ShaneM, you wanted to talk about documentation integration
15:54:11 <Zakim> I see ivan on the speaker queue
15:54:15 <manu> ack ivan
15:56:24 <ShaneM> do you envision a separate short name?  should this be on the W3C server somewhere?
15:57:27 <Benjamin> q+
15:59:24 <ShaneM> I am out of cycles for today.  sorry!
15:59:48 <Zakim> -ShaneM
15:59:52 <ivan> guys, I have to go
16:00:03 <ivan> zakim, drop me
16:00:05 <Zakim> Ivan is being disconnected
16:00:07 <Zakim> -Ivan
16:00:23 <ShaneM> ShaneM has left #rdfa
16:06:57 <manu> Manu: Ok, so sounds like we'll do the following: Mark will translate his document to ReSpec and let us know when each section is done.
16:07:48 <manu> Manu: Benjamin and I will merge the completed sections to the current RDFa DOM API document
16:08:12 <manu> Manu: for sections that we don't agree on, we'll have to discuss on the W3C telecons.
16:08:32 <manu> Manu: Sound good?
16:08:54 <manu> Manu: (notes no disagreements)
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000301