11:09:22 RRSAgent has joined #rdf-wg 11:09:22 logging to http://www.w3.org/2011/10/12-rdf-wg-irc 11:09:24 Zakim has joined #rdf-wg 11:09:26 zakim, this is rdf2wg 11:09:26 ok, sandro; that matches SW_RDFWG(F2F)6:00AM 11:10:04 zakim, who is on the phone? 11:10:04 On the phone I see AZ, +1.617.324.aaaa, ??P2 11:10:11 sandro, we could hear you fairly well over h323 11:10:23 (a bit better than on zakim) 11:10:37 RRSAgent, pointer? 11:10:37 See http://www.w3.org/2011/10/12-rdf-wg-irc#T11-10-37 11:10:50 we see one very still, very blocky image. 11:10:54 Well, we'll have some Zakim-only people, so I think we have to use zakim for audio. 11:11:01 new call, 384kbos 11:12:23 Scott_Bauer has joined #rdf-wg 11:12:26 cygri has joined #rdf-wg 11:12:34 RRSAgent, pointer? 11:12:34 See http://www.w3.org/2011/10/12-rdf-wg-irc#T11-12-34 11:12:39 Meeting: RDF F2F2 11:13:30 mischa has offered to scribe the first session 11:14:04 AlexHall has joined #rdf-wg 11:16:08 +Peter_Patel-Schneider 11:17:38 davidwood has joined #rdf-wg 11:17:39 pfps has joined #rdf-wg 11:17:47 Zakim: scribe mischat 11:17:47 RRSAgent: scribe mischat 11:17:47 I'm logging. I don't understand 'scribe mischat ', mischat. Try /msg RRSAgent help 11:18:13 scribenick: mischat 11:18:20 sandro: that was me calling you 11:18:42 we're trying to sip into zakim, so that we can hear you better 11:19:32 scribe: Mischa Tuffield 11:20:41 mischat_ has joined #rdf-wg 11:21:24 -??P2 11:21:29 iand has joined #rdf-wg 11:21:50 +??P2 11:22:35 [david, I'm on the Web client of IRC, so not receiving anything alse] 11:23:51 Does someone in London have a Skype ID? 11:23:59 If so, I can try calling you. 11:24:03 gavinc has joined #rdf-wg 11:24:09 Guus, ack 11:25:18 We can actually hear you through the H channel - but it's unintelligible. 11:25:30 So please turn off the audio channel. 11:26:07 -??P2 11:26:15 zakim, who is on the call? 11:26:15 On the phone I see AZ, +1.617.324.aaaa, Peter_Patel-Schneider 11:26:24 +??P4 11:26:31 zakim, aaaa is MIT_Meeting_Room 11:26:31 +MIT_Meeting_Room; got it 11:26:38 AndyS, Ẕ̢̫̝̝͓͉̱̜̜̫ͭͬͧ̄̅͊̀̎̐ͬ͊͐̈̽ͩͪ̌͝͠a̡̾̔ͮ͋ͪ̀͌͑̿ͦ̃̊͗ͫ́̚͝͏͓̬̭̰̮̥̝̫̕ḵ̷̫̯̰̳̖͖͍̣̙ͯ̾̿͐͋͒̐ͪ͊͋̇̎̚͘͢͝ĭ͈̳̯̹̠̤̳̘ͤ̎͛ͮ͜͜͠ḿ͛̐̄͆̍̒̄̆ͩ̕͝͏̙̫̦̻̦ ̴̰̪̰͍̭̠̞̙̘͉̘͖͈̱̺̖̰̦̂ͥͥͤͦ̍ͥ͠t̴̛̳̲͓̰͕̣̂̄̂ͪ͊͗ͫ͊̇̃͗͆ͧ̃̎̇͌͗͜͡ẽ̵̔ͣ̎ͨͮͤ̃҉̡̡̛͍̪̩͇̲l̴̷̫̼̻̜̳̻͔̯͉͍̼̬̈ͧ͆͊͊ͥ͆͑ͬ̚͝e̎̏͆̓ͩͧ 11:27:28 I'm sure there is a FOAF tag for that 11:27:44 what about a language tag? 11:27:45 as well an inverse foaf property 11:28:19 Can you turn off the audio on your video? 11:29:34 Please, can you turn off the audio on your video 11:30:30 topic: introductions 11:30:43 is there a video stream available for remote participants? 11:30:54 David Wood, Gavin, Tim Lebo, Alex Hall, Sandro, Scott Bauer, Lee F 11:31:01 scribeL mischa 11:31:04 AZ, we tried but nothing yet. Will try again to fix it in next break. 11:31:07 scribe: mischa 11:31:37 zakim, who is talking? 11:31:40 Mischa, Pierre, Ian, Andy, Richard, NickH, Ivan, Steve, Danbri, Yves 11:31:43 scribenick: mischat 11:31:49 sandro, listening for 10 seconds I heard sound from the following: ??P4 (77%) 11:31:57 zakim, remind me of the telephone number please 11:31:57 I don't understand 'remind me of the telephone number', ww 11:32:05 zakim, who is on the call? 11:32:05 On the phone I see AZ, MIT_Meeting_Room, Peter_Patel-Schneider, ??P4 11:32:09 We're trying to sort the positioning out now 11:32:10 zakim, code? 11:32:10 the conference code is 733294 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), davidwood 11:32:12 Zakim, what is the code? 11:32:13 the conference code is 733294 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), sandro 11:32:35 LeeF has joined #rdf-wg 11:32:36 zakim, who is speaking? 11:32:47 zakim, ??P4 is BBC_Meeting_Room 11:32:47 +BBC_Meeting_Room; got it 11:32:49 +??P2 11:32:50 danbri, listening for 10 seconds I heard sound from the following: AZ (34%), ??P4 (64%) 11:32:56 Guus: is proposing we jump to the first item of the agenda 11:32:56 Zakim, ??P2 is ww 11:32:56 +ww; got it 11:33:12 it's hearing noise from AZ 11:33:27 AZ, can we mute you? you can unmute via bot here 11:33:30 can we mute AZ or is that just rude? 11:33:32 zakim, mute AZ 11:33:32 AZ should now be muted 11:33:36 Zakim, mute me 11:33:36 AZ was already muted, AZ 11:33:37 zakim, mute me 11:33:37 ww should now be muted 11:33:56 strange, my phone was muted already 11:34:02 Time for POTS! 11:34:58 -BBC_Meeting_Room 11:35:00 even post is voip these days :) 11:35:04 danbri spending most of this meeting being tied to his chair by power cables 11:35:19 +??P4 11:35:29 zakim, ??P4 is BBC_Meeting_Room 11:35:29 +BBC_Meeting_Room; got it 11:36:08 Guus: move to the first item of the agenda, the naming issue 11:36:23 http://www.w3.org/2011/rdf-wg/wiki/F2F2#Participants 11:36:32 it would be nice if the agenda had pointers to the relevant information. 11:36:33 zakim, BBC_Meeting_Room holds mischat, Guus, danbri, yvesr, pchampin, swh, ivan, cygri, iand, andys 11:36:33 +mischat, Guus, danbri, yvesr, pchampin, swh, ivan, cygri, iand, andys; got it 11:36:45 http://www.w3.org/2011/rdf-wg/wiki/F2F2#Agenda 11:36:54 sandro has changed the topic to: Oct 12 -- http://www.w3.org/2011/rdf-wg/wiki/F2F2#Agenda 11:36:59 zakim, BBC_Meeting_Room also holds NickH 11:36:59 +NickH; got it 11:37:01 Guus: first item to discuss and decide on teminology 11:37:17 Guus: based on sandro's g* teminology 11:37:26 Guus: gbox == graph container 11:37:35 Guus: gsnap == graph or graph set 11:37:45 Guus: gtext == graph serialisation 11:37:49 q+ 11:37:52 "graph set" is misleading because it sounds like a bunch of graphs 11:38:03 … so are these a good place to start? 11:38:15 sandro: doesn't remember us talking about a graph set 11:39:16 ivan: can we use the queue, as I am scribing from here 11:39:25 q+ to summarize MIT discussion 11:39:32 q+ to propose to drop g-text from the discussion, it doesn't seem to be necessary 11:39:32 sandro: didn't like the term graph-set, and i think the rest of the terms are far 11:39:52 sandro: we should use the g* terminology informally for the time being 11:40:01 +1 to Sandro 11:40:01 q+ 11:40:06 ack sandro 11:40:11 for the public working set we should use the Guus proposed graph terminology 11:40:19 ack davidwood 11:40:19 davidwood, you wanted to summarize MIT discussion 11:40:23 davidwood: had a private conversation with LeeF 11:40:27 sandro: Let's keep using g-* terms if they seem useful, but "graph set" is bad. 11:40:53 david: "graph" itself is too ambiguous. 11:40:55 davidwood: LeeF proposed it graph snapshot, the idea of using graph for gsnap could be an issue 11:40:59 as it is too ambitious 11:41:09 I can't find much on g-snap, except http://www.w3.org/Search/Mail/Public/search?type-index=public-rdf-wg&index-type=t&keywords=%22graph+set%22&search=Search 11:41:18 terminology summary proposal was at http://lists.w3.org/Archives/Public/public-rdf-wg/2011Jul/0092.html 11:41:34 sorry I meant - can't find much on graph set 11:41:40 Turtle needs to talk about graph seralizations 11:41:43 cygri: g-snap and g-box pop up a lot, but the g-text term doesn't pop up lots 11:41:47 There was an earlier proposal to drop g-text. +1 to cygri. 11:41:56 +1 cygri dropping "g-text" and just using "graph serialization" 11:41:56 so we might not need an official term for it 11:41:58 ack me 11:41:58 cygri, you wanted to propose to drop g-text from the discussion, it doesn't seem to be necessary 11:42:20 q? 11:42:28 If we need a term for Turtle, we can always create a term for g-text at that time. 11:42:31 ack guus 11:42:36 Guus: thinks that graph-set is poor, and gnap-snapshot is a bit geeky 11:42:41 "graph dump?" or has unpleasant associations? 11:42:43 q? 11:42:58 Is anyone keen on "graph set"? 11:43:21 +1 to ask whether anyone wants to change the term “RDF graph” from Concepts 11:43:22 +1 "graph set" sounds a lot like a set of graphs. 11:43:24 to me "graph set" also sounds like "a set of graphs" 11:43:28 gavinc, when I heard "graph set", I thought it meant a g-box, so i guess the intuitions are wrong. And it'll probably annoy mathematicians. 11:43:31 Guus: requirement for the naming is that they match concepts which new people coming into RDF must be easy to understand 11:43:38 q+ to ask whether anyone wants to change the term “RDF graph” from Concepts 11:43:40 "graph version"? 11:43:47 ack me 11:43:47 cygri, you wanted to ask whether anyone wants to change the term “RDF graph” from Concepts 11:43:48 I don't imagine that these are really terms that are going to need to be taught in beginners' tutorials, are they? 11:43:56 Guus: graph set is a bit geeky, and might lead people to think that it is a "collection of graphs" 11:43:57 tomayac has joined #rdf-wg 11:43:57 q+ to suggest Graph Image (like a picture of frozen snapshot, notion ... same as machine images, .iso etc) 11:44:10 why not "RDF graph" as in all Sem Web specs? 11:44:20 g+ 11:44:22 q+ 11:44:33 "graph" is totally ambiguous but "RDF graph" is well defined 11:44:56 cygri: notes that the term "RDF graph" matches are use of gsnap, would we have to renamed the term in the RDF Concepts document 11:44:59 ack danbri 11:44:59 danbri, you wanted to suggest Graph Image (like a picture of frozen snapshot, notion ... same as machine images, .iso etc) 11:45:02 Is it? Or is it equally ambiguous 11:45:12 danbri: suggest "RDF image" as a term for g-snap 11:45:20 ack me 11:45:20 "Image" is okay, but not as good as "snapshop", for me. 11:45:23 danbri: the term image, as in something which doesn't change 11:45:28 concur 11:45:36 (with Sandro) 11:45:38 i like davidwood's "graph version" 11:45:41 +1 to ivan 11:45:44 ivan: we should try to use the term "graph" consistently for the g-snap 11:45:49 graph version works for me 11:46:13 +1 to ivan 11:46:17 Guus: this would make the smallest change to the documents 11:46:18 i might try the 'image' metaphor in supporting materials. people mostly will just use 'graph' and be vague, whatever we decide. 11:46:19 strawpoll between "RDF Graph", "Graph Snapshot", and "Graph Version" ? 11:46:29 -1 to Ivan (sorry). We really need to be unambiguous. 11:47:01 Guus: by default we should use the RDF graph to mean the g-snap 11:47:02 q? 11:47:15 q? 11:47:18 ack ivan 11:47:39 q+ 11:47:44 zwu2 has joined #rdf-wg 11:47:57 Guus: graph serialisation and graph container, are we happy with this? 11:48:10 Guus: is all the discussion around g-snap then right? 11:48:32 cygri: davidwood are suggesting we change the term "graph" in the RDF concepts 11:48:34 ? 11:48:42 -1 to rename "RDF graph" 11:48:43 cygri: as per your "-1" early 11:49:08 cygri, yes. I propose that RDF Graph as defined in RDF Concepts be changed to "graph snapshot" or another term that we agree upon. 11:49:24 sandro: agrees that it would be hardwork to change the term in the concepts, but agrees that it would be beneficial to make it less ambiguous 11:49:36 Can we write the question in IRC? 11:49:42 Guus: keeping it is as, RDF graph for g-snap? 11:49:48 +1 11:50:02 +1 11:50:03 +1 11:50:04 +1 11:50:07 -1 11:50:10 -0 11:50:10 +1 11:50:13 =1 11:50:15 0 very conflicted 11:50:15 +1 11:50:17 Strawpoll -- g-snap ==> RDF graph 11:50:17 +1 11:50:18 +1 11:50:21 +1 11:50:25 +1 11:50:26 +1 11:50:31 +1 (fscking US keyboard) 11:50:33 +1 11:50:34 (and banish the use of "graph" alone, "graph" != "RDF graph") 11:50:36 +1 11:50:39 0 11:50:59 q+ 11:51:02 q+ 11:51:03 ack me 11:51:07 i guess it just needs clarification 11:51:13 q+ 11:51:14 q+ 11:51:25 davidwood: is surprised that we are choosing to keep the term as it, given the issues we faced early on in the WG 11:51:39 WE might know that, my -0 is that I'm not sure that anyone else will be clear about that. 11:51:48 +1 11:51:48 q- 11:51:52 q+ 11:51:57 zakim, unmute me 11:51:57 AZ should no longer be muted 11:52:12 +1 "RDF Graph" : as long as "Graph" is contrasted with the other terms (container, serialization), it clarifies what it is and is not. 11:52:13 -1 to david's sentiments - RDF graph is not confusing in itself, the issue was that there are other notions that did not have names, and they were bleeding into the only name that we had 11:52:16 q? 11:52:17 Guus: states that we learnt from the early discussions, and by tightening up the other definitions like g-text and g-box 11:52:19 q? 11:52:22 +1 to pfps 11:52:24 +1 to guus. we lacked a good term for g-box. once that's fixed, it'll be easier to be clear and unambiguous 11:52:36 Souri has joined #RDF-WG 11:52:36 Guus: we would be making the term "RDF Graph" less ambiguous 11:53:02 +1 to tlebo 11:53:04 q- 11:53:07 ack tlebo 11:53:10 ack pchampin 11:53:14 +1 tlebo 11:53:17 tlebo: by fixing terms for the other two terms, would make it term graph == g-snap 11:53:20 do all these definitions have identity conditions for the things they're naming? 11:53:23 q- 11:53:25 tlebo: If we have "Graph Container" and "Graph Serialization", then "Graph" becomes clearer, and renaming it would be a problem. 11:53:47 q? 11:53:49 Where "Graph" is "RDF Graph" yes? 11:53:53 The one thing we get out of the continued use of the term "graph" for a g-snap is that it can be considered a proper set. 11:53:56 ack swh 11:54:04 yes, where "Graph" becomes "RDF Graph" 11:54:09 pchampin: states that the official term for the g-snap should be Graph, and having the other two terms defined would make it less ambiguous 11:54:25 q+ 11:54:33 swh: said that the term graph hasn't really hurt anyone in practice 11:54:39 davidwood: suggests that we move on 11:54:50 g-snaps should be "RDF Graph" not "Graph" 11:55:06 PROPOSED: In our documents, we'll use the terms "RDF Graph" for g-snap, "Graph Container" for g-box, and "Graph Serialization" for g-text 11:55:16 Guus: resolution In our documents we will use the term RDF Graph for notion of the g-snap 11:55:36 +1 11:55:41 0 11:55:41 Guus: any objections to the proposal 11:55:41 +1 11:55:42 +1 11:55:43 +1 11:55:44 +1 11:55:45 +1 11:55:46 (with a little hesitation, but... it's okay.) 11:55:46 +1 11:55:48 Guus: any +1's 11:55:48 -0. still not sure about graph container 11:55:48 +1 11:55:52 +1 11:55:55 0+ 11:55:56 +1 11:56:01 Guus: thanks for the first resolution 11:56:01 -0 graph container vs. dataset seems a bit confused 11:56:01 me :) 11:56:05 RESOLVED: In our documents, we'll use the terms "RDF Graph" for g-snap, "Graph Container" for g-box, and "Graph Serialization" for g-text 11:56:34 q- 11:56:35 Guus: we just won on numbers of hours chatting about graphs :) 11:56:56 Guus: topic : named graphs discussion 11:57:28 Guus: we have 3 major contributions here Richard, Tim, and who … 11:57:42 http://www.w3.org/2011/prov/wiki/Using_named_graphs_to_model_Accounts 11:57:45 Guus: tlebo as you are the guest, please go ahead and describe your pro posable 11:57:53 s/who/Sandro/ 11:58:16 tlebo: ^^ developing a method for describing different views of the same events 11:58:35 tlebo: OWL ontology, which uses RDF to make assertions about the world 11:58:53 tlebo: we will have to manage chunks of this knowledge using named graphs 11:58:55 topic: Named Graphs (?) 11:59:28 davidwood: the provenance DM has just been put into FPWD 12:00:05 davidwood: what is the relationship between this document and the owl provenance DM? 12:00:50 tlebo: we are using named graphs to manipulate statements from different sources 12:01:07 q? 12:01:35 tlebo: the end result, using the provenance OWL ontology, the contents of a named graph would be triples asserted by different agents 12:01:59 Guus: found the statement at the beginning defining what a named graph is 12:02:20 Is Tim's (Jeremy's) "named graph" a g-snap? 12:02:25 "sandro's document"? 12:02:27 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Options 12:02:32 I feel compelled to mention the statement identifier approach again so we can actually talk *directly* about "triples asserted by different agents" instead of being forced to use named graphs as an indirection 12:02:35 Guus: you state in one of these assertions is that the named-graph is global 12:02:37 q+ 12:03:00 Similarly, is the "global RDF graph" a g-box? 12:03:01 Guus: these named graphs are more like files, more like g-boxs 12:03:25 tlebo: could adopt of new terminology after this meeting 12:03:52 sandro: tlebo's document doesn't assume global naming, it assumes local naming 12:03:52 q+ re "Named graphs let you specify a subset of the "global" RDF graph."; that has a kind of mystical feel to it. The global graph would be all triples imaginable? Full of contradictions etc? 12:04:12 q- 12:04:49 Guus: doesn't understand the statement "Named graphs let you specify a subset of the "global" RDF graph." 12:05:14 q? 12:05:15 sandro: in our current world, you need a sparql-endpoint URI and a … (sorry sandro ?) 12:05:24 ack danbri 12:05:24 danbri, you wanted to discuss "Named graphs let you specify a subset of the "global" RDF graph."; that has a kind of mystical feel to it. The global graph would be all triples 12:05:28 ... imaginable? Full of contradictions etc? 12:05:35 danbri: "Named graphs let you specify a subset of the "global" RDF graph." <-- dan was thinking about the Web not about SPARQL 12:05:56 danbri: thinks that is more sensible in a SPARQL context not the RDF one 12:06:12 sandro: in our current world, you need a sparql-endpoint URI and the tag IRI of the graph within the endpoints dataset. So you need 2 URIs to name a graph. This is unforunate, and not in keeping with web architecture. 12:06:37 davidwood: it sounds like a top-down approach 12:06:46 q+ 12:06:46 q? 12:06:53 tlebo: we are talking about a "RDF consumer" based approach 12:08:22 +1 12:08:27 danbri: we have presented RDF to people, we have been criticised for trying to make a giant database for the web, we need to consider named graphs as something which would enable decentralisation 12:08:27 blah blah pluralism blah 12:08:37 Named graphs are about decentrializations and pluralism 12:08:40 +1 to the "blah blah" part 12:08:43 ack Souri 12:08:47 basically we got a lot of pushback for seeming to naively believe all RDF could be merged into a single flat unified triple db 12:08:50 danbri: asked please do not go down a path of massive giant graph 12:09:30 Souri: in the triples-store world, you need to definite the sparql endpoint URL and a graph name. 12:09:35 Named Graphs is our comeback, where we say 'nah, we are more pragmatic, ... named graphs are different datasets offering their own perspective into the Web, without need or pressure for global consistency with every other piece of rdf' 12:09:37 q? 12:09:56 mischat: davidwood 12:10:12 (ie. there isn't (sorry timbl) a giant Global graph as such (except for the happy smaller subset of RDF graphs that happen at some given point to be true); rather we have a graph-of-graphs) 12:10:35 that's tlebo 12:10:51 Guus: any more questions for tim? 12:11:06 zakim, BBC_Meeting_Room also has Thomas 12:11:06 +Thomas; got it 12:11:16 Guus: please sandro go through your email 12:11:28 tlebo has joined #rdf-wg 12:11:35 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Options 12:12:00 sandro: has been thinking about how to make progress on graphs, finds the subject overwhelming 12:12:02 AndyS has joined #rdf-wg 12:12:19 sandro: at a high-level the above document should capture our goals ^^ 12:12:30 sandro: http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Options 12:12:57 sandro: 3 difference things we need to do 1. come up with syntaxes for conveying datasets 12:13:17 sandro: trig being the big contender, and nquads is there too 12:13:34 … the 2nd area, is about vocabularies about conveying datasets 12:13:48 Graph Seralizations Strawman: http://www.w3.org/2011/rdf-wg/wiki/Graphs-In-Turtle 12:14:18 sandro: 1 is datatypes for documents, 2 plain or RDF strings, 3 reification vocabulary 12:14:37 ivan: doesn't understand the difference between 2.1 and 2.2 12:14:49 q+ to ask how Sandro's proposal relates to the way graphs are named in some currently implemented RDF databases. 12:15:01 2.1 is "

"^^rdf:turtle 12:15:07 :G1 owl:sameAs ":s :p :o"^^rdf:Turtle 12:15:22 :G1 rdf:turtleSerialization ":s :p :o" 12:15:23 sandro: in both cases string in RDF, in 2.1 the datatype is like turtle, so that the value space is an RDF graph, in 2.2 it is a string, so we some predicate which states that the value is a graph 12:15:37 do we have datatype URI conventions for Mime types yet? eg. foo:application/rdf+xml ? 12:15:57 sandro: the three ways above do not require any change to syntax 12:16:22 Guus: are these an alternative for things in 1 12:17:01 danbri, don't I wish 12:17:06 sandro: we could do both, but not necessary 12:17:06 Guus: we could have a stawpoll on this later 12:17:06 sandro: too early for a resolution 12:17:09 (has anyone stress-tested RDF stores with multi-gigabyte string literals?) 12:17:35 danbari, yes, they all broke horrigly with even megabyte size literals 12:17:36 sandro: 3rd area, if you get sent data outputted from a decision in 1 or 2, what do you do with the data upon receipt 12:17:37 danbri: i believe so, but clearly not a strong enough convention or best practice that i can't find the vocabulary again with google without trying very hard 12:17:44 [ignore SPARQL "FROM" and "FROM NAMED"] +1 and sort out later 12:18:13 sandro: i.e. what are you supposed to do when you get a file with a default graph for example 12:18:36 q+ to ask what the association between URIs and resources in plain RDF is in Sandro's taxonomy 12:18:46 re 2.1. the latest I found from TAG is this http://www.w3.org/2001/tag/2002/01-uriMediaType-9 ...debate still between new URI scheme vs http://-prefixed names 12:18:46 danbri, the internals of several RDF stores that I am aware of (Mulgara, Sesame, OWLIM) would NOT handle multi-gigabyte strings at all well. That is contrary to their design presumptions. 12:18:55 sandro: another big question, are we naming graphs on a global scale 12:20:08 davidwood: is curious how this relates this to RDF databases, i.e. we don't seem to acknowledge that there is no mention of common use cases in RDF stores 12:20:37 sandro: this that all triplestore are agnostic to the semantics of the named graphs 12:21:14 sandro: so if you blindly interact with datasets across the web, then this isn't an issue 12:21:32 HTTP GET / 12:21:46 davidwood: thinks that the SPARQL service verb is going this way, where there is automated consumption of datasets on the web 12:21:58 HTTP GET http://example/dataset?query=... 12:21:59 I'm not sure that SPARQL stores are semantics-neutral 12:22:01 q+ 12:22:06 davidwood: doesn't think that the semantics and the implementations are that far apart 12:22:10 q? 12:22:13 ack me 12:22:13 cygri, you wanted to ask what the association between URIs and resources in plain RDF is in Sandro's taxonomy 12:22:14 ack davidwood 12:22:17 at the very least it effects the optimisers 12:22:17 davidwood, you wanted to ask how Sandro's proposal relates to the way graphs are named in some currently implemented RDF databases. 12:23:08 cygri: trying to make sense of your options, and what the options mean and what effects. If you look at RDF 1.0 and we look at the association between URIs and resource 12:23:21 cygri: where does this association fall in your taxonomy of options 12:23:53 sandro: the URI is naming a person globally, this should be a 3.1 thing, from sandro's breakdown 12:24:49 cygri: is talking about semantics, and how this fits into the semantic document. As is stands the RDF semantics is rather quiet about these 12:25:04 cygri: topics of global naming 12:25:22 q? 12:25:23 sandro: points to the discussion on the mailing list between richard, pat, and peter 12:26:12 It wasn't that Pat and I disagree about how the RDF Semantics work. Instead, we disagree on how this is to be described. I tend to divorce the formal semantics from any surround - I think that Pat tries to push more of this surround into the description of the semantics. 12:26:33 [is part of the "Semantics" here not really "Pragmatics"?] 12:26:59 sandro: would like to be able to tell developers how to write code which can talk to other peoples datasets 12:27:05 gavinc: agrees with sandro and thinks that sparql avoids talking about semantics. different datasets will all be implemented differently, and hence their semantics are different 12:27:08 1st choice is surely do we make things people current do "wrong" or do we have something that covers several ways of using URI-association-graph: (central design or community emergent behaviour?) A lot of NGs is local only - who cares? - not published. 12:27:15 gavinc: is not sure we need perfect semantics 12:27:32 gavinc: doesn't think this lack of semantics has hurt anybody 12:27:57 q? 12:28:05 sandro: what gavinc is talking about was captured in 3.3.2 12:28:06 ack gavinc 12:28:13 sandro: http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Options#Out-of-Band_Selection 12:28:24 q+ 12:28:29 q? 12:28:30 q+ to make distinction between what an implementation does and what a user of an implementation does 12:28:45 davidwood: there is a social construct which is disjoint from the syntax. this is a social convention :) 12:29:02 q? 12:29:02 +1 to davidwood 12:29:08 q? 12:29:18 azk zwu 12:29:23 ack zwu 12:29:23 Guus: any more questions for sandro 12:29:27 davidwood: don't want to stifle innovation by specifying it too tightly 12:29:38 zwu2: what are the confusions which you seeing ? 12:30:27 q+ 12:30:41 sandro: thinks there will be a future where you are talking to many datasets, and it will become important when each implementation will have different ways of storing their graphs in their triple stores 12:30:50 ack LeeF 12:30:50 LeeF, you wanted to make distinction between what an implementation does and what a user of an implementation does 12:31:00 As long as we have rdf2:GraphContainer, don't we have a basis for others to describe the associations among them. e.g., :GN a rdf2:GraphContainer; my:unionOf :G1, :G2 ? 12:31:19 LeeF: /me can't understand u 12:31:49 +1 to thinking about conformance 12:32:40 LeeF: is thinking about conformance, is not clear, is it is the RDF dataset isn't conformant. Should the triplestore have an conformant API. 12:32:42 I think it's the person using the API.... 12:32:56 tlebo - yes I think so but it can become a burden. c.f. Assembler vs high level code (reification has this problem, more so) 12:33:21 q? 12:33:52 LeeF: are there test cases which test the semantics when talking about conforming datasets 12:34:25 ack cygri 12:35:11 cygri: you want system not to have to guess what kind of graph layout we're finding in some store 12:35:18 q+ 12:35:22 q+ to mention interoperability as the place semantics meet implementations 12:35:26 cygri: wanted to comment on when sandro mentioned a developer which needs to talk to lots of RDF datasets, and what to expect. 12:35:37 +1 - how RDF gets associated with a graph URI is different from what that association means 12:35:44 Seems like an issue for VoID 12:35:51 +1 to documenting dataset patterns that people have used (like those Gavin mentioned). 12:35:55 cygri: thinks this is about patterns when using/interacting with datasets. This shouldn't touch on the semantics of RDF 12:36:01 q+ 12:36:04 +1 to cygri 12:36:06 ack Guus 12:36:08 +1 for documenting patterns over proscribing one notion 12:36:19 +1 to cygri 12:36:22 cygri: thinks that we should be documenting patterns, is the way to go, and doesn't think that making everyone have one view of the world, won't work 12:36:29 +1 12:36:39 AndyS: that's why we have compilers, which have something solid to build upon. just need good tools. 12:36:46 I don't think it's a "can't" define semantics I'd say shouldn't ;) 12:37:00 Guus: is asking cygri if he would prefer to document pragmatics instead of defining semantics 12:37:22 Guus: would like to provide guides and not limit the practice 12:37:30 +1 guus 12:37:40 ww - that was the reif argument ... didn't work out (not sure why) Ditto RDF lists. 12:37:57 example dataset organization: source vs. content based graph organization https://github.com/timrdf/csv2rdf4lod-automation/wiki/Named-graph-organization 12:37:59 guus: saying we want the widest semantics that we can agree on 12:38:01 ack davidwood 12:38:01 davidwood, you wanted to mention interoperability as the place semantics meet implementations 12:38:10 +1 to guus 12:38:25 cygri is it fair to read your approach (re pattern description) as a variant on "All problems in computer science can be solved by another level of indirection"? 12:38:35 (cygri leaves room) 12:39:04 ==> (the room leaves cygri) 12:39:26 q? 12:39:28 davidwood: we are getting worked about defining everything, has an issue that everyone interprets the semantics differently then we will have interoperability issues 12:39:30 ack pchampin 12:39:59 pchampin: has a question for cygri 12:40:34 q+ to suggest this is a classic layer-of-indirection solution to avoid committee design 12:40:36 pchampin: thinks that semantics is exactly what we need to define interoperability. And is not comfortable with cygri's distinction 12:40:42 q? 12:40:54 q+ 12:40:57 q? 12:41:08 q- 12:41:32 q+ to ask silly question about using fragment identifiers to resolve "local vs. global" graph names. 12:41:35 "Patterns of Use" vs "Semantics". 12:41:36 pchampin: is not comfortable your distinction between patterns of use and semantics 12:42:09 any volunteers for taking over scribing? 12:42:39 scribe AndyS 12:42:40 scribenick: AndyS 12:42:47 cygri: semantics are complicated 12:43:23 +1 break at top of hour 12:43:34 { } is "the global one", #http://www.w3.org/People/Berners-Lee/card# { } is "the local one" .... (or _http://www.w3.org/People/Berners-Lee/card_ ) 12:43:37 q? 12:43:42 ack danbri 12:43:42 danbri, you wanted to suggest this is a classic layer-of-indirection solution to avoid committee design 12:43:44 ack danbri 12:44:30 danbri: practical vs semantics - maybe more have an indirection point - standards avoid impossible agreement decision 12:44:37 danbri: cygri is trying to put in an extensibility hook, since we can't agree how to limit things now. 12:44:48 q+ 12:44:56 ... makes practical in WG time. 12:44:56 q+ 12:45:32 guus: if we could agree, shoudl we formalize local or global naming at least? 12:45:47 cygri: yes if not too much pain 12:45:50 q? 12:45:58 ack tlebo 12:45:58 tlebo, you wanted to ask silly question about using fragment identifiers to resolve "local vs. global" graph names. 12:46:16 tlebo: use cases for both local and global 12:46:41 ... different syntaxes e.g. URI frag 12:46:42 local = mint your own (UUID-style) URI 12:46:58 local = lie about being global 12:47:06 ack sandro 12:47:06 maybe a) there are some practices that are just *wrong* eg. naming a graph with a URI of a human b) some that are OK but no consensus around details, eg. URI is URI of a random Web page c) some that are clearer but have practical annoyances (eg. using uuid: or urn:) ... so describing patterns approach is consistent with saying which amongst a-b-c-etc we prefer 12:47:11 guus: issue is if/should we stds that? 12:48:21 @danbri, I'd say that {} would be *wrong*, while #http://purl.org/twc/id/person/TimLebo# would be perfectly valid in anyone's dataset. 12:48:54 sandro: tag example: local g-snap : predicate + graph literal could RDF assertions to show association. 12:49:20 q+ 12:49:40 ack me 12:49:40 ack AndyS 12:49:53 q+ to comment on the practical difficulty of defining semantics for this 12:50:21 ack pchampin 12:51:07 andy: use case for immutable graph container 12:51:21 pchampin: Q: options wiki page: pred+graph literal means defer (sandro: log:semantics) but it says something about the resource not the URI 12:51:32 q+ 12:52:04 sandro: yes but names a web resource and representation is the graph (indirection again?) 12:52:23 we shouldn't get into the semantics of N3 predicates - it's just the extension mechanism that is relevant imho 12:52:23 aren't graphs in sparql named with resources rather than URIs-as-strings? 12:52:38 q- 12:53:02 pchampin: one concern on difficult to define semantics : we seem to talk about the IRI itself 12:53:03 iand, no, the spec says "pair of IRI and graph" – nothing about resources 12:53:15 ack cygri 12:53:15 cygri, you wanted to comment on the practical difficulty of defining semantics for this 12:53:18 q? 12:54:46 cygri: meta: area of semantics we seem to get into vague (richard waves hands) but push back is on detail. We shoudl discuss concrete semantics proposal with detaiils. 12:55:22 .... and we are not there yet. One example (sandro) and we don't get further. 12:55:45 guus: Test case (triples) examples is a way to do that 12:55:50 +1 cygri we have gap between requirements on the semantics and the specification of the semantics 12:55:50 cygri: yes 12:56:05 q? 12:56:18 davidwood1 has joined #rdf-wg 12:56:29 restart at 15 after...? 12:56:34 yes 12:56:58 guus: break now for 15 mins - then review situation. We will discuss options from Sandros's list 12:57:08 we can hear you well, yes. 12:57:09 zakim, who is here? 12:57:09 On the phone I see AZ, MIT_Meeting_Room, Peter_Patel-Schneider, ww (muted), BBC_Meeting_Room 12:57:11 MIT_Meeting_Room has davidwood, gavinc, zwu2, tlebo, AlexHall, sandro, Souri, Scott_Bauer, LeeF 12:57:14 BBC_Meeting_Room has mischat, Guus, danbri, yvesr, pchampin, swh, ivan, cygri, iand, andys, NickH, Thomas 12:57:17 On IRC I see davidwood1, AndyS, tlebo, Souri, zwu2, tomayac, LeeF, gavinc, iand, mischat, pfps, davidwood, AlexHall, cygri, Scott_Bauer, Zakim, RRSAgent, AZ, danbri, Guus, swh, 12:57:19 ... ivan, pchampin, ww, yvesr, manu, NickH, trackbot, manu1, sandro 12:57:33 Yeah -- play with video maybe, but keep the audio as-is. 12:57:42 nah --- ignore Zakim. 12:57:49 update the wiki page! 12:58:12 yep, 9:15 ET 13:06:42 -AZ 13:07:41 +AZ 13:12:57 MacTed has joined #rdf-wg 13:18:02 iand has joined #rdf-wg 13:18:37 reconvene? 13:20:45 sandro, do you get video from us 13:20:46 can people in MIT able to see us ? davidwood gavinc or anyone ? 13:20:47 ? 13:21:48 no 13:21:48 for values of see that are not very good 13:21:58 still not? 13:22:08 you still have audio 13:22:12 no 13:22:28 we see you well 13:22:37 tlebo has joined #rdf-wg 13:22:38 and video is gone 13:22:41 looks like xmeeting is sending very little traffic to you 13:23:19 LeeF has joined #rdf-wg 13:24:24 reconvene 13:24:50 we see you!!!!! 13:25:02 yay!!! 13:25:08 !!!!! 13:25:22 we heard that laugh 13:25:30 no, we do, now. 13:26:07 guus: sandro, we stopped the options discussion: continue? 13:26:59 Pat and I can't help to formalize something that we don't understand 13:27:02 sandro: agree with cygri of disconnect between detail/semantics and approaches discussions 13:27:37 davidwood: suggest start with 5 UCs (the A priority) 13:27:49 the 5 use cases 13:27:52 1.1 (A PRIORITY) Slicing datasets according to multiple dimensions 13:27:54 1.3 (A PRIORITY) Graph Changes Over Time 13:27:55 1.5 (A PRIORITY) Exchanging the contents of RDF stores 13:27:57 4.9 (A PRIORITY) Trust Web Opinions 13:27:58 5.2 (A PRIORITY) OWL's “Ontology Documents” 13:28:00 sandro: understand how to implement 13:28:55 guus: meta: we have to assess if we have clarity to std semantic notion. We need an established practice not new work. 13:29:08 sandro: test cases => formal semantics 13:29:46 guus: one possibility is we conclude can't get there and instead intro graph names not more 13:30:12 yvesr to talk about graph slicing 13:30:41 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Slicing_datasets_according_to_multiple_dimensions 13:30:41 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Slicing_datasets_according_to_multiple_dimensions 13:30:41 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Slicing_datasets_according_to_multiple_dimensions 13:30:46 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Slicing_datasets_according_to_multiple_dimensions 13:30:49 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Slicing_datasets_according_to_multiple_dimensions 13:31:08 BBC want central RDF store then need to have slices (per product) 13:31:26 yvres: product is e.g. /programmes, /music 13:31:51 ... need to slice by resources as well for fast update: 13:31:57 q+ to ask whether that's like "redundant stored data" or "views" 13:32:01 ... found stores good at whole graph ops 13:32:22 +infinity to updating small bits using graph replacement rather then UPDATE 13:32:47 +1 to Gavin 13:32:51 ... e.g. Eastenders (a TV program(me)) chnage => change whole graph 13:33:14 this sounds similar to 1.7.1 editing datasets at the granulaity of the graph 13:33:35 ack me 13:33:35 cygri, you wanted to ask whether that's like "redundant stored data" or "views" 13:33:39 cygri: is a view computed on the fly or duplicated data? 13:34:00 yvres: duplicated 13:34:32 ... original UC was graphs in graphs because of overlaps of views 13:35:20 ... currently hierarchical: /programmes/Eastenders ==> fast operations 13:35:24 q? 13:35:40 q+ to ask about non-heirarchical subgraphs 13:36:16 cygri: in some store there is a union dft graph. Update in NG is seen in dft graph. Do you want same but more complicated? 13:36:22 ack davidwood 13:36:22 davidwood, you wanted to ask about non-heirarchical subgraphs 13:36:29 http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#prov-dm-overview 13:36:33 yvres: yes - we'd like that also access control 13:36:35 The wasComplementOf relationship is used to denote that two entities complement each other, in the sense that they each represent a partial, but mutually compatible characterization of the same thing. 13:37:44 davidwood: Let's talk about non-hierachical subgraph relationships. 13:38:00 q+ to ask yves another question about hierarchical 13:38:20 davidwood: if we had a looser notion of subgraph then we can do this (scribe??) 13:38:48 yvres: currently two graphs can overlap in triples 13:38:51 davidwood: subgraphs should have the freedom to overlap in terms of membership of their triples. 13:38:54 q- 13:39:08 guus: What mechanisms do we need? 13:39:21 +q to talk about implementations of this 13:39:21 ... name containers? 13:39:32 guus: it sounds like the crucial thing here is to name containers 13:40:09 mischat has joined #rdf-wg 13:40:11 yvesr: You can check triple-by-triple to see if two graphs overlap. 13:40:13 yvres: issues: (1) specification of strucures e.g. overlap Can check currently. bNodes are "a bit more complicated" 13:40:43 ... (2) NG impl issue: good if split of triples : overlaps are duplication 13:40:45 q+ 13:40:46 this seems like a SPARQL issue from my POV 13:40:46 yvesr: There can be lots of duplication of information 13:40:49 ack gavinc 13:40:49 gavinc, you wanted to talk about implementations of this 13:40:54 q+ to think out loud about “nested datasets” 13:41:50 gavin: Speaking to one implementation. One method we used to define the relationship between super and sub graphs. SPARQL CONSTRUCT queries to create bounded descriptions, stored as separate named graph, later. 13:41:53 gavinc: example - supergraphs defined by CONSTRUCT of subgraphs - stored as separate graph 13:42:01 I'm not sure how relevant this is, but in Anzo we pretty much just define "RDF Datasets" as first class citizens - they're defined in the system and are collections of named graphs as per the SPARQL notion of a dataset 13:42:05 2 datasets can share a graph 13:42:15 and we use the datasets as a way to handle higher-level manipulations 13:42:15 gavin: None of these were based on semantic relationship -- the Construct queries defined the supergraphs. 13:42:38 q? 13:42:42 sandro: not really sub/super graph, but ... other graphs. 13:42:56 gavin: No new triples created -- it was just re-grouping triples. 13:43:02 gavin: no new triples : CONSTRUCT is a method of grouping triples 13:43:14 gavin: a fairly common pattern. 13:43:16 Mulgara has a feature to create a named graph that is a view consisting of boolean set operations on -- surely other stores have this feature as well? 13:43:22 ack invan 13:43:32 ack ivan 13:43:35 [set operations on other named graphs] 13:44:07 q+ to answer 13:44:14 ivan: what can we do for you? 13:44:15 q- 13:44:41 q+ to say that "web semantics for datasets" would allow other folks to mix & match yvesr's data. 13:44:43 yrves: not complete clear - loosely defined maybe better 13:44:57 ivan: is there a stronger semantics that (in a few years) woudl be better 13:45:12 yvres: yes - eg. graph of things editors can change 13:45:25 q? 13:45:30 ... whether this is big spec csost. 13:45:54 guus: Is this data mgt , rather than RDF change? 13:45:54 q+ re ISSUE-33 13:46:01 issue-33? 13:46:01 ISSUE-33 -- Do we provide a way to refer to sub-graphs and/or individual triples? -- open 13:46:01 http://www.w3.org/2011/rdf-wg/track/issues/33 13:46:16 ... (exploring) 13:46:19 q? 13:46:20 ack sandro 13:46:20 sandro, you wanted to answer and to say that "web semantics for datasets" would allow other folks to mix & match yvesr's data. 13:46:56 sandro: yvres says "graph" for "graph container" 13:47:24 trackbot: BEER on yvesr 13:47:24 Sorry, cygri, I don't understand 'trackbot: BEER on yvesr'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 13:48:01 ... and my web semantic proposal woudl let mix and match deref via stable URL 13:48:21 ... build eco system 13:48:21 7 13:48:22 q? 13:48:25 q? 13:48:30 ack davidwood 13:48:30 davidwood, you wanted to discuss ISSUE-33 13:48:41 q? 13:48:45 ISSUE-33? 13:48:45 ISSUE-33 -- Do we provide a way to refer to sub-graphs and/or individual triples? -- open 13:48:45 http://www.w3.org/2011/rdf-wg/track/issues/33 13:48:54 davidwood: for BBC UC can we close issue-33? 13:49:54 ... contention is remove parent-child but let graphs exists and overlap we do not need subgraph specially 13:50:19 q+ to suggest => :G rdf:includes :g1, :g2, :g3 . (flexible grouping in RDF, not having to go to SPARQL) 13:50:22 q? 13:50:34 q+ to say that one doesn't preclude the other 13:50:39 q+ 13:50:39 ... looser defn of subgaph and graph membership can overlap then we benefit from no fixed hierarchy 13:50:45 ... and we can close issue-33 13:50:58 q+ to say I agree we can let g-snaps overlap as they may, assuming we don't care about bnodes 13:51:06 pfps has joined #rdf-wg 13:51:22 davidwood: proposal "no" to issue-33 by defn g* so subgraphs are possible. 13:51:32 ack souri 13:51:32 Souri, you wanted to suggest => :G rdf:includes :g1, :g2, :g3 . (flexible grouping in RDF, not having to go to SPARQL) 13:51:32 ack Souri 13:51:59 +1 to souri 13:52:15 souri: As Gavin said, with grouping of graphs, not parent/child, ... I want to take these graphs together, and name the collection this,... not in SPARQL, just in RDF. 13:52:42 ... in the triplestore, G container is always the merge of the contents of G1, G2, etc. 13:52:44 souri, this is in RDF not SPARQL, then query graph G then snapshots G 13:52:47 +PatH 13:53:00 ack me 13:53:00 cygri, you wanted to say that one doesn't preclude the other 13:53:01 ack cygri 13:54:24 cygri, two things: good things from arb overlap graphs but may still want to have "subgraph" explicit concpt 13:54:49 ack ivan 13:54:50 Is @davidwood saying that #33's subgraph notion can be accounted for by placing RDF Graphs (g-snap) into Graph Containers (g-box)? If you want to "hierarchicalize" RDF Graphs, you'd do it by placing them into hierarchical Graph Containers. 13:54:52 ... and UC wikidata talks about triples not graphs (was that right?) 13:55:09 Souri's formulation allows the creation of parent-child subgraphs as a degenerate case. 13:55:20 Therefore, cyri's concern is handled. 13:55:35 wikidata is a very good use-case for the same sort of issues: you always have two dimensions on which you want to slice your dataset: per item in the wiki, and per authorisation rights 13:55:35 q- 13:55:39 ivan: subset can be useful so don't see overlap covers subgraph need as is very useful. 13:56:02 PatHayes has joined #rdf-wg 13:56:05 guus: what have we leant? 13:56:30 sandro: we need bnodes sharing - subgraphs 13:56:43 guus: gSnap senseof graph 13:56:53 tlebo, if you name a graph in a g-box and fill it with triples from a g-snap, then sure. 13:57:01 sandro, bnode scope is orthogonal to subgraphs 13:57:07 bnode sharing clearly DOESN'T need subgraphs as bnodes can be amusingly shared in sparql datasets today ;) 13:57:30 q+ to ask a very basic question 13:57:47 yvres: not sure operators useful - want to mark a triple as in bags. 13:58:07 ... graph as container 13:58:18 bnode sharing would be facilitated by naming g-snaps 13:58:21 it is, cygri? I thought bnodes were scoped to graphs..... 13:58:45 sandro - by syntax 13:58:53 sandro, no. they are not scoped at all. bnode *identifiers* are scoped by document 13:59:03 +g to explain at least one "implementation" of bnode "sharing" between many graphs 13:59:08 can't you achieve this with a SPARQL insert thing 13:59:11 +1 Guus 13:59:13 guus: do a lookup as to where it is? 13:59:25 q? 13:59:27 +q to explain at least one "implementation" of bnode "sharing" between many graphs 13:59:33 iand: name sets of triples? 13:59:36 unfortunately at present RDF dos not scope bnodes at all, and sparql takes advantage of this. 13:59:48 q? 13:59:52 +1000 PatHayes 13:59:56 named set of triples == named g-snap 14:00:02 sorry, cygri -- yes, but I thought in Named Graphs bnodes were not allowed to be shared. 14:00:31 sandro, the carroll et al paper might say that. sparql doesn't. 14:00:40 iand: if use name, what triples is it? 14:00:52 q? 14:00:55 q+ 14:00:55 the carroll et all paper didn't say that... at least not by my reading 14:01:03 ack pchampin 14:01:03 pchampin, you wanted to ask a very basic question 14:01:06 and it seems PatHayes at well 14:01:06 no, the carroll +al paper does not address this bnode issue. 14:01:16 gavinc, you might be right. i should re-read it 14:01:45 and given et all included PatHayes I'm going to agree with him 14:01:50 pchampin: do we have an accepted way to talk about graph containers? 14:02:03 pchampin: or RDF graphs (aka g-snap) 14:02:06 guus: we have consensus for this. 14:02:18 q? 14:02:19 +1 everyone seems to agree we need a way to name graph containers 14:02:36 s/ et all / et al / 14:02:45 do any use cases require naming of graphs (g-snaps) 14:02:58 i share iand's question 14:02:58 ack gavinc 14:02:58 gavinc, you wanted to explain at least one "implementation" of bnode "sharing" between many graphs 14:03:04 path: must not confuse container and snap 14:03:13 q/ 14:03:15 q? 14:03:31 PatHayes, you're missing the look of complete "Who Me???" on my face. I don't think THAT'S what we're disagreeing about. 14:03:56 ok, sandro, sorry if ive been misreading you. 14:03:57 Propose to RESOLVE "we need a way to name graph containers" 14:04:13 gavinc: bnodes not scoped anywhere and impls use this. skolemization round tripping possible. 14:04:24 ... may not be a good way. 14:04:51 sandro: trig, nq syntax. 14:04:57 maybe we should state the consensus that, at the minimum, graph containers should have a naming mechanism 14:05:00 +1 to davidwood suggestion 14:05:01 gavinc: variations 14:05:19 q? 14:05:20 path: I agree 14:05:24 ... as a resolution 14:05:33 gavin: We clearly need *some* standardization to allow people to transmit datasets where there are blank nodes shared between graphs. 14:05:47 davidwood: name gboxes ... propose resolution 14:06:59 having names for both snapshots and containers would be horribly confusing 14:07:36 eh, we already do and it's not that bad 14:07:44 and the names are the same ;) 14:07:49 :) 14:07:51 yvesr, we are already in practice in this confusion. 14:08:04 q+ (aside) to confirm (hopefully) that graph names cannot be bNodes (and must necessarily be IRIs) 14:08:24 ack (aside) 14:08:24 (aside), you wanted to confirm (hopefully) that graph names cannot be bNodes (and must necessarily be IRIs) 14:08:34 guus: unclear "named graph" 14:08:34 cygri: no - named graph snap 14:08:34 ... it's the formal def 14:08:41 cygri: collection of named snapshots 14:08:45 Doesn't RDF already support naming everything we can image? :-) 14:08:53 s/image/imagine/ 14:08:56 souri, yes. bnode is not a name. But a bnode can refer to anything that can be named. 14:09:00 queue= 14:09:03 Souri, the named graph paper at least was happily clear that it was IRI not Resource (eg, no blank nodes) 14:09:04 zakim, who is here? 14:09:04 On the phone I see MIT_Meeting_Room, Peter_Patel-Schneider, ww (muted), BBC_Meeting_Room, AZ, PatH 14:09:06 MIT_Meeting_Room has davidwood, gavinc, zwu2, tlebo, AlexHall, sandro, Souri, Scott_Bauer, LeeF 14:09:09 BBC_Meeting_Room has mischat, Guus, danbri, yvesr, pchampin, swh, ivan, cygri, iand, andys, NickH, Thomas 14:09:11 q- 14:09:12 On IRC I see PatHayes, pfps, mischat, LeeF, tlebo, iand, MacTed, davidwood, AndyS, Souri, zwu2, tomayac, gavinc, AlexHall, cygri, Scott_Bauer, Zakim, RRSAgent, AZ, danbri, Guus, 14:09:17 ... swh, ivan, pchampin, yvesr, manu, NickH, trackbot, manu1, sandro 14:09:19 q? 14:09:20 q+ 14:09:24 zakim, MIT_Meeting_Room also has Eric 14:09:24 +Eric; got it 14:10:00 scribe pchampin 14:10:02 q- 14:10:41 does the bot need : prefix? 14:10:42 scribenick: pchampin 14:11:05 pat: what I understood: we have IRIs refering to graph containers, and IRIs refering to graphs (snapshots) 14:11:27 ... is that IRI going to appear in any RDF triple? and refer to the graph in this way? 14:11:56 guus: that would make life easier 14:12:22 q+ 14:12:40 PatHayes: that would make life possible 14:12:51 pat: to talk about a container changing over time, you need a programing language, which RDF is not 14:13:43 cygri: SPARQL is in last call; it already uses this notion of containers of graph; it is not a programming language 14:14:05 ... it is based on an abstract syntax: datasets 14:14:11 (SPARQL update -- graph store) 14:14:28 ... it does not have to become a part of RDF semantics 14:14:49 (where is g-box, g-snap, g-text defined?) 14:15:15 tlebo: http://www.w3.org/2011/rdf-wg/wiki/Graph_Terminology 14:15:15 http://www.w3.org/2011/rdf-wg/wiki/GraphConceptTerminology 14:15:25 pat: I'm not suggesting that we should have this way of talking about boxes 14:16:06 ... if we have to incorporate notions of time dependency in the semantics, this will be a major change 14:16:18 aside -- putting time and change pragmatics into semantics, seems like trying to teach flatlanders (per http://en.wikipedia.org/wiki/Flatland ) about the mythical 3rd dimension 14:16:28 by 'programming language' I mean only that it presumes an underlying notion of state 14:16:39 cygri: I agree that I would not like to make this kind of change in RDF semantics 14:16:59 q? 14:17:05 q? 14:17:06 ack 14:17:07 thanks, @iand 14:17:09 ack cygri 14:17:16 q+ 14:17:24 ack sandro 14:17:54 ericP has joined #rdf-wg 14:18:31 sandro: we can probably leave time out of the semantics 14:18:41 keep in mind, time is only one dimension over which the contents of a named g-box can change 14:18:46 time is far from the only variable 14:18:51 pat: that is, if we keep *dereferencing* out of the semantics too 14:19:04 +1 to swh 14:19:40 q? 14:19:44 ww has joined #rdf-wg 14:19:51 +1 to sandro 14:20:11 andy: there is a difference btw using dereferencing the LOD way, and recording it in the RDF semantics 14:20:38 So, maybe there can be some consensus around talking about dereferencing, but not in the RDF Semantics. 14:20:55 guus: still trying to draw lessons from the BBC usecase 14:21:18 ... we need to put triples in different containers 14:21:31 pat: I agree dereferencing involves time, but time is hard, so I think we should leave dereferencing outside of the RDF Semantics. 14:21:36 ivan: and let the content of those containers overlap 14:21:51 q? 14:22:24 cygri: the usecase requires shared bnodes between graphs (and containers) 14:22:26 cygri: This use case involves bnodes being shared between Graph Containers. 14:22:37 does it require bnode sharing? can't the graphs just entail each other? 14:22:54 Requires in reality shared blank nodes BETWEEN datasets, which ummm, impossible. New reality quickly becomes the use case tends to mean you can't/shouldn't use bnodes 14:23:02 AndyS has joined #rdf-wg 14:23:14 not require bnode sharing, but allow it. 14:23:17 steve: you could also say: if you are going to use this use case, then you *can't* use bnodes 14:23:24 yves: unfortunately, we do use bnodes 14:23:31 .well-known/genid is the answer. :-] 14:23:43 +1 to sandro :) 14:23:50 +sigh to sandro 14:23:57 couldn't gsnap: { _:s1 } capture gbox: { _:s2 } ? 14:24:01 q+ 14:24:14 q- 14:24:19 sandro, :) 14:24:22 sometimes you know its the same bnode -- additional information e.g. subgraph 14:24:31 q? 14:24:40 www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC 14:24:45 BBC_meeting_room is out of coffee :-( 14:24:50 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC 14:24:59 cygri, you can have some of ours. We have lots left. 14:25:25 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_OWL.27s_.E2.80.9COntology_Documents.E2.80.9D 14:25:37 guus: let's switch to another usecase 14:25:41 damn all your coffees, i havnt even had a shower yet. 14:25:43 5.2 5.2 (A PRIORITY) OWL's “Ontology Documents” 14:25:47 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_OWL.27s_.E2.80.9COntology_Documents.E2.80.9D 14:25:50 gavin: 5.2 OWL ontology documents 14:25:52 PatHayes too much information 14:25:59 ;- 14:26:30 ... the general convention: you name the graph container with the ontology URI 14:28:05 ... the OWL ontology for Dublin Core exists on the web and you can deference it 14:28:33 {hard to scribe explaination} 14:28:46 gavin: The OWL ontology for Dublin Core exists on the web, and you can reference it. However, there are other ontologies with that name. There might be a DL ontology for dublin core. 14:28:51 gavin: different ontologies, different URIs, but SOMETIMES I NEED TO GIVE THEM THE SAME NAME -- so I can switch which representation of the ontology I'm using. 14:28:55 gavin: Almost every ontology editor and OWL reasoner does it. 14:29:00 but why do you want to say this common uri is a name? 14:29:14 david: it's a nasty hack, but it's a good idea 14:29:26 q+ 14:29:51 danbri: every now and then, I receive a mail suggesting to have the FOAF ontology conform with OWL-DL or other standard 14:29:57 q+ 14:30:01 owl:Ontology rdfs:subClassOf rdf:Graph? 14:30:04 q- 14:30:14 ... it would be good if, with content negociation, different versions could be served 14:30:25 danbri: With FOAF, I always emails saying I should use DL, and they email me an OWL file. 14:30:27 gavin, it make me think of something I made a while ago: http://liris.cnrs.fr/~azimmerm/yoda 14:30:30 ivan: every OWL ontology, DL or not-DL, seen with RDF glasses, is a graph 14:30:32 q+ to say there seems to be confusion between a namespace URI and an ontology URI 14:30:38 ivan: Every ontology, DL or not, is an RDF graph. 14:30:41 s/ont/OWL ont/ 14:30:44 ... if you change the ontology, it is a different graph 14:30:52 q+ to answer ivan 14:31:10 i agree with danbri content negotiation is what is missing here, and mime-types for the various OWL variants 14:31:28 guus: gavin, what is the requirement here? 14:31:33 When you refer to an ontology by URI, you are referring to a g-box. When you reason over it, you are reasoning over a g-snap. 14:31:38 q+ 14:31:43 gavin: the problem is how owl:imports interacts with named graphs 14:32:02 ... depending how you implement it, different weird things happen 14:32:07 q+ 14:32:19 is this an RDF issue? 14:32:33 "owl:" means it's OWL's problem :) 14:32:38 ... e.g. people use owl:imports inside SPARQL, what does that mean exactly? 14:33:15 http://www.w3.org/TR/owl2-syntax/#Imports 14:33:30 mischat, yes it is an RDF issue for the graph TF because of this statement in the UC: "An Ontology Document has an IRI, but it is left open-ended what that IRI represents (graph in a graph store? file on a file system? web resource?) Can the document IRI and the graph IRI that stores the ontology be the same?" 14:33:42 peter: care has been taken in OWL2 with owl:import: this is a pragmatic issue, not a semantic issue (?) 14:33:50 "From a physical point of view, an ontology contains a set of IRIs, shown in Figure 1 as the directlyImportsDocuments association; these IRIs identify the ontology documents of the directly imported ontologies as specified in Section 3.2. The logical directly imports relation between ontologies, shown in Figure 1 as the directlyImports association, is obtained by accessing the directly imported ontology documents and converting them into OWL 2 ontologies. The l 14:33:52 It is the same dual use of the name of the graph that we are wrestling with here. 14:34:43 AndyS has joined #rdf-wg 14:34:43 guus: for me, this use case is out of our scope, because owl:import has only operational semantics 14:34:45 davidwood: i understand that it is on the UC document, it looks like something for a primer about linked data and sparql stores 14:34:46 q? 14:34:52 q? 14:35:08 q? 14:35:19 gavin: The requirement is how owl:imports intereact with Named Graphs. If you treat owl:import as derefencing, you get different results from using it as the dataset tag. 14:36:02 mischat, yes, it will probably end up that way once we figure out how we name graphs. 14:36:09 PatHayes: It seems to me, part of the idea behind "Named Graphs", was the act of attaching a URI was a special thing to do. Just because an IRI retrieves a graph doesnt mean it's the 'name' of the graph. Could be several retreive it, but only one of those is its name. 14:36:22 pat: in the named graph paper, several URIs can resolve to a graph, but only one is officially naming it 14:36:44 ack iand 14:36:44 PatHayes: It's okay to have an IRI that retreives different graphs at different times, as long as it's not the "name" of the graph 14:36:44 iand, you wanted to say there seems to be confusion between a namespace URI and an ontology URI 14:36:49 ... you can have several other URIs doing weird thing for practical reasons 14:37:07 -1 PatHayes -- I think it's core the Web Architecture that "identify" and "name" are the same thing. 14:37:29 ack me 14:37:31 q? 14:37:32 sandro, that HAS to be wrong. 14:37:46 iand: coming back to the dublin core example, you can have many variants of the ontology, but they share the same ontology URI 14:37:56 gavin: Ontology URI is the name of ontology, the base URI, where it's published, etc.... 14:37:59 q- 14:38:28 q+ to talk about "identify"-vs-"name" 14:38:32 actually I said dublin core has one namespace URI but could have multiple ontologies with different variants of OWL, each with their own URI 14:38:50 +1 iand 14:38:56 pchampin: had an answer for ivan, agree's with danbri 14:38:57 (agreed iand) 14:39:11 q+ for identify/name when that gets to be a topic. 14:39:21 pchampin: the ontology is more abstract than the graph 14:39:31 ivan: every OWL is an RDF graph 14:39:49 ivan: conceptually every OWL can be mapped to a graph 14:40:03 iand, of course the "namespace" doesn't really exist in RDF 14:40:03 ack me 14:40:03 pchampin, you wanted to answer ivan 14:40:21 ack cygr 14:40:29 From AWWW: http://www.w3.org/TR/webarch/#pr-use-uris 14:40:30 ack cygri 14:40:30 cygri: the OWL specs says how you can turn any ontology onto a graph 14:40:37 "To benefit from and increase the value of the World Wide Web, agents should provide URIs as identifiers for resources." 14:40:48 ... also an ontology has an identifier (URI) 14:40:48 re ontologies and graphs -- 'turn into', 'map to', 'is just a', ... hearing lots of phrases, 'translates into a', ... 14:40:57 Note that equates a URI and an identifier. 14:41:14 ... wouldn't it be great if OWL3 said "here is how an OWL ontology is mapped into a graph, here is how it is mapped into a named graph, here is..." 14:41:29 Sounds like short-circuit of naming: name of concept/abstraction != name of graph that encodes (one way) the ontology 14:41:34 ivan: that's the job of the OWL3 WG 14:41:50 ivan, so in FOAF we have from the ns URI both RDF/XML conneged with lots of triples, and text/html conneg defaulted, with a few triples via RDFa; --- is this one Ontology in your sense, or two? 14:41:51 +1 AndyS 14:41:59 cygri: we can make things easier for the OWL3 WG to do that 14:42:01 Also, http://www.w3.org/TR/webarch/#id-resources: "By design a URI identifies one resource" 14:42:08 davidwood, what is your point? All that is about identification, not naming. 14:42:14 Provenance-WG is alll about describing conversion processes and their results. 14:42:37 q? 14:42:58 PatHayes, my point is that we don't name anything on the Web other than with a URI. I must agree with Sandro that Web names are Web identifiers are Web URIs. 14:43:19 Perhaps we are using the term "name" differently? 14:43:31 davidwood, yes... however that one resource might have many descriptions 14:43:41 AlexHall: Lots of copies of some ontology can exist on the web. 14:43:51 alex: we are ok to have conflicting representation of the same ontology, with the same URI 14:43:54 Ah, your "names" are descriptions? Why not call them descriptions? 14:44:06 david, in spite of what sandro says, the RDF specs and the named graph paper both disagree with y'all. 14:44:06 My "names" are handles. 14:44:07 ... conflict usually resolved by the application 14:44:14 q? 14:44:18 davidwood: the tag have been talking about how "URIs define one resource" recently in the context of fragment ids in RDFa http://www.w3.org/mid/4E8F7DE2.5000908@digitalbazaar.com 14:45:19 ivan: two issues: you say that the same ontology graph will be present in different systems, meaning that dereferencing the URI of the ontology will return a copy 14:45:24 and people seem to be happy that a frag URIs can identify different things on the web … based on the agent. which is slightly to danbri's point re: mime-types and conneg 14:45:29 ivan: "the same ontology graph will be present in many different systems" -- that's true, and means the name of the ontology, when dereferenced, it gives you a "core copy" of it....? But when you said "these representations can be different/conflicting with each other", I have a problem with that. 14:45:30 mischat, interesting (and brave!) 14:45:49 +1 agreed, different ontologies with the same name -- that's a bug. 14:45:51 ... but saying that those copies may be conflicting, it is a bug (a useful bug, but a bug) 14:46:04 PatHayes, can you point me to a section in the RDF docs that makes your point clear? 14:46:29 different ontologies with same name is not a bug. it's a difference in opinion. 14:46:41 +1 14:46:44 ivan , why is the name considered "core"? I suggest that is a mistake. The name is attached by some kind of baptism. 14:46:46 mischat, using rat URIs to distinguish relies upon client-side modification, by definition 14:46:51 s/rat/tag/ 14:46:53 guus: is it the work of this WG to solve this? 14:47:01 sandro, gavin, david: YES 14:47:06 swh: frag? 14:47:14 cygri, can you phrase that equally-ish 'it's a single ontology that people are saying different things about'? (might not even be a different opinion, just a different choice of assertions) 14:47:14 ww has joined #rdf-wg 14:47:16 sandro: there's nothing OWL-specific here; it comes up in any case of RDF. 14:47:20 mischat, danbri: don't think you should conneg ontologies that define things differently - conneg variants are supposed to be basically interchangeable 14:47:25 guus: suggest we have a separate document about RDF authorities 14:47:30 q? 14:47:34 "The Role of Derefencing in RDF" -- a new RDF WG Note. 14:47:38 mischat, fragment URIs, I was replying to your point :) 14:47:38 ? 14:47:43 yeah i see 14:47:48 ivan: it means that the dereferencing model does not work 14:47:58 AndyS1 has joined #rdf-wg 14:48:06 iand, can you define 'basically interchangeable'? e.g. 'same intellectual content' ... can we conneg Flash and SVG? .MP3 and .WAV? PDF and HTML5? 14:48:22 gavin: you mean that the web does not work... 14:48:35 q? 14:48:47 ack sandro 14:48:47 sandro, you wanted to talk about "identify"-vs-"name" 14:48:48 ack AlexHall 14:48:49 ack AlexHall 14:49:53 httpRange-14 is mentioned. it'll be all downhill from here 14:49:55 but that means if we have a local dataset that uses for a name a 'global' (or core) URI, that would not dereference to the local copy in the dataset but it would go somewhere else. Ie, putting URI dereferencing into the dataset model may go wrong 14:50:07 zakim, who is playing music? 14:50:08 I don't understand your question, danbri. 14:50:13 sandro: the web-arch way for a URI to identify a thing is not the same as the RDF way 14:50:36 resolved httpRange-14? 14:50:57 pat: agree with sandro, the httpRange-14 solves this, but has the WG endorsed it? 14:51:29 We need a godwins law for httprange-14 14:51:37 coffee break? 14:53:00 (pat and sandro arguing about following the TAG or not in their resolution of httpRange-14) 14:53:48 pat: httpRange-14 does not say anything about what resource a IRI identifies, only what *kind* of resource 14:53:53 let's get coffee then httprange-14 will be resolved when we get back 14:54:36 iand, it will have resolved itself 14:54:42 :-) :-) We need a godwins law for httprange-14 14:54:59 guus: can we get a clear statement of what we expect as a result of this WG 14:55:04 i quite liked the idea of a note 14:55:07 ... not in terms of semantics, but of pragmatics 14:56:07 sandro: there should be a document explaining how dereference relates to RDF 14:56:10 guus: agree 14:56:23 sandro: It sounds like we should be working on a document (Note, Rec, part of Rec) aboud how dereference relates to RDF. 14:56:32 PatHayes: amen 14:57:37 david, re. your earlier question, see http://www.w3.org/TR/rdf-mt/#urisandlit 14:58:08 Thanks, Pathayes 14:58:12 OK, see yall in an hour. 14:58:17 gentlemen, I have to leave now 14:58:34 -PatH 14:58:55 bye 14:59:04 -AZ 15:03:37 -ww 15:09:02 -MIT_Meeting_Room 15:15:36 AlexHall has joined #rdf-wg 15:52:31 AlexHall has joined #rdf-wg 15:54:38 zwu2 has joined #rdf-wg 15:55:55 Scott_Bauer has joined #rdf-wg 15:56:50 reconvene in 5? 15:57:11 still missing most of the room at MIT 16:00:21 AndyS has joined #rdf-wg 16:01:13 +PatH 16:01:45 -PatH 16:01:50 tlebo has joined #rdf-wg 16:03:01 gavinc has joined #rdf-wg 16:03:23 Souri has joined #RDF-WG 16:03:37 +MIT_Meeting_Room 16:03:53 davidwood has joined #rdf-wg 16:04:07 welcome bac, MIT meeting room 16:05:17 davidwood, can you hear us? 16:05:25 EUROPE CALLING AMERICAS 16:05:29 swh has joined #rdf-wg 16:05:38 MIT is back on the phone. 16:07:38 LeeF has joined #rdf-wg 16:07:54 topic: meta-discussion of how to make progress in F2F 16:08:21 davidwood: name, identifier, dereferencing is causing problems. 16:08:23 q+ 16:08:32 ack PatHayes 16:08:32 PatHayes, you wanted to discuss identify/name when that gets to be a topic. 16:08:35 davidwood: after 6 months, we're still not using terms consistently enough to enable progress 16:08:48 ... suggestions for way forward? 16:08:56 ack Guus 16:09:07 scribenick: ericP 16:09:16 q+ 16:09:21 Guus: i feel we moved forward a bit before the break: 16:09:39 ... .. some consensus that we need names for at least graphs, maybe more 16:09:54 ... .. some sense of the requirements these impose on RDF 16:10:10 ... .. use cases lead us to the deferencing dicusssion 16:10:45 ... still not clear how rdf dataset relates to g{snap,box} 16:10:52 +PatH 16:10:53 LeeF_ has joined #rdf-wg 16:11:09 davidwood: we need names for at least graph containers (gboxes) 16:11:35 s/names for at least graphs, maybe more/names for at least graph containers, maybe more/ 16:12:07 davidwood: paraphrasing PatHayes, "a name is not an identifier" 16:12:08 r 16:12:15 q+ 16:12:30 ... "... we can have multiple names for things" 16:12:47 pat: We're not obliged to presume that "naming" and "identifying" are the same relationships. 16:12:49 PatHayes: the notion of name and identifier are disctinct 16:13:02 ack cygri 16:13:05 ... no position on whether they *should* be the same 16:13:45 cygri: i think we made progress on understanding peoples' positions and requirements, as well as what's easy or hard 16:14:11 ... can we discuss what we can write over the coming weeks to make progress? 16:14:13 cygri: let's figure out what we should write in the coming weeks 16:14:27 ... e.g. i think we should gather use cases 16:14:28 +☃ for test cases 16:14:50 cygri: eg: patterns for use of named graphs, that exist in the wild, and potentially cause interop conflicts. 16:14:54 ... we should look for different existing use patterns which will reveal problems at e.g. SPARQL endpoints 16:15:07 q+ 16:15:09 q? 16:15:12 +1 to test cases 16:15:13 ack Guus 16:15:15 leef, what symbol was that? 16:15:23 Guus: +1 to test cases 16:15:49 ... want to see which we should put in RDF semantics and which are outside pragmatics 16:15:51 PatHayes, it was a unicode snowman 16:16:01 http://www.fileformat.info/info/unicode/char/2603/index.htm 16:16:07 (or not. hard to see.) 16:16:09 :-) 16:16:14 ... folks already have pragmatic approaches. the question is whether we can incorporate some of that into RDF 16:16:37 q? 16:16:40 ack sandro 16:16:51 Guus: with respect to naming and referencing, i don't expect us to put stuff into Semantics, but it will be in tests 16:17:14 LeeF_ has joined #rdf-wg 16:17:37 sandro: in gavin's use case, several folks said "there's a bug here" 16:17:49 PatHayes, http://unicodesnowmanforyou.com/ 16:18:00 ... we can try to solidify that 16:18:23 davidwood: "can a document IRI and the graph IRI be the same?" 16:18:32 gavinc: and the ontology IRI? 16:18:44 q? 16:18:54 sandro: is the ontology's name for itself the same as its location? 16:19:03 gavinc: axes: 16:19:08 ... .. graph name 16:19:09 graph-name vs location 16:19:19 ... .. a Ontology. 16:19:39 ... .. where you can retrieve the [ontology?] 16:19:52 :g1 { :g1 a owl:Ontology } 16:20:04 if a Ontology, surely should't be a graph? c.f. Person and graph 16:20:06 ... i think the prob exists on these axes 16:20:26 we no hear 16:20:32 can people speak in turn please 16:20:49 we heard a little of all of them 16:20:57 ... { a Ontology } gets repeated everywhere 16:21:32 sandro: possible test case, if we can infer a type for locations and/or names. 16:21:34 LeeF: is it kosher for the graph name to be X and for X to be the ontology triple 16:21:45 q+ 16:21:49 this sounds very like the question whether one iri can identify the NYTimes and also one day's version of it. 16:21:55 ack ivan 16:21:55 no 16:21:55 HTTP GET ; :g1 { :g1 a owl:Ontology } 16:22:09 davidwood: we should at least provide guidance to the community 16:22:36 that is exactly what I meant by using a name inside some rdf. 16:22:48 ivan: sandro vs. cygri controversy: should the formal part of the RDF docs talk about dereferencing the graph name 16:22:55 once you do that, it belongs to trhe semantics. 16:23:09 ... if the answer is "no", we can discuss writing additional guidance documents 16:23:11 is Gavin's #1 "graph name" of the Graph Container? 16:23:14 +1 to ivan 16:23:24 ... that question is the fundamental question 16:23:34 q+ to say we won't knwo until we've explored the use cases 16:23:40 +1 to ivan 16:23:51 q+ to give an example from sindice 16:23:52 sandro: i think we're only going to answer that question by working up from test cases 16:24:12 ivan: so let's look at tests keeping this in mind 16:24:18 test cases can provide information on what a solution might look like, but they don't help much to determine what the solution is 16:24:36 q+ 16:25:05 ... if the semantics requires a particular way of dereferencing the name or graph, would that change antidot's implementation? 16:25:05 test cases give useful information about intuitions. better than arguing :-) 16:25:14 +1 to ivan, all conversations we have had today seem to involve talk about dereferencing, linked data, and quads, but this hasn't been discussed yet. 16:25:14 +100 PatHayes 16:25:16 The Formal Semantics document is just one way to make a spec. First let's figure out what we want to spec. 16:25:17 PatHayes, but less fun! 16:25:26 :) 16:25:50 ericP, this irc record. 16:25:56 ack ericP 16:25:56 ericP, you wanted to say we won't knwo until we've explored the use cases 16:27:12 ericP: The SemWeb limps along, we're used to, we compose SPARQL queries that connnect different graphs, we're not surprised by individuals lying to us, etc. But Sandro is trying to enable things beyond what we are doing now. We don't want to make sure we don't rule out these use cases in the future. 16:27:20 q- 16:27:45 s/don't want to make sure/want to make sure/ 16:27:55 ... without understand how we can take this to a system where there is consistency between platforms, ... we need to figure out how we want the system to work before deciding what goes in the semantics document. 16:28:03 q+ 16:28:18 PatHayes: I agree, but we may find it can't be done in the Semantic Document. Be ready to be told "I can't do it". 16:28:21 PatHayes, 16:28:25 +1 to Pat :-) 16:28:45 davidwood: if you can't do it, where does that leave us? 16:29:12 PatHayes: without precisely defined semantics. maybe that's okay. 16:29:30 sandro, what do you feel about the semantics being defined in natural language and test cases? 16:29:31 Test cases are not a definition. Natural language can be rather squishy. 16:29:37 we'd need specific examples of the test cases 16:29:39 sandro: How bad would it be to do it with natural language and test cases? 16:29:49 PatHayes: that's like asking a horse trainer how they feel about life without horses 16:30:04 PatHayes: There's a long language of clashes resolves by formal semantics. If we can do it that way we should. 16:30:07 ... the world can get by, but [there's a cost] 16:30:12 davidwood: Thanks Pat! 16:30:17 ack cygri 16:30:17 cygri, you wanted to give an example from sindice 16:30:31 ... but don't be surprised if i can't write the semantics that you guys arrive at 16:30:42 squishy, good one. 16:30:44 ack me 16:30:59 s/sandro, what do/sandro: what do/ 16:31:15 cygri: re: dereferencing, we have a web crawling use case about an RDF search engine 16:31:23 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28C_priority.29_Web_crawling 16:31:27 q+ to confirm that we are discussing three things: graph name for an ontology, name of the ontology, location from where the ontology (or graph) i available 16:31:47 'ontology 16:31:53 ... it takes a URL X, dereferences it, put's the parse into GRAPH 16:31:55 sorry 16:31:57 s/ i av/ is av/ 16:32:18 ... it supports the truth that sandro wants 16:32:45 ... if we want to define this formally, we have to discuss @@1 16:32:53 ... in 2006, that was RDF/XML 16:33:03 ... in 2007, RDF/XML and Turtle 16:33:16 cygri: sindice's dataset uses the fetch-from location as the tag, and its graph containers. when we built this in 2006, this was parsed from RDF/XML, then conneg, then sniffing, then microformats support added, then RDFa, then microdata, ... and some day json-ld, etc. 16:33:24 ... then we added RDFa, ntriples, microdata, ... 16:33:36 cygri: The notion of dereferencing has changed over the years. 16:33:44 ... the notion of dereferencing has changed over the years 16:34:12 this is exactly why we had an abstract notion of rdf graph, to provide a level of abstraction above particulr syntax. 16:34:25 who wrote earlier that time was not the only parameter? 16:34:29 ... how do we write a formal spec that tells us how to dereference? 16:34:51 davidwood: can you tell me if 4.2 is subsumes 4.9 or 1.3? 16:34:56 uri for the test cases? 16:35:02 q? 16:35:06 sandro: [addressing cygri] 16:35:09 q 16:35:21 q 16:35:22 q? 16:35:22 ... i don't have a pat answer, but i think we can come up with something that's good enough 16:35:23 PatHayes, http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28C_priority.29_Web_crawling 16:35:26 q+ 16:35:46 thanks gavin 16:36:09 cygri: i think that a formal semantics must be precise, so we need to reduce our scope to what we can be precise about 16:36:41 typing with one hand, return and shift keys too close. 16:36:43 ... there's something else that can be done which is sort of hand-wavey which would be useful; recording this pattern 16:37:20 acl swh 16:37:21 ... but writing to rules to establish if is a conforming something of an IRI could be hard 16:37:24 ack swh 16:37:50 swh: agreed with ericP to a point, but have a different conclusion: 16:38:18 ... .. none of the use cases we've discussed benifits from a formal semantics for dereferencing 16:38:42 ack Souri 16:38:43 Souri, you wanted to confirm that we are discussing three things: graph name for an ontology, name of the ontology, location from where the ontology (or graph) i available 16:38:57 ... so unless we can find another use case, i think we can spend our time better elsewhere 16:39:06 Souri: in the ontology case, i see three things: 16:39:10 ... .. graph name 16:39:16 ... .. ontology name 16:39:21 ... .. location 16:39:32 5.2 16:39:44 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_OWL.27s_.E2.80.9COntology_Documents.E2.80.9D 16:39:50 Souri: these could all be different 16:39:57 is "graph name" of the container or g-snap? 16:40:05 ... can we add properties like rdf:availableFrom? 16:40:42 q+ 16:40:45 ... if folks want to use one IRI for all, fine 16:40:53 right now OWL works fine without any further semantics for ontology names 16:41:04 q- 16:41:08 ... if not, we can give them some properties to describe their relationships 16:41:21 ack PatHayes 16:41:26 davidwood: by "graph", gsnap or gbox? 16:42:03 suggest to go to the wikidata usecase 16:42:14 q+ 16:42:24 ack cygri 16:42:27 PatHayes: from cygri listing the syntaxes each year, the notion of defining dereferencing would be to address exactly that 16:42:37 ... i thought that was the one part we got exactly right 16:43:03 cygri: one of the cool things about syndice is that we can push a bunch of stuff down the pipe and we get triples 16:43:12 ... the process is really complicated 16:43:29 ... HTTP, mime time, sniffing, ... 16:43:46 s/mime time/mime type/ 16:43:47 ... we learn more about this all the time 16:44:03 s/mime type/media type/ ;) 16:44:17 ... getting from the IRI to the graph is hard to specify 16:44:37 ... i'm more interested in what you get after you dereference and parse and all that 16:44:47 there can even be multiple was to get from a URI to different graphs, e.g. conneg + RDFa 16:45:15 +1 to not specifying it 16:45:20 swh, and conneg'ed graphs may be different too 16:45:29 indeed 16:45:30 ericP++ 16:45:33 swh, (as it does on the bbc site, for example, although i agree it's not ideal) 16:45:56 q+ 16:46:01 LeeF has joined #rdf-wg 16:46:03 q- 16:47:29 LeeF_ has joined #rdf-wg 16:47:42 ericP: from the same input URI, you could end up with quite different snaps because of different processing that was done 16:48:08 q+ 16:49:35 ack cygri 16:49:38 q- 16:49:39 PatHayes: we violated the obvious deferencing rules when we decided that IRIs in RDF could identify graphs 16:50:05 AndyS has joined #rdf-wg 16:50:08 The mentioned decision was: "Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs (relevant to ISSUE-30)" http://www.w3.org/2011/rdf-wg/meeting/2011-04-14#resolution_1 16:50:34 do sparql datasets consist of g-snaps or g-boxes? 16:50:42 iand, g-snaps 16:51:07 (with g-boxes it's a “graph store”, defined in the SPARQL Update spec) 16:51:22 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC 16:51:29 cygri: i don't agree that a g-box is a graph store 16:52:11 iand: what AndyS is saying 16:52:32 nor I 16:52:42 cygri: isn't a g-box a set of g-snaps with the same name? 16:53:06 s/tanks/thanks/ 16:53:19 if I have a github repo with 15 versions of some RDF doc (er, graph), ... is that a g-box? 16:53:20 iand: no, I don't think so 16:53:28 iand, no. g-snaps don't have names as such 16:53:38 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Trust_Web_Opinions 16:53:39 gavinc: A graph store is made up of gboxes, a dataset is made up of g-snaps 16:53:41 g-snap = mathematical set of triples 16:53:48 q? 16:54:16 TOPIC: 4.9 (A PRIORITY) Trust Web Opinions 16:54:27 +1 gavinc -- what needs clarifying is graph store -> dataset for query, not graph store or dataset themselves 16:54:34 MacTed has joined #rdf-wg 16:55:58 sandro: people are publishing useful info on the web 16:56:12 ... alice is searchnig for a good local seafood restaurant 16:56:31 cygri: can't get my head round g-snaps not having names if SPARQL datasets are made of named g-snaps 16:56:35 iand: Also, a g-box is mutable and not a 'set' 16:56:35 ... there are different modes of failure sensitive to the data she may find: 16:56:47 ... .. deception (people lying) 16:56:48 iand: named graph = pair of uri and g-snap 16:56:57 ... .. errors (mistakes in the data) 16:57:03 sparql dataset = set of named graphs, plus a default graph (= g-snap) 16:57:05 ... .. simplication 16:57:10 ... .. time lag 16:57:21 ... .. subjectivity 16:57:49 cygri: you are saying named graphs are graphs without names that have a name associated with them 16:57:50 ... [of course] this occurs in science, IT (e.g. employee directory) 16:58:11 iand i don't think i said that 16:58:13 ... i haven't yet tied this down to test cases 16:58:20 iand, could you use "," and not ":" the minutes will be very annoying otherwise 16:58:45 ... e.g. i don't want to endorse a gbox; i want to endorse a gsnap (review changes out from under your endorsement) 16:59:06 davidwood: she already knows about the sources of reviews, but she doesn't know which she can trust 16:59:07 gavinc, yep, sorry 16:59:47 sandro: say she's using sindice to find seafood restos 16:59:54 q+ 17:00:07 davidwood: alice goes to sindice and gets RDF for resto reviews 17:00:24 ... upon what data/metadata is she "trusting" the review? 17:00:43 sandro: she had to know her threat model to manage her security 17:01:02 ... .. deception: web of trust 17:01:17 ... .. error: crowd sourcing 17:01:23 ... .. time lag... 17:01:35 davidwood: i'd like to get here with 1.3 17:02:14 ... implicit in this is that a given review published in the web must be spidered by sindice or alice, ... 17:02:32 ... in spidering, they must capture provenance data (where, when, ...) 17:02:54 sandro: sindice could just give alice the locations, and she fetches them 17:03:21 ww has joined #rdf-wg 17:03:21 if sindice just gives Alice a URI should just judge timeliness without trusting the publisher 17:03:26 it's a myth that you need URIs to do things 17:03:29 it's just a lot easier 17:03:34 s/should/she can't/ 17:03:44 davidwood: she'll need at least one bit of metadata, the IRI, or much more 17:03:52 All these issues come up on the web right now. People seem to manage, on the whole. Might be worth trying to figure out how/why and provide similar funcitonality for people to use in RDF. 17:04:06 ... if sindice finds a resto review in RDF, what's it try to GET? 17:04:37 cygri: deferences, parses (many parsers) 17:04:44 ... records: 17:04:48 ... .. domain name 17:04:51 ... .. time 17:04:57 ... .. HTTP headers 17:05:10 ivan: the name of the graph is the IRI which gave you the IRI? 17:05:12 cygri: yes 17:05:51 davidwood: if we standardized a named graph: named gbox or named gsnap, would that help? 17:06:07 q+ 17:06:15 q+ to reply to "don't stdize deref" 17:06:16 cygri: don't try to specify the dererencing step 17:06:16 q- 17:06:28 ... would be immediately outdated 17:06:32 i wrote my comment. 17:07:01 davidwood: would a standard for gboxes or gsnaps help the sindice use case? 17:07:12 cygri: practically, no; it's already implemented 17:07:29 ... would make it easier for us to discuss what we do in terms others would understand 17:07:32 PatHayes, for one thing humans don't treat IRIs as opaque. A review from "http://linkspamsite.com/blah" is magicly downranked 17:07:57 ... i listed this because i don't want the WG to standardize something harmful 17:08:00 ack sandro 17:08:00 sandro, you wanted to reply to "don't stdize deref" 17:08:45 http://sparql.sindice.com/sparql 17:08:50 gavin, nice. to me that suggests we could use a way to say foo is downrated in RDF. Now ask what kind of thing foo is... 17:09:45 sandro: if alice's software is speaking to sindice, using SPARQL against the dataset, it would help if here code knew that sindice is using their named graph convention 17:10:31 q+ to ask about test cases for "to dereference, follow the standards" 17:10:35 ... re: specifying dereferencing, i don't want to specify the mechanics; we can just lean on the specs (which is what PatHayes identified as the bit of the semantics that works) 17:10:39 That sounds like a job for a vocabulary, not sure it's the RDF-WGs problem 17:10:48 +1 17:10:57 +1 steam-powered parsers!! 17:11:04 And in the limit (geo-IP) not everyone may see the same thing for exactly the same request. 17:11:04 +1 swh 17:11:15 ack ivan 17:11:29 can't we phrase dereferencing as http:Requesting a rdf2:GraphContainer to obtain a http:Representation of a rdf2:Graph, http:ContentNegotiated to a particular rdf2:GraphSerialization ? 17:11:29 PatHayes: if someone has a new steam-powered parser, they just have to describe in painstaking detail how it emits triples 17:11:56 ivan: if we use this black box, do we exclude names? 17:12:19 Yeah, sounds like a job for the vocabulary, but I think we get right back to what is that vocab talking about, a Resource in a Graph or "The Graph". Where "Graph" is our nice new meaning of gbox+gsnap 17:12:25 ... e.g. AndyS's suggestion for using tag IRNs for time-stamped data 17:13:16 q+ 17:13:20 sandro: dereferencing is the way we learn the intent of the identifier 17:13:21 gavinc, yeah we need to make sure that the vocabulary has something to talk about 17:13:34 q+ to grouch 17:13:46 de-referability is not a property of URI scheme 17:14:01 http://www.dlib.org/dlib/june98/06powell.html 17:14:41 q? 17:14:49 all uris dereferenced for a nominal fee. money-back guarantee. 17:14:49 q- 17:14:53 ack cygri 17:14:53 cygri, you wanted to ask about test cases for "to dereference, follow the standards" 17:14:56 0K box! 17:15:00 q+ 17:15:02 ack cygri 17:15:29 cygri: so we leave dereferencing as a black box (leave to standards) 17:15:48 ... but i don't see how to write test cases 17:16:30 ... if it's a specification, it should be possible to write a test case 17:16:38 sandro: i agree with your goal 17:16:53 which, btw sandro, is one reason why naming/reference cannot be identical to awww:identifies. 17:16:59 ... most dereferences are in HTTP and there's a little glue around the edges 17:17:52 ... i haven't got a test case and agree that we need then 17:18:09 ack AndyS 17:18:13 sandro: names and awww:identifies could be congruant functions 17:18:18 ack danbri 17:19:28 1.3 (A PRIORITY) Graph Changes Over Time 17:19:29 8 track tapes... 17:19:30 danbri: re: deferencing, you speak as if dereferencability as it it were a behavior of the schema, but it evolves 17:19:31 q? 17:19:32 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Graph_Changes_Over_Time 17:19:49 of course 17:19:53 q+ 17:19:53 pfps if we can't discuss history are we doomed to repeat it? :-) 17:20:02 ack swh 17:20:03 resolved: de-referencability is not a simple characteristic of a URI scheme, but depends on social and technical mess surrounding us 17:20:29 Ugh 17:20:35 s/resolved// 17:20:42 q+ 17:20:46 swh: in our system you need to have different graphs at the same IRI at different times 17:21:05 q+ 17:21:10 :URL rdfs:subClassOf rdf2:GraphContainer ? 17:21:19 ... we need to say that some info was in at one time but not later 17:21:36 ... so of course you can't *just* use 17:21:39 rdfs2:GraphContainer owl:disjointWith rdf2:Graph . 17:22:01 q? 17:22:05 ... we just use 17:22:19 ... looked at MD5, but it was a pain 17:22:30 we actually use 17:22:57 (q: are anyone's 'graphs' computed from other 'graphs' rather than simply fetched? am assuming so but didn't hear much mention of this...) 17:23:10 do you need to be able to tell, by looking at the iri, which way it works (box or snap name) ? 17:23:33 sandro: if you use , you could own that graph and say that it's attached to 17:23:43 @pathayes, no, interrogate its rdf:types ? 17:23:51 +1 swh - this is first use case where graph name cannot be same as source of triples 17:23:55 ivan: we've never said that a graph need have only one name 17:24:03 really I said garlic + date + fetched-url 17:24:15 I have swh's use case too; it's quite a common pattern and worth naming/documenting/exposing 17:24:17 q+ 17:24:28 q+ to talk about rolling snapshots 17:24:32 PatHayes: i think that there's one name, which if you use it as a graph name, changes meaning from time to time 17:24:45 we didn't go for http://www.garlik.com/?url=http://example.com/&time=2010… to save bytes FWIW 17:25:02 AndyS has joined #rdf-wg 17:25:23 mischat, that's right 17:25:29 ivan: we have the notion of a "graph container" and a graph at different IRIs 17:25:41 gavinc: do they *have* to be different IRIs? 17:25:46 makes sense, mischat --- but you COULD quite easily, and then it would totally conform with "Web Semantics for Datasets". 17:27:40 q+ 17:27:51 davidwood: Possible consensus: The identifier for a graph container is disjoijnt with the identifier with the g-snap (rdf graph). 17:27:57 we were could have done, but we built this a while ago, before this conversation. we do this by using SPARQL to insert triples into a triplestore. and as far as we were aware we were conforming 17:28:11 you could use one iri to identify a grap and a container, but dont record that use in any published rdf. 17:28:12 davidwood: gavinc thinks that he's heard an emerging concensus that the graph container must be different from the name for a graph 17:28:32 ... objections? 17:28:59 Yes, there were (thankfully) objectons 17:29:08 LOAD will do that 17:29:32 swh: as applied globally, yes 17:29:45 disjoint is too strong. 17:29:49 davidwood: and here, so we don't have consensus here 17:30:04 q+ 17:30:05 q+ 17:30:22 sandro: [chasing why this breaks SPARQL] 17:30:26 q+ to say that if *denotes* a graph container, then it must still be possible to associate with a graph graph in an RDF dataset 17:30:46 isn't the beauty of it that you can choose to use the URL of where you dereferenced it from, or use whatever URI you wish when sticking it into your sparqlstore 17:31:15 SELECT .... FROM { ... } 17:31:22 g1 specifies a graph container 17:31:25 it gets dereferenced 17:31:31 and put into a local graph container that is also named g1 17:31:40 local g1 is contextualized by the invocation of the quer 17:31:41 timlebo: when you specify the SPARQL query, the FROM IRI sites the graph container, GRAPH dereferences IRI and stores it locally 17:31:46 agree with cygri, but want to add cautions regarding denoting-use in rdf which assumes connection to association. 17:31:51 FROM ==> FROM NAMED 17:31:53 q? 17:32:02 iand1 has joined #rdf-wg 17:32:14 ack me 17:32:14 cygri, you wanted to say that if *denotes* a graph container, then it must still be possible to associate with a graph graph in an RDF dataset 17:32:39 ... so the SPARQL query against your local is contextualized by your dereference 17:32:57 +1 cygri 17:33:00 s/graph graph/RDF Graph (gsnap) 17:33:02 s/graph graph/RDF Graph (gsnap)/ 17:33:20 It is a bad part of SPARQL. Promotes lazy naming. (and DAWG removed it once ... community wanted it back) 17:33:42 cygri: if i deference http://example.com/ (which may change tomorrow), i serialize it into a trig file 17:33:56 im losing sound here. 17:34:18 ... that trig file serializes a gsnap which i want to associate with the gbox () 17:34:34 PatHayes, we hear BBC. Perhaps you should redial? 17:34:44 Can't there be an eg:hasGraph relation between the gbox and the gsnap? 17:35:10 ... one identifier denotes a graph container @@2 17:35:15 in a spec we can mention lazy naming and point out how useful it is but also say how dangerous it can be with detailed warnings. 17:35:35 q++++ 17:35:41 ivan: i understand the example, and it makes me uneasy that the same IRI denotes two conceptually distinct things 17:35:45 where in this example is a URI being used for a gsnap? 17:35:47 ack +++ 17:35:48 PatHayes - good idea - say "don't publish - use locally" 17:35:56 +1 ivan 17:36:00 ... maybe we have to live with conflation 17:36:09 So we are back to "(15:04:03) davidwood: Propose to RESOLVE "we need a way to name graph containers"" 17:36:09 q- 17:36:09 +1 to living with the conflation!! 17:36:18 Still thinks that adopting vs. my:#http://xmlns.com/foaf/0.1/# and your:#http://xmlns.com/foaf/0.1/# addresses this confusion. 17:36:23 q- 17:36:26 ack sandro 17:36:26 sandro, you wanted to talk about rolling snapshots 17:36:28 +1 to living with conflation 17:36:38 -1 to conflation 17:36:50 sandro: i have issues with an IRI denoting two things 17:36:51 danbri++ 17:37:15 danbri: it's just an unspecified relationship 17:37:21 because people want to be happily sloppy, sandro. 17:37:27 sandro: so why can't we specify that relationship? 17:38:00 ... particular predicates can imply the 17:38:03 q? 17:38:14 s/bgox/gbox 17:38:20 this is very like the problem of giving iris to editions of documents, seems to me. 17:38:20 can someone propose some concrete text to discuss? 17:39:04 davidwood: we have namespace all over RDF 17:39:28 ... we have IRIs which point to SPAQL enpoints which point to resources 17:39:39 @PatHayes, frbr:Work vs frbr:Expression gives you clean disjointness of editions and their more abstract documents. 17:40:17 q+ 17:40:24 i know, tlebo. i wish all these scruffy people would agree to that disciplined. 17:40:34 to/to be/ 17:40:42 davidwood: these identifiers liter our RDF graphs 17:40:52 q? 17:41:01 q+ to talk about rolling snapshots 17:41:04 use imperial measures to solve that one. 17:41:07 GET ; { example: "http://example.org"^^xsd:anyURI } 17:41:08 tlebo, path, frbr distinctions are too often anything but clean when you try to get people to make specific decisions that apply them in practice 17:41:10 ... my position is that we should accept the dual nature of those IRIs as identifiers and collapse the duality when we open the box 17:41:14 ack tlebo 17:41:29 I'm pretty happy to go ahead being sloppy in violation of the semantics -- presumably, some day there will be a tool that is really valuable that relies on me following the semantics and then i will be motivated to change my implementation :) 17:41:35 tinlibo: propose that URLs are a subclass of graph container which you dereference to a graph 17:41:38 danbri, +1 17:42:04 LeeF, suspect world+dog agrees with you 17:42:36 q+ 17:42:38 ... (when we're talking about RDF graphs) 17:42:46 LeeF, the WG is the tool, and the semantics are where we write stuff down so we don't forget exactly what we decided... 17:42:53 q? 17:42:54 we're processing HTML mostly, not RDF 17:43:18 before break: there is something that we _did_ learn today: http://www.w3.org/2011/rdf-wg/wiki/Carandache 17:43:19 Topic: 10 minute break 17:43:23 -PatH 17:43:28 danbri, i'm not sure i understand what you're saying -- you're saying the semantics in the spec by themselves should be enough for me to change my implementation? that's unlikely 17:43:30 +1 17:44:05 MIT has gone silent (here) 17:44:20 we muted for the break, AndyS 17:45:38 LeeF_, no, more that you shouldn't be sat there, waiting and dissapointed, when no fabulous js/Java/php library comes along proving the usefulness of the Semantics. Rather, the fact that most such libraries more or less work well with each other, is partly due to things having been written down in obsessive detail in the semantics (and in testcases, sure) 17:54:31 Scott_Bauer has joined #rdf-wg 18:00:49 Reconvene 18:01:10 scribe: alexhall 18:01:23 +PatH 18:01:25 scribenick: AlexHall 18:01:32 If there were more people using Windows then there would be more people agreeing with me about just living with the conflation :-) 18:01:46 davidwood: don't think we ever really talked about UC 1.3. Steve started to and didn't finish, did you have anything else? 18:01:55 Topic: 1.5 (A PRIORITY) Exchanging the contents of RDF stores 18:01:55 swh: no, that was it 18:02:07 http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Exchanging_the_contents_of_RDF_stores 18:02:22 davidwood: whose use case? 18:02:28 I want it :) 18:02:47 iand? 18:02:59 nooo 18:03:09 swh: related to backups... how to move between stores? Things like trig do it fairly well except the default graph issue 18:03:26 swh: TriG doesn't work for this if the default graph is the merge of all the named graphs. 18:03:27 ... duplicate every triple if dft graph = union of ngs 18:03:37 ... also issues around bnodes 18:04:43 why should the default be the union of named graphs??? that sounds like an obviously wrong general assumption. 18:04:53 ivan: trig syntax won't tell you what is the default graph 18:05:16 PatHayes, it's not a general assumption -- it's just how some SPARQL engines are set up. 18:05:31 PatHayes, "can be" -- common pattern and they use NG to manage data (subsets of the data) 18:05:34 (steve's in particular, by default.) 18:05:39 q+ 18:05:42 guus: not a sparql store developer -- what's the issue here? 18:05:45 so, why are we even talking about this? 18:06:12 ok, so trig needs to be extended in some way? 18:06:14 ack sandro 18:06:14 sandro, you wanted to talk about rolling snapshots 18:06:15 ???: many stores define the default graph specially 18:06:23 q- 18:06:46 sandro: The other thing TriG doesn't do for this UC is bnodes (unless skolemized) 18:07:20 ack pchampin 18:07:22 swh, how about a meta comment in trig like this:? @SPARQL: CONSTRUCT { ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p ?o } } . 18:08:01 mischat has joined #rdf-wg 18:08:20 pchampin: think i disagree that this is a problem with trig. dataset is an immutable structure. how the default graph was defined is irrelevant. 18:08:22 TriG can do bNodes - just a small decision on scope - "small consensus" was doc-wide but point decision to be made. Orthogonal (later) 18:08:42 INSERT DATA { GRAPH {} } ... 18:08:46 ... if SPARQL stores are more than just dataset definitions then they need extra stuff to support that. 18:09:18 davidwood: looking at SPARQL update example here, data is going into a graph identified by a URI 18:09:52 ... 6 months ago, there was disagreement on this issue: what is being identified by this URI? 18:10:12 ... if we choose to align with SPARQL, then we're saying that this URI identifies a g-box 18:10:17 -1 18:10:24 i think we have already decided that we are NOT doing this. 18:10:39 q+ to ask what david means by “identify” 18:10:40 STRAWPOLL: Does anyone object to identifying a g-box with a URI, aligning with SPARQL 1.1 " INSERT DATA { GRAPH {} } " 18:11:31 of course you can identify a g-box with a URI, but you don't have to 18:11:42 pat: IRI is associated with graph, but doesn't denote it 18:11:48 cf the resolution from 2011-04-14 --- the url CAN denote the g-snap. 18:11:52 sandro: but the IRI can denote the g-box 18:11:52 ack cygri 18:11:52 cygri, you wanted to ask what david means by “identify” 18:11:53 CANT 18:12:10 ptr to resolution? 18:13:06 quoting SPARQL Update: “A Graph Store is a mutable container of RDF graphs managed by a single service. Similar to an http://www.w3.org/TR/sparql11-query/#sparqlDataset operated on by the http://www.w3.org/TR/sparql11-query/, a Graph Store contains one (unnamed) slot holding a default graph and zero or more named slots holding named graphs. Operations may specify graphs to work with, or they may rely on a default graph for that operation.” 18:13:09 AndyS: http://www.w3.org/2011/rdf-wg/meeting/2011-04-14#resolution_1 18:13:16 sandro, thx 18:13:18 I don't think SPARQL GRAPH uris identify anything in particular 18:13:20 s/:/,/ 18:13:25 davidwood: when you give a server a URI instructing where to put some data, how can that URI not identify the g-box? 18:13:28 @swh me neither 18:13:57 sandro: in SPARQL as deployed, they aren't used (consistently) to denote anything 18:13:59 +1 to Sandro :-0 18:14:13 (That resolution was about datasets not graph stores.) 18:14:17 ... used to denote different things in different datasets 18:14:55 what does "zero or more named slots holding named graphs" mean? is that 2 names, one for the slot, one for the graph? 18:15:16 ericP: we could say that SPARQL has never operated on g-boxes, only g-snaps 18:15:34 i can't understand 'sparql operating over' here; it's more about how the system is managed 18:15:43 and db admins don't exist in the formal Semantics 18:15:45 davidwood: SPARQL might operate on g-boxes, but from the perspective of a user it's a g-snap for any given query. 18:15:46 (yet) 18:15:47 iand1, no, it's one name. 18:15:55 not when you update... 18:16:01 INSERT DATA { GRAPH # {} } :-) 18:16:29 +1 to tlebo 18:16:42 cambridge, slow down please 18:17:05 q? 18:18:19 sparql 1.1 query doesn't import the definition of graph from RDF Concepts. Doesn't seem to define it at all. http://www.w3.org/TR/sparql11-query/#docTerminology 18:19:05 ericP: meta-discussion about not allowing ourselves to be constrained by what SPARQL is doing right now. 18:19:21 q+ to suggest that SPARQL 1.1 *has* URI for g-boxes... somewhere 18:19:22 eric: so far, maybe, SPARQL is against only g-snaps? 18:19:23 iand, interesting - it dives directly in 'graph patterns' 18:19:30 q+ 18:19:35 INSERT DATA { GRAPH {

}} ... takes the gsnap in the gbox adds

to the set to create a new gsnap that is placed into the gbox ? 18:19:37 souri: if you're doing an update, it has to be a g-box. 18:20:01 ack pchampin 18:20:01 pchampin, you wanted to suggest that SPARQL 1.1 *has* URI for g-boxes... somewhere 18:20:01 q? 18:20:07 http://www.w3.org/TR/sparql11-http-rdf-update/#indirect-graph-identification 18:20:08 q+ to add question already in irc 18:20:43 pchampin: thinking about section from SPARQL 1.1 that comes close to assigning URIs for graph containers 18:21:15 ... indirect identification by building a graph URI from the service URI and the graph URI 18:21:23 q- 18:21:36 Ahhhhh. I forgot/missed that. 18:22:41 sandro: this torpedoes my claim that you have to use 2 URIs to denote a g-box in SPARQL. 18:23:00 q+ 18:23:39 service description document http://www.w3.org/TR/sparql11-service-description/ ? 18:24:02 andy: you don't get something back from a dataset, a dataset is a set of graphs some of which with URIs associated 18:24:12 ... a graph store is a different aspect 18:24:52 ... SPARQL 1.0, a dataset is a set of graph and named graphs that is what the query runs over 18:25:14 ... then you have FROM/FROM NAMED which describes how to build the dataset from g-boxes/g-snaps 18:25:32 and dereference 18:25:40 s/dereference/dereferencing/ 18:25:50 ... then SPARQL 1.1 adds the notion of graph store, which is a collection of slots for graphs that can change over time 18:26:06 mischat_ has joined #rdf-wg 18:26:16 PROPOSED: SPARQL11-http-rdf-update URLs like /rdf-graphs/service?graph=http%3A//www.example.com/other/graph denote graph containers (gboxes). The embedded URI *might* also denote that same container, for some dataset arrangement patterns. 18:26:31 davidwood: is it your opinion that we can map the terms from SPARQL to our g-* terms (with an additional term to describe a collection of g-boxes)? 18:27:04 andy: yes, but it doesn't take into account stuff around graph literals 18:27:36 INSERT DATA { GRAPH {

}} ... takes the gsnap in the gbox adds

to the set to create a new gsnap that is placed into the gbox . This creates a new Dataset as well. ? 18:27:42 ack gavinc 18:27:42 gavinc, you wanted to add question already in irc 18:28:17 gavinc: given the original insert data statement, is what i wrote in IRC true? 18:28:49 no 18:28:49 i vote for it. 18:28:53 +1 to @gavinc's INSERT 18:28:57 :-( 18:29:02 +1 to gavin's explanation 18:29:07 ok if " gbox" means "the gbox labeled with " 18:29:22 yes, pchampin 18:29:30 yves, what was wrong with it? 18:29:37 Yes. 18:29:44 what does 'label' mean? More exactly, what doesn't it mean? 18:29:53 "paired" 18:29:57 [] sd:name . 18:29:57 "identify" has huge tag-baggage. 18:30:00 (I think that matches the spec) 18:30:10 q? 18:30:15 (http://prefix.cc/sd) 18:30:25 yves: find it counter-intuitive, think it will be horribly confusing to somebody reading the spec for the first time. 18:30:29 q+ 18:30:58 q+ to strawpoll 18:31:02 [] sd:name gavinc:iri; a rdf2:GraphContainer . 18:31:10 im having a hard time thinking what else it can possibly mean. 18:32:00 ack cygri 18:32:17 ack swh 18:32:20 q+ to ask gavinc about "add to a set" 18:32:45 swh: for gavinc, the thing that's wrong is that insert doesn't work over datasets, it works over graph stores. datasets are immutable. 18:32:51 q+ 18:33:09 A Graph Store is paired with a Dataset that that is made up of the ??? of gboxes that contain the gsnaps that make up the Dataset 18:33:14 It may be more readable backwards 18:33:21 INSERT DATA { GRAPH {

}} means take the gsnap that is the current state of the gbox , perform an RDF-Merge with

to form a new gsnap and make that the current state of 18:33:52 davidwood: sparql also has delete, but you can't delete from a set can you? 18:34:05 you can add triples to a set, just like you can add 1 to a number, you just get a *different* set 18:34:19 ok, so do we need the equivalent of the gbox/gsnap terminology for dataset? 18:34:25 dbox/dsnap? 18:34:31 PatH, yes. A graph store can have a NEW gbox added 18:34:41 tnx. 18:34:52 we need to be careful to distinguish between side-effecting operations and functional operations 18:35:13 q+ to book a slot on the Q [point to follow] 18:35:26 q- 18:36:12 ack sandro 18:36:12 sandro, you wanted to strawpoll 18:36:14 I once had lunch with Peter Landin. 18:36:20 +1 @iand's rephrasing of @gavinc's INSERT interpretation 18:36:33 sandro: do we want to cement this down any more? 18:36:43 zhe: depends on how you describe the pairing 18:36:45 STRAWPOLL: SPARQL11-http-rdf-update URLs like /rdf-graphs/service?graph=http%3A//www.example.com/other/graph denote graph containers (gboxes). The embedded URI *might* also denote that same container, for some dataset arrangement patterns. 18:37:01 ±1 18:37:06 like how a g-box of triples can at time T is a g-snap. A graphstore of quads at time T is a dataset 18:37:17 +1 actually 18:37:18 +1 18:37:30 I have no idea what that means 18:37:31 @iand's interpretation: This is in line with PROV-WG's immutable prov:Entity prov:derivedFrom (a distinct) prov:Entity . 18:37:52 +1 18:37:53 Souri has joined #RDF-WG 18:38:13 +0 18:38:15 sandro: some people use datasets in such a way that the embedded graph tag will denote the gbox. 18:38:31 davidwood: can you please define denote for us? 18:39:05 "identifying" is how HTTP dereferencing works; "denotes" is how RDF works. 18:39:13 so says @PatHayes 18:39:16 denotes -> "is a way of referring to". There may be other ways. 18:39:16 +0 18:39:17 well, its any naming. 18:39:58 pat: it was the TAG that made that distinction, between "identify" and naming (in the general sense, which is how we use it). 18:40:19 what are we saying +1, -1, +0, -0 to? (I was disconnected for last few minutes) 18:40:24 PatHayes: things apply to identifying that DO NOT apply to "denotes" - because it lets you access it. 18:40:37 smaal reformuulation: "INSERT DATA { GRAPH {

}} means take the gsnap that is the current state of the gbox , perform an RDF-Merge with

and make that the current contents of " 18:40:50 STRAWPOLL: SPARQL11-http-rdf-update URLs like /rdf-graphs/service?graph=http%3A//www.example.com/other/graph denote graph containers (gboxes). The embedded URI *might* also denote that same container, the way some people use datasets. 18:41:04 pfps, you might be right. 18:41:28 it's not the same container! 18:42:08 'might' and 'some' in a strawpoll confuses me :/ 18:42:20 INSERT DATA { GRAPH {

}} implies rdf:type :gbox 18:42:32 iand, no 18:42:35 := merge( , {s p o} ) 18:42:43 implies in what entailment regime? 18:42:46 q? 18:42:53 sandro: i think most of the confusion here is the connection between IRI and gbox 18:42:54 it's both a wave and a particle 18:42:55 iand: We aren't ready to make a statement that identifies the gbox... 18:42:55 pfps: in english 18:43:07 davidwood: i didn't say identifies 18:43:13 ack AlexHall 18:43:15 cygri, but is it dead or alive? 18:43:24 en-tag 18:43:31 yvesr, you won't know before you open the g-box 18:43:36 Note that I'm NOT saying the IRI denotes the g-box, but the QUALIFIED one does as per http://www.w3.org/TR/sparql11-http-rdf-update/#indirect-graph-identification 18:43:36 iand, no, you said rdf:type 18:43:41 AlexHall: re: the relationship between the graph store and dataset 18:43:59 ... the dsnap is the immutable collection of graphs states taken from the graph store 18:44:20 q? 18:44:31 ack AndyS 18:44:31 AndyS, you wanted to book a slot on the Q [point to follow] 18:44:38 q+ to ask if this strawpoll is intended to describe a new best practice 18:44:50 ack ericP 18:44:50 ericP, you wanted to ask if this strawpoll is intended to describe a new best practice 18:44:50 ! sameAs <.../rdf-graphs/service?graph=http%3A//www.example.com/other/graph> (but are both rdf2:GraphContainers). However, both have some common skos:broader... 18:45:26 ericP: is the goal of this strawpoll to provide guidance for how people might manage their g-snaps and the g-boxes they stole them from? 18:45:44 ... is it meant to provide guidance? describe best practice? document the only way we can do this? 18:46:03 sandro: i think this is the only way to do this that makes sense. 18:46:31 ericP: how can i evaluate this? is there a test case I can throw at it? 18:46:48 sandro: use it in some RDF 18:46:53 dc:author sandro:me 18:47:11 rdf:type r:GraphContainer 18:47:31 davidwood: we need to adjourn soon 18:47:59 ericP: don't think we can answer this tonight. perhaps we should write some coherent test cases first. 18:48:07 TRUE: /rdf-graphs/service?graph=http%3A//www.example.com/other/graph a rdf2:GraphContainer; skos:broader ?x . a rdf2:GraphContainer; skos:broader ?x . 18:48:28 davidwood: this example rdf is describing the gbox? 18:48:28 sandro, this illustrates for me exactly the problem. you are the author of the box. 18:48:32 sandro: yes 18:48:48 q+ to ask Steve/Andy about synching RDF dataset def in SPARQL doc 18:48:59 these GraphContainers are frbr:Items :-) 18:49:05 ???: what is being described, the box or the graph in the box? 18:49:24 q+ 18:49:42 sandro: normally dc:author is applied to web pages, and web pages are boxes too. when we say somebody is the author of the webpage, we generally mean they are the author of the latest version. 18:49:42 ack Guus 18:49:42 Guus, you wanted to ask Steve/Andy about synching RDF dataset def in SPARQL doc 18:49:53 eg:refreshRate 3. 18:50:00 mischat has joined #rdf-wg 18:50:03 ... in this context, might mean that sandro:me is the author is the latest gsnap in the box 18:50:30 q- 18:52:19 guus: can we try re-formulating the definition of SPARQL dataset in terms of the RDF dataset terms? 18:52:30 davidwood: agenda-bashing time 18:52:44 i wont be able to be there tomorrow, so y'all might get things done a bit faster :-) 18:52:56 ... revisit latest formulation of gavin's description of INSERT DATA, can possibly shake out some strawpolls 18:53:41 It is possible to improve - (carefully - safe against later RDF-WG decisions) 18:53:44 ... as well as sandro's g-box IRI strawpoll 18:54:05 ... propose to add these items to tomorrow's agenda 18:54:38 guus: really want to visit the wikidata use case 18:55:18 sandro: time to assign some homework 18:55:43 ISSUE-33? 18:55:43 ISSUE-33 -- Do we provide a way to refer to sub-graphs and/or individual triples? -- open 18:55:43 http://www.w3.org/2011/rdf-wg/track/issues/33 18:55:44 ... look over the issue list for ones you care about or think are obsolete 18:56:04 davidwood: would like to revisit issue-33 18:56:15 @sandro - we can apply "mangling service endpoint and GRAPH to name the g-box" to TRiG by replacing "service endpoint" with a sufficient "location" of the TRiG file. (because sparql endpoint and TRiG file are two of a more general notion) 18:56:56 BIG elephant: putting semantics in to name of a named graph or not 18:57:04 guus: still no answer to the issue of whether to put semantics into the relationship between the name and the graph 18:57:29 sandro: my strawpoll is trying to narrow down that space 18:58:52 ... clear that we can't have consensus that the IRI denotes the gbox because it will break too much deployed stuff 18:59:40 davidwood: adjourned 18:59:51 -PatH 18:59:55 PROPOSED: While it's desirable to have dataset tag IRIs denote their associated g-boxes, because of existing deployments we can't just rule that now. Instead, we can provide some way to flag the cases where it does, so the market can move in that direction. 19:00:00 (for tomrrow.) 19:00:00 -MIT_Meeting_Room 19:00:58 PROPOSED: While it's desirable to have dataset tag IRIs denote their associated g-boxes, because of existing deployments we can't just rule that now. In particular, in different datasets, the relation is different. Instead, we can provide some way to flag the cases where it does, so the market can move in that direction. 19:01:22 PatHayes, can you formally define g-box for us? 19:06:09 AndyS has left #rdf-wg 19:08:09 a g-box, named with zero or more IRIs, is a function (mapping) from time to g-snaps. 19:09:53 a g-box is a function from the current environment to a g-snap 19:09:57 that function can be named with an IRI 19:12:53 gavin: what about localhost: 19:13:15 david: We should say what people do on the open web, and if people want to break things on their own machine, that's their problem. 19:14:13 david: people are free to make stupid mistakes; it's just less useful when they do... 19:31:57 -Peter_Patel-Schneider 20:45:32 AlexHall has joined #rdf-wg 21:14:03 iand has joined #rdf-wg 21:56:04 iand has joined #rdf-wg 22:05:01 disconnecting the lone participant, BBC_Meeting_Room, in SW_RDFWG(F2F)6:00AM 22:05:03 SW_RDFWG(F2F)6:00AM has ended 22:05:07 Attendees were AZ, +1.617.324.aaaa, Peter_Patel-Schneider, ww, mischat, Guus, danbri, yvesr, pchampin, swh, ivan, cygri, iand, andys, NickH, davidwood, gavinc, zwu2, tlebo, 22:05:10 ... AlexHall, sandro, Souri, Scott_Bauer, LeeF, Thomas, PatH, Eric, MIT_Meeting_Room 22:49:25 Zakim has left #rdf-wg 23:38:14 tomayac has joined #rdf-wg 23:40:31 mischat has joined #rdf-wg