... 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

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

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.