Chatlog 2011-10-12

From RDF Working Group Wiki
Jump to: navigation, search

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

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

<sandro> PRESENT: davidwood, gavinc, zwu2, AlexHall, sandro, Souri, Scott_Bauer, LeeF, Mischa, Pierre, Ian, Andy, Richard, NickH, Ivan, Steve, Danbri, Yves, Guus, ericP, tomayac, PatHayes
<sandro> GUEST: Tim (tlebo) Lebo, RPI
<sandro> REMOTE: pfps, az, ww
11:09:22 <RRSAgent> RRSAgent has joined #rdf-wg
11:09:22 <RRSAgent> logging to
11:09:24 <Zakim> Zakim has joined #rdf-wg
11:09:26 <sandro> zakim, this is rdf2wg
11:09:26 <Zakim> ok, sandro; that matches SW_RDFWG(F2F)6:00AM
11:10:04 <AZ> zakim, who is on the phone?
11:10:04 <Zakim> On the phone I see AZ, +1.617.324.aaaa, ??P2
11:10:11 <yvesr> sandro, we could hear you fairly well over h323
11:10:23 <yvesr> (a bit better than on zakim)
11:10:37 <sandro> RRSAgent, pointer?
11:10:37 <RRSAgent> See
11:10:50 <sandro> we see one very still, very blocky image.
11:10:54 <sandro> Well, we'll have some Zakim-only people, so I think we have to use zakim for audio.
11:11:01 <sandro> new call, 384kbos
11:12:23 <Scott_Bauer> Scott_Bauer has joined #rdf-wg
11:12:26 <cygri> cygri has joined #rdf-wg
11:12:34 <sandro> RRSAgent, pointer?
11:12:34 <RRSAgent> See
11:12:39 <sandro> Meeting: RDF F2F2
11:13:30 <Guus> mischa has offered to scribe the first session
11:14:04 <AlexHall> AlexHall has joined #rdf-wg
11:16:08 <Zakim> +Peter_Patel-Schneider
11:17:38 <davidwood> davidwood has joined #rdf-wg
11:17:39 <pfps> pfps has joined #rdf-wg
11:17:47 <mischat> Zakim: scribe mischat 
11:17:47 <mischat> RRSAgent: scribe mischat 
11:17:47 <RRSAgent> I'm logging. I don't understand 'scribe mischat ', mischat.  Try /msg RRSAgent help
11:18:13 <ivan> scribenick: mischat
11:18:20 <mischat> sandro: that was me calling you
11:18:42 <yvesr> we're trying to sip into zakim, so that we can hear you better
11:19:32 <danbri> scribe: Mischa Tuffield
11:20:41 <mischat_> mischat_ has joined #rdf-wg
11:21:24 <Zakim> -??P2
11:21:29 <iand> iand has joined #rdf-wg
11:21:50 <Zakim> +??P2
11:22:35 <Guus> [david, I'm on the Web client of IRC, so not receiving anything alse]
11:23:51 <davidwood> Does someone in London have a Skype ID?
11:23:59 <davidwood> If so, I can try calling you.
11:24:03 <gavinc> gavinc has joined #rdf-wg
11:24:09 <davidwood> Guus, ack
11:25:18 <sandro> We can actually hear you through the H channel - but it's unintelligible.
11:25:30 <sandro> So please turn off the audio channel.
11:26:07 <Zakim> -??P2
11:26:15 <sandro> zakim, who is on the call?
11:26:15 <Zakim> On the phone I see AZ, +1.617.324.aaaa, Peter_Patel-Schneider
11:26:24 <Zakim> +??P4
11:26:31 <sandro> zakim, aaaa is MIT_Meeting_Room
11:26:31 <Zakim> +MIT_Meeting_Room; got it
11:27:28 <davidwood> I'm sure there is a FOAF tag for that
11:27:44 <swh> what about a language tag?
11:27:45 <mischat> as well an inverse foaf property
11:28:19 <gavinc> Can you turn off the audio on your video?
11:29:34 <gavinc> Please, can you turn off the audio on your video
11:30:30 <sandro> topic: introductions
11:30:43 <AZ> is there a video stream available for remote participants?
11:30:54 <sandro> David Wood, Gavin, Tim Lebo, Alex Hall, Sandro, Scott Bauer, Lee F
11:31:01 <sandro> scribeL mischa
11:31:04 <danbri> AZ, we tried but nothing yet. Will try again to fix it in next break.
11:31:07 <sandro> scribe: mischa
11:31:37 <sandro> zakim, who is talking?
11:31:40 <mischat> Mischa, Pierre, Ian, Andy, Richard, NickH, Ivan, Steve, Danbri, Yves
11:31:43 <AndyS> scribenick: mischat
11:31:49 <Zakim> sandro, listening for 10 seconds I heard sound from the following: ??P4 (77%)
11:31:57 <ww> zakim, remind me of the telephone number please
11:31:57 <Zakim> I don't understand 'remind me of the telephone number', ww
11:32:05 <sandro> zakim, who is on the call?
11:32:05 <Zakim> On the phone I see AZ, MIT_Meeting_Room, Peter_Patel-Schneider, ??P4
11:32:09 <AndyS> We're trying to sort the positioning out now
11:32:10 <davidwood> zakim, code?
11:32:10 <Zakim> the conference code is 733294 (tel:+1.617.761.6200, davidwood
11:32:12 <sandro> Zakim, what is the code?
11:32:13 <Zakim> the conference code is 733294 (tel:+1.617.761.6200, sandro
11:32:35 <LeeF> LeeF has joined #rdf-wg
11:32:36 <danbri> zakim, who is speaking?
11:32:47 <sandro> zakim, ??P4 is BBC_Meeting_Room
11:32:47 <Zakim> +BBC_Meeting_Room; got it
11:32:49 <Zakim> +??P2
11:32:50 <Zakim> danbri, listening for 10 seconds I heard sound from the following: AZ (34%), ??P4 (64%)
11:32:56 <mischat> Guus: is proposing we jump to the first item of the agenda 
11:32:56 <ww> Zakim, ??P2 is ww
11:32:56 <Zakim> +ww; got it
11:33:12 <danbri> it's hearing noise from AZ
11:33:27 <danbri> AZ, can we mute you? you can unmute via bot here
11:33:30 <mischat> can we mute AZ or is that just rude?
11:33:32 <danbri> zakim, mute AZ
11:33:32 <Zakim> AZ should now be muted
11:33:36 <AZ> Zakim, mute me
11:33:36 <Zakim> AZ was already muted, AZ
11:33:37 <ww> zakim, mute me
11:33:37 <Zakim> ww should now be muted
11:33:56 <AZ> strange, my phone was muted already
11:34:02 <gavinc> Time for POTS!
11:34:58 <Zakim> -BBC_Meeting_Room
11:35:00 <ww> even post is voip these days :)
11:35:04 <iand> danbri spending most of this meeting being tied to his chair by power cables
11:35:19 <Zakim> +??P4
11:35:29 <cygri> zakim, ??P4 is BBC_Meeting_Room
11:35:29 <Zakim> +BBC_Meeting_Room; got it
11:36:08 <mischat> Guus: move to the first item of the agenda, the naming issue
11:36:23 <pchampin>
11:36:32 <pfps> it would be nice if the agenda had pointers to the relevant information.
11:36:33 <danbri> zakim, BBC_Meeting_Room holds mischat, Guus, danbri, yvesr, pchampin, swh, ivan, cygri, iand, andys
11:36:33 <Zakim> +mischat, Guus, danbri, yvesr, pchampin, swh, ivan, cygri, iand, andys; got it
11:36:45 <AndyS>
11:36:54 <sandro> sandro has changed the topic to: Oct 12 --
11:36:59 <danbri> zakim, BBC_Meeting_Room also holds NickH
11:36:59 <Zakim> +NickH; got it
11:37:01 <mischat> Guus: first item to discuss and decide on teminology
11:37:17 <mischat> Guus: based on sandro's g* teminology
11:37:26 <mischat> Guus: gbox == graph container 
11:37:35 <mischat> Guus: gsnap == graph or graph set 
11:37:45 <mischat> Guus: gtext == graph serialisation 
11:37:49 <sandro> q+
11:37:52 <LeeF> "graph set" is misleading because it sounds like a bunch of graphs
11:38:03 <mischat> … so are these a good place to start?
11:38:15 <mischat> sandro: doesn't remember us talking about a graph set 
11:39:16 <mischat> ivan: can we use the queue, as I am scribing from here
11:39:25 <davidwood> q+ to summarize MIT discussion
11:39:32 <cygri> q+ to propose to drop g-text from the discussion, it doesn't seem to be necessary
11:39:32 <mischat> sandro: didn't like the term graph-set, and i think the rest of the terms are far
11:39:52 <mischat> sandro: we should use the g* terminology informally for the time being
11:40:01 <ivan> +1 to Sandro
11:40:01 <Guus> q+
11:40:06 <ivan> ack sandro 
11:40:11 <mischat> for the public working set we should use the Guus proposed graph terminology 
11:40:19 <danbri> ack davidwood
11:40:19 <Zakim> davidwood, you wanted to summarize MIT discussion
11:40:23 <mischat> davidwood: had a private conversation with LeeF 
11:40:27 <sandro> sandro: Let's keep using g-* terms if they seem useful, but "graph set" is bad.
11:40:53 <sandro> david: "graph" itself is too ambiguous.
11:40:55 <mischat> davidwood: LeeF proposed it graph snapshot, the idea of using graph for gsnap could be an issue
11:40:59 <mischat> as it is too ambitious 
11:41:09 <danbri> I can't find much on g-snap, except 
11:41:18 <iand> terminology summary proposal was at
11:41:34 <danbri> sorry I meant - can't find much on graph set
11:41:40 <gavinc> Turtle needs to talk about graph seralizations 
11:41:43 <mischat> cygri: g-snap and g-box pop up a lot, but the g-text term doesn't pop up lots
11:41:47 <davidwood> There was an earlier proposal to drop g-text.  +1 to cygri.
11:41:56 <sandro> +1 cygri dropping "g-text" and just using "graph serialization"
11:41:56 <mischat> so we might not need an official term for it 
11:41:58 <cygri> ack me
11:41:58 <Zakim> cygri, you wanted to propose to drop g-text from the discussion, it doesn't seem to be necessary
11:42:20 <sandro> q?
11:42:28 <davidwood> If we need a term for Turtle, we can always create a term for g-text at that time.
11:42:31 <ivan> ack guus
11:42:36 <mischat> Guus: thinks that graph-set is poor, and gnap-snapshot is a bit geeky
11:42:41 <danbri> "graph dump?" or has unpleasant associations?
11:42:43 <danbri> q?
11:42:58 <gavinc> Is anyone keen on "graph set"?
11:43:21 <cygri> +1 to ask whether anyone wants to change the term “RDF graph” from Concepts
11:43:22 <sandro> +1 "graph set" sounds a lot like a set of graphs.
11:43:24 <pchampin> to me "graph set" also sounds like "a set of graphs"
11:43:28 <danbri> 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 <mischat> Guus:  requirement for the naming is that they match concepts which new people coming into RDF must be easy to understand 
11:43:38 <cygri> q+ to ask whether anyone wants to change the term “RDF graph” from Concepts
11:43:40 <davidwood> "graph version"?
11:43:47 <cygri> ack me
11:43:47 <Zakim> cygri, you wanted to ask whether anyone wants to change the term “RDF graph” from Concepts
11:43:48 <LeeF> 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 <mischat> Guus: graph set is a bit geeky, and might lead people to think that it is a "collection of graphs"
11:43:57 <tomayac> tomayac has joined #rdf-wg
11:43:57 <danbri> q+ to suggest Graph Image (like a picture of frozen snapshot, notion ... same as machine images, .iso etc)
11:44:10 <AZ> why not "RDF graph" as in all Sem Web specs?
11:44:20 <ivan> g+
11:44:22 <ivan> q+
11:44:33 <AZ> "graph" is totally ambiguous but "RDF graph" is well defined
11:44:56 <mischat> 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 <ivan> ack danbri 
11:44:59 <Zakim> danbri, you wanted to suggest Graph Image (like a picture of frozen snapshot, notion ... same as machine images, .iso etc)
11:45:02 <davidwood> Is it? Or is it equally ambiguous
11:45:12 <mischat> danbri: suggest "RDF image" as a term for g-snap
11:45:20 <danbri> ack me
11:45:20 <sandro> "Image" is okay, but not as good as "snapshop", for me.
11:45:23 <mischat> danbri: the term image, as in something which doesn't change
11:45:28 <davidwood> concur
11:45:36 <davidwood> (with Sandro)
11:45:38 <iand> i like davidwood's "graph version" 
11:45:41 <pfps> +1 to ivan
11:45:44 <mischat> ivan: we should try to use the term "graph" consistently for the g-snap
11:45:49 <danbri> graph version works for me
11:46:13 <cygri> +1 to ivan
11:46:17 <mischat> Guus: this would make the smallest change to the documents 
11:46:18 <danbri> i might try the 'image' metaphor in supporting materials. people mostly will just use 'graph' and be vague, whatever we decide.
11:46:19 <sandro> strawpoll between "RDF Graph", "Graph Snapshot", and "Graph Version" ?
11:46:29 <davidwood> -1 to Ivan (sorry).  We really need to be unambiguous.
11:47:01 <mischat> Guus: by default we should use the RDF graph to mean the g-snap
11:47:02 <davidwood> q?
11:47:15 <ivan> q?
11:47:18 <ivan> ack ivan
11:47:39 <cygri> q+
11:47:44 <zwu2> zwu2 has joined #rdf-wg
11:47:57 <mischat> Guus: graph serialisation and graph container, are we happy with this?
11:48:10 <mischat> Guus: is all the discussion around g-snap then right?
11:48:32 <mischat> cygri: davidwood are suggesting we change the term "graph" in the RDF concepts 
11:48:34 <mischat> ?
11:48:42 <AZ> -1 to rename "RDF graph"
11:48:43 <mischat> cygri: as per your "-1" early
11:49:08 <davidwood> 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 <mischat> 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 <gavinc> Can we write the question in IRC?
11:49:42 <mischat> Guus: keeping it is as, RDF graph for g-snap?
11:49:48 <ivan> +1
11:50:02 <cygri> +1
11:50:03 <swh> +1
11:50:04 <pchampin> +1
11:50:07 <davidwood> -1
11:50:10 <gavinc> -0
11:50:10 <mischat> +1
11:50:13 <tomayac> =1
11:50:15 <sandro> 0 very conflicted
11:50:15 <yvesr> +1
11:50:17 <AndyS> Strawpoll --  g-snap ==> RDF graph
11:50:17 <iand> +1
11:50:18 <zwu2> +1
11:50:21 <AlexHall> +1
11:50:25 <AZ> +1
11:50:26 <AndyS> +1
11:50:31 <tomayac> +1 (fscking US keyboard)
11:50:33 <danbri> +1
11:50:34 <AZ> (and banish the use of "graph" alone, "graph" != "RDF graph")
11:50:36 <pfps> +1
11:50:39 <LeeF> 0
11:50:59 <tlebo> q+
11:51:02 <pchampin> q+
11:51:03 <cygri> ack me
11:51:07 <yvesr> i guess it just needs clarification
11:51:13 <AZ> q+
11:51:14 <iand> q+
11:51:25 <mischat> 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 <gavinc> WE might know that, my -0 is that I'm not sure that anyone else will be clear about that.
11:51:48 <swh> +1
11:51:48 <iand> q-
11:51:52 <swh> q+
11:51:57 <AZ> zakim, unmute me
11:51:57 <Zakim> AZ should no longer be muted
11:52:12 <tlebo> +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 <pfps> -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 <tlebo> q?
11:52:17 <mischat> 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 <Guus> q?
11:52:22 <iand> +1 to pfps
11:52:24 <cygri> +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> Souri has joined #RDF-WG
11:52:36 <mischat> Guus: we would be making the term "RDF Graph" less ambiguous 
11:53:02 <pfps> +1 to tlebo
11:53:04 <tlebo> q-
11:53:07 <ivan> ack tlebo 
11:53:10 <ivan> ack pchampin 
11:53:14 <AZ> +1 tlebo
11:53:17 <mischat> tlebo: by fixing terms for the other two terms, would make it term graph == g-snap
11:53:20 <danbri> do all these definitions have identity conditions for the things they're naming?
11:53:23 <AZ> q-
11:53:25 <sandro> tlebo: If we have "Graph Container" and "Graph Serialization", then "Graph" becomes clearer, and renaming it would be a problem.
11:53:47 <yvesr> q?
11:53:49 <gavinc> Where "Graph" is "RDF Graph" yes?
11:53:53 <davidwood> 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 <ivan> ack swh 
11:54:04 <tlebo> yes, where "Graph" becomes "RDF Graph"
11:54:09 <mischat> 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 <AlexHall> q+
11:54:33 <mischat> swh: said that the term graph hasn't really hurt anyone in practice 
11:54:39 <mischat> davidwood: suggests that we move on 
11:54:50 <AZ> g-snaps should be "RDF Graph" not "Graph"
11:55:06 <sandro> 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 <mischat> Guus: resolution In our documents we will use the term RDF Graph for notion of the g-snap
11:55:36 <sandro> +1
11:55:41 <davidwood> 0
11:55:41 <mischat> Guus: any objections to the proposal 
11:55:41 <pchampin> +1
11:55:42 <Souri> +1
11:55:43 <pfps> +1
11:55:44 <iand> +1
11:55:45 <AZ> +1
11:55:46 <sandro> (with a little hesitation, but... it's okay.)
11:55:46 <yvesr> +1
11:55:48 <mischat> Guus:  any +1's
11:55:48 <cygri> -0. still not sure about graph container
11:55:48 <zwu2> +1
11:55:52 <tomayac> +1
11:55:55 <ww> 0+
11:55:56 <ivan> +1
11:56:01 <mischat> Guus:  thanks for the first resolution 
11:56:01 <gavinc> -0 graph container vs. dataset seems a bit confused
11:56:01 <yvesr> me :)
11:56:05 <sandro> 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 <AlexHall> q-
11:56:35 <mischat> Guus: we just won on numbers of hours chatting about graphs :)
11:56:56 <mischat> Guus: topic : named graphs discussion 
11:57:28 <mischat> Guus: we have 3 major contributions here Richard, Tim, and who … 
11:57:42 <tlebo>
11:57:45 <mischat> Guus: tlebo as you are the guest, please go ahead and describe your pro posable 
11:57:53 <ivan> s/who/Sandro/
11:58:16 <mischat> tlebo: ^^ developing a method for describing different views of the same events 
11:58:35 <mischat> tlebo: OWL ontology, which uses RDF to make assertions about the world
11:58:53 <mischat> tlebo: we will have to manage chunks of this knowledge using named graphs
11:58:55 <sandro> topic: Named Graphs (?)
11:59:28 <mischat> davidwood: the provenance DM has just been put into FPWD
12:00:05 <mischat> davidwood: what is the relationship between this document and the owl provenance DM?
12:00:50 <mischat> tlebo: we are using named graphs to manipulate statements from different sources 
12:01:07 <Guus> q?
12:01:35 <mischat> 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 <mischat> Guus: found the statement at the beginning defining what a named graph is 
12:02:20 <davidwood> Is Tim's (Jeremy's) "named graph" a g-snap?
12:02:25 <tlebo> "sandro's document"?
12:02:27 <sandro>
12:02:32 <ww> 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 <mischat> Guus: you state in one of these assertions is that the named-graph is global 
12:02:37 <sandro> q+
12:03:00 <davidwood> Similarly, is the "global RDF graph" a g-box?
12:03:01 <mischat> Guus: these named graphs are more like files, more like g-boxs
12:03:25 <mischat> tlebo: could adopt of new terminology after this meeting
12:03:52 <mischat> sandro: tlebo's document doesn't assume global naming, it assumes local naming 
12:03:52 <danbri> 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 <sandro> q-
12:04:49 <mischat> Guus: doesn't understand the statement "Named graphs let you specify a subset of the "global" RDF graph."
12:05:14 <danbri> q?
12:05:15 <mischat> sandro: in our current world, you need a sparql-endpoint URI and a … (sorry sandro ?)
12:05:24 <ivan> ack danbri 
12:05:24 <Zakim> 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 <Zakim> ... imaginable? Full of contradictions etc?
12:05:35 <mischat> 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 <mischat> danbri: thinks that is more sensible in a SPARQL context not the RDF one 
12:06:12 <sandro> 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 <mischat> davidwood: it sounds like a top-down approach
12:06:46 <Souri> q+
12:06:46 <Guus> q?
12:06:53 <mischat> tlebo: we are talking about a "RDF consumer" based approach 
12:08:22 <ww> +1
12:08:27 <mischat> 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 <danbri> blah blah pluralism blah
12:08:37 <gavinc> Named graphs are about decentrializations and pluralism 
12:08:40 <cygri> +1 to the "blah blah" part
12:08:43 <ivan> ack Souri 
12:08:47 <danbri> 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 <mischat> danbri: asked please do not go down a path of massive giant graph
12:09:30 <mischat> Souri: in the triples-store world, you need to definite the sparql endpoint URL and a graph name. 
12:09:35 <danbri> 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 <Guus> q?
12:09:56 <yvesr> mischat: davidwood 
12:10:12 <danbri> (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 <sandro> that's tlebo
12:10:51 <mischat> Guus: any more questions for tim?
12:11:06 <ivan> zakim, BBC_Meeting_Room also has Thomas
12:11:06 <Zakim> +Thomas; got it
12:11:16 <mischat> Guus: please sandro go through your email 
12:11:28 <tlebo> tlebo has joined #rdf-wg
12:11:35 <sandro>
12:12:00 <mischat> sandro: has been thinking about how to make progress on graphs, finds the subject overwhelming 
12:12:02 <AndyS> AndyS has joined #rdf-wg
12:12:19 <mischat> sandro: at a high-level the above document should capture our goals ^^
12:12:30 <mischat> sandro:
12:12:57 <mischat> sandro: 3 difference things we need to do 1. come up with syntaxes for conveying datasets 
12:13:17 <mischat> sandro: trig being the big contender, and nquads is there too 
12:13:34 <mischat> … the 2nd area, is about vocabularies about conveying datasets 
12:13:48 <gavinc> Graph Seralizations Strawman:
12:14:18 <mischat> sandro: 1 is datatypes for documents, 2 plain or RDF strings, 3 reification vocabulary 
12:14:37 <mischat> ivan: doesn't understand the difference between 2.1 and 2.2
12:14:49 <davidwood> q+ to ask how Sandro's proposal relates to the way graphs are named in some currently implemented RDF databases.
12:15:01 <AndyS> 2.1 is "<s><p><o>"^^rdf:turtle
12:15:07 <cygri> :G1 owl:sameAs ":s :p :o"^^rdf:Turtle
12:15:22 <cygri> :G1 rdf:turtleSerialization ":s :p :o"
12:15:23 <mischat> 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 <danbri> do we have datatype URI conventions for Mime types yet? eg. foo:application/rdf+xml ?
12:15:57 <mischat> sandro: the three ways above do not require any change to syntax 
12:16:22 <mischat> Guus: are these an alternative for things in 1
12:17:01 <gavinc> danbri, don't I wish
12:17:06 <mischat> sandro: we could do both, but not necessary 
12:17:06 <mischat> Guus: we could have a stawpoll on this later 
12:17:06 <mischat> sandro: too early for a resolution 
12:17:09 <danbri> (has anyone stress-tested RDF stores with multi-gigabyte string literals?)
12:17:35 <gavinc> danbari, yes, they all broke horrigly with even megabyte size literals
12:17:36 <mischat> 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 <ww> 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 <AndyS>   [ignore SPARQL "FROM" and "FROM NAMED"]  +1 and sort out later
12:18:13 <mischat> sandro: i.e. what are you supposed to do when you get a file with a default graph for example
12:18:36 <cygri> q+ to ask what the association between URIs and resources in plain RDF is in Sandro's taxonomy
12:18:46 <danbri> re 2.1. the latest I found from TAG is this ...debate still between new URI scheme vs http://-prefixed names
12:18:46 <davidwood> 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 <mischat> sandro: another big question, are we naming graphs on a global scale 
12:20:08 <mischat> 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 <mischat> sandro: this that all triplestore are agnostic to the semantics of the named graphs 
12:21:14 <mischat> sandro: so if you blindly interact with datasets across the web, then this isn't an issue 
12:21:32 <AndyS> HTTP GET /
12:21:46 <mischat> davidwood: thinks that the SPARQL service verb is going this way, where there is automated consumption of datasets on the web 
12:21:58 <AndyS> HTTP GET http://example/dataset?query=...
12:21:59 <swh> I'm not sure that SPARQL stores are semantics-neutral
12:22:01 <gavinc> q+
12:22:06 <mischat> davidwood: doesn't think that the semantics and the implementations are that far apart 
12:22:10 <sandro> q?
12:22:13 <cygri> ack me
12:22:13 <Zakim> cygri, you wanted to ask what the association between URIs and resources in plain RDF is in Sandro's taxonomy
12:22:14 <ivan> ack davidwood 
12:22:17 <swh> at the very least it effects the optimisers
12:22:17 <Zakim> 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 <mischat> 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 <mischat> cygri: where does this association fall in your taxonomy of options
12:23:53 <mischat> sandro: the URI is naming a person globally, this should be a 3.1 thing, from sandro's breakdown 
12:24:49 <mischat> 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 <mischat> cygri: topics of global naming 
12:25:22 <Guus> q?
12:25:23 <mischat> sandro: points to the discussion on the mailing list between richard, pat, and peter 
12:26:12 <pfps> 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 <Guus> [is part of the "Semantics" here not really "Pragmatics"?]
12:26:59 <mischat> sandro: would like to be able to tell developers how to write code which can talk to other peoples datasets 
12:27:05 <mischat> 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 <AndyS> 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 <mischat> gavinc: is not sure we need perfect semantics 
12:27:32 <mischat> gavinc: doesn't think this lack of semantics has hurt anybody
12:27:57 <Guus> q?
12:28:05 <mischat> sandro: what gavinc is talking about was captured in 3.3.2 
12:28:06 <Guus> ack gavinc
12:28:13 <mischat> sandro:
12:28:24 <zwu2> q+
12:28:29 <sandro> q?
12:28:30 <LeeF> q+ to make distinction between what an implementation does and what a user of an implementation does
12:28:45 <mischat> davidwood: there is a social construct which is disjoint from the syntax. this is a social convention :)
12:29:02 <tlebo> q?
12:29:02 <cygri> +1 to davidwood
12:29:08 <ivan> q?
12:29:18 <ivan> azk zwu
12:29:23 <ivan> ack zwu
12:29:23 <mischat> Guus: any more questions for sandro 
12:29:27 <cygri> davidwood: don't want to stifle innovation by specifying it too tightly
12:29:38 <mischat> zwu2: what are the confusions which you seeing ?
12:30:27 <cygri> q+
12:30:41 <mischat> 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 <ivan> ack LeeF 
12:30:50 <Zakim> LeeF, you wanted to make distinction between what an implementation does and what a user of an implementation does
12:31:00 <tlebo> 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 <mischat> LeeF: /me can't understand u 
12:31:49 <cygri> +1 to thinking about conformance
12:32:40 <mischat> 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 <sandro> I think it's the person using the API....
12:32:56 <AndyS> 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 <Guus> q?
12:33:52 <mischat> LeeF: are there test cases which test the semantics when talking about conforming datasets 
12:34:25 <ivan> ack cygri 
12:35:11 <danbri> cygri: you want system not to have to guess what kind of graph layout we're finding in some store
12:35:18 <Guus> q+
12:35:22 <davidwood> q+ to mention interoperability as the place semantics meet implementations
12:35:26 <mischat> 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 <AlexHall> +1 - how RDF gets associated with a graph URI is different from what that association means
12:35:44 <gavinc> Seems like an issue for VoID
12:35:51 <tlebo> +1 to documenting dataset patterns that people have used (like those Gavin mentioned).
12:35:55 <mischat> cygri: thinks this is about patterns when using/interacting with datasets. This shouldn't touch on the semantics of RDF 
12:36:01 <pchampin> q+
12:36:04 <LeeF> +1 to cygri
12:36:06 <ivan> ack Guus 
12:36:08 <danbri> +1 for documenting patterns over proscribing one notion 
12:36:19 <zwu2> +1 to cygri
12:36:22 <mischat> 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 <yvesr> +1
12:36:39 <ww> AndyS: that's why we have compilers, which have something solid to build upon. just need good tools.
12:36:46 <gavinc> I don't think it's a "can't" define semantics I'd say shouldn't ;)
12:37:00 <mischat> Guus: is asking cygri if he would prefer to document pragmatics instead of defining semantics 
12:37:22 <mischat> Guus:  would like to provide guides and not limit the practice 
12:37:30 <AZ> +1 guus
12:37:40 <AndyS> ww - that was the reif argument ... didn't work out (not sure why)  Ditto RDF lists.
12:37:57 <tlebo> example dataset organization: source vs. content based graph organization
12:37:59 <iand> guus: saying we want the widest semantics that we can agree on
12:38:01 <ivan> ack davidwood 
12:38:01 <Zakim> davidwood, you wanted to mention interoperability as the place semantics meet implementations
12:38:10 <cygri> +1 to guus
12:38:25 <danbri> 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 <danbri> (cygri leaves room)
12:39:04 <AndyS> ==> (the room leaves cygri)
12:39:26 <Guus> q?
12:39:28 <mischat> 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 <ivan> ack pchampin 
12:39:59 <mischat> pchampin: has a question for cygri 
12:40:34 <danbri> q+ to suggest this is a classic layer-of-indirection solution to avoid committee design
12:40:36 <mischat> pchampin: thinks that semantics is exactly what we need to define interoperability. And is not comfortable with cygri's distinction 
12:40:42 <sandro> q?
12:40:54 <sandro> q+
12:40:57 <danbri> q?
12:41:08 <sandro> q-
12:41:32 <tlebo> q+ to ask silly question about using fragment identifiers to resolve "local vs. global" graph names.
12:41:35 <sandro> "Patterns of Use" vs "Semantics".
12:41:36 <mischat> pchampin: is not comfortable your distinction between patterns of use and semantics 
12:42:09 <Guus> any volunteers for taking over scribing?
12:42:39 <AndyS> scribe AndyS
12:42:40 <AndyS> scribenick: AndyS
12:42:47 <AndyS> cygri: semantics are complicated
12:43:23 <sandro> +1 break at top of hour
12:43:34 <tlebo> <> { } is "the global one", # { } is "the local one" .... (or  _ )
12:43:37 <AndyS> q?
12:43:42 <AndyS> ack danbri
12:43:42 <Zakim> danbri, you wanted to suggest this is a classic layer-of-indirection solution to avoid committee design
12:43:44 <ivan> ack danbri 
12:44:30 <AndyS> danbri: practical vs semantics - maybe more have an indirection point - standards avoid impossible agreement decision
12:44:37 <sandro> danbri: cygri is trying to put in an extensibility hook, since we can't agree how to limit things now.
12:44:48 <sandro> q+
12:44:56 <AndyS> ... makes practical in WG time.
12:44:56 <AndyS> q+
12:45:32 <AndyS> guus: if we could agree, shoudl we formalize local or global naming at least? 
12:45:47 <AndyS> cygri: yes if not too much pain
12:45:50 <Guus> q?
12:45:58 <ivan> ack tlebo 
12:45:58 <Zakim> tlebo, you wanted to ask silly question about using fragment identifiers to resolve "local vs. global" graph names.
12:46:16 <AndyS> tlebo: use cases for both local and global
12:46:41 <AndyS> ... different syntaxes e.g. URI frag
12:46:42 <AlexHall> local = mint your own (UUID-style) URI
12:46:58 <gavinc> local = lie about being global 
12:47:06 <mischat> ack sandro 
12:47:06 <danbri> 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 <AndyS> guus: issue is if/should we stds that?
12:48:21 <tlebo> @danbri, I'd say that <> {} would be *wrong*, while # would be perfectly valid in anyone's dataset.
12:48:54 <AndyS> sandro: tag example: local g-snap : predicate + graph literal could RDF assertions to show association.
12:49:20 <pchampin> q+
12:49:40 <AndyS> ack me
12:49:40 <ivan> ack AndyS 
12:49:53 <cygri> q+ to comment on the practical difficulty of defining semantics for this
12:50:21 <ivan> ack pchampin 
12:51:07 <Guus> andy: use case for immutable graph container
12:51:21 <AndyS> 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 <ivan> q+
12:52:04 <AndyS> sandro: yes but <t1> names a web resource and representation is the graph (indirection again?)
12:52:23 <yvesr> we shouldn't get into the semantics of N3 predicates - it's just the extension mechanism that is relevant imho
12:52:23 <iand> aren't graphs in sparql named with resources rather than URIs-as-strings?
12:52:38 <ivan> q-
12:53:02 <AndyS> pchampin: one concern on difficult to define semantics : we seem to talk about the IRI itself
12:53:03 <cygri> iand, no, the spec says "pair of IRI and graph" – nothing about resources
12:53:15 <ivan> ack cygri 
12:53:15 <Zakim> cygri, you wanted to comment on the practical difficulty of defining semantics for this
12:53:18 <AndyS> q?
12:54:46 <AndyS> 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 <AndyS> .... and we are not there yet.  One example (sandro) and we don't get further.
12:55:45 <AndyS> guus: Test case (triples) examples is a way to do that 
12:55:50 <sandro> +1 cygri we have gap between requirements on the semantics and the specification of the semantics
12:55:50 <AndyS> cygri: yes
12:56:05 <AndyS> q?
12:56:18 <davidwood1> davidwood1 has joined #rdf-wg
12:56:29 <sandro> restart at 15 after...?
12:56:34 <iand> yes
12:56:58 <AndyS> guus: break now for 15 mins - then review situation.  We will discuss options from Sandros's list
12:57:08 <sandro> we can hear you well, yes.
12:57:09 <ivan> zakim, who is here?
12:57:09 <Zakim> On the phone I see AZ, MIT_Meeting_Room, Peter_Patel-Schneider, ww (muted), BBC_Meeting_Room
12:57:11 <Zakim> MIT_Meeting_Room has davidwood, gavinc, zwu2, tlebo, AlexHall, sandro, Souri, Scott_Bauer, LeeF
12:57:14 <Zakim> BBC_Meeting_Room has mischat, Guus, danbri, yvesr, pchampin, swh, ivan, cygri, iand, andys, NickH, Thomas
12:57:17 <Zakim> 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 <Zakim> ... ivan, pchampin, ww, yvesr, manu, NickH, trackbot, manu1, sandro
12:57:33 <sandro> Yeah -- play with video maybe, but keep the audio as-is.
12:57:42 <sandro> nah --- ignore Zakim.
12:57:49 <sandro> update the wiki page!
12:58:12 <sandro> yep, 9:15 ET
13:06:42 <Zakim> -AZ
13:07:41 <Zakim> +AZ
13:12:57 <MacTed> MacTed has joined #rdf-wg
13:18:02 <iand> iand has joined #rdf-wg
13:18:37 <Guus> reconvene?
13:20:45 <yvesr> sandro, do you get video from us
13:20:46 <mischat> can people in MIT able to see us ? davidwood gavinc or anyone ?
13:20:47 <yvesr> ?
13:21:48 <davidwood> no
13:21:48 <gavinc> for values of see that are not very good
13:21:58 <yvesr> still not?
13:22:08 <gavinc> you still have audio
13:22:12 <davidwood> no
13:22:28 <yvesr> we see you well
13:22:37 <tlebo> tlebo has joined #rdf-wg
13:22:38 <gavinc> and video is gone
13:22:41 <yvesr> looks like xmeeting is sending very little traffic to you
13:23:19 <LeeF> LeeF has joined #rdf-wg
13:24:24 <AndyS> reconvene
13:24:50 <sandro> we see you!!!!!
13:25:02 <yvesr> yay!!!
13:25:08 <AndyS> !!!!!
13:25:22 <sandro> we heard that laugh
13:25:30 <sandro> no, we do, now.
13:26:07 <AndyS> guus: sandro, we stopped the options discussion: continue?
13:26:59 <pfps> Pat and I can't help to formalize something that we don't understand
13:27:02 <AndyS> sandro: agree with cygri of disconnect between detail/semantics and approaches discussions
13:27:37 <AndyS> davidwood: suggest start with 5 UCs (the A priority)
13:27:49 <gavinc> the 5 use cases
13:27:52 <gavinc> 1.1 (A PRIORITY) Slicing datasets according to multiple dimensions
13:27:54 <gavinc> 1.3 (A PRIORITY) Graph Changes Over Time
13:27:55 <gavinc> 1.5 (A PRIORITY) Exchanging the contents of RDF stores
13:27:57 <gavinc> 4.9 (A PRIORITY) Trust Web Opinions
13:27:58 <gavinc> 5.2 (A PRIORITY) OWL's “Ontology Documents”
13:28:00 <AndyS> sandro: understand how to implement
13:28:55 <AndyS> 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 <AndyS> sandro: test cases => formal semantics
13:29:46 <AndyS> guus: one possibility is we conclude can't get there and instead intro graph names not more
13:30:12 <AndyS> yvesr to talk about graph slicing
13:30:41 <cygri>
13:30:41 <yvesr>
13:30:41 <iand>
13:30:46 <davidwood>
13:30:49 <pchampin>
13:31:08 <AndyS> BBC want central RDF store  then need to have slices (per product) 
13:31:26 <AndyS> yvesr: product is e.g. /programmes, /music
13:31:51 <AndyS> ... need to slice by resources as well for fast update: 
13:31:57 <cygri> q+ to ask whether that's like "redundant stored data" or "views"
13:32:01 <AndyS> ... found stores good at whole graph ops
13:32:22 <gavinc> +infinity to updating small bits using graph replacement rather then UPDATE
13:32:47 <davidwood> +1 to Gavin
13:32:51 <AndyS> ... e.g. Eastenders (a TV program(me)) chnage => change whole graph 
13:33:14 <iand> this sounds similar to 1.7.1 editing datasets at the granulaity of the graph 
13:33:35 <cygri> ack me
13:33:35 <Zakim> cygri, you wanted to ask whether that's like "redundant stored data" or "views"
13:33:39 <AndyS> cygri: is a view computed on the fly or duplicated data?
13:34:00 <AndyS> yvesr: duplicated
13:34:32 <AndyS> ... original UC was graphs in graphs because of overlaps of views
13:35:20 <AndyS> ... currently hierarchical: /programmes/Eastenders ==> fast operations
13:35:24 <Guus> q?
13:35:40 <davidwood> q+ to ask about non-heirarchical subgraphs
13:36:16 <AndyS> 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 <ivan> ack davidwood 
13:36:22 <Zakim> davidwood, you wanted to ask about non-heirarchical subgraphs
13:36:29 <davidwood>
13:36:33 <AndyS> yvesr: yes - we'd like that also access control
13:36:35 <davidwood>  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 <sandro> davidwood: Let's talk about non-hierachical subgraph relationships.
13:38:00 <pchampin> q+ to ask yves another question about hierarchical
13:38:20 <AndyS> davidwood: if we had a looser notion of subgraph then we can do this (scribe??)
13:38:48 <AndyS> yvesr: currently two graphs can overlap in triples
13:38:51 <sandro> davidwood: subgraphs should have the freedom to overlap in terms of membership of their triples.
13:38:54 <pchampin> q-
13:39:08 <AndyS> guus: What mechanisms do we need?
13:39:21 <gavinc> +q to talk about implementations of this
13:39:21 <AndyS> ... name containers?
13:39:32 <sandro> guus: it sounds like the crucial thing here is to name containers
13:40:09 <mischat> mischat has joined #rdf-wg
13:40:11 <sandro> yvesr: You can check triple-by-triple to see if two graphs overlap.
13:40:13 <AndyS> yvesr: issues: (1) specification of strucures e.g. overlap Can check currently.  bNodes are "a bit more complicated"
13:40:43 <AndyS> ... (2) NG impl issue: good if split of triples : overlaps are duplication
13:40:45 <ivan> q+
13:40:46 <mischat> this seems like a SPARQL issue from my POV
13:40:46 <sandro> yvesr: There can be lots of duplication of information
13:40:49 <ivan> ack gavinc 
13:40:49 <Zakim> gavinc, you wanted to talk about implementations of this
13:40:54 <cygri> q+ to think out loud about “nested datasets”
13:41:50 <sandro> 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 <AndyS> gavinc: example - supergraphs defined by CONSTRUCT of subgraphs - stored as separate graph
13:42:01 <LeeF> 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 <LeeF> 2 datasets can share a graph
13:42:15 <LeeF> and we use the datasets as a way to handle higher-level manipulations
13:42:15 <sandro> gavin: None of these were based on semantic relationship -- the Construct queries defined the supergraphs.
13:42:38 <Guus> q?
13:42:42 <sandro> sandro: not really sub/super graph, but ... other graphs.
13:42:56 <sandro> gavin: No new triples created -- it was just re-grouping triples.
13:43:02 <AndyS> gavin: no new triples : CONSTRUCT is a method of grouping triples
13:43:14 <sandro> gavin: a fairly common pattern.
13:43:16 <AlexHall> 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 <Guus> ack invan
13:43:32 <Guus> ack ivan
13:43:35 <AlexHall> [set operations on other named graphs]
13:44:07 <sandro> q+ to answer
13:44:14 <AndyS> ivan: what can we do for you?
13:44:15 <cygri> q-
13:44:41 <sandro> q+ to say that "web semantics for datasets" would allow other folks to mix & match yvesr's data.
13:44:43 <AndyS> yvesr: not complete clear - loosely defined maybe better
13:44:57 <AndyS> ivan: is there a stronger semantics that (in a few years) woudl be better
13:45:12 <AndyS> yvesr: yes - eg. graph of things editors can change
13:45:25 <sandro> q?
13:45:30 <AndyS> ... whether this is big spec csost.
13:45:54 <AndyS> guus: Is this data mgt , rather than RDF change?
13:45:54 <davidwood> q+ re ISSUE-33
13:46:01 <sandro> issue-33?
13:46:01 <trackbot> ISSUE-33 -- Do we provide a way to refer to sub-graphs and/or individual triples? -- open
13:46:01 <trackbot>
13:46:16 <AndyS> ... (exploring)
13:46:19 <Guus> q?
13:46:20 <ivan> ack sandro 
13:46:20 <Zakim> 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 <AndyS> sandro: yvesr says "graph" for "graph container"
13:47:24 <cygri> trackbot: BEER on yvesr
13:47:24 <trackbot> Sorry, cygri, I don't understand 'trackbot: BEER on yvesr'. Please refer to for help
13:48:01 <AndyS> ... and my web semantic proposal woudl let mix and match deref via stable URL
13:48:21 <AndyS> ... build eco system
#13:48:21 <NickH> �[A7
13:48:22 <ivan> q?
13:48:25 <ivan> q?
13:48:30 <ivan> ack davidwood 
13:48:30 <Zakim> davidwood, you wanted to discuss ISSUE-33
13:48:41 <Guus> q?
13:48:45 <ivan> ISSUE-33?
13:48:45 <trackbot> ISSUE-33 -- Do we provide a way to refer to sub-graphs and/or individual triples? -- open
13:48:45 <trackbot>
13:48:54 <AndyS> davidwood: for BBC UC can we close issue-33?
13:49:54 <AndyS> ... contention is remove parent-child but let graphs exists and overlap we do not need subgraph specially
13:50:19 <Souri> q+ to suggest => :G     rdf:includes   :g1, :g2, :g3 .  (flexible grouping in RDF, not having to go to SPARQL)
13:50:22 <sandro> q?
13:50:34 <cygri> q+ to say that one doesn't preclude the other
13:50:39 <ivan> q+
13:50:39 <AndyS> ... looser defn of subgaph and graph membership can overlap then we benefit from no fixed hierarchy
13:50:45 <AndyS> ... and we can close issue-33
13:50:58 <sandro> 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> pfps has joined #rdf-wg
13:51:22 <AndyS> davidwood: proposal "no" to issue-33 by defn g* so subgraphs are possible.
13:51:32 <AndyS> ack souri
13:51:32 <Zakim> Souri, you wanted to suggest => :G     rdf:includes   :g1, :g2, :g3 .  (flexible grouping in RDF, not having to go to SPARQL)
13:51:32 <ivan> ack Souri
13:51:59 <davidwood> +1 to souri
13:52:15 <sandro> 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 <sandro> ... in the triplestore, G container is always the merge of the contents of G1, G2, etc.
13:52:44 <AndyS> souri, this is in RDF not SPARQL, then query graph G then snapshots G
13:52:47 <Zakim> +PatH
13:53:00 <cygri> ack me
13:53:00 <Zakim> cygri, you wanted to say that one doesn't preclude the other
13:53:01 <ivan> ack cygri 
13:54:24 <AndyS> cygri, two things: good things from arb overlap graphs but may still want to have "subgraph" explicit concpt
13:54:49 <ivan> ack ivan
13:54:50 <tlebo> 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 <AndyS> ... and UC wikidata talks about triples not graphs (was that right?)
13:55:09 <davidwood> Souri's formulation allows the creation of parent-child subgraphs as a degenerate case.  
13:55:20 <davidwood> Therefore, cyri's concern is handled.
13:55:35 <yvesr> 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 <sandro> q-
13:55:39 <AndyS> ivan: subset can be useful so don't see overlap covers subgraph need as is very useful.
13:56:02 <PatHayes> PatHayes has joined #rdf-wg
13:56:05 <AndyS> guus: what have we leant?
13:56:30 <AndyS> sandro: we need bnodes sharing - subgraphs
13:56:43 <AndyS> guus: gSnap senseof graph
13:56:53 <davidwood> tlebo, if you name a graph in a g-box and fill it with triples from a g-snap, then sure.
13:57:01 <cygri> sandro, bnode scope is orthogonal to subgraphs
13:57:07 <gavinc> bnode sharing clearly DOESN'T need subgraphs as bnodes can be amusingly shared in sparql datasets today ;)
13:57:30 <pchampin> q+ to ask a very basic question
13:57:47 <AndyS> yvesr: not sure operators useful - want to mark a triple as in bags.
13:58:07 <AndyS> ... graph as container
13:58:18 <davidwood> bnode sharing would be facilitated by naming g-snaps
13:58:21 <sandro> it is, cygri?   I thought bnodes were scoped to graphs.....
13:58:45 <AndyS> sandro - by syntax
13:58:53 <cygri> sandro, no. they are not scoped at all. bnode *identifiers* are scoped by document
13:59:03 <gavinc> +g to explain at least one "implementation" of bnode "sharing" between many graphs
13:59:08 <mischat> can't you achieve this with a SPARQL insert thing
13:59:11 <mischat> +1 Guus 
13:59:13 <AndyS> guus: do a lookup as to where it is?
13:59:25 <tlebo> q?
13:59:27 <gavinc> +q to explain at least one "implementation" of bnode "sharing" between many graphs
13:59:33 <AndyS> iand: name sets of triples?
13:59:36 <PatHayes> unfortunately at present RDF dos not scope bnodes at all, and sparql takes advantage of this.
13:59:48 <ivan> q?
13:59:52 <gavinc> +1000 PatHayes
13:59:56 <davidwood> named set of triples == named g-snap
14:00:02 <sandro> sorry, cygri -- yes, but I thought in Named Graphs bnodes were not allowed to be shared.
14:00:31 <cygri> sandro, the carroll et al paper might say that. sparql doesn't.
14:00:40 <AndyS> iand: if use name, what triples is it?
14:00:52 <ivan> q?
14:00:55 <AndyS> q+
14:00:55 <gavinc> the carroll et all paper didn't say that... at least not by my reading
14:01:03 <ivan> ack pchampin 
14:01:03 <Zakim> pchampin, you wanted to ask a very basic question
14:01:06 <gavinc> and it seems PatHayes at well
14:01:06 <PatHayes> no, the carroll +al paper does not address this bnode issue.
14:01:16 <cygri> gavinc, you might be right. i should re-read it
14:01:45 <gavinc> and given et all included PatHayes I'm going to agree with him
14:01:50 <AndyS> pchampin: do we have an accepted way to talk about graph containers?
14:02:03 <pchampin> pchampin: or RDF graphs (aka g-snap)
14:02:06 <AndyS> guus: we have consensus for this.
14:02:18 <ivan> q?
14:02:19 <sandro> +1 everyone seems to agree we need a way to name graph containers
14:02:36 <Souri> s/ et all / et al /
14:02:45 <iand> do any use cases require naming of graphs (g-snaps)
14:02:58 <LeeF> i share iand's question
14:02:58 <ivan> ack gavinc 
14:02:58 <Zakim> gavinc, you wanted to explain at least one "implementation" of bnode "sharing" between many graphs
14:03:04 <AndyS> path: must not confuse container and snap
14:03:13 <ivan> q/
14:03:15 <ivan> q?
14:03:31 <sandro> 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 <PatHayes> ok, sandro, sorry if ive been misreading you.
14:03:57 <davidwood> Propose to RESOLVE "we need a way to name graph containers"
14:04:13 <AndyS> gavinc: bnodes not scoped anywhere and impls use this.  skolemization round tripping possible.
14:04:24 <AndyS> ... may not be a good way.
14:04:51 <AndyS> sandro: trig, nq syntax.
14:04:57 <Guus> maybe we should state the consensus that, at the minimum, graph containers should have a naming mechanism
14:05:00 <iand> +1 to davidwood suggestion
14:05:01 <AndyS> gavinc: variations
14:05:19 <ivan> q?
14:05:20 <AndyS> path: I agree
14:05:24 <Guus> ... as a resolution
14:05:33 <sandro> gavin: We clearly need *some* standardization to allow people to transmit datasets where there are blank nodes shared between graphs.
14:05:47 <AndyS> davidwood: name gboxes ... propose resolution
14:06:59 <yvesr> having names for both snapshots and containers would be horribly confusing
14:07:36 <gavinc> eh, we already do and it's not that bad
14:07:44 <gavinc> and the names are the same ;)
14:07:49 <yvesr> :)
14:07:51 <PatHayes> yvesr, we are already in practice in this confusion.
14:08:04 <Souri> q+ (aside) to confirm (hopefully) that graph names cannot be bNodes (and must necessarily be IRIs)
14:08:24 <Souri> ack (aside)
14:08:24 <Zakim> (aside), you wanted to confirm (hopefully) that graph names cannot be bNodes (and must necessarily be IRIs)
14:08:34 <AndyS> guus: unclear "named graph"
14:08:34 <AndyS> cygri: no -  named graph snap
14:08:34 <AndyS> ... it's the formal def 
14:08:41 <AndyS> cygri: collection of named snapshots
14:08:45 <sandro> Doesn't RDF already support naming everything we can image?  :-)
14:08:53 <sandro> s/image/imagine/
14:08:56 <PatHayes> souri, yes. bnode is not a name. But a bnode can refer to anything that can be named.
14:09:00 <sandro> queue=
14:09:03 <gavinc> Souri, the named graph paper at least was happily clear that it was IRI not Resource (eg, no blank nodes)
14:09:04 <ivan> zakim, who is here?
14:09:04 <Zakim> On the phone I see MIT_Meeting_Room, Peter_Patel-Schneider, ww (muted), BBC_Meeting_Room, AZ, PatH
14:09:06 <Zakim> MIT_Meeting_Room has davidwood, gavinc, zwu2, tlebo, AlexHall, sandro, Souri, Scott_Bauer, LeeF
14:09:09 <Zakim> BBC_Meeting_Room has mischat, Guus, danbri, yvesr, pchampin, swh, ivan, cygri, iand, andys, NickH, Thomas
14:09:11 <Souri> q-
14:09:12 <Zakim> 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 <Zakim> ... swh, ivan, pchampin, yvesr, manu, NickH, trackbot, manu1, sandro
14:09:19 <Souri> q?
14:09:20 <AndyS> q+
14:09:24 <ivan> zakim, MIT_Meeting_Room also has Eric
14:09:24 <Zakim> +Eric; got it
14:10:00 <pchampin> scribe pchampin
14:10:02 <AndyS> q-
14:10:41 <danbri> does the bot need : prefix?
14:10:42 <danbri> scribenick: pchampin
14:11:05 <pchampin> pat: what I understood: we have IRIs refering to graph containers, and IRIs refering to graphs (snapshots)
14:11:27 <pchampin> ... is that IRI going to appear in any RDF triple? and refer to the graph in this way?
14:11:56 <pchampin> guus: that would make life easier
14:12:22 <cygri> q+
14:12:40 <gavinc> PatHayes: that would make life possible 
14:12:51 <pchampin> pat: to talk about a container changing over time, you need a programing language, which RDF is not
14:13:43 <pchampin> cygri: SPARQL is in last call; it already uses this notion of containers of graph; it is not a programming language
14:14:05 <pchampin> ... it is based on an abstract syntax: datasets
14:14:11 <AndyS> (SPARQL update -- graph store)
14:14:28 <pchampin> ... it does not have to become a part of RDF semantics
14:14:49 <tlebo> (where is g-box, g-snap, g-text defined?)
14:15:15 <iand> tlebo:
14:15:15 <AlexHall>
14:15:25 <pchampin> pat: I'm not suggesting that we should have this way of talking about boxes
14:16:06 <pchampin> ... if we have to incorporate notions of time dependency in the semantics, this will be a major change
14:16:18 <danbri> aside -- putting time and change pragmatics into semantics, seems like trying to teach flatlanders (per ) about the mythical 3rd dimension
14:16:28 <PatHayes> by 'programming language' I mean only that it presumes an underlying notion of state
14:16:39 <pchampin> cygri: I agree that I would not like to make this kind of change in RDF semantics
14:16:59 <sandro> q?
14:17:05 <Guus> q?
14:17:06 <cygri> ack
14:17:07 <tlebo> thanks, @iand
14:17:09 <ivan> ack cygri 
14:17:16 <sandro> q+
14:17:24 <ivan> ack sandro 
14:17:54 <ericP> ericP has joined #rdf-wg
14:18:31 <pchampin> sandro: we can probably leave time out of the semantics
14:18:41 <AlexHall> keep in mind, time is only one dimension over which the contents of a named g-box can change
14:18:46 <swh> time is far from the only variable
14:18:51 <pchampin> pat: that is, if we keep *dereferencing* out of the semantics too
14:19:04 <yvesr> +1 to swh 
14:19:40 <ivan> q?
14:19:44 <ww> ww has joined #rdf-wg
14:19:51 <ww> +1 to sandro
14:20:11 <pchampin> andy: there is a difference btw using dereferencing the LOD way, and recording it in the RDF semantics
14:20:38 <sandro> So, maybe there can be some consensus around talking about dereferencing, but not in the RDF Semantics.
14:20:55 <pchampin> guus: still trying to draw lessons from the BBC usecase
14:21:18 <pchampin> ... we need to put triples in different containers
14:21:31 <sandro> 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 <pchampin> ivan: and let the content of those containers overlap
14:21:51 <ivan> q?
14:22:24 <pchampin> cygri: the usecase requires shared bnodes between graphs (and containers)
14:22:26 <sandro> cygri: This use case involves bnodes being shared between Graph Containers.
14:22:37 <ericP> does it require bnode sharing? can't the graphs just entail each other?
14:22:54 <gavinc> 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> AndyS has joined #rdf-wg
14:23:14 <PatHayes> not require bnode sharing, but allow it.
14:23:17 <pchampin> steve: you could also say: if you are going to use this use case, then you *can't* use bnodes
14:23:24 <pchampin> yves: unfortunately, we do use bnodes
14:23:31 <sandro> .well-known/genid is the answer.   :-]
14:23:43 <swh> +1 to sandro :)
14:23:50 <gavinc> +sigh to sandro
14:23:57 <ericP> couldn't gsnap: { _:s1 <p1> <o1> } capture gbox: { _:s2 <p1> <o1> } ?
14:24:01 <cygri> q+
14:24:14 <cygri> q-
14:24:19 <yvesr> sandro, :)
14:24:22 <AndyS> sometimes you know its the same bnode -- additional information e.g. subgraph
14:24:31 <sandro> q?
14:24:40 <sandro>
14:24:45 <cygri> BBC_meeting_room is out of coffee :-(
14:24:50 <mischat>
14:24:59 <sandro> cygri, you can have some of ours.   We have lots left.
14:25:25 <mischat>
14:25:37 <pchampin> guus: let's switch to another usecase
14:25:41 <PatHayes> damn all your coffees, i havnt even had a shower yet.
14:25:43 <mischat> 5.2 5.2 (A PRIORITY) OWL's “Ontology Documents” 
14:25:47 <ivan>
14:25:50 <pchampin> gavin: 5.2 OWL ontology documents
14:25:52 <cygri> PatHayes too much information
14:25:59 <PatHayes> ;-
14:26:30 <pchampin> ... the general convention: you name the graph container with the ontology URI
14:28:05 <pchampin> ... the OWL ontology for Dublin Core exists on the web and you can deference it
14:28:33 <pchampin> {hard to scribe explaination}
14:28:46 <sandro> 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 <sandro> 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 <sandro> gavin: Almost every ontology editor and OWL reasoner does it.
14:29:00 <PatHayes> but why do you want to say this common uri is a name?
14:29:14 <pchampin> david: it's a nasty hack, but it's a good idea
14:29:26 <PatHayes> q+
14:29:51 <pchampin> 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 <iand> q+ 
14:30:01 <cygri>  owl:Ontology rdfs:subClassOf rdf:Graph?
14:30:04 <iand> q-
14:30:14 <pchampin> ... it would be good if, with content negociation, different versions could be served
14:30:25 <sandro> danbri: With FOAF, I always emails saying I should use DL, and they email me an OWL file.  
14:30:27 <AZ> gavin, it make me think of something I made a while ago:
14:30:30 <pchampin> ivan: every OWL ontology, DL or not-DL, seen with RDF glasses, is a graph
14:30:32 <iand> q+ to say there seems to be confusion between a namespace URI and an ontology URI
14:30:38 <sandro> ivan: Every ontology, DL or not, is an RDF graph.
14:30:41 <sandro> s/ont/OWL ont/
14:30:44 <pchampin> ... if you change the ontology, it is a different graph
14:30:52 <pchampin> q+ to answer ivan
14:31:10 <mischat> i agree with danbri content negotiation is what is missing here, and mime-types for the various OWL variants 
14:31:28 <pchampin> guus: gavin, what is the requirement here?
14:31:33 <davidwood> 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 <cygri> q+
14:31:43 <pchampin> gavin: the problem is how owl:imports interacts with named graphs
14:32:02 <pchampin> ... depending how you implement it, different weird things happen
14:32:07 <AlexHall> q+
14:32:19 <mischat> is this an RDF issue?
14:32:33 <swh> "owl:" means it's OWL's problem :)
14:32:38 <pchampin> ... e.g. people use owl:imports inside SPARQL, what does that mean exactly?
14:33:15 <ivan>
14:33:30 <davidwood> 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 <pchampin> peter: care has been taken in OWL2 with owl:import: this is a pragmatic issue, not a semantic issue (?)
14:33:50 <ivan> "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 <davidwood> It is the same dual use of the name of the graph that we are wrestling with here.
14:34:43 <AndyS> AndyS has joined #rdf-wg
14:34:43 <pchampin> guus: for me, this use case is out of our scope, because owl:import has only operational semantics
14:34:45 <mischat> 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 <davidwood> q?
14:34:52 <mischat> q?
14:35:08 <sandro> q?
14:35:19 <sandro> 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 <davidwood> mischat, yes, it will probably end up that way once we figure out how we name graphs.
14:36:09 <sandro> 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 <pchampin> pat: in the named graph paper, several URIs can resolve to a graph, but only one is officially naming it
14:36:44 <ivan> ack iand 
14:36:44 <sandro> 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 <Zakim> iand, you wanted to say there seems to be confusion between a namespace URI and an ontology URI
14:36:49 <pchampin> ... you can have several other URIs doing weird thing for practical reasons
14:37:07 <sandro> -1 PatHayes -- I think it's core the Web Architecture that "identify" and "name" are the same thing.
14:37:29 <iand> ack me
14:37:31 <Guus> q?
14:37:32 <PatHayes> sandro, that HAS to be wrong.
14:37:46 <pchampin> 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 <sandro> gavin: Ontology URI is the name of ontology, the base URI, where it's published, etc....
14:37:59 <PatHayes> q-
14:38:28 <sandro> q+ to talk about "identify"-vs-"name"
14:38:32 <iand> 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 <gavinc> +1 iand
14:38:56 <mischat> pchampin: had an answer for ivan, agree's with danbri 
14:38:57 <sandro> (agreed iand)
14:39:11 <PatHayes> q+ for identify/name when that gets to be a topic.
14:39:21 <mischat> pchampin: the ontology is more abstract than the graph
14:39:31 <mischat> ivan: every OWL is an RDF graph
14:39:49 <mischat> ivan: conceptually every OWL can be mapped to a graph
14:40:03 <gavinc> iand, of course the "namespace" doesn't really exist in RDF
14:40:03 <pchampin> ack me
14:40:03 <Zakim> pchampin, you wanted to answer ivan
14:40:21 <Guus> ack cygr
14:40:29 <davidwood> From AWWW:
14:40:30 <Guus> ack cygri
14:40:30 <pchampin> cygri: the OWL specs says how you can turn any ontology onto a graph
14:40:37 <davidwood> "To benefit from and increase the value of the World Wide Web, agents should provide URIs as identifiers for resources."
14:40:48 <pchampin> ... also an ontology has an identifier (URI)
14:40:48 <danbri> re ontologies and graphs -- 'turn into', 'map to', 'is just a', ... hearing lots of phrases, 'translates into a', ...
14:40:57 <davidwood> Note that equates a URI and an identifier.
14:41:14 <pchampin> ... 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 <AndyS> Sounds like short-circuit of naming: name of concept/abstraction != name of graph that encodes (one way) the ontology
14:41:34 <pchampin> ivan: that's the job of the OWL3 WG
14:41:50 <danbri> 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 <AlexHall> +1 AndyS
14:41:59 <pchampin> cygri: we can make things easier for the OWL3 WG to do that
14:42:01 <davidwood> Also, "By design a URI identifies one resource"
14:42:08 <PatHayes> davidwood, what is your point? All that is about identification, not naming.
14:42:14 <sandro> Provenance-WG is alll about describing conversion processes and their results.
14:42:37 <Guus> q?
14:42:58 <davidwood> 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 <davidwood> Perhaps we are using the term "name" differently?
14:43:31 <gavinc> davidwood, yes... however that one resource might have many descriptions
14:43:41 <sandro> AlexHall: Lots of copies of some ontology can exist on the web.
14:43:51 <pchampin> alex: we are ok to have conflicting representation of the same ontology, with the same URI
14:43:54 <davidwood> Ah, your "names" are descriptions?  Why not call them descriptions?
14:44:06 <PatHayes> david, in spite of what sandro says, the RDF specs and the named graph paper both disagree with y'all.
14:44:06 <davidwood> My "names" are handles.
14:44:07 <pchampin> ... conflict usually resolved by the application
14:44:14 <sandro> q?
14:44:18 <mischat> davidwood: the tag have been talking about how "URIs define one resource" recently in the context of fragment ids in RDFa 
14:45:19 <pchampin> 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 <mischat> 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 <sandro> 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 <davidwood> mischat, interesting (and brave!)
14:45:49 <sandro> +1 agreed, different ontologies with the same name -- that's a bug.
14:45:51 <pchampin> ... but saying that those copies may be conflicting, it is a bug (a useful bug, but a bug)
14:46:04 <davidwood> PatHayes, can you point me to a section in the RDF docs that makes your point clear?
14:46:29 <cygri> different ontologies with same name is not a bug. it's a difference in opinion.
14:46:41 <yvesr> +1
14:46:44 <PatHayes> 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 <swh> mischat, using rat URIs to distinguish relies upon client-side modification, by definition
14:46:51 <swh> s/rat/tag/
14:46:53 <pchampin> guus: is it the work of this WG to solve this?
14:47:01 <pchampin> sandro, gavin, david: YES
14:47:06 <mischat> swh: frag?
14:47:14 <danbri> 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> ww has joined #rdf-wg
14:47:16 <sandro> sandro: there's nothing OWL-specific here; it comes up in any case of RDF.
14:47:20 <iand> mischat, danbri: don't think you should conneg ontologies that define things differently - conneg variants are supposed to be basically interchangeable
14:47:25 <pchampin> guus: suggest we have a separate document about RDF authorities
14:47:30 <cygri> q?
14:47:34 <sandro> "The Role of Derefencing in RDF" -- a new RDF WG Note.
14:47:38 <swh> mischat, fragment URIs, I was replying to your point :)
14:47:38 <sandro> ?
14:47:43 <mischat> yeah i see 
14:47:48 <pchampin> ivan: it means that the dereferencing model does not work
14:47:58 <AndyS1> AndyS1 has joined #rdf-wg
14:48:06 <danbri> 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 <pchampin> gavin: you mean that the web does not work...
14:48:35 <Guus> q?
14:48:47 <sandro> ack sandro 
14:48:47 <Zakim> sandro, you wanted to talk about "identify"-vs-"name"
14:48:48 <ivan> ack AlexHall 
14:48:49 <Guus> ack AlexHall
14:49:53 <cygri> httpRange-14 is mentioned. it'll be all downhill from here
14:49:55 <ivan> 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 <danbri> zakim, who is playing music?
14:50:08 <Zakim> I don't understand your question, danbri.
14:50:13 <pchampin> sandro: the web-arch way for a URI to identify a thing is not the same as the RDF way
14:50:36 <AndyS> resolved httpRange-14? 
14:50:57 <pchampin> pat: agree with sandro, the httpRange-14 solves this, but has the WG endorsed it?
14:51:29 <iand> We need a godwins law for httprange-14
14:51:37 <cygri> coffee break?
14:53:00 <pchampin> (pat and sandro arguing about following the TAG or not in their resolution of httpRange-14)
14:53:48 <pchampin> pat: httpRange-14 does not say anything about what resource a IRI identifies, only what *kind* of resource
14:53:53 <iand> let's get coffee then httprange-14 will be resolved when we get back
14:54:36 <yvesr> iand, it will have resolved itself
14:54:42 <sandro> :-)   :-)     <iand> We need a godwins law for httprange-14
14:54:59 <pchampin> guus: can we get a clear statement of what we expect as a result of this WG
14:55:04 <yvesr> i quite liked the idea of a note
14:55:07 <pchampin> ... not in terms of semantics, but of pragmatics
14:56:07 <pchampin> sandro: there should be a document explaining how dereference relates to RDF
14:56:10 <pchampin> guus: agree
14:56:23 <sandro> 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 <sandro> PatHayes: amen
14:57:37 <PatHayes> david, re. your earlier question, see
14:58:08 <davidwood> Thanks, Pathayes
14:58:12 <PatHayes> OK, see yall in an hour.
14:58:17 <AZ> gentlemen, I have to leave now
14:58:34 <Zakim> -PatH
14:58:55 <AZ> bye
14:59:04 <Zakim> -AZ
15:03:37 <Zakim> -ww
15:09:02 <Zakim> -MIT_Meeting_Room
15:15:36 <AlexHall> AlexHall has joined #rdf-wg
15:52:31 <AlexHall> AlexHall has joined #rdf-wg
15:54:38 <zwu2> zwu2 has joined #rdf-wg
15:55:55 <Scott_Bauer> Scott_Bauer has joined #rdf-wg
15:56:50 <Guus> reconvene in 5?
15:57:11 <AlexHall> still missing most of the room at MIT
16:00:21 <AndyS> AndyS has joined #rdf-wg
16:01:13 <Zakim> +PatH
16:01:45 <Zakim> -PatH
16:01:50 <tlebo> tlebo has joined #rdf-wg
16:03:01 <gavinc> gavinc has joined #rdf-wg
16:03:23 <Souri> Souri has joined #RDF-WG
16:03:37 <Zakim> +MIT_Meeting_Room
16:03:53 <davidwood> davidwood has joined #rdf-wg
16:04:07 <Guus> welcome bac, MIT meeting room
16:05:17 <danbri> davidwood, can you hear us?
16:05:29 <swh> swh has joined #rdf-wg
16:05:38 <sandro> MIT is back on the phone.
16:07:38 <LeeF> LeeF has joined #rdf-wg
16:07:54 <ericP> topic: meta-discussion of how to make progress in F2F
16:08:21 <tlebo> davidwood: name, identifier, dereferencing is causing problems.
16:08:23 <Guus> q+
16:08:32 <davidwood> ack PatHayes
16:08:32 <Zakim> PatHayes, you wanted to discuss identify/name when that gets to be a topic.
16:08:35 <ericP> davidwood: after 6 months, we're still not using terms consistently enough to enable progress
16:08:48 <ericP> ... suggestions for way forward?
16:08:56 <davidwood> ack Guus
16:09:07 <ericP> scribenick: ericP
16:09:16 <cygri> q+
16:09:21 <ericP> Guus: i feel we moved forward a bit before the break:
16:09:39 <ericP> ... .. some consensus that we need names for at least graphs, maybe more
16:09:54 <ericP> ... .. some sense of the requirements these impose on RDF
16:10:10 <ericP> ... .. use cases lead us to the deferencing dicusssion
16:10:45 <ericP> ... still not clear how rdf dataset relates to g{snap,box}
16:10:52 <Zakim> +PatH
16:10:53 <LeeF_> LeeF_ has joined #rdf-wg
16:11:09 <ericP> davidwood: we need names for at least graph containers (gboxes)
16:11:35 <ericP> s/names for at least graphs, maybe more/names for at least graph containers, maybe more/
16:12:07 <ericP> davidwood: paraphrasing PatHayes, "a name is not an identifier"
16:12:08 <yvesr> r
16:12:15 <Guus> q+
16:12:30 <ericP> ... "... we can have multiple names for things"
16:12:47 <sandro> pat: We're not obliged to presume that "naming" and "identifying" are the same relationships.
16:12:49 <ericP> PatHayes: the notion of name and identifier are disctinct
16:13:02 <davidwood> ack cygri
16:13:05 <ericP> ... no position on whether they *should* be the same
16:13:45 <ericP> cygri: i think we made progress on understanding peoples' positions and requirements, as well as what's easy or hard
16:14:11 <ericP> ... can we discuss what we can write over the coming weeks to make progress?
16:14:13 <sandro> cygri: let's figure out what we should write in the coming weeks
16:14:27 <ericP> ... e.g. i think we should gather use cases
16:14:28 <LeeF_> +☃ for test cases
16:14:50 <sandro> cygri: eg: patterns for use of named graphs, that exist in the wild, and potentially cause interop conflicts.
16:14:54 <ericP> ... we should look for different existing use patterns which will reveal problems at e.g. SPARQL endpoints
16:15:07 <sandro> q+
16:15:09 <davidwood> q?
16:15:12 <ericP> +1 to test cases
16:15:13 <davidwood> ack Guus
16:15:15 <PatHayes> leef, what symbol was that?
16:15:23 <ericP> Guus: +1 to test cases
16:15:49 <ericP> ... want to see which we should put in RDF semantics and which are outside pragmatics
16:15:51 <sandro> PatHayes, it was a unicode snowman
16:16:01 <davidwood>
16:16:07 <sandro> (or not.  hard to see.)
16:16:09 <PatHayes> :-)
16:16:14 <ericP> ... folks already have pragmatic approaches. the question is whether we can incorporate some of that into RDF
16:16:37 <davidwood> q?
16:16:40 <davidwood> ack sandro
16:16:51 <ericP> 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_> LeeF_ has joined #rdf-wg
16:17:37 <ericP> sandro: in gavin's use case, several folks said "there's a bug here"
16:17:49 <LeeF_> PatHayes,
16:18:00 <ericP> ... we can try to solidify that
16:18:23 <ericP> davidwood: "can a document IRI and the graph IRI be the same?"
16:18:32 <ericP> gavinc: and the ontology IRI?
16:18:44 <davidwood> q?
16:18:54 <ericP> sandro: is the ontology's name for itself the same as its location?
16:19:03 <ericP> gavinc: axes:
16:19:08 <ericP> ... .. graph name
16:19:09 <sandro> graph-name vs location
16:19:19 <ericP> ... .. <x> a Ontology.
16:19:39 <ericP> ... .. where you can retrieve the [ontology?]
16:19:52 <AlexHall> :g1 { :g1 a owl:Ontology }
16:20:04 <swh> if <x> a Ontology, surely <x> should't be a graph? c.f. Person and graph
16:20:06 <ericP> ... i think the prob exists on these axes
16:20:26 <danbri> we no hear
16:20:32 <mischat> can people speak in turn please 
16:20:49 <danbri> we heard a little of all of them
16:20:57 <ericP> ... { <x> a Ontology } gets repeated everywhere
16:21:32 <sandro> sandro: possible test case, if we can infer a type for locations and/or names.
16:21:34 <ericP> LeeF: is it kosher for the graph name to be X and for X to be the ontology triple
16:21:45 <ivan> q+
16:21:49 <PatHayes> this sounds very like the question whether one iri can identify the NYTimes and also one day's version of it.
16:21:55 <davidwood> ack ivan
16:21:55 <AndyS> no
16:21:55 <gavinc> HTTP GET <g1> ; :g1 { :g1 a owl:Ontology }
16:22:09 <ericP> davidwood: we should at least provide guidance to the community
16:22:36 <PatHayes> that is exactly what I meant by using a name inside some rdf. 
16:22:48 <ericP> ivan: sandro vs. cygri controversy: should the formal part of the RDF docs talk about dereferencing the graph name
16:22:55 <PatHayes> once you do that, it belongs to trhe semantics.
16:23:09 <ericP> ... if the answer is "no", we can discuss writing additional guidance documents
16:23:11 <tlebo> is Gavin's #1 "graph name" of the Graph Container?
16:23:14 <PatHayes> +1 to ivan
16:23:24 <ericP> ... that question is the fundamental question
16:23:34 <ericP> q+ to say we won't knwo until we've explored the use cases
16:23:40 <swh> +1 to ivan 
16:23:51 <cygri> q+ to give an example from sindice
16:23:52 <ericP> sandro: i think we're only going to answer that question by working up from test cases
16:24:12 <ericP> ivan: so let's look at tests keeping this in mind
16:24:18 <pfps> 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 <swh> q+
16:25:05 <ericP> ... if the semantics requires a particular way of dereferencing the name or graph, would that change antidot's implementation?
16:25:05 <PatHayes> test cases give useful information about intuitions. better than arguing :-)
16:25:14 <mischat> +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 <gavinc> +100 PatHayes
16:25:16 <sandro> 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 <cygri> PatHayes, but less fun!
16:25:26 <LeeF_> :)
16:25:50 <PatHayes> ericP, this irc record.
16:25:56 <davidwood> ack ericP
16:25:56 <Zakim> ericP, you wanted to say we won't knwo until we've explored the use cases
16:27:12 <sandro> 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 <swh> q-
16:27:45 <AlexHall> s/don't want to make sure/want to make sure/
16:27:55 <sandro> ... 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 <swh> q+
16:28:18 <sandro> 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 <ericP> PatHayes, 
16:28:25 <pfps> +1 to Pat  :-)
16:28:45 <sandro> davidwood: if you can't do it, where does that leave us?
16:29:12 <sandro> PatHayes: without precisely defined semantics.   maybe that's okay.
16:29:30 <ericP> sandro, what do you feel about the semantics being defined in natural language and test cases?
16:29:31 <pfps> Test cases are not a definition.  Natural language can be rather squishy.
16:29:37 <danbri> we'd need specific examples of the test cases
16:29:39 <sandro> sandro: How bad would it be to do it with natural language and test cases?
16:29:49 <ericP> PatHayes: that's like asking a horse trainer how they feel about life without horses
16:30:04 <sandro> PatHayes: There's a long language of clashes resolves by formal semantics.   If we can do it that way we should.    
16:30:07 <ericP> ... the world can get by, but [there's a cost]
16:30:12 <sandro> davidwood: Thanks Pat!
16:30:17 <davidwood> ack cygri
16:30:17 <Zakim> cygri, you wanted to give an example from sindice
16:30:31 <ericP> ... but don't be surprised if i can't write the semantics that you guys arrive at
16:30:42 <PatHayes> squishy, good one.
16:30:44 <cygri> ack me
16:30:59 <sandro> s/sandro, what do/sandro: what do/
16:31:15 <ericP> cygri: re: dereferencing, we have a web crawling use case about an RDF search engine
16:31:23 <mischat>
16:31:27 <Souri> 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 <PatHayes> 'ontology
16:31:53 <ericP> ... it takes a URL X, dereferences it, put's the parse into GRAPH <X>
16:31:55 <PatHayes> sorry
16:31:57 <Souri> s/ i av/ is av/
16:32:18 <ericP> ... it supports the truth that sandro wants
16:32:45 <ericP> ... if we want to define this formally, we have to discuss @@1
16:32:53 <ericP> ... in 2006, that was RDF/XML
16:33:03 <ericP> ... in 2007, RDF/XML and Turtle
16:33:16 <sandro> 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 <ericP> ... then we added RDFa, ntriples, microdata, ...
16:33:36 <sandro> cygri: The notion of dereferencing has changed over the years.
16:33:44 <ericP> ... the notion of dereferencing has changed over the years
16:34:12 <PatHayes> this is exactly why we had an abstract notion of rdf graph, to provide a level of abstraction above particulr syntax.
16:34:25 <pchampin> who wrote earlier that time was not the only parameter?
16:34:29 <ericP> ... how do we write a formal spec that tells us how to dereference?
16:34:51 <ericP> davidwood: can you tell me if 4.2 is subsumes 4.9 or 1.3?
16:34:56 <PatHayes> uri for the test cases?
16:35:02 <davidwood> q?
16:35:06 <ericP> sandro: [addressing cygri]
16:35:09 <PatHayes> q
16:35:21 <PatHayes> q
16:35:22 <danbri> q?
16:35:22 <ericP> ... i don't have a pat answer, but i think we can come up with something that's good enough
16:35:23 <gavinc> PatHayes,
16:35:26 <PatHayes> q+
16:35:46 <PatHayes> thanks gavin
16:36:09 <ericP> 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 <PatHayes> typing with one hand, return and shift keys too close.
16:36:43 <ericP> ... there's something else that can be done which is sort of hand-wavey which would be useful; recording this pattern
16:37:20 <davidwood> acl swh
16:37:21 <ericP> ... but writing to rules to establish if <G> is a conforming something of an IRI could be hard
16:37:24 <davidwood> ack swh
16:37:50 <ericP> swh: agreed with ericP to a point, but have a different conclusion:
16:38:18 <ericP> ... .. none of the use cases we've discussed benifits from a formal semantics for dereferencing
16:38:42 <davidwood> ack Souri
16:38:43 <Zakim> 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 <ericP> ... so unless we can find another use case, i think we can spend our time better elsewhere
16:39:06 <ericP> Souri: in the ontology case, i see three things:
16:39:10 <ericP> ... .. graph name
16:39:16 <ericP> ... .. ontology name
16:39:21 <ericP> ... .. location
16:39:32 <davidwood> 5.2
16:39:44 <davidwood>
16:39:50 <ericP> Souri: these could all be different
16:39:57 <tlebo> is "graph name" of the container or g-snap?
16:40:05 <ericP> ... can we add properties like rdf:availableFrom?
16:40:42 <tlebo> q+
16:40:45 <ericP> ... if folks want to use one IRI for all, fine
16:40:53 <pfps> right now OWL works fine without any further semantics for ontology names
16:41:04 <tlebo> q-
16:41:08 <ericP> ... if not, we can give them some properties to describe their relationships
16:41:21 <davidwood> ack PatHayes
16:41:26 <ericP> davidwood: by "graph", gsnap or gbox?
16:42:03 <Guus> suggest to go to the wikidata usecase
16:42:14 <cygri> q+
16:42:24 <ivan> ack cygri 
16:42:27 <ericP> PatHayes: from cygri listing the syntaxes each year, the notion of defining dereferencing would be to address exactly that
16:42:37 <ericP> ... i thought that was the one part we got exactly right
16:43:03 <ericP> 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 <ericP> ... the process is really complicated
16:43:29 <ericP> ... HTTP, mime time, sniffing, ...
16:43:46 <ivan> s/mime time/mime type/
16:43:47 <ericP> ... we learn more about this all the time
16:44:03 <gavinc> s/mime type/media type/ ;)
16:44:17 <ericP> ... getting from the IRI to the graph is hard to specify
16:44:37 <ericP> ... i'm more interested in what you get after you dereference and parse and all that
16:44:47 <swh> there can even be multiple was to get from a URI to different graphs, e.g. conneg + RDFa
16:45:15 <swh> +1 to not specifying it
16:45:20 <yvesr> swh, and conneg'ed graphs may be different too
16:45:29 <swh> indeed
16:45:30 <cygri> ericP++
16:45:33 <yvesr> swh, (as it does on the bbc site, for example, although i agree it's not ideal)
16:45:56 <cygri> q+
16:46:01 <LeeF> LeeF has joined #rdf-wg
16:46:03 <cygri> q-
16:47:29 <LeeF_> LeeF_ has joined #rdf-wg
16:47:42 <cygri> ericP: from the same input URI, you could end up with quite different snaps because of different processing that was done
16:48:08 <cygri> q+
16:49:35 <davidwood> ack cygri
16:49:38 <cygri> q-
16:49:39 <ericP> PatHayes: we violated the obvious deferencing rules when we decided that IRIs in RDF could identify graphs
16:50:05 <AndyS> AndyS has joined #rdf-wg
16:50:08 <sandro> 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)"
16:50:34 <iand> do sparql datasets consist of g-snaps or g-boxes?
16:50:42 <cygri> iand, g-snaps
16:51:07 <cygri> (with g-boxes it's a “graph store”, defined in the SPARQL Update spec)
16:51:22 <cygri>
16:51:29 <iand> cygri: i don't agree that a g-box is a graph store
16:52:11 <cygri> iand: what AndyS is saying
16:52:32 <danbri> nor I
16:52:42 <iand> cygri: isn't a g-box a set of g-snaps with the same name?
16:53:06 <Souri> s/tanks/thanks/
16:53:19 <danbri> if I have a github repo with 15 versions of some RDF doc (er, graph), ... is that a g-box?
16:53:20 <davidwood> iand: no, I don't think so
16:53:28 <cygri> iand, no. g-snaps don't have names as such
16:53:38 <davidwood>
16:53:39 <gavinc> gavinc: A graph store is made up of gboxes, a dataset is made up of g-snaps
16:53:41 <cygri> g-snap = mathematical set of triples
16:53:48 <davidwood> q?
16:54:16 <davidwood> TOPIC: 4.9 (A PRIORITY) Trust Web Opinions
16:54:27 <AndyS> +1 gavinc -- what needs clarifying is graph store -> dataset for query, not graph store or dataset themselves 
16:54:34 <MacTed> MacTed has joined #rdf-wg
16:55:58 <ericP> sandro: people are publishing useful info on the web
16:56:12 <ericP> ... alice is searchnig for a good local seafood restaurant
16:56:31 <iand> cygri: can't get my head round g-snaps not having names if SPARQL datasets are made of named g-snaps
16:56:35 <davidwood> iand: Also, a g-box is mutable and not a 'set'
16:56:35 <ericP> ... there are different modes of failure sensitive to the data she may find:
16:56:47 <ericP> ... .. deception (people lying)
16:56:48 <cygri> iand: named graph = pair of uri and g-snap
16:56:57 <ericP> ... .. errors (mistakes in the data)
16:57:03 <cygri> sparql dataset = set of named graphs, plus a default graph (= g-snap)
16:57:05 <ericP> ... .. simplication
16:57:10 <ericP> ... .. time lag
16:57:21 <ericP> ... .. subjectivity
16:57:49 <iand> cygri: you are saying named graphs are graphs without names that have a name associated with them
16:57:50 <ericP> ... [of course] this occurs in science, IT (e.g. employee directory)
16:58:11 <cygri> iand i don't think i said that
16:58:13 <ericP> ... i haven't yet tied this down to test cases
16:58:20 <gavinc> iand, could you use "," and not ":" the minutes will be very annoying otherwise
16:58:45 <ericP> ... 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 <ericP> davidwood: she already knows about the sources of reviews, but she doesn't know which she can trust
16:59:07 <iand> gavinc, yep, sorry
16:59:47 <ericP> sandro: say she's using sindice to find seafood restos
16:59:54 <PatHayes> q+
17:00:07 <ericP> davidwood: alice goes to sindice and gets RDF for resto reviews
17:00:24 <ericP> ... upon what data/metadata is she "trusting" the review?
17:00:43 <ericP> sandro: she had to know her threat model to manage her security
17:01:02 <ericP> ... .. deception: web of trust
17:01:17 <ericP> ... .. error: crowd sourcing
17:01:23 <ericP> ... .. time lag...
17:01:35 <ericP> davidwood: i'd like to get here with 1.3
17:02:14 <ericP> ... implicit in this is that a given review published in the web must be spidered by sindice or alice, ...
17:02:32 <ericP> ... in spidering, they must capture provenance data (where, when, ...)
17:02:54 <ericP> sandro: sindice could just give alice the locations, and she fetches them
17:03:21 <ww> ww has joined #rdf-wg
17:03:21 <swh> if sindice just gives Alice a URI should just judge timeliness without trusting the publisher
17:03:26 <danbri> it's a myth that you need URIs to do things
17:03:29 <danbri> it's just a lot easier
17:03:34 <swh> s/should/she can't/
17:03:44 <ericP> davidwood: she'll need at least one bit of metadata, the IRI, or much more
17:03:52 <PatHayes> 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 <ericP> ... if sindice finds a resto review in RDF, what's it try to GET?
17:04:37 <ericP> cygri: deferences, parses (many parsers)
17:04:44 <ericP> ... records:
17:04:48 <ericP> ... .. domain name
17:04:51 <ericP> ... .. time
17:04:57 <ericP> ... .. HTTP headers
17:05:10 <ericP> ivan: the name of the graph is the IRI which gave you the IRI?
17:05:12 <ericP> cygri: yes
17:05:51 <ericP> davidwood: if we standardized a named graph: named gbox or named gsnap, would that help?
17:06:07 <ivan> q+
17:06:15 <sandro> q+ to reply to "don't stdize deref"
17:06:16 <ericP> cygri: don't try to specify the dererencing step
17:06:16 <PatHayes> q-
17:06:28 <ericP> ... would be immediately outdated
17:06:32 <PatHayes> i wrote my comment.
17:07:01 <ericP> davidwood: would a standard for gboxes or gsnaps help the sindice use case?
17:07:12 <ericP> cygri: practically, no; it's already implemented
17:07:29 <ericP> ... would make it easier for us to discuss what we do in terms others would understand
17:07:32 <gavinc> PatHayes, for one thing humans don't treat IRIs as opaque. A review from "" is magicly downranked
17:07:57 <ericP> ... i listed this because i don't want the WG to standardize something harmful
17:08:00 <gavinc> ack sandro
17:08:00 <Zakim> sandro, you wanted to reply to "don't stdize deref"
17:08:45 <cygri>
17:08:50 <PatHayes> 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 <ericP> 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 <cygri> q+ to ask about test cases for "to dereference, follow the standards"
17:10:35 <ericP> ... 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 <swh> That sounds like a job for a vocabulary, not sure it's the RDF-WGs problem
17:10:48 <yvesr> +1
17:10:57 <sandro> +1 steam-powered parsers!!
17:11:04 <AndyS> And in the limit (geo-IP) not everyone may see the same thing for exactly the same request.  
17:11:04 <AlexHall> +1 swh
17:11:15 <davidwood> ack ivan
17:11:29 <tlebo> 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 <ericP> PatHayes: if someone has a new steam-powered parser, they just have to describe in painstaking detail how it emits triples
17:11:56 <ericP> ivan: if we use this black box, do we exclude names?
17:12:19 <gavinc> 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 <ericP> ... e.g. AndyS's suggestion for using tag IRNs for time-stamped data
17:13:16 <AndyS> q+
17:13:20 <ericP> sandro: dereferencing is the way we learn the intent of the identifier
17:13:21 <AlexHall> gavinc, yeah we need to make sure that the vocabulary has something to talk about
17:13:34 <danbri> q+ to grouch
17:13:46 <danbri> de-referability is not a property of URI scheme
17:14:01 <danbri>
17:14:41 <yvesr> q?
17:14:49 <PatHayes> all uris dereferenced for a nominal fee. money-back guarantee.
17:14:49 <danbri> q-
17:14:53 <davidwood> ack cygri
17:14:53 <Zakim> cygri, you wanted to ask about test cases for "to dereference, follow the standards"
17:14:56 <gavinc> 0K box!
17:15:00 <danbri> q+
17:15:02 <ivan> ack cygri 
17:15:29 <ericP> cygri: so we leave dereferencing as a black box (leave to standards)
17:15:48 <ericP> ... but i don't see how to write test cases
17:16:30 <ericP> ... if it's a specification, it should be possible to write a test case
17:16:38 <ericP> sandro: i agree with your goal
17:16:53 <PatHayes> which, btw sandro, is one reason why naming/reference cannot be identical to awww:identifies.
17:16:59 <ericP> ... most dereferences are in HTTP and there's a little glue around the edges
17:17:52 <ericP> ... i haven't got a test case and agree that we need then
17:18:09 <davidwood> ack AndyS
17:18:13 <ericP> sandro: names and awww:identifies could be congruant functions
17:18:18 <davidwood> ack danbri
17:19:28 <davidwood> 1.3 (A PRIORITY) Graph Changes Over Time
17:19:29 <PatHayes> 8 track tapes...
17:19:30 <ericP> danbri: re: deferencing, you speak as if dereferencability as it it were a behavior of the schema, but it evolves
17:19:31 <yvesr> q?
17:19:32 <davidwood>
17:19:49 <PatHayes> of course
17:19:53 <swh> q+
17:19:53 <sandro> pfps if we can't discuss history are we doomed to repeat it?  :-)
17:20:02 <davidwood> ack swh
17:20:03 <danbri> resolved: de-referencability is not a simple characteristic of a URI scheme, but depends on social and technical mess surrounding us
17:20:29 <davidwood> Ugh
17:20:35 <davidwood> s/resolved//
17:20:42 <sandro> q+ 
17:20:46 <ericP> swh: in our system you need to have different graphs at the same IRI at different times
17:21:05 <PatHayes> q+
17:21:10 <tlebo> :URL rdfs:subClassOf rdf2:GraphContainer ?
17:21:19 <ericP> ... we need to say that some info was in <X> at one time but not later
17:21:36 <ericP> ... so of course you can't *just* use <X>
17:21:39 <tlebo>  rdfs2:GraphContainer owl:disjointWith rdf2:Graph .
17:22:01 <sandro> q?
17:22:05 <ericP> ... we just use <X-2011-10-12T17:22:05>
17:22:19 <ericP> ... looked at MD5, but it was a pain
17:22:30 <swh> we actually use <http://foo.example/foo#2011-10-12>
17:22:57 <danbri> (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 <PatHayes> do you need to be able to tell, by looking at the iri, which way it works (box or snap name) ?
17:23:33 <ericP> sandro: if you use <>, you could own that graph and say that it's attached to <http://foo.example/foo#2011-10-12>
17:23:43 <tlebo> @pathayes, no, interrogate its rdf:types ?
17:23:51 <iand> +1 swh - this is first use case where graph name cannot be same as source of triples
17:23:55 <ericP> ivan: we've never said that a graph need have only one name
17:24:03 <sandro> really I said garlic + date + fetched-url
17:24:15 <danbri> I have swh's use case too; it's quite a common pattern and worth naming/documenting/exposing
17:24:17 <sandro> q+ 
17:24:28 <sandro> q+ to talk about rolling snapshots
17:24:32 <ericP> 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 <mischat> we didn't go for… to save bytes FWIW
17:25:02 <AndyS> AndyS has joined #rdf-wg
17:25:23 <swh> mischat, that's right
17:25:29 <ericP> ivan: we have the notion of a "graph container" and a graph at different IRIs
17:25:41 <ericP> gavinc: do they *have* to be different IRIs?
17:25:46 <sandro> makes sense, mischat  --- but you COULD quite easily, and then it would totally conform with "Web Semantics for Datasets".
17:27:40 <cygri> q+
17:27:51 <sandro> davidwood: Possible consensus:   The identifier for a graph container is disjoijnt with the identifier with the g-snap (rdf graph).
17:27:57 <mischat> 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 <PatHayes> you could use one iri to identify a grap and a container, but dont record that use in any published rdf.
17:28:12 <ericP> 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 <ericP> ... objections?
17:28:59 <davidwood> Yes, there were (thankfully) objectons
17:29:08 <swh> LOAD <http://foo.example/> will do that
17:29:32 <ericP> swh: as applied globally, yes
17:29:45 <PatHayes> disjoint is too strong.
17:29:49 <ericP> davidwood: and here, so we don't have consensus here
17:30:04 <PatHayes> q+
17:30:05 <pchampin> q+
17:30:22 <ericP> sandro: [chasing why this breaks SPARQL]
17:30:26 <cygri> q+ to say that if <u> *denotes* a graph container, then it must still be possible to associate <u> with a graph graph in an RDF dataset
17:30:46 <mischat> 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 <LeeF_> SELECT .... FROM <g1> { ... } 
17:31:22 <LeeF_> g1 specifies a graph container
17:31:25 <LeeF_> it gets dereferenced
17:31:31 <LeeF_> and put into a local graph container that is also named g1
17:31:40 <LeeF_> local g1 is contextualized by the invocation of the quer
17:31:41 <ericP> timlebo: when you specify the SPARQL query, the FROM IRI sites the graph container, GRAPH <IRI> dereferences IRI and stores it locally
17:31:46 <PatHayes> agree with cygri, but want to add cautions regarding denoting-use in rdf which assumes connection to association.
17:31:51 <AndyS> FROM ==> FROM NAMED
17:31:53 <davidwood> q?
17:32:02 <iand1> iand1 has joined #rdf-wg
17:32:14 <cygri> ack me
17:32:14 <Zakim> cygri, you wanted to say that if <u> *denotes* a graph container, then it must still be possible to associate <u> with a graph graph in an RDF dataset
17:32:39 <ericP> ... so the SPARQL query against your local <IRI> is contextualized by your dereference
17:32:57 <sandro> +1 cygri
17:33:00 <gavinc> s/graph graph/RDF Graph (gsnap)
17:33:02 <gavinc> s/graph graph/RDF Graph (gsnap)/
17:33:20 <AndyS> It is a bad part of SPARQL.  Promotes lazy naming.  (and DAWG removed it once ... community wanted it back)
17:33:42 <ericP> cygri: if i deference (which may change tomorrow), i serialize it into a trig file
17:33:56 <PatHayes> im losing sound here.
17:34:18 <ericP> ... that trig file serializes a gsnap which i want to associate with the gbox (<>)
17:34:34 <davidwood> PatHayes, we hear BBC.  Perhaps you should redial?
17:34:44 <sandro> Can't there be an eg:hasGraph relation between the gbox and the gsnap?
17:35:10 <ericP> ... one identifier denotes a graph container @@2
17:35:15 <PatHayes> 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 <sandro> q++++
17:35:41 <ericP> ivan: i understand the example, and it makes me uneasy that the same IRI denotes two conceptually distinct things
17:35:45 <LeeF_> where in this example is a URI being used for a gsnap?
17:35:47 <gavinc> ack +++ 
17:35:48 <AndyS> PatHayes - good idea - say "don't publish - use locally"
17:35:56 <PatHayes> +1 ivan
17:36:00 <ericP> ... maybe we have to live with conflation
17:36:09 <iand1> So we are back to "(15:04:03) davidwood: Propose to RESOLVE "we need a way to name graph containers""
17:36:09 <PatHayes> q-
17:36:09 <LeeF_> +1 to living with the conflation!!
17:36:18 <tlebo> Still thinks that adopting <> vs. my:# and your:# addresses this confusion.
17:36:23 <pchampin> q-
17:36:26 <davidwood> ack sandro
17:36:26 <Zakim> sandro, you wanted to talk about rolling snapshots
17:36:28 <gavinc> +1 to living with conflation 
17:36:38 <iand1> -1 to conflation
17:36:50 <ericP> sandro: i have issues with an IRI denoting two things
17:36:51 <cygri> danbri++
17:37:15 <ericP> danbri: it's just an unspecified relationship
17:37:21 <PatHayes> because people want to be happily sloppy, sandro. 
17:37:27 <ericP> sandro: so why can't we specify that relationship?
17:38:00 <ericP> ... particular predicates can imply the <bgox of>
17:38:03 <ericP> q?
17:38:14 <yvesr> s/bgox/gbox
17:38:20 <PatHayes> this is very like the problem of giving iris to editions of documents, seems to me.
17:38:20 <iand1> can someone propose some concrete text to discuss?
17:39:04 <ericP> davidwood: we have namespace all over RDF
17:39:28 <ericP> ... we have IRIs which point to SPAQL enpoints which point to resources
17:39:39 <tlebo> @PatHayes, frbr:Work vs frbr:Expression gives you clean disjointness of editions and their more abstract documents.
17:40:17 <tlebo> q+
17:40:24 <PatHayes> i know, tlebo. i wish all these scruffy people would agree to that disciplined.
17:40:34 <PatHayes> to/to be/
17:40:42 <ericP> davidwood: these identifiers liter our RDF graphs
17:40:52 <sandro> q?
17:41:01 <sandro> q+ to talk about rolling snapshots
17:41:04 <PatHayes> use imperial measures to solve that one.
17:41:07 <gavinc> GET <> ; <> { <> example: ""^^xsd:anyURI }
17:41:08 <danbri> 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 <ericP> ... 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 <davidwood> ack tlebo
17:41:29 <LeeF_> 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 <ericP> tlebo: propose that URLs are a subclass of graph container which you dereference to a graph
17:41:38 <yvesr> danbri, +1
17:42:04 <AndyS> LeeF, suspect world+dog agrees with you
17:42:36 <PatHayes> q+ 
17:42:38 <ericP> ... (when we're talking about RDF graphs)
17:42:46 <danbri> 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 <davidwood> q?
17:42:54 <swh> we're processing HTML mostly, not RDF
17:43:18 <ivan> before break: there is something that we _did_ learn today:
17:43:19 <davidwood> Topic: 10 minute break
17:43:23 <Zakim> -PatH
17:43:28 <LeeF_> 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 <tlebo> +1
17:44:05 <AndyS> MIT has gone silent (here)
17:44:20 <sandro> we muted for the break, AndyS 
17:45:38 <danbri> 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> Scott_Bauer has joined #rdf-wg
18:00:49 <davidwood> Reconvene
18:01:10 <AlexHall> scribe: alexhall
18:01:23 <Zakim> +PatH
18:01:25 <ivan> scribenick: AlexHall
18:01:32 <LeeF_> 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 <AlexHall> 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 <davidwood> Topic: 1.5 (A PRIORITY) Exchanging the contents of RDF stores
18:01:55 <AlexHall> swh: no, that was it
18:02:07 <davidwood>
18:02:22 <AlexHall> davidwood: whose use case?
18:02:28 <swh> I want it :)
18:02:47 <davidwood> iand?
18:02:59 <iand1> nooo
18:03:09 <AlexHall> swh: related to backups... how to move between stores? Things like trig do it fairly well except the default graph issue
18:03:26 <sandro> swh: TriG doesn't work for this if the default graph is the merge of all the named graphs.
18:03:27 <AlexHall> ... duplicate every triple if dft graph = union of ngs
18:03:37 <AlexHall> ... also issues around bnodes
18:04:43 <PatHayes> why should the default be the union of named graphs??? that sounds like an obviously wrong general assumption.
18:04:53 <AlexHall> ivan: trig syntax won't tell you what is the default graph
18:05:16 <sandro> PatHayes, it's not a general assumption -- it's just how some SPARQL engines are set up.
18:05:31 <AndyS> PatHayes, "can be" -- common pattern and they use NG to manage data (subsets of the data)
18:05:34 <sandro> (steve's in particular, by default.)
18:05:39 <pchampin> q+
18:05:42 <AlexHall> guus: not a sparql store developer -- what's the issue here?
18:05:45 <PatHayes> so, why are we even talking about this?
18:06:12 <PatHayes> ok, so trig needs to be extended in some way?
18:06:14 <davidwood> ack sandro
18:06:14 <Zakim> sandro, you wanted to talk about rolling snapshots
18:06:15 <AlexHall> ???: many stores define the default graph specially
18:06:23 <PatHayes> q-
18:06:46 <sandro> sandro: The other thing TriG doesn't do for this UC is bnodes (unless skolemized)
18:07:20 <davidwood> ack pchampin
18:07:22 <ericP> 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> mischat has joined #rdf-wg
18:08:20 <AlexHall> 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 <AndyS> 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 <davidwood> INSERT DATA { GRAPH <g> {} } ...
18:08:46 <AlexHall> ... if SPARQL stores are more than just dataset definitions then they need extra stuff to support that.
18:09:18 <AlexHall> davidwood: looking at SPARQL update example here, data is going into a graph identified by a URI
18:09:52 <AlexHall> ... 6 months ago, there was disagreement on this issue: what is being identified by this URI?
18:10:12 <AlexHall> ... if we choose to align with SPARQL, then we're saying that this URI identifies a g-box
18:10:17 <cygri> -1
18:10:24 <PatHayes> i think we have already decided that we are NOT doing this.
18:10:39 <cygri> q+ to ask what david means by “identify”
18:10:40 <sandro> STRAWPOLL: Does anyone object to identifying a g-box with a URI, aligning with SPARQL 1.1 " INSERT DATA { GRAPH <g> {} } "
18:11:31 <iand1> of course you can identify a g-box with a URI, but you don't have to
18:11:42 <AlexHall> pat: IRI is associated with graph, but doesn't denote it
18:11:48 <sandro> cf the resolution from 2011-04-14 --- the url CAN denote the g-snap.
18:11:52 <AlexHall> sandro: but the IRI can denote the g-box
18:11:52 <davidwood> ack cygri
18:11:52 <Zakim> cygri, you wanted to ask what david means by “identify”
18:11:53 <sandro> CANT
18:12:10 <AndyS> ptr to resolution?
18:13:06 <cygri> quoting SPARQL Update: “A Graph Store is a mutable container of RDF graphs managed by a single service. Similar to an operated on by the, 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 <sandro> AndyS:
18:13:16 <AndyS> sandro, thx
18:13:18 <swh> I don't think SPARQL GRAPH uris identify anything in particular
18:13:20 <sandro> s/:/,/
18:13:25 <AlexHall> 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 <pchampin> @swh me neither
18:13:57 <AlexHall> sandro: in SPARQL as deployed, they aren't used (consistently) to denote anything
18:13:59 <pfps> +1 to Sandro :-0
18:14:13 <AndyS> (That resolution was about datasets not graph stores.)
18:14:17 <AlexHall> ... used to denote different things in different datasets
18:14:55 <iand1> 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 <AlexHall> ericP: we could say that SPARQL has never operated on g-boxes, only g-snaps
18:15:34 <danbri> i can't understand 'sparql operating over' here; it's more about how the system is managed
18:15:43 <danbri> and db admins don't exist in the formal Semantics
18:15:45 <AlexHall> 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 <danbri> (yet)
18:15:47 <sandro> iand1, no, it's one name.  
18:15:55 <yvesr> not when you update...
18:16:01 <tlebo> INSERT DATA { GRAPH #<g> {} }   :-)
18:16:29 <zwu2> +1 to tlebo
18:16:42 <cygri> cambridge, slow down please
18:17:05 <davidwood> q?
18:18:19 <iand> sparql 1.1 query doesn't import the definition of graph from RDF Concepts. Doesn't seem to define it at all.
18:19:05 <AlexHall> ericP: meta-discussion about not allowing ourselves to be constrained by what SPARQL is doing right now.
18:19:21 <pchampin> q+ to suggest that SPARQL 1.1 *has* URI for g-boxes... somewhere
18:19:22 <sandro> eric: so far, maybe, SPARQL is against only g-snaps?
18:19:23 <yvesr> iand, interesting - it dives directly in 'graph patterns'
18:19:30 <AndyS> q+
18:19:35 <gavinc> INSERT DATA { GRAPH <iri> { <s> <p> <o> }} ... takes the gsnap in the <iri> gbox adds <s> <p> <o> to the set to create a new gsnap that is placed into the gbox <iri> ?
18:19:37 <AlexHall> souri: if you're doing an update, it has to be a g-box.
18:20:01 <davidwood> ack pchampin
18:20:01 <Zakim> pchampin, you wanted to suggest that SPARQL 1.1 *has* URI for g-boxes... somewhere
18:20:01 <Guus> q?
18:20:07 <pchampin>
18:20:08 <gavinc> q+ to add question already in irc
18:20:43 <AlexHall> pchampin: thinking about section from SPARQL 1.1 that comes close to assigning URIs for graph containers
18:21:15 <AlexHall> ... indirect identification by building a graph URI from the service URI and the graph URI
18:21:23 <AndyS> q-
18:21:36 <sandro> Ahhhhh.    I forgot/missed that.
18:22:41 <AlexHall> sandro: this torpedoes my claim that you have to use 2 URIs to denote a g-box in SPARQL.
18:23:00 <cygri> q+
18:23:39 <tlebo> service description document ?
18:24:02 <AlexHall> 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 <AlexHall> ... a graph store is a different aspect
18:24:52 <AlexHall> ... SPARQL 1.0, a dataset is a set of graph and named graphs that is what the query runs over
18:25:14 <AlexHall> ... then you have FROM/FROM NAMED which describes how to build the dataset from g-boxes/g-snaps
18:25:32 <pchampin> and dereference
18:25:40 <pchampin> s/dereference/dereferencing/
18:25:50 <AlexHall> ... 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_> mischat_ has joined #rdf-wg
18:26:16 <sandro> PROPOSED: SPARQL11-http-rdf-update URLs like /rdf-graphs/service?graph=http%3A// denote graph containers (gboxes).    The embedded URI *might* also denote that same container, for some dataset arrangement patterns.
18:26:31 <AlexHall> 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 <AlexHall> andy: yes, but it doesn't take into account stuff around graph literals
18:27:36 <gavinc> INSERT DATA { GRAPH <iri> { <s> <p> <o> }} ... takes the gsnap in the <iri> gbox adds <s> <p> <o> to the set to create a new gsnap that is placed into the gbox <iri>. This creates a new Dataset as well. ?
18:27:42 <davidwood> ack gavinc
18:27:42 <Zakim> gavinc, you wanted to add question already in irc
18:28:17 <AlexHall> gavinc: given the original insert data statement, is what i wrote in IRC true?
18:28:49 <yvesr> no
18:28:49 <PatHayes> i vote for it.
18:28:53 <tlebo> +1 to @gavinc's INSERT
18:28:57 <PatHayes> :-(
18:29:02 <sandro> +1 to gavin's explanation
18:29:07 <pchampin> ok if "<iri> gbox" means "the gbox labeled with <iri>"
18:29:22 <sandro> yes, pchampin 
18:29:30 <PatHayes> yves, what was wrong with it?
18:29:37 <AndyS> Yes.
18:29:44 <ivan> what does 'label' mean? More exactly, what doesn't it mean?
18:29:53 <sandro> "paired"
18:29:57 <tlebo> [] sd:name <iri> .
18:29:57 <PatHayes> "identify" has huge tag-baggage.
18:30:00 <sandro> (I think that matches the spec)
18:30:10 <davidwood> q?
18:30:15 <tlebo> (
18:30:25 <AlexHall> yves: find it counter-intuitive, think it will be horribly confusing to somebody reading the spec for the first time.
18:30:29 <swh> q+
18:30:58 <sandro> q+ to strawpoll 
18:31:02 <tlebo> [] sd:name gavinc:iri; a rdf2:GraphContainer .
18:31:10 <PatHayes> im having a hard time thinking what else it can possibly mean.
18:32:00 <davidwood> ack cygri 
18:32:17 <yvesr> ack swh 
18:32:20 <davidwood> q+ to ask gavinc about "add to a set"
18:32:45 <AlexHall> 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 <AlexHall> q+
18:33:09 <gavinc> 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 <gavinc> It may be more readable backwards
18:33:21 <iand> INSERT DATA { GRAPH <iri> { <s> <p> <o> }} means take the gsnap that is the current state of the gbox <iri>, perform an RDF-Merge with <s> <p> <o> to form a new gsnap and make that the current state of <iri>
18:33:52 <AlexHall> davidwood: sparql also has delete, but you can't delete from a set can you?
18:34:05 <pfps> 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 <yvesr> ok, so do we need the equivalent of the gbox/gsnap terminology for dataset?
18:34:25 <yvesr> dbox/dsnap?
18:34:31 <gavinc> PatH, yes. A graph store can have a NEW gbox added
18:34:41 <PatHayes> tnx.
18:34:52 <pfps> we need to be careful to distinguish between side-effecting operations and functional operations
18:35:13 <AndyS> q+ to book a slot on the Q [point to follow]
18:35:26 <davidwood> q-
18:36:12 <davidwood> ack sandro
18:36:12 <Zakim> sandro, you wanted to strawpoll
18:36:14 <PatHayes> I once had lunch with Peter Landin.
18:36:20 <tlebo> +1 @iand's rephrasing of @gavinc's INSERT interpretation
18:36:33 <AlexHall> sandro: do we want to cement this down any more?
18:36:43 <AlexHall> zhe: depends on how you describe the <IRI,graph> pairing
18:36:45 <sandro> STRAWPOLL: SPARQL11-http-rdf-update URLs like /rdf-graphs/service?graph=http%3A// denote graph containers (gboxes).    The embedded URI *might* also denote that same container, for some dataset arrangement patterns.
18:37:01 <cygri> ±1
18:37:06 <mischat> 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 <cygri> +1 actually
18:37:18 <LeeF_> +1
18:37:30 <swh> I have no idea what that means
18:37:31 <tlebo> @iand's interpretation: This is in line with PROV-WG's immutable prov:Entity prov:derivedFrom (a distinct) prov:Entity .
18:37:52 <AndyS> +1
18:37:53 <Souri> Souri has joined #RDF-WG
18:38:13 <PatHayes> +0
18:38:15 <AlexHall> sandro: some people use datasets in such a way that the embedded graph tag will denote the gbox.
18:38:31 <AlexHall> davidwood: can you please define denote for us?
18:39:05 <tlebo> "identifying" is how HTTP dereferencing works; "denotes" is how RDF works.
18:39:13 <tlebo> so says @PatHayes
18:39:16 <davidwood> denotes -> "is a way of referring to".  There may be other ways.
18:39:16 <zwu2> +0
18:39:17 <PatHayes> well, its any naming.
18:39:58 <sandro> 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 <Souri> what are we saying +1, -1, +0, -0 to? (I was disconnected for last few minutes)
18:40:24 <tlebo> PatHayes: things apply to identifying that DO NOT apply to "denotes" - because it lets you access it.
18:40:37 <Guus> smaal reformuulation: "INSERT DATA { GRAPH <iri> { <s> <p> <o> }} means take the gsnap that is the current state of the gbox <iri>, perform an RDF-Merge with <s> <p> <o> and make that the current contents of <iri>"
18:40:50 <sandro> STRAWPOLL: SPARQL11-http-rdf-update URLs like /rdf-graphs/service?graph=http%3A// denote graph containers (gboxes).    The embedded URI *might* also denote that same container, the way some people use datasets.
18:41:04 <PatHayes> pfps, you might be right. 
18:41:28 <tlebo> it's not the same container!
18:42:08 <yvesr> 'might' and 'some' in a strawpoll confuses me :/
18:42:20 <iand> INSERT DATA { GRAPH <iri> { <s> <p> <o> }} implies <iri> rdf:type :gbox
18:42:32 <cygri> iand, no
18:42:35 <PatHayes> <iri> := merge( <iri>, {s p o} )
18:42:43 <pfps> implies in what entailment regime?
18:42:46 <ericP> q?
18:42:53 <AlexHall> sandro: i think most of the confusion here is the connection between IRI and gbox
18:42:54 <cygri> it's both a wave and a particle
18:42:55 <davidwood> iand: We aren't ready to make a statement that <iri> identifies the gbox...
18:42:55 <iand> pfps: in english
18:43:07 <iand> davidwood: i didn't say identifies
18:43:13 <davidwood> ack AlexHall
18:43:15 <yvesr> cygri, but is it dead or alive?
18:43:24 <PatHayes> en-tag
18:43:31 <cygri> yvesr, you won't know before you open the g-box
18:43:36 <sandro> Note that I'm NOT saying the IRI denotes the g-box, but the QUALIFIED one does as per
18:43:36 <davidwood> iand, no, you said rdf:type
18:43:41 <ericP> AlexHall: re: the relationship between the graph store and dataset
18:43:59 <ericP> ... the dsnap is the immutable collection of graphs states taken from the graph store
18:44:20 <ericP> q?
18:44:31 <davidwood> ack AndyS
18:44:31 <Zakim> AndyS, you wanted to book a slot on the Q [point to follow]
18:44:38 <ericP> q+ to ask if this strawpoll is intended to describe a new best practice
18:44:50 <davidwood> ack ericP
18:44:50 <Zakim> ericP, you wanted to ask if this strawpoll is intended to describe a new best practice
18:44:50 <tlebo> <>   !   sameAs     <.../rdf-graphs/service?graph=http%3A//> (but are both rdf2:GraphContainers). However, both have some common skos:broader...
18:45:26 <AlexHall> 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 <AlexHall> ... is it meant to provide guidance? describe best practice? document the only way we can do this?
18:46:03 <AlexHall> sandro: i think this is the only way to do this that makes sense.
18:46:31 <AlexHall> ericP: how can i evaluate this? is there a test case I can throw at it?
18:46:48 <AlexHall> sandro: use it in some RDF
18:46:53 <sandro> <> dc:author sandro:me
18:47:11 <sandro> <> rdf:type r:GraphContainer
18:47:31 <AlexHall> davidwood: we need to adjourn soon
18:47:59 <AlexHall> ericP: don't think we can answer this tonight. perhaps we should write some coherent test cases first.
18:48:07 <tlebo>  TRUE: /rdf-graphs/service?graph=http%3A// a rdf2:GraphContainer; skos:broader ?x . <> a rdf2:GraphContainer; skos:broader ?x .
18:48:28 <AlexHall> davidwood: this example rdf is describing the gbox?
18:48:28 <PatHayes> sandro, this illustrates for me exactly the problem. you are the author of the box.
18:48:32 <AlexHall> sandro: yes
18:48:48 <Guus> q+ to ask Steve/Andy about synching RDF dataset def in SPARQL doc
18:48:59 <tlebo> these GraphContainers are frbr:Items :-)
18:49:05 <AlexHall> ???: what is being described, the box or the graph in the box?
18:49:24 <cygri> q+
18:49:42 <AlexHall> 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 <davidwood> ack Guus
18:49:42 <Zakim> Guus, you wanted to ask Steve/Andy about synching RDF dataset def in SPARQL doc
18:49:53 <sandro> <> eg:refreshRate 3. 
18:50:00 <mischat> mischat has joined #rdf-wg
18:50:03 <AlexHall> ... in this context, might mean that sandro:me is the author is the latest gsnap in the box
18:50:30 <cygri> q-
18:52:19 <AlexHall> guus: can we try re-formulating the definition of SPARQL dataset in terms of the RDF dataset terms?
18:52:30 <AlexHall> davidwood: agenda-bashing time
18:52:44 <PatHayes> i wont be able to be there tomorrow, so y'all might get things done a bit faster :-)
18:52:56 <AlexHall> ... revisit latest formulation of gavin's description of INSERT DATA, can possibly shake out some strawpolls
18:53:41 <AndyS> It is possible to improve - (carefully - safe against later RDF-WG decisions)
18:53:44 <AlexHall> ... as well as sandro's g-box IRI strawpoll
18:54:05 <AlexHall> ... propose to add these items to tomorrow's agenda
18:54:38 <AlexHall> guus: really want to visit the wikidata use case
18:55:18 <AlexHall> sandro: time to assign some homework
18:55:43 <ivan> ISSUE-33?
18:55:43 <trackbot> ISSUE-33 -- Do we provide a way to refer to sub-graphs and/or individual triples? -- open
18:55:43 <trackbot>
18:55:44 <AlexHall> ... look over the issue list for ones you care about or think are obsolete
18:56:04 <AlexHall> davidwood: would like to revisit issue-33
18:56:15 <tlebo> @sandro - we can apply "mangling service endpoint and GRAPH <IRI> 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 <tlebo> BIG elephant: putting semantics in to name of a named graph or not
18:57:04 <AlexHall> guus: still no answer to the issue of whether to put semantics into the relationship between the name and the graph
18:57:29 <AlexHall> sandro: my strawpoll is trying to narrow down that space
18:58:52 <AlexHall> ... clear that we can't have consensus that the IRI denotes the gbox because it will break too much deployed stuff
18:59:40 <AlexHall> davidwood: adjourned
18:59:51 <Zakim> -PatH
18:59:55 <sandro> 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 <sandro> (for tomrrow.)
19:00:00 <Zakim> -MIT_Meeting_Room
19:00:58 <sandro> 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 <sandro> PatHayes, can you formally define g-box for us?
19:06:09 <AndyS> AndyS has left #rdf-wg
19:08:09 <sandro> a g-box, named with zero or more IRIs, is a function (mapping) from time to g-snaps.
19:09:53 <LeeF_> a g-box is a function from the current environment to a g-snap
19:09:57 <LeeF_> that function can be named with an IRI
19:12:53 <sandro> gavin: what about localhost:
19:13:15 <sandro> 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 <sandro> david: people are free to make stupid mistakes; it's just less useful when they do...
19:31:57 <Zakim> -Peter_Patel-Schneider
20:45:32 <AlexHall> AlexHall has joined #rdf-wg
21:14:03 <iand> iand has joined #rdf-wg
21:56:04 <iand> iand has joined #rdf-wg
22:05:01 <Zakim> disconnecting the lone participant, BBC_Meeting_Room, in SW_RDFWG(F2F)6:00AM
22:05:03 <Zakim> SW_RDFWG(F2F)6:00AM has ended
22:05:07 <Zakim> 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 <Zakim> ... AlexHall, sandro, Souri, Scott_Bauer, LeeF, Thomas, PatH, Eric, MIT_Meeting_Room
22:49:25 <Zakim> Zakim has left #rdf-wg
23:38:14 <tomayac> tomayac has joined #rdf-wg
23:40:31 <mischat> mischat has joined #rdf-wg