Chatlog 2012-05-23

See panel, original RRSAgent log or preview nicely formatted version.

Please justify/explain non-obvious edits to this page, in your "edit summary" text.

14:38:16 <RRSAgent> RRSAgent has joined #rdf-wg
14:38:16 <RRSAgent> logging to http://www.w3.org/2012/05/23-rdf-wg-irc
14:38:18 <trackbot> RRSAgent, make logs world
14:38:18 <Zakim> Zakim has joined #rdf-wg
14:38:20 <trackbot> Zakim, this will be 73394
14:38:20 <Zakim> ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 22 minutes
14:38:21 <trackbot> Meeting: RDF Working Group Teleconference
14:38:21 <trackbot> Date: 23 May 2012
14:38:26 <ivan> Chair: Guus
14:39:20 <ivan> ivan has changed the topic to: RDF Call agenda: http://www.w3.org/2011/rdf-wg/wiki/Meetings:Telecon2012.05.23
14:44:52 <manu1> manu1 has joined #rdf-wg
14:48:10 <Zakim> SW_RDFWG()11:00AM has now started
14:48:18 <Zakim> +Guus
14:48:22 <Zakim> +??P3
14:48:31 <yvesr> Zakim, ??P3 is me
14:48:31 <Zakim> +yvesr; got it
14:48:47 <Guus> Guus has joined #rdf-wg
14:48:59 <Guus> zakim, who is here?
14:48:59 <Zakim> On the phone I see Guus, yvesr
14:49:00 <Zakim> On IRC I see Guus, manu1, Zakim, RRSAgent, mlnt, mischat, yvesr, ivan, davidwood, trackbot, NickH, manu, sandro, ericP
14:49:37 <cygri> cygri has joined #rdf-wg
14:49:43 <yvesr> i think i am supposed to scribe - but i didn't do it in a looong time so will probably need some help :)
14:52:51 <tbaker> tbaker has joined #rdf-wg
14:55:26 <swh> swh has joined #rdf-wg
14:56:31 <AZ> AZ has joined #rdf-wg
14:57:01 <yvesr> scribenick: yvesr
14:57:57 <LeeF> LeeF has joined #rdf-wg
14:58:08 <ScottB> ScottB has joined #rdf-wg
14:58:25 <Zakim> +??P4
14:58:42 <AZ> zakim, ??p4 is me
14:58:42 <Zakim> +AZ; got it
14:58:51 <sandro> trackbot, start meeting
14:58:53 <Zakim> +EricP
14:58:53 <trackbot> RRSAgent, make logs world
14:58:55 <trackbot> Zakim, this will be 73394
14:58:55 <Zakim> ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 2 minutes
14:58:56 <trackbot> Meeting: RDF Working Group Teleconference
14:58:56 <trackbot> Date: 23 May 2012
14:59:35 <Arnaud> Arnaud has joined #rdf-wg
15:00:30 <gavinc> gavinc has joined #rdf-wg
15:00:36 <swh> Zakim, what is the code?
15:00:36 <Zakim> the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), swh
15:01:35 <gavinc> Zakim, who is here?
15:01:35 <Zakim> I notice SW_RDFWG()11:00AM has restarted
15:01:36 <Zakim> On the phone I see Guus, yvesr, AZ, EricP, Sandro, Tony, Arnaud, ??P12, gavinc
15:01:36 <Zakim> On IRC I see gavinc, Arnaud, ScottB, LeeF, AZ, swh, tbaker, cygri, Guus, manu1, Zakim, RRSAgent, mlnt, mischat, yvesr, ivan, davidwood, trackbot, NickH, manu, sandro, ericP
15:01:38 <Zakim> +??P14
15:01:41 <manu1> zakim, I am ??P12
15:01:41 <Zakim> +manu1; got it
15:01:44 <swh> Zakim, ??P14 is me
15:01:45 <Zakim> +swh; got it
15:01:46 <Zakim> +cygri
15:02:24 <Zakim> +??P17
15:02:30 <ivan> zakim, dial ivan-voip
15:02:30 <Zakim> ok, ivan; the call is being made
15:02:34 <Zakim> +Ivan
15:02:59 <tbaker> zakim, ??P17 is tbaker
15:03:02 <Zakim> +tbaker; got it
15:03:21 <Guus> zakim, who is here?
15:03:26 <Zakim> On the phone I see Guus, yvesr, AZ, EricP, Sandro, Tony, Arnaud, manu1, gavinc, swh, cygri, tbaker, Ivan
15:03:30 <Zakim> On IRC I see gavinc, Arnaud, ScottB, LeeF, AZ, swh, tbaker, cygri, Guus, manu1, Zakim, RRSAgent, mlnt, mischat, yvesr, ivan, davidwood, trackbot, NickH, manu, sandro, ericP
15:04:39 <yvesr> Guus: propose to accept minutes of last week
15:05:00 <yvesr> Guus: resolve to accept minutes
15:05:17 <manu1> RESOLVED: Accept minutes from last week.
15:05:24 <gavinc> RESOLVED: accept the minutes of the 16 May telecon
15:06:01 <yvesr> Guus: the pending review list is empty
15:07:07 <manu1> q+ to voice concerns about TURTLE / N-Triples.
15:07:10 <yvesr> Guus: First, proposal to split the turtle document in two 
15:07:19 <yvesr> Guus: turtle / n-triples
15:07:45 <Guus> ack manu1
15:07:45 <Zakim> manu1, you wanted to voice concerns about TURTLE / N-Triples.
15:07:49 <ivan> ack manu1 
15:07:51 <yvesr> manu1: general concern that it is moving in the wrong direction
15:08:23 <yvesr> manu1: it would be best if Turtle would be *the* language to express RDF natively - primary RDF serialisation language
15:08:43 <yvesr> manu1: I am not going to raise a formal objection
15:09:04 <yvesr> gavinc: ntriples will still be a subset of the turtle language - the main change is to the document structure
15:09:26 <yvesr> gavinc: there are a lot of things that only apply to ntriples
15:09:40 <yvesr> gavinc: having them in a separate document makes the turtle document easier to write
15:09:50 <yvesr> manu1: could send the wrong message to the RDF community
15:10:09 <yvesr> manu1: turtle should include n-triples and n-quads
15:10:16 <yvesr> manu1: it should be the same language
15:10:33 <yvesr> gavinc: it is saying that n-triples shouldn't have its own media type, quite a strong statement
15:10:43 <yvesr> gavinc: we would have quite a lot of objections to that
15:10:54 <FabGandon> FabGandon has joined #rdf-wg
15:11:04 <yvesr> Guus: it should all be solved by a very clear statement
15:11:12 <yvesr> Guus: the reasons for splitting the document are very strong
15:11:38 <ivan> q+
15:11:42 <yvesr> manu1: n-triples and turtle have so many similarities that not merging them will be confusing
15:11:52 <yvesr> manu1: to the web developer community
15:12:03 <Guus> ack ivan
15:12:17 <Zakim> +[Sophia]
15:12:17 <yvesr> ivan: i understand where manu is coming from, but it is more a question of image rather than technology
15:12:30 <FabGandon> Zakim, Sophia is me
15:12:30 <Zakim> +FabGandon; got it
15:12:31 <yvesr> ivan: perhaps we should re-brand n-triples as 'mini-turtle'?
15:12:45 <yvesr> ivan: the title should make it clear that it is the stripped-down version of turtle
15:12:54 <manu1> q+ to say make it TURTLE Lite and I'm happy.
15:13:01 <yvesr> ivan: the document which describes n-triples is describing a small subset of turtle
15:13:05 <sandro> +0.5 "miniturtle"
15:13:10 <yvesr> gavinc: it should include language saying that you should use turtlw
15:13:15 <yvesr> s/turtlw/turtle
15:13:28 <Guus> ack manu1
15:13:28 <Zakim> manu1, you wanted to say make it TURTLE Lite and I'm happy.
15:13:38 <yvesr> manu1: make the name of the document turtle-light or mini-turtle and i am happy
15:13:59 <cygri> q+
15:14:06 <sandro> actually, "microturtle" may be better.     It's MUCH smaller than turtle.
15:14:07 <yvesr> gavinc: calling it n-triples is causing problems, because it's not exaclty what is known as n-triples now
15:14:38 <yvesr> cygri: this working group isn't about bringing new stuff to new communities, it is also serving the needs of the existing RDF dev community
15:14:54 <yvesr> cygri: from this point of view it does make sense to split the documents and it does make sense to keep the same name
15:15:03 <manu1> q+ to talk about existing users.
15:15:21 <Guus> ack cygri
15:15:26 <ericP> manu1, how do you like "The N-Triples Sublanguage of Turtle"? ('cause i think that we want current N-Triples use cases to migrate to this new form.)
15:15:30 <yvesr> cygri: i would be concerned of inventing new names for things that have been around for a long time
15:15:39 <sandro> how about:   RDF N-Triples - a microturtle syntax    :-)
15:15:44 <Guus> ack manu1
15:15:44 <Zakim> manu1, you wanted to talk about existing users.
15:15:48 <yvesr> Guus: let's keep this brief
15:16:02 <yvesr> manu1: the people who are already using it shouldn't be confused by a change of name
15:16:09 <yvesr> manu1: as they're already using it
15:16:20 <yvesr> ivan: gavinc can find something nice 
15:16:44 <yvesr> Guus: there are strong arguments for splitting the document into two, i'd propose we resolve that
15:16:59 <yvesr> PROPOSAL: SPlit the Turtle document into two - turtle and n-triples
15:17:00 <ericP> +1
15:17:05 <sandro> +1
15:17:07 <manu1> +1
15:17:09 <tbaker> +1
15:17:10 <yvesr> s/SPlit/Split
15:17:12 <yvesr> +1
15:17:13 <gavinc> +1
15:17:16 <Arnaud> +1
15:17:22 <ivan> +1 with the proviso that the n-triple document's title may be different
15:17:23 <manu1> +1 (as long as we name the new N-Triples document with a clear TURTLE Lite) message.
15:17:25 <sandro> ( TinyTurtle )
15:17:25 <cygri> +1
15:17:32 <yvesr> RESOLVED: Split the Turtle document into two - turtle and n-triples
15:18:02 <yvesr> Guus: first question was the whitespace question in Turtle
15:18:15 <yvesr> gavinc: this is whitespace in n-triples
15:18:48 <yvesr> gavinc: if there are whitespaces rules, they are at the top of the appendix, not in the grammar part of the appendix, and they should be in the grammar part as well
15:18:57 <yvesr> Guus: so we reached consensus on this
15:19:07 <yvesr> gavinc: yes, we reached consensus
15:19:57 <yvesr> ericP: there was some discussions about using exactly one whitespace
15:20:09 <yvesr> gavinc: the grammar should be somewhat loose
15:20:26 <yvesr> gavinc: you can have multiple empty lines, multiple whitespaces
15:20:28 <sandro> Maybe "Useful Subsets of Turtle"     *sigh*
15:20:57 <yvesr> gavinc: there should be some canonicalisation rules that enable one triple to be expressed in exactly the same way
15:21:04 <yvesr> ericP: canonicalisation of order as well?
15:21:19 <cygri> gavinc++
15:21:19 <yvesr> gavinc: it could include that as well, but triple-specific at first
15:21:22 <sandro> q+ to ask about rdf canonicalization (including bnodes)
15:21:49 <manu1> q+ to say this applies to JSON-LD Normalization.
15:21:51 <yvesr> ericP: is there a value to writing those rules as SHOULD, as parser-write will have to handle all cases anyway
15:22:02 <Guus> ack sandro
15:22:02 <Zakim> sandro, you wanted to ask about rdf canonicalization (including bnodes)
15:22:05 <swh> I see the value of having a recommendation for serilising triples
15:22:18 <swh> but \r\n for e.g. isn't grep friendly
15:22:29 <yvesr> sandro: it would be interesting to have the whole document, including bnodes, to be canonicalised
15:22:49 <gavinc> mmm... graph isomorphism for fun and ... no, not profit
15:22:49 <yvesr> sandro: it would be nice to be able to compare whether two graphs are equal by just comparing their documents
15:22:49 <swh> canonicalising bNodes is hard
15:22:50 <ericP> i'd rather produce the profile when we have a whay to do whole document canonicalization
15:23:04 <Zakim> +LeeF
15:23:24 <yvesr> ericP: if we waited for the canonicalisation, we would have a big chunk to give to the world
15:23:25 <gavinc> canonicalising bNodes is not only hard but GI-Hard
15:23:49 <yvesr> sandro: canonical n-triples making it easier to write parsers
15:24:01 <yvesr> s/n-triples/triples
15:24:02 <Guus> ack manu1
15:24:02 <Zakim> manu1, you wanted to say this applies to JSON-LD Normalization.
15:24:18 <yvesr> manu1: we have been working on this canonicalisation problem since a year
15:24:35 <yvesr> manu1: right now we serialize it to nquads (in json-ld)
15:24:47 <gavinc> http://en.wikipedia.org/wiki/Graph_isomorphism_problem
15:24:47 <yvesr> manu1: the tricky part is figuring out how many spaces you put between things
15:25:00 <manu1> http://json-ld.org/spec/latest/rdf-graph-normalization/
15:25:05 <yvesr> manu1: the very tricky part is figuring out the canonicalisation algorithm
15:25:20 <yvesr> manu1: it can get very complicated
15:25:38 <yvesr> manu1: in the case of http://json-ld.org/spec/latest/rdf-graph-normalization/ the output is some very specific n-quad document
15:25:46 <swh> q+
15:25:50 <yvesr> manu1: the graph normalisation algorithm is very hard
15:26:11 <yvesr> swh: some times you can't afford to do canonicalisation
15:26:11 <Guus> acl swh
15:26:15 <yvesr> swh: especially on large graphs
15:26:18 <Guus> ack swh
15:26:21 <sandro> q+
15:26:34 <Guus> ack sandro
15:26:48 <gavinc> sandro++
15:26:49 <cygri> sandro++
15:26:51 <yvesr> sandro: if the graph  happens to be canonical, then the bytes in the documents will be the same for the two same graphs
15:27:02 <ericP> we speak of `grep`, but i think the only tool that's enabled by canonicalized whitespace is some peculiar use cases of `cut`
15:27:06 <yvesr> sandro: that's one benefit of doing so
15:27:19 <yvesr> sandro: assuming canonicalisation handles b-nodes and triple ordering
15:27:44 <yvesr> manu1: as soon as you add b-nodes to the equation, it starts to be very hard to process large graphs
15:27:54 <yvesr> manu1: we have not found a polynomial-time algorithm to do that
15:27:58 <sandro> isnt graph isomorphism np-complete?
15:28:11 <yvesr> manu1: the canonicalisation itself is easy to define though
15:28:15 <pchampin> pchampin has joined #rdf-wg
15:28:21 <sandro> +1  :-)
15:28:36 <gavinc> sandro, GI-Hard
15:28:37 <Zakim> +??P6
15:28:43 <ericP> Guus: how much does this matter to the Turtle document
15:28:44 <pchampin> zakim, P6 is me
15:28:44 <Zakim> sorry, pchampin, I do not recognize a party named 'P6'
15:28:45 <gavinc> got it's very own complexity class
15:28:48 <yvesr> Guus: let's move on to the second issue
15:28:49 <manu1> gavinc: This doesn't have anything to do with TURTLE, so we can move on.
15:28:51 <sandro> Ah, I see.
15:28:53 <pchampin> zakim, ??P6 is me
15:28:53 <Zakim> +pchampin; got it
15:28:57 <ericP> gavinc: because we've separated N-Triples, absolutely none
15:29:29 <yvesr> sandro: strict vs. loose parsing - http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0408.html
15:30:01 <yvesr> sandro: I tried implementing Turtle and realised I could make it much easier if I didn't bother to check in the lexer little bits of the URI syntax
15:30:07 <cygri> q+
15:30:15 <yvesr> sandro: the grammar of Turtle enforces some rules about what can be in an IRI
15:30:18 <LeeF> Is there a test case that distinguishes between it being enforced in the lexer versus being enforced higher up in the chain?
15:30:30 <LeeF> Right, that's what I was expecting (what Sandro just said)
15:30:33 <yvesr> sandro: I could write a legitimate parser by taking it out
15:30:45 <yvesr> sandro: We should at least state it
15:30:49 <swh> I don't see how it has any baring on the grammar
15:30:52 <Guus> ack cygri
15:31:34 <yvesr> cygri: two issues - is it ok to have a definition of what an IRI is in Turtle?
15:31:36 <sandro> I've backed off the "fix them up" idea.
15:31:43 <gavinc> +q to talk about the nature of the grammar 
15:32:01 <yvesr> cygri: the other issue - editorial issue: how exactly valid IRIs in Turtle are described in the document
15:32:24 <yvesr> cygri: an option is to not define what's inside the angle bracket, and point to the IRI RFC
15:32:55 <Guus> q?
15:33:07 <yvesr> sandro: added to that there is a conformance issue
15:33:23 <yvesr> sandro: can i have a conformant Turtle parser that accepts IRIs that are not in the Turtle grammar
15:33:38 <yvesr> sandro: the tradition in our community has been that it was OK
15:33:50 <Guus> ack gavinc
15:33:50 <Zakim> gavinc, you wanted to talk about the nature of the grammar
15:33:56 <yvesr> sandro: as long as I can call it a Turtle parser without that, it's OK
15:34:08 <yvesr> gavinc: the grammar specifies a grammar, not *the* grammar
15:34:30 <yvesr> gavinc: if you write a different grammar, for example one that uses different production rules for IRIs, it still meets the same rules
15:34:35 <sandro> sandro: As long as I can implement a turtle parser that doesn't reject bad syntax-IRIs, I'm okay.
15:35:06 <sandro> q?
15:35:08 <yvesr> gavinc: what matters is if i put something that is not an IRI inside a <..>
15:35:12 <sandro> q+
15:35:17 <cygri> q+
15:35:20 <sandro> q-
15:35:24 <ericP> q?
15:35:26 <yvesr> gavinc: you can't have an RDF graph where one of the node isn't a literal or an IRI
15:35:43 <yvesr> sandro: checking whether something is in an IRI is incredibly hard
15:35:51 <yvesr> sandro: it's programmatically intractable
15:35:56 <Guus> ack cygri
15:36:05 <yvesr> sandro: what you can do is to have some heuristics checking whether it might be ok
15:36:39 <yvesr> cygri: we should tightened up the conformance clause in Turtle
15:36:57 <yvesr> cygri: if there was another grammar that ends matching the same strings, then that's conformant
15:36:58 <Zakim> -Ivan
15:37:11 <swh> +1 to cygri 
15:37:16 <gavinc> +1
15:37:17 <ericP> +1
15:37:20 <yvesr> cygri: the Turtle language is not its grammar
15:37:27 <ivan> zakim, dial ivan-voip
15:37:27 <Zakim> ok, ivan; the call is being made
15:37:29 <Zakim> +Ivan
15:37:33 <pchampin> +1
15:37:45 <sandro> +0 cyrgi.   I can live with conformance defines Turtle Document, and says a Turtle Parser handles Turtle Documents, and is silent on how to handle non-Turtle documents.
15:37:51 <yvesr> cygri: there are different needs for conformance for different situations
15:38:09 <yvesr> cygri: it naturally gives rise to a Turtle validator - it's obvious that we need it
15:38:09 <sandro> q+ to ask about negative syntax tests
15:38:17 <yvesr> cygri: it should dig into the IRIs and check their validity
15:38:20 <Guus> ack sandro
15:38:20 <Zakim> sandro, you wanted to ask about negative syntax tests
15:38:23 <yvesr> sandro: that's reasonable to me
15:38:33 <yvesr> sandro: we should include negative syntax test
15:38:45 <yvesr> sandro: it would be OK to fail the negative syntax test
15:39:03 <dlehn> dlehn has joined #rdf-wg
15:39:24 <yvesr> cygri: according to what I said earlier, I would say no
15:39:25 <dlongley> dlongley has joined #rdf-wg
15:39:28 <ericP> for the implementation report, can we go to PR witout any implementations passing the negative syntax tests?
15:39:42 <yvesr> sandro: we should mention this class of things that are Turtle validators
15:39:49 <yvesr> sandro: and that those negative tests apply to those
15:39:51 <sandro> sandro: Maybe the negative syntax texts are only for Turtle Validators.
15:40:01 <yvesr> cygri: the html5 spec spells out all that, a good example to look at
15:40:31 <yvesr> cygri: validators, user agents, etc.
15:40:37 <ericP> i think talking about implementations, conformance levels etc, will make the spec much much bigger and more opaque
15:40:58 <yvesr> Guus: I'd like to handle that while we're at the CR stage
15:41:10 <cygri> ericP, read the html5 conformance section before saying that
15:41:23 <sandro> cygri, you're talking about http://www.w3.org/TR/html5/infrastructure.html#conformance-requirements ?
15:41:27 <yvesr> gavinc: i think it's a 'do nothing' resolution
15:41:42 <gavinc> s/gavinc/ericP
15:41:46 <cygri> sandro, yes
15:41:55 <yvesr> Guus: my take is that it requires a small rephrasing of the conformance note
15:42:03 <gavinc> It requires WRITING a conformence clause
15:42:34 <cygri> q+
15:42:36 <yvesr> sandro: something that says that the grammar can be drammatically simplified 
15:43:25 <yvesr> cygri: it is a bad idea to say that - chances are that if you do not check the IRIs, you might break your system - because other components might
15:43:40 <sandro> q+
15:43:42 <yvesr> cygri: I think it's not a good idea to tell to people they can cut corners
15:43:48 <Guus> ack cygri
15:43:54 <Guus> ack sandro
15:44:02 <gavinc> ... ....
15:44:03 <yvesr> cygri: it's OK to phrase conformance slightly differently, but we shouldn't encourage to not check that
15:44:35 <gavinc> There are no RDF graphs that cannot be represented in Turtle
15:44:35 <swh> we're talking about extreme corner cases here
15:44:54 <yvesr> sandro: most systems are opaque with respect to IRIs
15:45:15 <yvesr> swh: the most used parser at the moment does check them
15:45:20 <yvesr> s/swh/cygri
15:45:22 <manu1> q+ to ask about what IRIs cannot be serialized in TURTLE - example?
15:45:58 <sandro> manu, any IRI with | in it, for instance.
15:46:14 <manu1> q-
15:46:23 <yvesr> cygri: we shouldn't specify error-handling - it is unlikely that there is one behavior that works for all situations
15:46:32 <yvesr> cygri: we should leave the corner-cases unspecified
15:46:44 <manu1> q+ to express concern over IRI opacity.
15:46:55 <yvesr> cygri: the cost/benefit decision is for implementers to make
15:47:09 <yvesr> Guus: some of these things we can still handle at CR time
15:47:17 <yvesr> sandro: we don't have to handle it now
15:47:18 <manu1> q-
15:47:47 <manu1> q+ to raise issue about NQuads in TURTLE...
15:47:58 <yvesr> Guus: each meeting seems to float towards a Last Call graph, but we're still not there this week - i hope we can do it next week
15:48:21 <yvesr> manu1: I feel pretty strongly that we need named quads in turtle
15:48:35 <swh> we have discussed it a lot
15:48:47 <cygri> manu1, there were a few emails about this
15:48:50 <swh> Garlik/Experian WILL formally object to including quads in turtle
15:48:51 <cygri> 2000 or so
15:48:51 <gavinc> This issue has been raised a number of times. Strong objections were raised as to making text/turtle produce quads rather than Triples
15:48:52 <sandro> q+
15:49:00 <yvesr> manu1: if we don't put it in there, people are going to abandon Turtle in the long run
15:49:13 <yvesr> sandro: there's nothing wrong with that - people will move over to a better language
15:49:36 <yvesr> manu1: if we solve that problem now, the cost to society is lower
15:49:46 <yvesr> sandro: perhaps we could specify it as an extension to this language
15:49:58 <yvesr> manu1: such migrations are not painless
15:50:02 <gavinc> Please refer to perma thread on @graph, TriG, etc
15:50:29 <yvesr> manu1: is there anyone in the group who thinks that we don't need named graphs?
15:50:51 <LeeF> Just roundtrip with trig instead, no?
15:50:56 <sandro> manu, the problem is that GRAPHs turns out to be very hard for this group to sort out.
15:50:58 <Guus> q?
15:50:58 <ivan> q+
15:51:04 <yvesr> manu1: it would be good to be able to go from JSON-LD to Turtle and back to JSON-LD
15:51:07 <gavinc> ack manu1
15:51:07 <Zakim> manu1, you wanted to raise issue about NQuads in TURTLE...
15:51:10 <Guus> ack sandro
15:51:15 <cygri> ericP, twoples were a mistake already. uniples!
15:51:17 <Guus> ack manu1
15:51:23 <yvesr> sandro: I think Turtle is well-understood as not including named graphs
15:51:30 <yvesr> sandro: if we include them, we need to come up with a different name
15:51:43 <ericP> +1 to sandro, we'll need a name like "Turtle" for a "turtle-like" language
15:51:46 <LeeF> I agree with Sandro.
15:51:56 <LeeF> SteveH strongly agrees.
15:52:05 <gavinc> Many people stronly agree
15:52:15 <yvesr> manu1: I am worried it's language proliferation all over again
15:52:30 <Guus> ack ivan
15:52:39 <yvesr> ivan: I disagree - I think the question about whether named graphs is important is rethorical
15:52:44 <sandro> I am totally sympathetic to manu's position ....     but I don't think we can do it that way.
15:52:49 <yvesr> ivan: it has been the main topic of discussion in the group for months
15:53:03 <yvesr> ivan: there should be a separate TriG - Turtle + Named Graphs
15:53:18 <yvesr> ivan: a number of existing deployment need to know in advance what's in the data
15:53:36 <yvesr> ivan: whether it is just Turtle or whether it includes Named Graphs as well
15:53:41 <sandro> -1 on Steve's requirement that graph-syntax and and turtle be disjoint.
15:54:01 <yvesr> ivan: any Turtle documents should be a valid TriG document - it's not a different language
15:54:01 <pchampin> +∞
15:54:03 <sandro> +1 any turtle documement is a graph-syntax language.
15:54:10 <manu1> I would be fine with TURTLE 2.0 including graph syntax.
15:54:11 <yvesr> ivan: it is separating the concepts very clearly
15:54:21 <swh> objects is too strong
15:54:25 <manu1> (but this is something we need for Web Payments, PaySwarm and JSON-LD)
15:54:26 <swh> q+ to explain
15:54:37 <swh> exactly :)
15:55:00 <yvesr> ivan: when we get to the point where TriG is defined, JSON-LD has a round-trip with TriG
15:55:25 <yvesr> manu1: I am deferring to the group, but I think it is a mistake
15:55:32 <yvesr> Guus: we're going to leave at that for the moment
15:55:51 <yvesr> Guus: is next week possible for the Last Call?
15:56:15 <yvesr> gavinc: in the todo list, we need to find the balance between sandro and cygri's points
15:56:26 <swh> q-
15:57:20 <yvesr> gavinc: validation, conformance, implementation may make the document more complicated
15:57:37 <gavinc> s/gavinc/ericP
15:57:45 <gavinc> +1 to cygri writing some text! :D
15:57:46 <yvesr> cygri: i could draft five sentences that I'd like to see in the conformance section
15:57:57 <sandro> +1 richard proposing text for Conformance
15:58:29 <yvesr> ACTION: cygri to draft five sentences for the conformance section in Turtle
15:58:29 <trackbot> Created ACTION-173 - Draft five sentences for the conformance section in Turtle [on Richard Cyganiak - due 2012-05-30].
15:59:36 <manu1> For the record - I'm fine with N-Triples renamed as (Turtle Lite/Micro/etc.), Turtle as Turtle, TRiG as Turtle 1.1
16:00:07 <sandro> sandro: And of course my non-validating Turtle Parser is going to allow @prefix/prefix to mix with period and non-period.
16:00:46 <yvesr> Guus: let's move on to JSON-LD
16:00:59 <yvesr> Guus: let's not have a long discussion on this
16:01:20 <manu1> Topic: JSON-LD Syntax
16:01:22 <manu1> http://json-ld.org/spec/ED/json-ld-syntax/20120522/
16:04:22 <yvesr> manu1: the conversion from one language to another is an algorithmic thing
16:04:40 <gavinc> HTML5 defines both, Turtle defines both, XML defines both
16:04:41 <ericP> q+
16:04:45 <yvesr> sandro: JSON-LD is a syntax without semantics atm - we're suggesting it should have semantics, that mapped to RDF
16:04:58 <ericP> q+ to discuss mechanics of a community WD review and tracking down how to interpret the JSON-LD document
16:05:11 <yvesr> manu1: if the issue is that it's not clear what the RDF mapping is, then it is in the JSON-LD API
16:05:25 <yvesr> manu1: it would be weird for the group to publish one document without the other
16:05:42 <ivan> q+
16:05:45 <yvesr> manu1: that API document needs to be published through the W3C in some form either way
16:05:51 <Guus> ack ericP
16:06:13 <yvesr> manu1: we shouldn't make a big editorial decision to tackle an issue around how the document will be published
16:06:22 <Zakim> ericP, you wanted to discuss mechanics of a community WD review and tracking down how to interpret the JSON-LD document
16:06:51 <yvesr> ericP: we could have a first public working draft that would point to one fairly stable document that has the API, stating that it will be standardised
16:06:57 <manu1> q+ to say that we could do a FPWD for JSON-LD API
16:07:20 <yvesr> ericP: are the semantics the way that the developers are going to use JSON-LD?
16:08:02 <yvesr> ericP: there is a community that consumes JSON as a wire format, and who won't commit to the JSON API
16:08:17 <yvesr> ericP: what makes editorial sense for one community doesn't alienate the other community
16:08:23 <Guus> ack ivan
16:08:24 <yvesr> s/the other/another
16:08:35 <manu1> My current concerns about JSON-LD in RDF WG:
16:08:37 <manu1>   * The primary contributors of JSON-LD are not Invited Experts in RDF WG and
16:08:39 <manu1>     thus can't take part in the conversation on the mailing list / in the group.
16:08:41 <manu1>   * Bringing the RDF WG up-to-speed with JSON-LD - what is the most efficient way?
16:08:42 <manu1>   * Do a FPWD as soon as possible after everyone knows what is going on.
16:08:44 <manu1>   * How are issues handled? JSON-LD issue tracker, or RDF WG issue tracker?
16:08:46 <manu1>   * Time-box JSON-LD stages to ensure rapid progress?
16:08:53 <Guus> ack manu1
16:08:53 <Zakim> manu1, you wanted to say that we could do a FPWD for JSON-LD API
16:09:05 <yvesr> ivan: if this group publishes both the syntax and the API, then there has to be some clearer references, and then there is no problem
16:09:20 <yvesr> ivan: there is no major issue in the split in two documents
16:09:31 <yvesr> ivan: however only one document was submitted to this WG
16:09:37 <yvesr> ivan: why was the other document omitted?
16:09:52 <yvesr> ivan: let's try to see if we can publish both documents within this WG
16:10:24 <yvesr> Guus: please come back to the WG with how you want to go forward
16:10:32 <sandro> q?
16:10:47 <cygri> personally, i'm not much interested in the JSON API, but I'm very interested in the RDF mapping
16:10:52 <sandro> but that doesn't mean we're interested in both.
16:11:07 <yvesr> Guus: the group is only interested if there's a clear link to RDF, which currently is in the API
16:11:27 <yvesr> Guus: please send your message with also a link to the API
16:11:30 <yvesr> manu1: ok
16:11:35 <Arnaud> I won't take more time on the call but I'm unclear as to the status of the JSON-LD spec
16:11:58 <manu1> Arnaud: JSON-LD Syntax spec is ready for a FPWD... this group is attempting to decide if they're going to publish it as a FPWD.
16:12:01 <yvesr> Topic: RDF Concepts WD
16:12:02 <Arnaud> and what it will take from a legal point of view for the WG to pick it up
16:12:10 <ivan> Arnaud: at the moment it is a document produced by a community group
16:12:15 <yvesr> Guus: should we do a republication of the RDF Concepts Working Draft
16:12:35 <gavinc> Would like to publish with N-Triples FPWD, Turtle LC
16:12:49 <yvesr> cygri: there are still a number of issues open, but only in two categories
16:12:49 <Arnaud> there is a defined process to move a community spec to a wg, regarding copyrights and licensing commitments
16:12:58 <yvesr> cygri: 1) editorial stuff, 2) graphs
16:13:09 <yvesr> cygri: the second category might take a bit more time
16:13:12 <ivan> q+
16:13:25 <Arnaud> and I think this is the first instance of practicing this process
16:13:25 <yvesr> cygri: all the rest have been sorted out - so it's a good time to publish a revised WD
16:13:30 <Guus> ack ivan
16:13:46 <yvesr> ivan: do we really have a formal decision on the HTML datatype?
16:13:48 <yvesr> Guus: yes
16:14:04 <cygri> http://www.w3.org/2011/rdf-wg/track/issues/63
16:14:11 <cygri> RESOLVED: to accept the resolution to ISSUE 63 as proposed in http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0222.html but without the definition of the canonical mapping
16:14:36 <yvesr> ivan: then I am perfectly happy publishing a revised draft
16:15:21 <yvesr> PROPOSED: Publishing a revised version of RDF Concepts
16:15:21 <gavinc> +1 perfer timing with Turtle LC, N-Triples FPWD but won't stand in the way
16:15:29 <cygri> +1
16:15:29 <ivan> +1
16:15:31 <yvesr> +1
16:15:33 <pchampin> +1
16:15:35 <tbaker> +0
16:15:35 <AZ> +1
16:15:36 <swh> +1
16:15:36 <LeeF> +1
16:15:48 <cygri> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#
16:16:07 <Arnaud> +1
16:16:22 <sandro> +0
16:16:28 <yvesr> RESOLVED: Publishing a revised version of RDF Concepts
16:16:34 <gavinc> Link with version encoded http://dvcs.w3.org/hg/rdf/file/bb711b18e3fc/rdf-concepts/index.html
16:16:45 <yvesr> Guus: we're now out of time
16:17:00 <gavinc> +1 to 15 more minutes to resolve the Graph issues
16:17:04 <sandro> +1
16:17:12 <cygri> +1
16:17:14 <pchampin> +1
16:17:39 <yvesr> Topic: Named Graphs
16:17:55 <cygri> ISSUE-5 Graph literals http://www.w3.org/2011/rdf-wg/track/issues/5
16:18:01 <yvesr> cygri: the first issue is ISSUE-5 on graph literals
16:18:11 <yvesr> cygri: is it necessary to define some literal datatype for graphs?
16:18:26 <Arnaud> sorry, I have to drop off
16:18:38 <Zakim> -Arnaud
16:18:47 <yvesr> cygri: the proposal is to close this issue - we don't need such a datatype
16:18:52 <cygri> PROPOSED: Close ISSUE-5 ("Should we define Graph Literal datatypes?"), saying No, we should not.
16:19:04 <gavinc> Peter F. Patel-Schneider votes +1 to no graph literals
16:19:09 <swh> +1
16:19:17 <Zakim> -manu1
16:19:25 <ivan> +0.5
16:19:26 <Guus> Andy: +1
16:19:29 <yvesr> +0
16:19:31 <AZ> +0
16:19:38 <sandro> +0
16:19:40 <gavinc> +1
16:19:44 <tbaker> +0
16:19:45 <cygri> there was +1 from pat too
16:19:46 <Guus> +1
16:19:54 <LeeF> +1
16:20:02 <gavinc> Pat Hayes votes +1
16:20:23 <yvesr> RESOLVED: Close ISSUE-5 ("Should we define Graph Literal datatypes?"), saying No, we should not.
16:20:35 <cygri> ISSUE-28 Syntactic nesting of g-texts http://www.w3.org/2011/rdf-wg/track/issues/28
16:20:35 <yvesr> Guus: moving to ISSUE-28
16:21:01 <yvesr> cygri: do we need to support nesting in graphs? especially as N3 supports it
16:21:03 <cygri> PROPOSED: Close ISSUE-28 ("Do we need syntactic nesting of graphs (g-texts) as in N3?"), saying No, we do not -- the use cases presented to the WG can be addressed without, and making syntactic nesting pay off would require additional logic machinery that's beyond this WG's scope.
16:21:06 <yvesr> cygri: is it OK to do without that?
16:21:43 <gavinc> Peter F. Patel-Schneider votes +1
16:21:45 <AZ> +1
16:21:56 <gavinc> AndyS votes +1
16:22:06 <sandro> +0 okay with proposal; don't agree it's beyond our scope.   still, compatibility with sparql requires no nesting of datasets
16:22:10 <yvesr> +0.5
16:22:24 <swh> +1
16:22:40 <yvesr> ivan: a different statement is that it is beyond what the WG can reasonably do in a limited time
16:22:44 <cygri> PROPOSED: Close ISSUE-28 ("Do we need syntactic nesting of graphs (g-texts) as in N3?"), saying No, we do not -- the use cases presented to the WG can be addressed without, and making syntactic nesting pay off would require additional logic machinery that's beyond this WG's timeframe
16:22:57 <ivan> +1
16:22:58 <yvesr> +0.5
16:23:00 <AZ> +1
16:23:01 <LeeF> +1
16:23:01 <pchampin> +1
16:23:03 <Guus> +1
16:23:03 <sandro> +0.5
16:23:11 <swh> +0.5
16:23:18 <gavinc> +1
16:23:32 <yvesr> RESOLVED:  Close ISSUE-28 ("Do we need syntactic nesting of graphs (g-texts) as in N3?"), saying No, we do not -- the use cases presented to the WG can be addressed without, and making syntactic nesting pay off would require additional logic machinery that's beyond this WG's timeframe
16:23:32 <tbaker> +0
16:23:42 <cygri> ISSUE-29 Do we support SPARQL's notion of "default graph"? http://www.w3.org/2011/rdf-wg/track/issues/29
16:23:44 <swh> [for the record I think it would be huge mistake]
16:24:24 <yvesr> swh: trying to standardise nested graphs without implementation experience would be a mistake
16:24:30 <sandro> swh: "it" being "standardizing nested graphs"
16:24:40 <LeeF> Stop causing trouble, steve :)
16:24:55 <swh> +1 to LeeF
16:25:08 <cygri> PROPOSED: Close ISSUE-29 (Do we support SPARQL's notion of "default graph"?'), Yes, we do.
16:25:09 <gavinc> Peter F. Patel-Schneider votes +1 to RDF datasets, even without semantics, provide the necessary machinery
16:25:13 <yvesr> cygri: should we include a default graph
16:25:15 <gavinc> AndyS votes +1
16:25:15 <sandro> +1
16:25:20 <yvesr> cygri: there's an obvious case for it
16:25:20 <swh> +1
16:25:21 <yvesr> +1
16:25:21 <ivan> +1
16:25:24 <AZ> +1
16:25:25 <Guus> +1
16:25:30 <gavinc> PatH votes +1
16:25:33 <LeeF> +1
16:25:34 <gavinc> +1
16:25:44 <tbaker> +1
16:26:15 <yvesr> RESOLVED: Close ISSUE-29 (Do we support SPARQL's notion of "default graph"?'), Yes, we do.
16:26:35 <cygri> ISSUE-30 Relation RDF Datasets with multiple graphs http://www.w3.org/2011/rdf-wg/track/issues/30
16:26:40 <cygri> PROPOSED: Close ISSUE-30 ("How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?"), saying we will use SPARQL's notion of RDF dataset as much of the foundation of our handling of multiple graphs.
16:26:55 <yvesr> cygri: this issue is almost not worth spending any time on it
16:27:04 <sandro> +1
16:27:08 <swh> +1
16:27:09 <ivan> +1
16:27:12 <gavinc> +1
16:27:15 <yvesr> cygri: in terms of the abstract syntax we accept the SPARQL thing: pairs of IRIs and graphs and a default graph
16:27:15 <AZ> +1
16:27:18 <yvesr> +1
16:27:26 <gavinc> Peter F. Patel-Schneider: +1 to RDF datasets, even without semantics, provide this facility
16:27:26 <Guus> +1
16:27:30 <gavinc> AndyS: +1
16:27:31 <tbaker> +1
16:27:33 <gavinc> PathH: +1
16:27:36 <gavinc> +1
16:27:38 <yvesr> RESOLVED:  Close ISSUE-30 ("How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?"), saying we will use SPARQL's notion of RDF dataset as much of the foundation of our handling of multiple graphs.
16:27:46 <cygri> ISSUE-33 Mechanism to refer to sub-graphs and/or individual triples http://www.w3.org/2011/rdf-wg/track/issues/33
16:28:06 <cygri> PROPOSED: Close ISSUE-33 ("Do we provide a way to refer sub-graphs and/or individual triples?"), with the understanding that datasets can be used to refer to sub-graphs and individual triples.
16:28:07 <cygri> [edit]
16:28:15 <yvesr> cygri: there was a proposal that we should not have graph identifiers, but triple identifiers
16:28:18 <gavinc> Peter F. Patel-Schneider: +1 to RDF datasets, even without semantics, provide enough here.
16:28:26 <yvesr> cygri: counter-argument was that we don't really need that - graphs with one triple are OK
16:28:31 <gavinc> PatH: +1
16:28:34 <gavinc> AndyS: +1
16:28:36 <sandro> +1 triples and subgraphs are special cases of graphs
16:28:36 <yvesr> cygri: and then we don't need to do anything special about it
16:28:41 <ivan> +1
16:28:44 <FabGandon> +1
16:28:45 <Guus> +1
16:28:46 <gavinc> +1
16:28:47 <tbaker> +1
16:28:49 <yvesr> does it address the sub-graph case
16:28:59 <sandro> (understanding that this does NOT rule out sharing blank nodes between named graphs)
16:30:40 <pchampin> +1
16:31:01 <yvesr> yvesr: does it tackle the sub-graph issue as well?
16:31:21 <cygri> PROPOSED: Close ISSUE-33 ("Do we provide a way to refer sub-graphs and/or individual triples?"), with the understanding that datasets can be used to refer to sub-graphs and individual triples. This does NOT rule out sharing blank nodes between named graphs.
16:31:25 <yvesr> cygri: you can create a new graph for the sub-graph, it is an implementation issue to deal with that without bloating the storage
16:31:27 <sandro> +1
16:31:31 <Guus> +1
16:31:39 <yvesr> cygri: happy to find some phrasing that makes that clearer  though
16:31:50 <yvesr> +1
16:32:08 <gavinc> AndyS: +1
16:32:13 <gavinc> PatH: +1
16:32:19 <tbaker> +0.5
16:32:23 <ivan> +1
16:32:56 <cygri> ACTION: cygri to work with yves on informative text regarding avoiding duplication for subgraphs
16:32:56 <trackbot> Created ACTION-174 - Work with yves on informative text regarding avoiding duplication for subgraphs [on Richard Cyganiak - due 2012-05-30].
16:32:56 <swh> +1
16:33:01 <LeeF> +1
16:33:11 <yvesr> RESOLVED: Close ISSUE-33 ("Do we provide a way to refer sub-graphs and/or individual triples?"), with the understanding that datasets can be used to refer to sub-graphs and individual triples. This does NOT rule out sharing blank nodes between named graphs.
16:33:44 <Zakim> -gavinc
16:33:45 <Zakim> -Ivan
16:33:46 <Zakim> -EricP
16:33:47 <Zakim> -cygri
16:33:47 <Zakim> -Sandro
16:33:49 <Zakim> -tbaker
16:33:51 <Zakim> -FabGandon
16:33:55 <Zakim> -yvesr
16:33:57 <Zakim> -swh
16:33:59 <Zakim> -AZ
16:34:03 <Zakim> -pchampin
16:34:07 <Zakim> -Tony
16:34:33 <Zakim> -LeeF
16:36:10 <Guus> trackbot, end meeting
16:36:10 <trackbot> Zakim, list attendees
16:36:10 <Zakim> As of this point the attendees have been Guus, yvesr, AZ, EricP, Sandro, Tony, Arnaud, gavinc, manu1, swh, cygri, Ivan, tbaker, FabGandon, LeeF, pchampin
16:36:18 <trackbot> RRSAgent, please draft minutes
16:36:18 <RRSAgent> I have made the request to generate http://www.w3.org/2012/05/23-rdf-wg-minutes.html trackbot
16:36:19 <trackbot> RRSAgent, bye
16:36:21 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2012/05/23-rdf-wg-actions.rdf :
16:36:24 <RRSAgent> ACTION: cygri to draft five sentences for the conformance section in Turtle [1]
16:36:26 <RRSAgent>   recorded in http://www.w3.org/2012/05/23-rdf-wg-irc#T15-58-29
16:36:27 <RRSAgent> ACTION: cygri to work with yves on informative text regarding avoiding duplication for subgraphs [2]
16:36:30 <RRSAgent>   recorded in http://www.w3.org/2012/05/23-rdf-wg-irc#T16-32-59
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000599