14:38:13 trackbot, start telcon 14:38:13 logging to http://www.w3.org/2012/05/23-rdf-wg-irc 14:38:15 RRSAgent, make logs world 14:38:15 I have made the request, trackbot 14:38:17 Zakim, this will be 73394 14:38:17 ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 22 minutes 14:38:18 Meeting: RDF Working Group Teleconference 14:38:18 Date: 23 May 2012 14:38:23 Chair: Guus 14:48:07 SW_RDFWG()11:00AM has now started 14:48:14 +Guus 14:48:19 +??P3 14:48:28 Zakim, ??P3 is me 14:48:28 +yvesr; got it 14:48:56 zakim, who is here? 14:48:56 On the phone I see Guus, yvesr 14:48:57 On IRC I see Guus, manu1, Zakim, RRSAgent, mlnt, mischat, yvesr, ivan, davidwood, trackbot, NickH, manu, sandro, ericP 14:49:40 i think i am supposed to scribe - but i didn't do it in a looong time so will probably need some help :) 14:56:57 scribenick: yvesr 14:58:22 +??P4 14:58:39 zakim, ??p4 is me 14:58:39 +AZ; got it 14:58:47 trackbot, start meeting 14:58:49 +EricP 14:58:50 RRSAgent, make logs world 14:58:50 I have made the request, trackbot 14:58:52 Zakim, this will be 73394 14:58:52 ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 2 minutes 14:58:53 Meeting: RDF Working Group Teleconference 14:58:53 Date: 23 May 2012 15:00:32 Zakim, what is the code? 15:00:33 the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), swh 15:01:32 Zakim, who is here? 15:01:32 I notice SW_RDFWG()11:00AM has restarted 15:01:33 On the phone I see Guus, yvesr, AZ, EricP, Sandro, Tony, Arnaud, ??P12, gavinc 15:01:33 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:35 +??P14 15:01:38 zakim, I am ??P12 15:01:38 +manu1; got it 15:01:41 Zakim, ??P14 is me 15:01:42 +swh; got it 15:01:43 +cygri 15:02:21 +??P17 15:02:27 zakim, dial ivan-voip 15:02:27 ok, ivan; the call is being made 15:02:31 +Ivan 15:02:56 zakim, ??P17 is tbaker 15:02:59 +tbaker; got it 15:03:18 zakim, who is here? 15:03:23 On the phone I see Guus, yvesr, AZ, EricP, Sandro, Tony, Arnaud, manu1, gavinc, swh, cygri, tbaker, Ivan 15:03:27 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:35 Guus: propose to accept minutes of last week 15:04:57 Guus: resolve to accept minutes 15:05:14 RESOLVED: Accept minutes from last week. 15:05:21 RESOLVED: accept the minutes of the 16 May telecon 15:05:58 Guus: the pending review list is empty 15:07:04 q+ to voice concerns about TURTLE / N-Triples. 15:07:07 Guus: First, proposal to split the turtle document in two 15:07:16 Guus: turtle / n-triples 15:07:42 ack manu1 15:07:42 manu1, you wanted to voice concerns about TURTLE / N-Triples. 15:07:45 ack manu1 15:07:48 manu1: general concern that it is moving in the wrong direction 15:08:20 manu1: it would be best if Turtle would be *the* language to express RDF natively - primary RDF serialisation language 15:08:40 manu1: I am not going to raise a formal objection 15:09:01 gavinc: ntriples will still be a subset of the turtle language - the main change is to the document structure 15:09:23 gavinc: there are a lot of things that only apply to ntriples 15:09:37 gavinc: having them in a separate document makes the turtle document easier to write 15:09:46 manu1: could send the wrong message to the RDF community 15:10:06 manu1: turtle should include n-triples and n-quads 15:10:13 manu1: it should be the same language 15:10:29 gavinc: it is saying that n-triples shouldn't have its own media type, quite a strong statement 15:10:40 gavinc: we would have quite a lot of objections to that 15:11:00 Guus: it should all be solved by a very clear statement 15:11:09 Guus: the reasons for splitting the document are very strong 15:11:35 q+ 15:11:39 manu1: n-triples and turtle have so many similarities that not merging them will be confusing 15:11:49 manu1: to the web developer community 15:11:59 ack ivan 15:12:13 +[Sophia] 15:12:14 ivan: i understand where manu is coming from, but it is more a question of image rather than technology 15:12:27 Zakim, Sophia is me 15:12:27 +FabGandon; got it 15:12:28 ivan: perhaps we should re-brand n-triples as 'mini-turtle'? 15:12:42 ivan: the title should make it clear that it is the stripped-down version of turtle 15:12:51 q+ to say make it TURTLE Lite and I'm happy. 15:12:58 ivan: the document which describes n-triples is describing a small subset of turtle 15:13:02 +0.5 "miniturtle" 15:13:07 gavinc: it should include language saying that you should use turtlw 15:13:11 s/turtlw/turtle 15:13:25 ack manu1 15:13:25 manu1, you wanted to say make it TURTLE Lite and I'm happy. 15:13:34 manu1: make the name of the document turtle-light or mini-turtle and i am happy 15:13:56 q+ 15:14:02 actually, "microturtle" may be better. It's MUCH smaller than turtle. 15:14:03 gavinc: calling it n-triples is causing problems, because it's not exaclty what is known as n-triples now 15:14:35 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:50 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:14:59 q+ to talk about existing users. 15:15:18 ack cygri 15:15:23 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:26 cygri: i would be concerned of inventing new names for things that have been around for a long time 15:15:36 how about: RDF N-Triples - a microturtle syntax :-) 15:15:41 ack manu1 15:15:41 manu1, you wanted to talk about existing users. 15:15:45 Guus: let's keep this brief 15:15:59 manu1: the people who are already using it shouldn't be confused by a change of name 15:16:06 manu1: as they're already using it 15:16:17 ivan: gavinc can find something nice 15:16:41 Guus: there are strong arguments for splitting the document into two, i'd propose we resolve that 15:16:56 PROPOSAL: SPlit the Turtle document into two - turtle and n-triples 15:16:57 +1 15:17:02 +1 15:17:04 +1 15:17:05 +1 15:17:07 s/SPlit/Split 15:17:09 +1 15:17:09 +1 15:17:12 +1 15:17:19 +1 with the proviso that the n-triple document's title may be different 15:17:20 +1 (as long as we name the new N-Triples document with a clear TURTLE Lite) message. 15:17:21 ( TinyTurtle ) 15:17:22 +1 15:17:29 RESOLVED: Split the Turtle document into two - turtle and n-triples 15:17:59 Guus: first question was the whitespace question in Turtle 15:18:12 gavinc: this is whitespace in n-triples 15:18:45 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:54 Guus: so we reached consensus on this 15:19:04 gavinc: yes, we reached consensus 15:19:53 ericP: there was some discussions about using exactly one whitespace 15:20:06 gavinc: the grammar should be somewhat loose 15:20:22 gavinc: you can have multiple empty lines, multiple whitespaces 15:20:24 Maybe "Useful Subsets of Turtle" *sigh* 15:20:53 gavinc: there should be some canonicalisation rules that enable one triple to be expressed in exactly the same way 15:21:01 ericP: canonicalisation of order as well? 15:21:15 gavinc++ 15:21:16 gavinc: it could include that as well, but triple-specific at first 15:21:19 q+ to ask about rdf canonicalization (including bnodes) 15:21:46 q+ to say this applies to JSON-LD Normalization. 15:21:48 ericP: is there a value to writing those rules as SHOULD, as parser-write will have to handle all cases anyway 15:21:59 ack sandro 15:21:59 sandro, you wanted to ask about rdf canonicalization (including bnodes) 15:22:01 I see the value of having a recommendation for serilising triples 15:22:15 but \r\n for e.g. isn't grep friendly 15:22:25 sandro: it would be interesting to have the whole document, including bnodes, to be canonicalised 15:22:45 mmm... graph isomorphism for fun and ... no, not profit 15:22:46 sandro: it would be nice to be able to compare whether two graphs are equal by just comparing their documents 15:22:46 canonicalising bNodes is hard 15:22:46 i'd rather produce the profile when we have a whay to do whole document canonicalization 15:23:01 +LeeF 15:23:21 ericP: if we waited for the canonicalisation, we would have a big chunk to give to the world 15:23:22 canonicalising bNodes is not only hard but GI-Hard 15:23:46 sandro: canonical n-triples making it easier to write parsers 15:23:58 s/n-triples/triples 15:23:59 ack manu1 15:23:59 manu1, you wanted to say this applies to JSON-LD Normalization. 15:24:15 manu1: we have been working on this canonicalisation problem since a year 15:24:31 manu1: right now we serialize it to nquads (in json-ld) 15:24:43 http://en.wikipedia.org/wiki/Graph_isomorphism_problem 15:24:44 manu1: the tricky part is figuring out how many spaces you put between things 15:24:57 http://json-ld.org/spec/latest/rdf-graph-normalization/ 15:25:02 manu1: the very tricky part is figuring out the canonicalisation algorithm 15:25:16 manu1: it can get very complicated 15:25:35 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:43 q+ 15:25:47 manu1: the graph normalisation algorithm is very hard 15:26:08 swh: some times you can't afford to do canonicalisation 15:26:08 acl swh 15:26:12 swh: especially on large graphs 15:26:15 ack swh 15:26:18 q+ 15:26:31 ack sandro 15:26:45 sandro++ 15:26:46 sandro++ 15:26:48 sandro: if the graph happens to be canonical, then the bytes in the documents will be the same for the two same graphs 15:26:59 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:03 sandro: that's one benefit of doing so 15:27:16 sandro: assuming canonicalisation handles b-nodes and triple ordering 15:27:41 manu1: as soon as you add b-nodes to the equation, it starts to be very hard to process large graphs 15:27:51 manu1: we have not found a polynomial-time algorithm to do that 15:27:54 isnt graph isomorphism np-complete? 15:28:08 manu1: the canonicalisation itself is easy to define though 15:28:18 +1 :-) 15:28:33 sandro, GI-Hard 15:28:34 +??P6 15:28:40 Guus: how much does this matter to the Turtle document 15:28:41 zakim, P6 is me 15:28:41 sorry, pchampin, I do not recognize a party named 'P6' 15:28:42 got it's very own complexity class 15:28:44 Guus: let's move on to the second issue 15:28:45 gavinc: This doesn't have anything to do with TURTLE, so we can move on. 15:28:47 Ah, I see. 15:28:50 zakim, ??P6 is me 15:28:50 +pchampin; got it 15:28:54 gavinc: because we've separated N-Triples, absolutely none 15:29:26 sandro: strict vs. loose parsing - http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0408.html 15:29:57 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:04 q+ 15:30:12 sandro: the grammar of Turtle enforces some rules about what can be in an IRI 15:30:15 Is there a test case that distinguishes between it being enforced in the lexer versus being enforced higher up in the chain? 15:30:27 Right, that's what I was expecting (what Sandro just said) 15:30:30 sandro: I could write a legitimate parser by taking it out 15:30:42 sandro: We should at least state it 15:30:46 I don't see how it has any baring on the grammar 15:30:48 ack cygri 15:31:31 cygri: two issues - is it ok to have a definition of what an IRI is in Turtle? 15:31:33 I've backed off the "fix them up" idea. 15:31:40 +q to talk about the nature of the grammar 15:31:58 cygri: the other issue - editorial issue: how exactly valid IRIs in Turtle are described in the document 15:32:21 cygri: an option is to not define what's inside the angle bracket, and point to the IRI RFC 15:32:52 q? 15:33:03 sandro: added to that there is a conformance issue 15:33:20 sandro: can i have a conformant Turtle parser that accepts IRIs that are not in the Turtle grammar 15:33:35 sandro: the tradition in our community has been that it was OK 15:33:47 ack gavinc 15:33:47 gavinc, you wanted to talk about the nature of the grammar 15:33:53 sandro: as long as I can call it a Turtle parser without that, it's OK 15:34:04 gavinc: the grammar specifies a grammar, not *the* grammar 15:34:27 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:31 sandro: As long as I can implement a turtle parser that doesn't reject bad syntax-IRIs, I'm okay. 15:35:03 q? 15:35:05 gavinc: what matters is if i put something that is not an IRI inside a <..> 15:35:09 q+ 15:35:14 q+ 15:35:16 q- 15:35:21 q? 15:35:22 gavinc: you can't have an RDF graph where one of the node isn't a literal or an IRI 15:35:39 sandro: checking whether something is in an IRI is incredibly hard 15:35:48 sandro: it's programmatically intractable 15:35:53 ack cygri 15:36:02 sandro: what you can do is to have some heuristics checking whether it might be ok 15:36:35 cygri: we should tightened up the conformance clause in Turtle 15:36:54 cygri: if there was another grammar that ends matching the same strings, then that's conformant 15:36:55 -Ivan 15:37:08 +1 to cygri 15:37:13 +1 15:37:14 +1 15:37:16 cygri: the Turtle language is not its grammar 15:37:24 zakim, dial ivan-voip 15:37:24 ok, ivan; the call is being made 15:37:26 +Ivan 15:37:30 +1 15:37:42 +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:47 cygri: there are different needs for conformance for different situations 15:38:05 cygri: it naturally gives rise to a Turtle validator - it's obvious that we need it 15:38:06 q+ to ask about negative syntax tests 15:38:14 cygri: it should dig into the IRIs and check their validity 15:38:17 ack sandro 15:38:17 sandro, you wanted to ask about negative syntax tests 15:38:20 sandro: that's reasonable to me 15:38:30 sandro: we should include negative syntax test 15:38:42 sandro: it would be OK to fail the negative syntax test 15:39:20 cygri: according to what I said earlier, I would say no 15:39:25 for the implementation report, can we go to PR witout any implementations passing the negative syntax tests? 15:39:38 sandro: we should mention this class of things that are Turtle validators 15:39:45 sandro: and that those negative tests apply to those 15:39:47 sandro: Maybe the negative syntax texts are only for Turtle Validators. 15:39:58 cygri: the html5 spec spells out all that, a good example to look at 15:40:28 cygri: validators, user agents, etc. 15:40:34 i think talking about implementations, conformance levels etc, will make the spec much much bigger and more opaque 15:40:55 Guus: I'd like to handle that while we're at the CR stage 15:41:07 ericP, read the html5 conformance section before saying that 15:41:20 cygri, you're talking about http://www.w3.org/TR/html5/infrastructure.html#conformance-requirements ? 15:41:23 gavinc: i think it's a 'do nothing' resolution 15:41:39 s/gavinc/ericP 15:41:43 sandro, yes 15:41:52 Guus: my take is that it requires a small rephrasing of the conformance note 15:42:00 It requires WRITING a conformence clause 15:42:30 q+ 15:42:33 sandro: something that says that the grammar can be drammatically simplified 15:43:22 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:36 q+ 15:43:38 cygri: I think it's not a good idea to tell to people they can cut corners 15:43:45 ack cygri 15:43:51 ack sandro 15:43:59 ... .... 15:44:00 cygri: it's OK to phrase conformance slightly differently, but we shouldn't encourage to not check that 15:44:32 There are no RDF graphs that cannot be represented in Turtle 15:44:32 we're talking about extreme corner cases here 15:44:51 sandro: most systems are opaque with respect to IRIs 15:45:12 swh: the most used parser at the moment does check them 15:45:17 s/swh/cygri 15:45:19 q+ to ask about what IRIs cannot be serialized in TURTLE - example? 15:45:55 manu, any IRI with | in it, for instance. 15:46:10 q- 15:46:19 cygri: we shouldn't specify error-handling - it is unlikely that there is one behavior that works for all situations 15:46:29 cygri: we should leave the corner-cases unspecified 15:46:41 q+ to express concern over IRI opacity. 15:46:52 cygri: the cost/benefit decision is for implementers to make 15:47:06 Guus: some of these things we can still handle at CR time 15:47:13 sandro: we don't have to handle it now 15:47:15 q- 15:47:44 q+ to raise issue about NQuads in TURTLE... 15:47:54 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:17 manu1: I feel pretty strongly that we need named quads in turtle 15:48:31 we have discussed it a lot 15:48:44 manu1, there were a few emails about this 15:48:47 Garlik/Experian WILL formally object to including quads in turtle 15:48:47 2000 or so 15:48:48 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:48 q+ 15:48:56 manu1: if we don't put it in there, people are going to abandon Turtle in the long run 15:49:09 sandro: there's nothing wrong with that - people will move over to a better language 15:49:32 manu1: if we solve that problem now, the cost to society is lower 15:49:42 sandro: perhaps we could specify it as an extension to this language 15:49:55 manu1: such migrations are not painless 15:49:58 Please refer to perma thread on @graph, TriG, etc 15:50:26 manu1: is there anyone in the group who thinks that we don't need named graphs? 15:50:48 Just roundtrip with trig instead, no? 15:50:53 manu, the problem is that GRAPHs turns out to be very hard for this group to sort out. 15:50:55 q? 15:50:55 q+ 15:51:01 manu1: it would be good to be able to go from JSON-LD to Turtle and back to JSON-LD 15:51:03 ack manu1 15:51:03 manu1, you wanted to raise issue about NQuads in TURTLE... 15:51:07 ack sandro 15:51:12 ericP, twoples were a mistake already. uniples! 15:51:13 ack manu1 15:51:19 sandro: I think Turtle is well-understood as not including named graphs 15:51:27 sandro: if we include them, we need to come up with a different name 15:51:40 +1 to sandro, we'll need a name like "Turtle" for a "turtle-like" language 15:51:43 I agree with Sandro. 15:51:53 SteveH strongly agrees. 15:52:02 Many people stronly agree 15:52:11 manu1: I am worried it's language proliferation all over again 15:52:26 ack ivan 15:52:36 ivan: I disagree - I think the question about whether named graphs is important is rethorical 15:52:41 I am totally sympathetic to manu's position .... but I don't think we can do it that way. 15:52:46 ivan: it has been the main topic of discussion in the group for months 15:53:00 ivan: there should be a separate TriG - Turtle + Named Graphs 15:53:15 ivan: a number of existing deployment need to know in advance what's in the data 15:53:32 ivan: whether it is just Turtle or whether it includes Named Graphs as well 15:53:38 -1 on Steve's requirement that graph-syntax and and turtle be disjoint. 15:53:57 ivan: any Turtle documents should be a valid TriG document - it's not a different language 15:53:58 +∞ 15:54:00 +1 any turtle documement is a graph-syntax language. 15:54:07 I would be fine with TURTLE 2.0 including graph syntax. 15:54:08 ivan: it is separating the concepts very clearly 15:54:18 objects is too strong 15:54:21 (but this is something we need for Web Payments, PaySwarm and JSON-LD) 15:54:23 q+ to explain 15:54:34 exactly :) 15:54:57 ivan: when we get to the point where TriG is defined, JSON-LD has a round-trip with TriG 15:55:22 manu1: I am deferring to the group, but I think it is a mistake 15:55:28 Guus: we're going to leave at that for the moment 15:55:48 Guus: is next week possible for the Last Call? 15:56:12 gavinc: in the todo list, we need to find the balance between sandro and cygri's points 15:56:23 q- 15:57:17 gavinc: validation, conformance, implementation may make the document more complicated 15:57:33 s/gavinc/ericP 15:57:42 +1 to cygri writing some text! :D 15:57:43 cygri: i could draft five sentences that I'd like to see in the conformance section 15:57:54 +1 richard proposing text for Conformance 15:58:25 ACTION: cygri to draft five sentences for the conformance section in Turtle 15:58:25 Created ACTION-173 - Draft five sentences for the conformance section in Turtle [on Richard Cyganiak - due 2012-05-30]. 15:59:33 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:04 sandro: And of course my non-validating Turtle Parser is going to allow @prefix/prefix to mix with period and non-period. 16:00:43 Guus: let's move on to JSON-LD 16:00:55 Guus: let's not have a long discussion on this 16:01:17 Topic: JSON-LD Syntax 16:01:19 http://json-ld.org/spec/ED/json-ld-syntax/20120522/ 16:01:41 Guus: does the WG want to take part of this work? 16:01:52 -1 to publishing JSON-LD so long as it does not contain a mapping to and from RDF 16:02:00 Guus: having looked at the thread of discussion, the formal link to RDF is the key issue 16:02:39 manu1: JSON-LD does have a mapping to RDF, although not in that document 16:02:45 manu1: it is in the JSON-LD API 16:02:57 ivan: for now it is a community group document - we need a normative reference 16:03:01 +1 to publishing a JSON-LD spec if the link to RDF can be added explicitly to the spec 16:03:10 'cause it's the RDF WG 16:03:12 manu1: you're asking to put an algorithm in the JSON-LD syntax 16:03:15 gavinc++ 16:03:33 ivan: if the JSON-LD APIs are mature enough for standardisation, we could publish the two documents 16:03:49 ivan: if not, the RDF-related part have to be part of the JSON-LD document 16:03:59 Guus: would it be possible? 16:04:12 manu1: it wouldn't make any sense from an editorial perspective 16:04:22 manu1: the conversion from one language to another is an algorithmic thing 16:04:40 HTML5 defines both, Turtle defines both, XML defines both 16:04:41 q+ 16:04:45 sandro: JSON-LD is a syntax without semantics atm - we're suggesting it should have semantics, that mapped to RDF 16:04:58 q+ to discuss mechanics of a community WD review and tracking down how to interpret the JSON-LD document 16:05:11 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 manu1: it would be weird for the group to publish one document without the other 16:05:42 q+ 16:05:45 manu1: that API document needs to be published through the W3C in some form either way 16:05:51 ack ericP 16:06:13 manu1: we shouldn't make a big editorial decision to tackle an issue around how the document will be published 16:06:22 ericP, you wanted to discuss mechanics of a community WD review and tracking down how to interpret the JSON-LD document 16:06:51 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 q+ to say that we could do a FPWD for JSON-LD API 16:07:20 ericP: are the semantics the way that the developers are going to use JSON-LD? 16:08:02 ericP: there is a community that consumes JSON as a wire format, and who won't commit to the JSON API 16:08:17 ericP: what makes editorial sense for one community doesn't alienate the other community 16:08:23 ack ivan 16:08:24 s/the other/another 16:08:35 My current concerns about JSON-LD in RDF WG: 16:08:37 * The primary contributors of JSON-LD are not Invited Experts in RDF WG and 16:08:39 thus can't take part in the conversation on the mailing list / in the group. 16:08:41 * Bringing the RDF WG up-to-speed with JSON-LD - what is the most efficient way? 16:08:42 * Do a FPWD as soon as possible after everyone knows what is going on. 16:08:44 * How are issues handled? JSON-LD issue tracker, or RDF WG issue tracker? 16:08:46