Chatlog 2011-04-28

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

13:58:29 <RRSAgent> RRSAgent has joined #rdfa
13:58:29 <RRSAgent> logging to http://www.w3.org/2011/04/28-rdfa-irc
13:58:31 <trackbot> RRSAgent, make logs world
13:58:31 <Zakim> Zakim has joined #rdfa
13:58:33 <trackbot> Zakim, this will be 7332
13:58:33 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 2 minutes
13:58:34 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:58:34 <trackbot> Date: 28 April 2011
13:58:45 <manu1> Chair: Manu
13:58:47 <manu1> Present: Ivan, Manu, Nathan, Ted, Benjamin, Steven, Shane, Thomas
13:58:58 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Apr/0160.html
14:01:05 <MacTed> Zakim, code?
14:01:05 <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:01:10 <MacTed> Zakim, who's here?
14:01:10 <Zakim> SW_RDFa()10:00AM has not yet started, MacTed
14:01:11 <Zakim> On IRC I see RRSAgent, tomayac, Steven, MacTed, danbri, Benjamin, ivan, webr3, manu1, manu, trackbot
14:01:17 <MacTed> Zakim, this is 7332
14:01:17 <Zakim> ok, MacTed; that matches SW_RDFa()10:00AM
14:01:21 <MacTed> Zakim, who's here?
14:01:21 <Zakim> On the phone I see tomayac, Benjamin, OpenLink_Software
14:01:22 <Zakim> On IRC I see RRSAgent, tomayac, Steven, MacTed, danbri, Benjamin, ivan, webr3, manu1, manu, trackbot
14:01:28 <MacTed> Zakim, OpenLink_Software is temporarily me
14:01:28 <Zakim> +MacTed; got it
14:01:30 <MacTed> Zakim, mute me
14:01:30 <Zakim> MacTed should now be muted
14:01:40 <Zakim> +??P14
14:01:50 <manu1> zakim, I am ??P14
14:01:50 <Zakim> +manu1; got it
14:02:01 <ivan> zakim, dial ivan-voip
14:02:01 <Zakim> ok, ivan; the call is being made
14:02:01 <MacTed> Zakim, unmute me
14:02:02 <Zakim> MacTed should no longer be muted
14:02:02 <Zakim> +Ivan
14:02:08 <ShaneM> ShaneM has joined #rdfa
14:02:49 <Zakim> +??P15
14:02:56 <ShaneM> zakim, ??P15 is ShaneM
14:02:56 <Zakim> +ShaneM; got it
14:03:23 <Zakim> +[IPcaller]
14:03:30 <webr3> Zakim, i am IPcaller
14:03:30 <Zakim> ok, webr3, I now associate you with [IPcaller]
14:04:07 <manu1> scribenick: MacTed
14:04:10 <manu1> Scribe: Ted
14:04:49 <Steven> zakim, dial steven-work
14:04:49 <Zakim> ok, Steven; the call is being made
14:04:51 <Zakim> +Steven
14:05:24 <MacTed> Topic: Interest in RDF and RDFa API
14:05:24 <ivan> http://www.w3.org/mid/A0CD95FB-1D6F-43A1-8547-20A3D0E8C8BA@kit.edu
14:06:11 <webr3> lol, yeah i replied too: http://lists.w3.org/Archives/Public/semantic-web/2011Apr/0214.html
14:06:42 <webr3> Danny -> http://www.aifb.kit.edu/web/Denny_Vrandecic/en
14:07:21 <manu1> Ivan: Danny Vrandečić is working with Wikipedia 
14:08:41 <manu1> Gavin Carothers implemented the Python RDF API as well
14:09:10 <MacTed> ivan: how far are we from API used in Tabulator?
14:09:23 <MacTed> webr3: quite close but with different method names and definitions
14:10:48 <manu1> Topic: Linked JSON Mailing List
14:12:03 <MacTed> manu: RDF WG decided that JSON serialization was beyond immediate scope
14:12:56 <MacTed> manu: has been talking with others outside of RDF WG group, and several within, who are interested in this work
14:13:39 <MacTed> manu: Gavin Carothers, Richard Cyganiak, Glenn McDonald, Harry Halpin... others
14:13:58 <webr3> mailing list works now
14:14:23 <MacTed> webr3: Linked JSON mailing list is up and running
14:15:20 <webr3> mailing list link - http://lists.w3.org/Archives/Public/public-linked-json/
14:15:23 <MacTed> manu: hopes we'll all populate the list, and then decide how to focus the work -- tangible goals, etc., starting from stripped down spec, maybe the JSON-LD spec
14:16:14 <MacTed> webr3: also focused on Point Of Interest group right now
14:17:10 <MacTed> manu: thinks NYT could be enlisted for that group
14:17:11 <tomayac> +1 for getting the nyt people involved
14:17:28 <MacTed> manu: We may want to pull in people from Twitter, Facebook, etc.
14:18:35 <manu1> Topic: RDF API
14:18:38 <manu1> http://www.w3.org/2010/02/rdfa/sources/rdf-api/
14:19:28 <manu1> There is talk about splitting the RDF API document into a lower-level and a higher-level document.
14:19:28 <manu1> -1 for separate documents
14:19:32 <ivan> +1 for separate documents
14:19:34 <ivan> q+
14:19:37 <MacTed> webr3: 3 levels of API seem to be sketched out, (re)organization needs some work
14:20:33 <MacTed> ivan: favors separate docs for Developer and User to avoid scaring people with details unnecessary to their purposes
14:20:41 <webr3> +1 i have to admit
14:20:49 <manu1> q+
14:20:54 <manu1> ack ivan
14:20:55 <ivan> q-
14:21:07 <MacTed> ivan: best to have documents that cover reader's needs without overwhelming
14:21:18 <ivan> q+
14:21:23 <ivan> ack manu1 
14:21:45 <MacTed> manu: prefers to have one document so whole API can be seen in one place, rather than having scattered jigsaw puzzle pieces
14:22:20 <tomayac> +1 for one doc, as IMHO people who just want to code a mash-up won't read either...
14:22:21 <MacTed> (I favor clearly distinct, relatively standalone sections within one doc...)
14:22:34 <ivan> ack ivan
14:22:40 <webr3> q+
14:23:24 <manu1> q+ to say that the OWL2 docs are very difficult to follow
14:23:31 <MacTed> ivan: examples of broken up docs include OWL2, RIF -- they have one small doc which sketches how the other docs work together
14:23:51 <manu1> ack IPCaller
14:23:57 <manu1> ack [IPCaller]
14:23:59 <MacTed> Zakim, [IPcaller] is webr3
14:23:59 <Zakim> +webr3; got it
14:24:45 <MacTed> webr3: very much feels splitting is needed, between tool makers and tool users
14:24:59 <ivan> -> http://www.w3.org/TR/owl2-overview/ example for an overview document
14:25:22 <MacTed> webr3: lots of examples are needed, and a single doc will balloon
14:25:25 <manu1> ack web3
14:25:54 <webr3> manu, that could be the subject matter though.. OWL 2 is quite high level
14:26:04 <manu1> ack manu1
14:26:04 <Zakim> manu1, you wanted to say that the OWL2 docs are very difficult to follow
14:26:12 <MacTed> manu: diagram example makes sense, but the need for the diagram expresses the argument not to split...
14:26:40 <MacTed> ivan: OWL2 is an example of how to do, not a picture of just what would happen here
14:27:38 <manu1> q+ to discuss what would go into this 2nd level document?
14:27:49 <MacTed> ivan: RDFa esoterica (bnode, deep rdf discussions, 303, etc.) is likely to scare away the people we very much don't want to scare away
14:27:57 <manu1> ack manu1
14:27:57 <Zakim> manu1, you wanted to discuss what would go into this 2nd level document?
14:28:09 <MacTed> manu: what would go in second level doc?
14:28:09 <webr3> manu, imho - RDFa API but for general RDF
14:28:43 <webr3> 2nd level -> "a read only RDF API for end developers, like the RDFa API"
14:28:44 <MacTed> ivan: projection; document data interface; equivalent of RDFa environment (query, reference to RDF environment)
14:28:50 <Benjamin> q+ to recommend popular linked data use cases be backed by the second lewvel api
14:28:58 <manu1> ack Benjamin
14:28:58 <Zakim> Benjamin, you wanted to recommend popular linked data use cases be backed by the second level API
14:29:03 <webr3> Benjamin +1
14:29:24 <manu1> q+ to discuss charter scope?
14:29:25 <MacTed> Benjamin: remembering, RDFa API was originally named Linked Data API ... 
14:29:38 <MacTed> Benjamin: thinks we should create this second level API
14:29:59 <manu1> ack manu1
14:29:59 <Zakim> manu1, you wanted to discuss charter scope?
14:30:11 <MacTed> manu: are we chartered to work on such a second doc?  are there toes we're going to step on?
14:30:14 <webr3> q+
14:30:17 <manu1> RDF Core API?
14:30:32 <webr3> q-
14:30:34 <MacTed> ivan: RDF Core API, RDF API ... we can play around with names 
14:30:41 <webr3> or "RDF Interfaces"
14:30:49 <tomayac> q+
14:30:51 <manu1> +1 to RDF Core API and another RDF API doc
14:30:52 <webr3> for this api that is, and new one as "RDF API"
14:31:44 <MacTed> macted: "Linked Data API" would imply that "RDF" is all there is to "Linked Data" ... which isn't the case
14:31:57 <ivan> q?
14:32:00 <ivan> act tomayac 
14:32:03 <manu1> ack tomayac
14:32:08 <MacTed> manu: anyone with other concerns about splitting this?
14:32:53 <MacTed> tomayac: people outside w3c are unlikely to look at these docs anyway...  why are we concerned with addressing them?
14:33:05 <webr3> tomayac, that would be sad if they don't imho - I'd want this doc to be focussed for those people, and if we are doign docs wrong, lets change that
14:33:14 <MacTed> ivan: that seems to ask "why do this at all?" 
14:33:48 <MacTed> ivan: hopefully, if we do this well, letting people quickly do simple/easy things, without having to immediately dive into difficult things, that's a win
14:34:06 <MacTed> ivan: this will expose them to other things they may want to do, which require they learn the complex stuff, but that's OK
14:34:31 <tomayac> in my experience, all js coders search for js docs by $searchterm +mdc to make sure the mozilla docs come up. i can imagine something similar to happen for a browser-vendor-implemented rdfa api.
14:34:48 <MacTed> ivan: for instance, quick-and-dirty read-only joins of DBpedia with Gene Data should be enabled by these docs
14:35:10 <webr3> toayac, i do that :p lol +mdc
14:35:18 <ivan> q+
14:35:28 <MacTed> manu: "+mdc" search term isn't that common in my experience
14:35:53 <MacTed> ivan: we should realize that w3c is currently developing *MANY* APIs ... 
14:36:11 <MacTed> ivan: and if people are relying strictly on mozilla docs, then this is pointless ... which doesn't seem true
14:36:52 <MacTed> ivan: if we have the Core, others can implement extensions and other layers atop the Core to empower other uses
14:36:56 <webr3> q+
14:37:00 <manu1> ack ivan
14:37:02 <ivan> ack ivan 
14:37:03 <manu1> ack webr3
14:37:30 <MacTed> webr3: reiterating ivan's point, we build the Core / bare minimum that community can then build upon
14:37:47 <tomayac> to put it the right way: i was talking about core js, which mdc does a great job on documenting it, no one goes to the ECMA script spec for simple questions
14:37:50 <manu1> q+ to say that people may want to add stuff to the RDF API (not RDF Core API)
14:37:58 <MacTed> webr3: we can then standardize/unify the things which others innovate and implement differently
14:38:22 <manu1> ack manu1
14:38:22 <Zakim> manu1, you wanted to say that people may want to add stuff to the RDF API (not RDF Core API)
14:38:43 <MacTed> manu: another pro for the split is we can standardize RDF Core and few will want/need to change that
14:38:52 <MacTed> manu: RDF Core - literals, graphs, nodes, etc.
14:39:09 <MacTed> manu: RDF API - query mechanisms, document interface(s), etc.
14:39:21 <webr3> +1 agree
14:39:26 <Benjamin> +1
14:39:27 <MacTed> manu: future innovation is expected to take place in RDF API, not in RDF Core
14:39:44 <webr3> q+ to bring focus back
14:39:58 <manu1> ack webr3
14:39:58 <Zakim> webr3, you wanted to bring focus back
14:39:58 <MacTed> ivan: RDF Core will basically reflect RDF concepts in JavaScript
14:40:18 <MacTed> s/RDF Core/RDF Core API/
14:40:27 <MacTed> webr3: 1. are we going ahead with two docs?
14:40:43 <MacTed> webr3: 2. if so, we need to change the name from "RDF API" now...
14:41:10 <MacTed> webr3: 3. are we getting rid of tripleset; are we sticking with node-node-node definition or constraining to RDF; etc?
14:41:17 <manu1> PROPOSAL: The current RDF API document should be split into two documents - the RDF Core API and the RDF API
14:41:19 <Benjamin> +1
14:41:19 <manu1> +1
14:41:21 <ivan> +1
14:41:25 <MacTed> +1
14:41:26 <ShaneM> +1
14:41:27 <Steven> +0
14:41:28 <webr3> +1 but review name
14:41:45 <ShaneM> (I don't like the name RDF Core API really)
14:41:50 <Steven> Don't feel strongly in this case
14:41:52 <webr3> RDF Core API, or RDF Interfaces ?
14:41:55 <tomayac> +0 name strange
14:42:51 <MacTed> naming confusion...
14:43:06 <ShaneM> XHTML+RDFa, HTML+RDFa, RDFa Core, RDF Core API, RDF API, and RDFa API
14:43:07 <webr3> +1 to what ivan just said
14:43:28 <webr3> RDF Interfaces, RDF API, RDFa API
14:43:38 <Benjamin> sounds good
14:43:40 <MacTed> "RDF Core API" becomes "RDF Interfaces API"; keep "RDF API" and "RDFa API"...
14:43:44 <manu1> RESOLVED: The current RDF API document should be split into two documents - the RDF Interfaces and the RDF API
14:44:15 <MacTed> "RDF Core API" becomes "RDF Interfaces"
14:44:46 <manu1> Subtopic: Removing Triple Set / Graph Literal
14:44:56 <manu1> q+ to discuss removing Graph Literal
14:45:01 <Zakim> -Benjamin
14:45:35 <MacTed> ivan: what we said... (roughly) "the RDF WG is currently discussing the notion of graph identification.  This WG will act based on their decision."
14:46:20 <manu1> ack manu1
14:46:20 <Zakim> manu1, you wanted to discuss removing Graph Literal
14:46:50 <Zakim> + +44.123.456.aaaa
14:47:01 <Benjamin> zakim, i am aaaa
14:47:01 <Zakim> +Benjamin; got it
14:47:19 <MacTed> [discussion of undefined term "Graph Literal"]
14:47:37 <MacTed> q+
14:47:44 <manu1> ack MacTed
14:48:17 <manu1> Ted: We don't need to define everything - we can use an ambiguous term for the time being
14:48:41 <manu1> Ted: We just say that we are not defining it, but we're putting it in as a placeholder.
14:49:00 <webr3> Ivan, placeholder text, or interface with a note?
14:49:02 <manu1> Ted: It's up to the RDF WG to define this stuff, we make that clear in the document
14:50:21 <manu1> Ivan: Defining WebIDL that states that a Triple Set extends a Node and a Literal, it makes a technical decision, it oversteps our bounds
14:50:22 <Benjamin> q+
14:50:37 <webr3> Ivan, as you said "what is the datatype" :p (not does it have a datatype)
14:50:47 <manu1> Ted: But why can't we just put a warning stating that the interface could change over time, based on what RDF WG finds.
14:51:16 <manu1> ack Benjamin
14:52:05 <MacTed> Benjamin: I think we should model RDF Interfaces by what has general consensus ...  since this doesn't have general consensus, maybe it's not "core" yet?
14:52:23 <ivan> q+
14:52:47 <webr3> we can define them (TripleSet/GraphLiteral) as extensions to the RDF Interfaces, just like OWL, or entailment, or SPARQL might
14:52:55 <webr3> (at a later date)
14:52:55 <MacTed> manu: seems like this will belong in RDF Interfaces once it's defined, so putting it outside "for now" is troublesome
14:53:28 <manu1> ack ivan
14:54:27 <MacTed> ivan: handwave is what's called for here
14:55:28 <MacTed> ivan: already because SPARQL does some loose association here, adding something about a "graph may have a URI" seems appropriate
14:57:03 <ivan> +1
14:57:04 <manu1> PROPOSAL: The RDF Interfaces should mention a Graph identification concept, but should not specify any WebIDL yet - we should note that the RDF WG is currently discussing the details of this mechanism.
14:57:08 <manu1> +1
14:57:14 <webr3> +1
14:57:23 <Benjamin> +1
14:57:23 <tomayac> +1
14:57:26 <Steven> +0
14:57:27 <ShaneM> ..... +1
14:57:27 <MacTed> +1
14:57:56 <MacTed> Steven: no strong feelings... hence +0
14:58:09 <webr3> all that's left is: (node node node) or (rdfresource, namednode, node)
14:58:32 <MacTed> ivan: 2 things remaining...
14:58:40 <webr3> and, literal needs to keep lexical form from a serialization for comparison
14:58:43 <Zakim> -ShaneM
14:58:51 <MacTed> [discussion of remaining...]
14:59:15 <manu1> Subtopic: Generalized Triples
14:59:42 <MacTed> ivan: Nathan found good set of argumentation why we would keep with  (node node node) approach
15:00:15 <MacTed> ivan: thinks we should do so, include that text, and see whether community jumps at us
15:00:51 <MacTed> webr3: basic argument is to allow more flexible code use/writing
15:01:16 <MacTed> ivan: what is "literal as predicate"?
15:01:29 <MacTed> manu: use case is in JSON conversions
15:01:38 <webr3> so does anybody object to node,node,node ?
15:02:04 <MacTed> PROPOSAL: The generalized triples approach, (node, node, node) should be kept in the RDF Interfaces document.
15:02:07 <MacTed> +1
15:02:09 <Steven> +1
15:02:09 <webr3> +3
15:02:11 <manu1> +1
15:02:13 <tomayac> +1 for keeping node^3
15:02:14 <Benjamin> +1
15:02:16 <ivan> +1
15:02:28 <MacTed> RESOLVED: The generalized triples approach, (node, node, node) should be kept in the RDF Interfaces document.
15:02:55 <manu1> Subtopic: Interface for Literal and Equality Comparison
15:03:05 <MacTed> ivan: last thing -- current interface for literal makes assumption that when you get lexical value, you convert it into the "natural" value which is what you store
15:03:15 <MacTed> ivan: original lexical value should also be stored
15:04:10 <MacTed> ivan: two lexical values are equal only if they match character-by-character ... even though "natural" values of different lexicals may be equal
15:05:03 <manu1> <a> <b> "011"^^xsd:integer . <a> <b> "11"^^xsd:integer .
15:05:50 <webr3> see - http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Apr/0158.html
15:05:52 <MacTed> ivan: these strings are not RDF equal, but they are numerically equivalent
15:05:55 <webr3> q+
15:06:09 <manu1> ack webr3
15:06:48 <webr3> What happens if we do this: createLiteral(100, "xsd:double").equals( createLiteral(+1e2, "xsd:double") ) === TRUE
15:07:30 <webr3> http://www.w3.org/2010/02/rdfa/sources/rdf-api/#widl-RDFEnvironment-createLiteral
15:07:48 <MacTed> [discussion about limiting input to createLiteral() method]
15:09:21 <webr3> right now, we have "The native value of the literal, if the datatype of the literal is not known by the implementation the nodes value must be the lexical representation of the value." at the minute
15:10:03 <webr3> q+ to say we have a nice short circuit in the API at the minute..
15:10:11 <manu1> q+ to say that we may want to turn this into an ISSUE
15:10:57 <manu1> ack manu1
15:10:57 <Zakim> manu1, you wanted to say that we may want to turn this into an ISSUE
15:10:58 <MacTed> cleanup -- "The native value of the literal. If the datatype of the literal is not known by the implementation, the node's value must be the lexical representation of the value."
15:11:13 <webr3> we have "equals(tocompare) -> If tocompare is NOT an instance of RDFNode then the it must be compared with this nodes value."
15:11:29 <Benjamin> q+ to shortly discuss scope and implementation of .equals(RDFNode) for BlankNodes.
15:12:03 <MacTed> ivan: suggests that we adjust wording, as this is not kosher RDF, and make note that some environments may not permit the new (correct) behavior
15:12:07 <Zakim> -Steven
15:12:44 <webr3> +1 macted to SHOULD
15:12:48 <manu1> ack webr3
15:12:48 <Zakim> webr3, you wanted to say we have a nice short circuit in the API at the minute..
15:13:08 <Zakim> -webr3
15:13:16 <MacTed> MacTed: SHOULD language seems to be what we should use...  when you can, DO.  when you can't, well, you can't!
15:13:29 <MacTed> webr3: my audio connection is gone - fell off the line
15:13:57 <webr3> what do we need to do for FPWD, I like as is and would like to push this to an issue for discussion
15:14:00 <MacTed> Benjamin: found it difficult to implement the notion of blank nodes as in the API
15:14:18 <manu1> Same here, I think we should push this off to an ISSUE
15:15:19 <MacTed> ivan: blank node interface needs additional attribute, being the graph to which it belongs
15:15:46 <webr3> which graph?? what identifier?
15:16:07 <webr3> a graph in memory? something from a .createBlankNode()?
15:16:19 <MacTed> the graph in which the bnode occurs
15:16:23 <MacTed> whatever graph that might me...
15:16:33 <MacTed> (hey!  we need graph identifiers!)
15:16:37 <webr3> bnode.equals(bnode) should just return false.. it's a useless equality
15:17:09 <MacTed> webr3 - I don't think we can cover this well via IRC... voice carried much more info
15:18:59 <webr3> okay .. so few changes to RDF Interfaces as we discussed, equality to ISSUE ?
15:19:15 <webr3> and vote on FPWD via mailing list to get a publish ?
15:19:47 <MacTed> discussion on FPWD readiness...
15:20:50 <MacTed> manu: suggestions are 1. change RDF API title to RDF Interfaces; 2. get to RDF API doc later; 3. make today's editorial changes and add "work in progress" disclaimer to start of document.
15:21:02 <webr3> +1
15:21:05 <MacTed> manu: then, we go to FPWD ... and then we move forward to RDF API doc, keeping in mind that we need to do CR for RDFa docs.
15:21:18 <MacTed> ivan: and then we come back to RDFa
15:21:35 <MacTed> PROPOSAL: FPWD after 1. change RDF API title to RDF Interfaces; 2. get to RDF API doc later; 3. make today's editorial changes and add "work in progress" disclaimer
15:21:45 <ivan> +1
15:21:45 <MacTed> +1
15:21:48 <manu1> +1
15:21:49 <tomayac> +1
15:21:53 <Benjamin> +1
15:22:16 <MacTed> RESOLVED: FPWD after 1. change RDF API title to RDF Interfaces; 2. get to RDF API doc later; 3. make today's editorial changes and add "work in progress" disclaimer
15:24:01 <webr3> +1
15:33:25 <Zakim> -tomayac
15:33:49 <Zakim> -MacTed
15:34:05 <Zakim> -Benjamin
15:40:45 <webr3> webr3 has joined #rdfa
15:42:44 <ShaneM> ShaneM has joined #rdfa
15:43:37 <Zakim> -manu1
15:43:38 <Zakim> -Ivan
15:43:38 <Zakim> SW_RDFa()10:00AM has ended
15:43:40 <Zakim> Attendees were tomayac, Benjamin, MacTed, manu1, Ivan, ShaneM, Steven, webr3, +44.123.456.aaaa
15:46:36 <ShaneM> ShaneM has left #rdfa
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000326