Chatlog 2012-10-03

From RDF Working Group Wiki
Revision as of 15:25, 5 October 2012 by Sandro (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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:17:56 <RRSAgent> RRSAgent has joined #rdf-wg
14:17:56 <RRSAgent> logging to http://www.w3.org/2012/10/03-rdf-wg-irc
14:17:58 <trackbot> RRSAgent, make logs world
14:17:58 <Zakim> Zakim has joined #rdf-wg
14:18:00 <trackbot> Zakim, this will be 73394
14:18:00 <Zakim> ok, trackbot; I see SW_RDFWG()11:00AM scheduled to start in 42 minutes
14:18:01 <trackbot> Meeting: RDF Working Group Teleconference
14:18:01 <trackbot> Date: 03 October 2012
14:18:07 <ivan> Chair: David Wood
14:57:08 <ScottB> ScottB has joined #rdf-wg
14:58:41 <pfps> pfps has joined #rdf-wg
14:58:47 <Zakim> SW_RDFWG()11:00AM has now started
14:58:54 <Zakim> +davidwood
14:59:08 <davidwood> Zakim, who is here?
14:59:08 <Zakim> On the phone I see davidwood
14:59:09 <Zakim> On IRC I see pfps, ScottB, Zakim, RRSAgent, AndyS, mischat, MacTed, ivan, LeeF, SteveH, manu1, manu, gkellogg, yvesr, davidwood, trackbot, ericP, sandro
14:59:22 <pfps> I am IRC only today
14:59:25 <ivan> zakim, code?
14:59:25 <Zakim> the conference code is 73394 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), ivan
14:59:35 <cygri> cygri has joined #rdf-wg
14:59:39 <Zakim> +Tony
14:59:53 <Zakim> +[IPcaller]
14:59:57 <ScottB> Zakim, Tony is temporarily me
14:59:57 <Zakim> +ScottB; got it
15:00:05 <AndyS> zakim, IPcaller is me
15:00:05 <Zakim> +AndyS; got it
15:00:07 <Zakim> +Sandro
15:00:47 <Zakim> +ivan
15:00:49 <pchampin> pchampin has joined #rdf-wg
15:01:02 <Zakim> +??P10
15:01:06 <gkellogg> zakim, I am ??P10
15:01:06 <Zakim> +gkellogg; got it
15:01:13 <cgreer> cgreer has joined #rdf-wg
15:01:28 <Zakim> +??P11
15:01:39 <gavinc> gavinc has joined #rdf-wg
15:01:43 <Zakim> + +1.408.996.aaaa
15:01:44 <Arnaud> Arnaud has joined #rdf-wg
15:01:56 <Zakim> +mhausenblas
15:01:58 <cygri> zakim, mhausenblas is temporarily me
15:01:58 <Zakim> +cygri; got it
15:02:02 <Zakim> +??P16
15:02:06 <SteveH> Zakim, ??P16 is me
15:02:06 <Zakim> +SteveH; got it
15:02:09 <Zakim> + +1.707.318.aabb
15:02:12 <Zakim> +gavinc
15:02:58 <davidwood> Zakim, who is here?
15:02:58 <Zakim> On the phone I see davidwood, ScottB, AndyS, Sandro, ivan, gkellogg, pchampin, +1.408.996.aaaa, cygri, SteveH, +1.707.318.aabb, gavinc
15:03:00 <Zakim> On IRC I see Arnaud, gavinc, cgreer, pchampin, cygri, pfps, ScottB, Zakim, RRSAgent, AndyS, mischat, MacTed, ivan, LeeF, SteveH, manu1, manu, gkellogg, yvesr, davidwood, trackbot,
15:03:00 <Zakim> ... ericP, sandro
15:03:06 <AZ> AZ has joined #rdf-wg
15:03:18 <Guus> Guus has joined #rdf-wg
15:03:52 <gavinc> zakim, aabb is cgreer
15:03:52 <Zakim> +cgreer; got it
15:03:57 <cgreer> zakim, aabb is me
15:03:57 <Zakim> sorry, cgreer, I do not recognize a party named 'aabb'
15:04:14 <Zakim> +Guus_Schreiber
15:04:37 <Zakim> +OpenLink_Software
15:04:42 <Zakim> +??P22
15:04:43 <MacTed> Zakim, OpenLink_Software is temporarily me
15:04:44 <Zakim> +MacTed; got it
15:04:45 <MacTed> Zakim, mute me
15:04:45 <Zakim> MacTed should now be muted
15:05:11 <AZ> Zakim, ??P22 is me
15:05:11 <Zakim> +AZ; got it
15:05:11 <pchampin> scribe: pchampin
15:05:25 <davidwood> PROPOSED to accept the minutes of the 26 September:
15:05:25 <davidwood>    http://www.w3.org/2011/rdf-wg/meeting/2012-09-26
15:05:45 <davidwood> RESOLVED to accept the minutes of the 26 September:
15:05:45 <davidwood>    http://www.w3.org/2011/rdf-wg/meeting/2012-09-26
15:05:58 <davidwood> Topic: Review of action items
15:07:12 <pchampin> cygri: I mostly offline next week
15:07:22 <pchampin> ... I can post my comments to the list next sunday
15:07:25 <davidwood> s/next/this/
15:07:30 <ivan> s/next/this/
15:08:30 <pchampin> david: can we have another reviewer for Provenance Constraints document?
15:08:59 <pchampin> ivan: this document is the furthest away from the WG
15:09:33 <Zakim> +[GVoice]
15:10:05 <ericP> apologies, all -- burried in prov constraints
15:10:37 <pchampin> david: some discussions that happened on the mailing list, related to datasets, seemed also related to the Constraints document
15:10:47 <pchampin> ... so we might want someone to review it
15:11:06 <Zakim> +??P27
15:11:16 <pchampin> ivan: the problem is that the document is hard to read, very mathematical
15:11:36 <pchampin> ... and hard to understand in isolation
15:11:55 <pchampin> ... the Provenance data-model is a pre-requisite
15:11:57 <ivan> q+
15:12:02 <ericP> q+ to ask what we hope to get out of a review
15:12:20 <pchampin> AZ: I can give it a try, but the deadlines for the reviews will be hard to meet
15:12:26 <yvesr> Zakim, ??P27 is me
15:12:26 <Zakim> +yvesr; got it
15:14:06 <pchampin> ivan: it would be more efficient for us if we came back to the Prov-WG
15:14:18 <pchampin> ... and ask them to ask us the questions they have for our WG
15:15:05 <AZ> you can still put an action on me, even if there is a chance that it'll be overdue
15:15:29 <ericP> q?
15:15:32 <ericP> ack mq
15:15:32 <pchampin> david: I'll try to get that done
15:15:34 <ericP> ack me
15:15:34 <Zakim> ericP, you wanted to ask what we hope to get out of a review
15:15:37 <ivan> ack me
15:15:46 <ericP> http://www.w3.org/2012/10/prov-dm
15:15:52 <ericP> http://www.w3.org/2012/10/prov-constraints
15:15:57 <ericP> http://www.w3.org/2012/10/prov-constraints#worksOnGraphStore
15:16:31 <pchampin> eric: I spent some time reading both documents
15:16:35 <pchampin> ... above are my notes about them
15:17:00 <pchampin> ... could help Antoine in his review
15:17:27 <PatH> PatH has joined #rdf-wg
15:17:53 <AndyS> Could be important to LDP
15:18:08 <Zakim> +PatH
15:19:28 <pchampin> david: after a quick look at the document, it seems to me that many stores already do that
15:19:39 <pchampin> ... storing bookkeeping data in a dedicated graph
15:21:28 <cygri> erciP, how do you create those annotations? edit HTML in the source?
15:21:59 <ericP> cygri, yup, look for .mark (i suffered a lack of imagination at the time)
15:22:00 <pchampin> topic: FTF3
15:22:13 <pchampin> david: I cleaned up the participants list on the wiki
15:22:39 <ericP> cygri, ".mark" in the style block and e.g. <span class="mark">...</span> elsewhere
15:23:06 <pchampin> ... If anybody has specific agenda request, please post them to the mailing list
15:23:27 <cygri> ericP, i'll have to do my annotations on paper this time because i won't have a computer around for it, so i'll pass this time. i can see though how this can be very useful for reviewing big documents
15:23:43 <pchampin> topic: graphs
15:24:18 <pchampin> david: we had several proposals for the Trig syntax
15:25:23 <davidwood> PROPOSED: This Working Group will not provide a Formal Semantics for RDF Datasets or for our Dataset Syntax (eg trig). In the future, the WG will decide whether to include something simple (relevant to datasets) in the RDF 1.1 Semantics, such as [ <N, G> name-entails <N', G'> just when N=N' and G entails G'. ] and the WG may publish some information about dataset semantics in WG NOTES.
15:25:27 <pchampin> ... but we should first try to settle on the dataset semantic proposal
15:25:48 <AZ> q+
15:25:58 <davidwood> ack AZ
15:26:50 <pchampin> AZ: I think there was another proposal last time, from Pat and Peter, defining an entailment for datasets
15:27:27 <pchampin> david: I think there was still contention about the meaning of the default graph
15:27:33 <cygri> q+
15:27:50 <PatH> q+
15:28:18 <pchampin> AZ: it is not about the *meaning* of the default graph, only a constraint on entailment
15:28:33 <pchampin> david: and what do you think are the ramifications?
15:28:49 <pchampin> AZ: it constrains a little bit more how you can possibly interpret a dataset as a whole
15:29:04 <davidwood> STRAWPOLL: Have no Dataset Semantics (in the lifetime of this WG) http://www.w3.org/2011/rdf-wg/meeting/2012-09-26#line0228
15:29:17 <pfps> +1
15:29:21 <davidwood> q?
15:29:26 <davidwood> ack cygri
15:29:33 <pchampin> david: the answer last week to the strawpoll above was mostly "no we shoulnd't"
15:29:46 <sandro> ( davidwood was just repeating STRAWPOLL from last week )
15:30:01 <davidwood> yes
15:30:04 <pchampin> cygri: an argument against Antoine's proposal (and Pat's):
15:30:36 <PatH> call Antoines proposal "componentwise" entasilment to save time.
15:30:40 <pchampin> ... it is potentially dangerous to put a sketch of semantics that does not solve any problem on its own
15:31:04 <sandro> cygri: A reason against both these proposals is: it's potentially dangerous to put a sketch of a semantics in there, where we know it's not really a solution to anything, just a minimal part of the picture, that no one felt like formally objecting against.  If we don't have consensus on a USEFUL and in some sense COMOPLETE, then better to leave semantics unconstrained, leave it to future work.
15:31:07 <sandro> +1 cygri 
15:31:12 <pchampin> ... so if we can not agree on a "full package", then let's not constrain at all
15:31:37 <sandro> cygri: These proposals would be constraining future WGs.
15:31:45 <pchampin> ... or any future work (future RDF WG) would have to deal with those constraints
15:32:03 <sandro> cygri: It's kind of setting up a minefield for future research.
15:33:01 <davidwood> ack PatH
15:33:17 <pchampin> david: the proposal is to not define a semantics, and may be give reference to *examples* of how it could be done
15:33:30 <sandro> pat: My proposal is not a constraint because it's just defining a term.
15:33:45 <pchampin> pat: my proposal does not constrain any future work
15:34:02 <pchampin> ... it merely proposes a terminology to talk about this kind of problem
15:34:25 <AZ> q+
15:34:53 <pchampin> ... the problem with Antoine's proposal is that an inconsistent default graph makes the entire dataset inconcistent
15:35:00 <sandro> pat: The problem with the somewhat larger proposal is that an inconsistent default graph leads to entailing everything.
15:35:09 <pchampin> ... hence the dataset would entail anything, regardless of what is in the named graphs
15:35:15 <davidwood> ack AZ
15:35:42 <pchampin> AZ: my proposal does not implies that
15:35:52 <pchampin> ... we don't define a notion of semantics
15:36:23 <pchampin> ... it just says that an inconsistent default graph will entail any default graph, not dataset
15:36:54 <pchampin> pat: entailment is assumed to be truth-preserving
15:37:15 <pchampin> ... so from that definition of truth, one would derive a definition of truth
15:37:24 <yvesr> what's the argument against a semantic without default graphs? (as was proposed above)
15:37:44 <pchampin> ... what you need is only to talk about entailment between graphs
15:38:25 <davidwood> PROPOSED: This Working Group will not provide a Formal Semantics for RDF Datasets or for our Dataset Syntax (eg trig). In the future, the WG will decide whether to include something simple (relevant to datasets) in the RDF 1.1 Semantics, such as [ <N, G> name-entails <N', G'> just when N=N' and G entails G'. ] and the WG may publish some information about dataset semantics in WG NOTES.
15:38:43 <pchampin> ... The "modest proposal" just extends RDF-entailment with "named entailment"
15:39:00 <davidwood> PROPOSED: This Working Group will not provide a Formal Semantics for RDF Datasets or for our Dataset Syntax (eg trig). In the future, the WG will decide whether to include something simple (relevant to datasets) in the RDF 1.1 Semantics and the WG may publish some information about dataset semantics in WG NOTES.
15:39:28 <cygri> q+
15:39:34 <davidwood> ack cygri
15:39:38 <MacTed> +1
15:39:53 <pchampin> david: would the group be more comfortable with the 2nd proposal above?
15:41:02 <ivan> q+
15:41:04 <pchampin> cygri: this is a slippery slope, as Pat's proposal makes it very easy to derive a dataset entailment from Pat's named-entailement
15:41:18 <pchampin> ... and we would end up where we didn't want to be in the first place
15:41:37 <sandro> PROPOSED: This Working Group will not include in a Rec-Track document any semantics for RDF Datasets or for our Dataset Syntax (eg trig).
15:41:54 <pchampin> pat: the difference is between defining something and saying that people must use it
15:42:00 <ivan> q-
15:42:06 <gavinc> people happen to ignore the semantics already when they need to, and fall back to it when they want to. No one seems to care today 
15:42:18 <AZ> possible proposal: this Working Group will not provide a Formal Semantics for RDF Datasets or for our Dataset Syntax (eg trig). In the future (that is, in a different WG), a formal semantics may be defined, or simply constraints on what entailment might be.
15:42:37 <sandro> +1
15:42:46 <pfps> +1
15:42:48 <AZ> I understand
15:43:17 <davidwood> PROPOSED: This Working Group will not provide a Formal Semantics for RDF Datasets or for our Dataset Syntax (eg trig). In the future, the WG will decide whether to include something simple (relevant to datasets) in the RDF 1.1 Semantics and the WG may publish some information about dataset semantics in WG NOTES.
15:43:26 <PatH> +1
15:43:41 <PatH> whoops, ignore that
15:43:44 <davidwood> PROPOSED: This Working Group will not provide a Formal Semantics for RDF Datasets or for our Dataset Syntax (eg trig). The WG may publish some information about dataset semantics in WG NOTES.
15:43:49 <AZ> +1
15:43:50 <sandro> +1
15:43:52 <pfps> +1
15:43:55 <ivan> +1
15:43:55 <MacTed> +1
15:43:56 <Arnaud> +1
15:43:56 <cygri> +1
15:43:58 <gkellogg> +1
15:43:58 <SteveH> +1
15:43:58 <pchampin> +1
15:44:06 <davidwood> +1
15:44:06 <cgreer> +1
15:44:24 <yvesr> +1
15:44:24 <cygri> (i'd like to see the note published too)
15:44:24 <MacTed> +1 Ivan
15:44:29 <gavinc> +1
15:44:44 <davidwood> RESOLVED: This Working Group will not provide a Formal Semantics for RDF Datasets or for our Dataset Syntax (eg trig). The WG may publish some information about dataset semantics in WG NOTES.
15:44:49 <ericP> party time!
15:44:54 <AZ> We have enough material to write a book about dataset semantics!
15:44:55 <sandro> victory!
15:44:57 <SteveH> tea and cake?
15:45:18 <yvesr> although i still think we need to really evaluate whether we want default graphs in trig
15:45:20 <pchampin> ivan: ok with the proposal, but I really would like the note to be published
15:45:31 <pchampin> ... we should really discuss it at the F2F
15:46:00 <pchampin> ... a note may list various conflicting approaches
15:46:24 <davidwood> MacTed suggested adding a ftf agendum regarding a dataset semantics Note.
15:46:34 <AZ> I'd be glad to contribute to such a note
15:46:44 <pchampin> sandro: we need to be careful that, even if the note is not normative, some people might use it as if it was
15:47:00 <sandro> +1 a descriptive NOTE (not a sort of "we think you should do this" kind of note.)
15:47:02 <davidwood> PROPOSED: Implementations that parse and store information from TriG documents MAY turn the TriG default graph into a named graph with a name chosen in an implementation-dependent way.
15:47:03 <pchampin> topic: trig syntax
15:47:13 <cygri> sandro, +1 to that
15:47:30 <davidwood> PROPOSED: We will produce a W3C Recommendation for a dataset syntax, similar to TriG and to SPARQL's named graph syntax.
15:48:23 <sandro> PROPOSED: We will produce a W3C Recommendation for a dataset syntax, similar to TriG and to SPARQL's named graph syntax.   This does not preclude another syntax, eg n-quads
15:48:25 <davidwood> PROPOSED: We will produce a W3C Recommendation for a dataset syntax, similar to TriG and to SPARQL's named graph syntax.  This does not preclude recommending a syntax like n-quads.
15:48:28 <gavinc> +1 http://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html 
15:48:32 <sandro> +1
15:48:34 <ivan> +1
15:48:34 <gkellogg> +1
15:48:35 <AndyS> The default graph in/out {} plays in here.
15:48:37 <AndyS> +1
15:48:37 <pfps> +1
15:48:38 <AZ> 1
15:48:40 <MacTed> +1
15:48:40 <cygri> +0.2
15:48:41 <cgreer> +1
15:48:42 <yvesr> +1
15:48:43 <pchampin> +1
15:48:44 <davidwood> +1
15:48:50 <SteveH> +1
15:48:55 <PatH> model for that note might be http://www.w3.org/TR/swbp-n-aryRelations/ 
15:49:07 <PatH> +1
15:49:08 <davidwood> RESOLVED: We will produce a W3C Recommendation for a dataset syntax, similar to TriG and to SPARQL's named graph syntax.  This does not preclude recommending a syntax like n-quads.
15:49:25 <ivan> +1 to Pat
15:49:25 <davidwood> PROPOSED: We'll request a media-type for this syntax which is different from the media-type for Turtle.  (That is, we will not consider this language to supplant Turtle and take over the name, becoming the new "Turtle", as was once proposed.)
15:49:35 <sandro> +1
15:49:37 <yvesr> +1
15:49:41 <ivan> +1
15:49:42 <cgreer> +1
15:49:42 <cygri> +1
15:49:43 <pchampin> +1
15:49:44 <davidwood> +1
15:49:45 <MacTed> +1
15:49:47 <gavinc> +1
15:49:47 <AndyS> +1
15:49:48 <AZ> +1
15:49:51 <gkellogg> +1
15:49:58 <Arnaud> 0
15:50:02 <davidwood> RESOLVED: We'll request a media-type for this syntax which is different from the media-type for Turtle.  (That is, we will not consider this language to supplant Turtle and take over the name, becoming the new "Turtle", as was once proposed.)
15:50:02 <PatH> +0
15:50:14 <davidwood> PROPOSED: Our dataset syntax will allow for the expression of empty named graphs, whatever their semantics might be (to be decided). The syntax is an empty curly-braces expression, as in "<g> { }".
15:50:23 <PatH> +1
15:50:25 <gavinc> -0.999...
15:50:38 <davidwood> PROPOSED: Our dataset syntax will allow for the expression of empty named graphs, whatever their semantics might be. The syntax is an empty curly-braces expression, as in "<g> { }".
15:50:43 <yvesr> -0.5
15:51:03 <cygri> +1
15:51:22 <pchampin> q+
15:51:30 <sandro> agreed gavinc 
15:51:35 <cygri> q+
15:51:55 <PatH> union
15:51:56 <pchampin> q-
15:51:56 <AndyS> gavinc's example -- <g> {} \n <g> {:s :p :o}
15:52:09 <PatH> Q
15:52:18 <PatH> q+
15:52:30 <davidwood> ack pchampin
15:52:37 <davidwood> ack cygri
15:52:44 <pchampin> gavin: the mention about the syntax may be confusing
15:53:04 <pchampin> ... as further expressions may make the graph non-empty after all
15:53:15 <pchampin> ... (see example above quoted by AndyS)
15:53:22 <Zakim> -cgreer
15:53:46 <sandro> cygri: The abstract syntax of datasets makes a distinction between an empty named graph and the named graph not existing in the dataset.    Given that, and no semantics, we need that distinction in the syntax.
15:53:47 <Zakim> +cgreer
15:54:04 <sandro> +1 cygri 
15:54:50 <pfps> +0.5 cygri
15:54:54 <davidwood> ack PatH
15:55:18 <AZ> the semantics is not defined at all
15:55:27 <pchampin> pat: the semantics of empty graphs is well defined; they are trivially true
15:55:40 <AZ> (of empty *named* graph i mean)
15:56:00 <pchampin> q+
15:56:21 <pchampin> ... there is another issue; what happens when someone empties a graph by deleting everything  inside it?
15:56:33 <gavinc> +q to say that I'm not saying that there are no empty graphs, just that empty graphs in a UNION syntax get funky
15:56:35 <pchampin> ... (something about the impossible dataset, I didn't quite get it)
15:56:39 <davidwood> ack pchampin
15:56:57 <PatH> sound very broken
15:57:00 <Zakim> +LeeF
15:57:07 <sandro> q+ to reply to Gavin saying sure, but we can handle it.
15:57:12 <ericP> SPARQL Update has DROP
15:57:16 <PatH> we cant hear...
15:57:25 <ericP> ack
15:57:27 <ericP> ack me
15:57:35 <AndyS> SPARQL has CLEAR
15:57:38 <MacTed> CLEAR empties the named graph; DROP drops the name
15:57:50 <pchampin> pchampin: is there a mechanism in SPARQL-update to remove a graph by name
15:57:56 <pchampin> ... rather than removing all the triples in a named graph
15:58:05 <pchampin> ... which is different if empty graphs are allowed?
15:58:06 <davidwood> q?
15:58:12 <pchampin> ack me
15:58:17 <MacTed> analogous to SQL    DELETE * FROM table     and    DROP table
15:58:18 <davidwood> ack gavinc
15:58:18 <Zakim> gavinc, you wanted to say that I'm not saying that there are no empty graphs, just that empty graphs in a UNION syntax get funky
15:58:22 <LeeF> SPARQL Update attempts to support quadstores by allowing stores to silently "remove" a graph that has no triples
15:58:47 <LeeF> That is, SPARQL Update tries to let empty graphs be basically the same as non-existent graphs 
15:59:06 <cygri> q+
15:59:09 <ericP> no one else can state it later *in the same document*
15:59:27 <cygri> q-
15:59:30 <pchampin> gavin: with the union semantics, it is strange to express empty graphs in Trig
15:59:31 <davidwood> ack sandro
15:59:31 <Zakim> sandro, you wanted to reply to Gavin saying sure, but we can handle it.
15:59:42 <pchampin> ivan, pat, sandro: why???
15:59:43 <sandro> PROPOSED: Our dataset syntax will allow for the expression of empty named graphs, whatever their semantics might be.
15:59:52 <cygri> +1
15:59:58 <ivan> +1
15:59:59 <PatH> +1
16:00:02 <gavinc> +0
16:00:02 <sandro> +1
16:00:03 <AZ> +1
16:00:03 <AndyS> +1
16:00:06 <pchampin> +0
16:00:09 <MacTed> +1
16:00:10 <ericP> +1
16:00:12 <SteveH> o AndyS �'s point, that sounds sigular
16:00:15 <yvesr> +0
16:00:19 <SteveH> and n-quads can't represent that easily
16:00:30 <yvesr> SteveH, that was my main concern
16:00:30 <davidwood> RESOLVED: Our dataset syntax will allow for the expression of empty named graphs, whatever their semantics might be.
16:00:33 <SteveH> out TriG-like?
16:00:38 <SteveH> *our
16:00:40 <yvesr> SteveH, introducing some assymetry between n-quads and trig
16:00:41 <ericP> [[ <n> { <s> <p> <o>, <o2> } ]] - [[ <n> { <s> <p> <o2> } ]] == [[ <n> { <s> <p> <o> } ]] ? seems probably pretty uncontroversial
16:00:45 <ericP> [[ <n> { <s> <p> <o> } ]] - [[ <n> { <s> <p> <o> } ]] == [[ <n> {  } ]] ? or maybe [[  ]] ?
16:01:08 <sandro> this was about the trig-like syntax, yes.
16:01:54 <davidwood> PROPOSED: We will call our recommended dataset syntax "TriG", but informally and in the media type, "trig".
16:02:06 <davidwood> PROPOSED: We will call a recommended dataset syntax "TriG", but informally and in the media type, "trig".
16:02:20 <sandro> davidwood: Yes, the empty named graph resolution was about trig, not n-quads (if we do that).
16:02:51 <ericP> wHAT'S wRONG wITH iT?
16:03:23 <gavinc> +0 no idea why it'
16:03:29 <gavinc> s called TriG in the first
16:03:33 <ivan> -0.1
16:03:45 <Arnaud> -0.5
16:03:57 <MacTed> +0
16:04:01 <PatH> +1
16:04:02 <pfps> =0 I have no opinion
16:04:11 <gkellogg> +1
16:04:14 <cygri> -0.1
16:04:18 <AndyS> The point about Turtle-related name is a good one - informally TriG will be used regardless but Turtle-NG is interesting.
16:04:19 <sandro> arnaud: I'm concerned by the proliferation of formats.
16:04:32 <sandro> +1
16:04:33 <LeeF> +1
16:04:34 <yvesr> +0 (depends how close that serialisation ends up being to existing TriG)
16:04:37 <davidwood> +1
16:04:44 <AZ> +1.1
16:04:49 <AZ> oops +0.1
16:04:58 <SteveH> -0.1
16:05:00 <pchampin> arnaud: I understand why TriG should be distinct from Turtle,
16:05:14 <pchampin> ... but I'm affraid the proliferation of formats would hinder adoption
16:05:16 <ivan> q+
16:05:18 <sandro> sandro: TriG is like tar or zip; nothing like turtle....
#16:05:23 <davidwood> RESOLVED: We will call a recommended dataset syntax "TriG", but informally and in the media type, "trig".
16:05:30 <davidwood> ack ivan
16:05:38 <pchampin> ... I understand the technical arguments, but from a marketting point of view it sounds bad
16:05:51 <SteveH> I don't think we have a resolution
16:05:59 <pchampin> ivan: I agree with Arnaud
16:07:05 <Guus> +1 to Arnaud's point; prefer not to resolve
16:07:09 <gavinc> Turtle Dataset Extension? 
16:07:10 <sandro> votes other than -1 and +1 don't actually count, formally.
16:07:32 <SteveH> sandro, how do we abstain then? that's what I wanted to do
16:07:39 <Guus> wrt media type, i mean
16:07:50 <sandro> well, sure, you abstained -- that means not counting, right?
16:07:59 <MacTed> . o O ( Turtle++?  Turtle#?  Turtle-bis? )
16:08:17 <sandro> q?
16:08:26 <Guus> Turtle4G
16:08:27 <pchampin> ivan: we have two very similar language, and instead of stressing out the similarity, we introduce a completely different name
16:08:31 <SteveH> sandro, I didn't believe so, but I'm confident y��ur knowledge of process is better than mi�ne
16:08:46 <MacTed> Turtle-for-Datasets (TFD)?
16:09:06 <sandro> q+
16:09:41 <SteveH> q+
16:09:57 <ivan> q+
16:10:05 <sandro> "Turtle Package Language"
16:10:08 <davidwood> ack sandro
16:10:10 <sandro> TurtlePack
16:10:15 <LeeF> I support TriG being separate from Turtle, but it even sounds like a complicated story to me nonetheless :-)
16:10:26 <pchampin> david: I think that it is not that complicated, provided that we give the appropriate guidance to people in using those different languages
16:10:33 <gavinc> ....
16:10:34 <MacTed> TurtleShell!
16:10:51 <ericP> turtle's hell?
16:10:54 <ericP> come use the RDF Semantic Web Linked Data RDFS OWL SPARQL RIF RDF/XML Turtle TRIG NQuads JSON-LD stack
16:10:55 <gavinc> Turtle{}
16:10:55 <davidwood> q?
16:11:00 <davidwood> ack SteveH
16:11:35 <pchampin> steveh: I abstain because I wait to see what it looks like to decide how it should be named
16:11:38 <PatH> if it quacks like a turtle..? Hmmm.
16:11:53 <pchampin> ... if it looks like TriG, let's call it TriG
16:12:24 <ivan> q-
16:12:25 <pchampin> sandro: true, we can defer that decision
16:12:55 <davidwood> NOT RESOLVED: We will call a recommended dataset syntax "TriG", but informally and in the media type, "trig".
16:13:02 <pchampin> ivan: I think the last proposal was not resolved
16:13:09 <PatH> 3 minutes to go.
16:13:14 <MacTed> Zakim, unmute me
16:13:14 <Zakim> MacTed should no longer be muted
16:13:22 <LeeF> Is there another proposal that has more support?
16:13:30 <gavinc> Nameless Graph Syntax
16:13:43 <cygri> AndyS, that's taken: http://code.google.com/p/oort/wiki/Grit
16:13:47 <davidwood> PROPOSED: We will call a recommended dataset syntax "TriG", but informally and in the media type, "trig".
16:13:49 <sandro> +1
16:13:50 <MacTed> +1
16:13:51 <gkellogg> +1
16:13:51 <cgreer> +1
16:13:51 <ericP> +1
16:13:52 <LeeF> +1
16:13:52 <gavinc> 0
16:13:54 <MacTed> Zakim, mute me
16:13:54 <Zakim> MacTed should now be muted
16:13:54 <SteveH> 0
16:13:56 <PatH> +1
16:13:59 <ivan> -0.9999...
16:14:06 <davidwood> +1
16:14:07 <pchampin> +0
16:14:12 <AZ> +0.1
16:14:12 <yvesr> +0 (for the same reason as above!)
16:14:13 <cygri> -0.2
16:14:18 <Guus> -0.5
16:14:20 <Arnaud> -0.5
16:14:34 <ivan> this is not a formal objection, just making my opinion clear...
16:14:36 <gavinc> in fact it is = to -1 
16:14:43 <PatH> passed with a scrape from ivans fender
16:15:13 <davidwood> RESOLVED: We will call a recommended dataset syntax "TriG", but informally and in the media type, "trig".
16:15:13 <sandro> people aren'y happy, but they can live with it.
16:15:18 <ivan> s/-0.9999.../-0.9/
16:15:20 <Guus> right
16:15:28 <davidwood> PROPOSED: In our dataset syntax, a "=" MUST NOT appear between the name and the graph.
16:15:33 <ivan> +1
16:15:33 <sandro> +1
16:15:42 <SteveH> +1
16:15:45 <gavinc> +1
16:15:47 <gkellogg> +1
16:15:48 <cygri> +1
16:15:49 <davidwood> +1
16:15:50 <Guus> +1
16:15:51 <AndyS> +1
16:15:52 <ericP> +1
16:15:52 <MacTed> +1
16:15:53 <pchampin> +1
16:15:54 <AZ> +1
16:15:58 <LeeF> +1
16:15:59 <yvesr> +0.5
16:16:02 <PatH> +1
16:16:05 <cygri> where "our dataset syntax" is the TriG-like one
16:16:12 <pchampin> sandro: "=" was optional in the original TriG syntax, but
16:16:14 <gavinc> yay, draft now matches resolution ;)
16:16:14 <sandro> yes, indeed.
16:16:17 <cgreer> +1
16:16:17 <pchampin> ... people rarely used it, and
16:16:22 <pchampin> ... it does not match the semantics
16:16:23 <davidwood> RESOLVED: In our TriG dataset syntax, a "=" MUST NOT appear between the name and the graph.
16:16:36 <davidwood> PROPOSED: In our TriG dataset syntax, the case-insensitive keyword "graph" MUST NOT appear before the name, in a name-graph pair.
16:16:43 <ivan> q+
16:16:46 <Arnaud> +1
16:16:52 <yvesr> that's a concern with calling the syntax TriG though, as it's not anymore compatible with old-TriG
16:16:53 <gkellogg> +1
16:17:07 <cygri> pchampin, i'm just being pedantic
16:17:12 <SteveH> yvesr, yes, but in practice no-one used the =
16:17:13 <PatH> +1
16:17:13 <MacTed> +1
16:17:21 <sandro> +1
16:17:22 <davidwood> ack ivan
16:17:49 <pchampin> ivan: the problem with the GRAPH keyword,
16:18:05 <pchampin> ... but we are creating a strange incompatibility with Turtle
16:18:28 <SteveH> q+
16:18:29 <gavinc> yes well allowing BASE and PREFIX was a mistake, but no one else seems to think so :P
16:18:41 <pchampin> ... where we have accepted SPARQL-like constructs
16:18:41 <SteveH> allowing BOTH was a mistake
16:18:44 <davidwood> ack SteveH
16:19:04 <gavinc> +1 SteveH
16:19:23 <pchampin> steveh: I thought this was a feature "at-risk"
16:19:38 <pchampin> ... so it might not be kept anyway
16:19:57 <PatH> +1 to "at risk"
16:19:59 <pchampin> ivan: ok, so I would put it "at-risk" in our TriG as well
16:20:08 <davidwood> PROPOSED: In our TriG dataset syntax, the case-insensitive keyword "graph" MUST NOT appear before the name, in a name-graph pair.  This is to be an "at risk" feature.
16:20:10 <pchampin> ... depending on the outcome of Turtle
16:20:14 <ivan> +1
16:20:19 <gavinc> +1
16:20:23 <SteveH> +1
16:20:23 <LeeF> +1
16:20:25 <yvesr> +1
16:20:26 <sandro> +1      
16:20:26 <gkellogg> +1
16:20:31 <MacTed> +1 as revised
16:20:31 <davidwood> +1
16:20:34 <AZ> +1
16:20:34 <cygri> ±0
16:20:43 <AndyS> +1 (make the at risk related to TTL)
16:20:43 <sandro> (the AT RISK be between "MUST NOT" and "MAY")
16:21:01 <Arnaud> +1
16:21:05 <cgreer> +1
16:21:09 <pchampin> +0
16:21:21 <davidwood> RESOLVED: In our TriG dataset syntax, the case-insensitive keyword "graph" MUST NOT appear before the name, in a name-graph pair.  This is to be an "at risk" feature.
16:21:57 <Zakim> -ivan
16:21:57 <PatH> ✈
16:21:58 <Zakim> -gkellogg
16:21:59 <Zakim> -cygri
16:22:00 <Zakim> -ScottB
16:22:00 <Zakim> -yvesr
16:22:01 <gavinc> trailing . is in http://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html#sec-graph-statements
16:22:01 <Zakim> -davidwood
16:22:01 <Zakim> -SteveH
16:22:02 <sandro> sandro: we're just left with "default graph" stuff.
16:22:02 <Zakim> - +1.408.996.aaaa
16:22:04 <Zakim> -MacTed
16:22:06 <Zakim> -AZ
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000514