Difference between revisions of "Chatlog 2010-03-25"

From SPARQL Working Group
Jump to: navigation, search
(putting PRESENT at the top)
Line 2: Line 2:
# clockwise from the top
# clockwise from the top
<sandro> PRESENT: bglimm, axel, andy, steveh, paul_gearon, lee, david, alex, souri, matt_perry, sandro, kasei, ivan
<sandro> PRESENT: bglimm, axel, andy, steveh, paul_gearon, lee, davidc, alex, souri, perry, sandro, kasei, ivan
12:04:31 <RRSAgent> RRSAgent has joined #sparql
12:04:31 <RRSAgent> RRSAgent has joined #sparql
12:04:31 <RRSAgent> logging to http://www.w3.org/2010/03/25-sparql-irc
12:04:31 <RRSAgent> logging to http://www.w3.org/2010/03/25-sparql-irc

Revision as of 13:48, 25 March 2010

See original RRSAgent log and preview nicely formatted version.

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

# clockwise from the top
<sandro> PRESENT: bglimm, axel, andy, steveh, paul_gearon, lee, davidc, alex, souri, perry, sandro, kasei, ivan
12:04:31 <RRSAgent> RRSAgent has joined #sparql
12:04:31 <RRSAgent> logging to http://www.w3.org/2010/03/25-sparql-irc
12:04:33 <trackbot> RRSAgent, make logs world
12:04:33 <Zakim> Zakim has joined #sparql
12:04:35 <trackbot> Zakim, this will be 77277
12:04:35 <Zakim> ok, trackbot; I see SW_(SPARQLF2F)8:00AM scheduled to start 4 minutes ago
12:04:36 <trackbot> Meeting: SPARQL Working Group Teleconference
12:04:36 <trackbot> Date: 25 March 2010
12:04:41 <LeeF> zakim, this will be SPARQL
12:04:41 <Zakim> ok, LeeF; I see SW_(SPARQLF2F)8:00AM scheduled to start 4 minutes ago
12:05:20 <LeeF> +MIT262
#12:07:42 <LeeF> Present: AxelPolleres, bglimm, AndyS, SteveH, LeeF, Ivan, kasei, Souri, MattPerry, pgearon
12:08:08 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/F2F3_Agenda
12:08:40 <SteveH> SteveH has joined #sparql
12:11:58 <pgearon_> pgearon_ has joined #sparql
12:14:29 <bglimm> scribe: bglimm
12:15:05 <bglimm> Agendum: Process for time permitting features
12:15:13 <AxelPolleres> http://www.w3.org/2009/05/sparql-phase-II-charter.html
12:15:13 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/FeatureProposal
12:15:24 <bglimm> AxelPolleres: some things are marked as time permitting
12:15:34 <MattPerry> MattPerry has joined #sparql
12:15:41 <bglimm> ... there is good progress on entailments regimes and property paths
12:16:12 <dcharbon2> dcharbon2 has joined #sparql
12:16:19 <bglimm> ... we though we can move within the group to consider them as non-removable 
12:16:32 <AxelPolleres> PROPOSED: The working group will proceed the time-permitting feature Entailment to Rec
12:16:58 <bglimm> +1
12:17:49 <AxelPolleres> PROPOSED: The working group will intends to take the time-permitting feature "Entailment" through to Rec
12:17:53 <bglimm> +1
12:17:56 <AxelPolleres> +1
12:17:57 <AndyS> +1
12:18:01 <dcharbon2> +1
12:18:01 <Souri> Souri has joined #sparql
12:18:28 <AxelPolleres> RESOLVED: The working group will intends to take the time-permitting feature "Entailment" through to Rec
12:18:38 <bglimm> AxelPoelleres: This is for now mainly an internal decision and does not need to be advertised. 
12:18:51 <bglimm> ... I think we can do the same for property paths
12:18:59 <AxelPolleres> PROPOSED: The working group will intends to take the time-permitting feature "PropertyPaths" through to Rec
12:19:02 <pgearon_> +1
12:19:26 <AxelPolleres> +1
12:19:35 <MattPerry> +1
12:19:53 <AxelPolleres> RESOLVED: The working group will intends to take the time-permitting feature "PropertyPaths" through to Rec
12:20:08 <bglimm> AxelPolleres: These were the two easy ones
12:20:23 <bglimm> ... I want to check the progress of the other ones too. 
12:20:36 <bglimm> ... Function library made some progress too
12:21:32 <bglimm> ...  The comma-select lists seems to be resolved to not have commas
12:21:46 <bglimm> LeeF: That is resolved. 
12:22:06 <bglimm> AxelPolleres: Ok, we don't need to address that any more. 
12:22:20 <bglimm> ... Then there is absic federated queries
12:22:32 <bglimm> s/absic/basic
12:23:02 <bglimm> LeeF: Eric is writing something up for that. 
12:23:11 <AndyS> Syntax feature was not just commas (have put IN,NOT IN to syntax)
12:23:33 <bglimm> ... Andy and I had a short conversation about it. I think we should keep it time permitting, but we may have something for this in the end
12:23:57 <bglimm> AxelPolleres: Lee, can you get a more precise timeline for the feature? 
12:24:18 <bglimm> ... Can we put an action on LeeF to ask Eric for his timeline?
12:24:45 <bglimm> LeeF: Eric said he'll have something ready next week.
12:24:59 <bglimm> LeeF: I'll liase with Eric on this.
12:25:05 <AxelPolleres> ACTION: LeeF to liase with Eric on BFQ and try to get a time schedule.
12:25:05 <trackbot> Created ACTION-203 - Liase with Eric on BFQ and try to get a time schedule. [on Lee Feigenbaum - due 2010-04-01].
12:25:30 <bglimm> AxelPolleres: Any progress on IN and BETWEEN operators?
12:25:54 <bglimm> AndyS: IN is in the grammar, BETWEEN is not
12:26:11 <AxelPolleres>  IN is in the grammar, BETWEEN unclear.... no real enthusiasm.
12:26:32 <bglimm> ... I didn't see much enthusiasm for anything more than what we have now 
12:27:17 <SteveH> SteveH has joined #sparql
12:27:23 <bglimm> IvanH: Adding features after last call, it is difficult to put them in. So we have to add it now if we want it. 
12:28:28 <bglimm> .... if it is just a small feature that goes into one of the existing documents like IN, then it can possibly be added, but adding more ocuments is not really possible.
12:29:02 <bglimm> AndyS: Could we add some documents now and turn it into a note if we run out of time?
12:30:00 <bglimm> AxelPolleres: I just want to get some order into the time permitting features. 
12:30:26 <bglimm> ... I want to decide which things go definitely in and which ones we will definitely not in
12:31:16 <bglimm> .... property path and entailment is clearly in, function library is being worked on, but we should push it a bit more
12:31:16 <AxelPolleres> agreement that IN/BETWEEN is in the scope ofTF-Func, I am fine for the moment. 
12:31:52 <bglimm> ... anything to add for the time permitting features discussion?
12:32:05 <bglimm> ... Ok, lets go to the update issues
12:32:20 <bglimm> ... The agenda lists several topics that need discussion
12:32:40 <bglimm> ... we want to nail down the syntax during the F2F
12:32:49 <bglimm> ... First: CREATE and DROP
12:33:15 <bglimm> ... CREATE and DROP are currently in the spec.
12:33:21 <LeeF> http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml is the current draft of the SPARQL Update spec
12:33:46 <LeeF> q+ to ask about SILENT
12:33:49 <bglimm> ?: We decided that we want to be able to create a graph explicitly
12:33:57 <LeeF> s/?/pgearon/
12:34:02 <Souri> q+
12:34:06 <sandro> RRSAgent, pointer?
12:34:06 <RRSAgent> See http://www.w3.org/2010/03/25-sparql-irc#T12-34-06
12:34:08 <AxelPolleres> INSERT GRAPH <a> WHERE {}
12:34:31 <bglimm> AxelPolleres: Is that the same as create graph <a>?
12:35:06 <LeeF> INSERT { GRAPH <a> { } } WHERE { }   is equivalent   to  CREATE GRAPH <a> ?
12:35:44 <bglimm> LeeF:  I am not sure it is the same
12:35:55 <AndyS> INSERT { GRAPH <a> { } } WHERE { FILTER(false) } 
12:36:13 <bglimm> pgearon: Some implementations might treat it as the same, others might not
12:37:34 <bglimm> LeeF: Difference between my and AndyS is that in Andy's the filter fails the only identity solution, in both cases I think the graph store wouldn't do anything
12:37:35 <AxelPolleres> agreement that "empty insertion" doesn't create graph? 
12:37:37 <SteveH> SteveH has joined #sparql
12:37:49 <AndyS> q+
12:38:10 <bglimm> IvanH: We always agree that creating graphs is useful, so what are we discussing here?
12:38:18 <AxelPolleres> ack LeeF
12:38:18 <Zakim> LeeF, you wanted to ask about SILENT
12:38:48 <bglimm> LeeF: I wanted to discuss whether we want to keep silent for CREATE and DROP
12:38:59 <bglimm> ... from a syntax point of view
12:39:07 <bglimm> ... What does it do?
12:39:19 <bglimm> AxelPolleres: It throws no errors.
12:39:44 <bglimm> LeeF: We need to tighten up the way the spec talks about errors
12:39:51 <AxelPolleres> we have the errors already defined in protocol, BTW,  GraphDoesNotExist,  GraphAlreadyExists...
12:40:08 <ivan> q+ on non-silent if the graph exists and and create occurs
12:40:20 <bglimm> LeeF: I am happy about the idea of having SILENT
12:40:55 <bglimm> AxelPolleres: Would we need SILENT also for other update constructs?
12:41:12 <bglimm> LeeF: It is a common thing for CREATE and DROP
12:41:50 <AxelPolleres> As for SILENT in other statements, I wouldn't see any errors except query syntax errors in other statements except CREATE/FROP to be honest, though
12:41:59 <bglimm> pgearon: Implementations at the moment give you an error or not. It would be good if we can configure this.
12:42:21 <bglimm> SteveH: In SQL you can also force it to not raise error for key violations etc
12:42:38 <bglimm> LeeF: Is anybody proposing to add that for other constructors?
12:42:46 <bglimm> AxelPolleres: I don't think so. 
12:42:51 <bglimm> LeeF: Lets move on then. 
12:42:52 <AndyS> q?
12:43:10 <AxelPolleres> ack Souri
12:43:35 <bglimm> Souri: How do you want to see a store as graph store or quad store?
12:44:27 <bglimm> ... If a query comes in, are we distinguishing between the case when we have an empty graph or the graph just does not exist?
12:44:48 <bglimm> LeeF: If we have drop and create, this implies that we can have empty graphs
12:45:09 <bglimm> ... you can also insert into a graph that does not exist, that will just create the graph
12:45:47 <bglimm> Souri: If a query comes in for an empty graph and the query want to select something it is different from the situation when there is no such graph
12:46:37 <AxelPolleres> q?
12:46:38 <bglimm> ... we don't really know beforehand which graphs are there, there are not really any graphs beforehand
12:47:02 <AxelPolleres> ASK {GRAPH <g> {} }
12:47:04 <AxelPolleres> ?
12:47:18 <AndyS> SELECT ?g { GRAPH ?g {}}
12:47:19 <LeeF> ASK { GRAPH <a> { } }
12:47:46 <bglimm> LeeF: Both queries distinguish this difference
12:47:50 <AxelPolleres> q?
12:47:55 <AxelPolleres> ack AndyS
12:47:59 <LeeF> ack AndyS
12:48:08 <bglimm> AndyS: I think the behaviour is clear in the query spec.
12:48:15 <Souri> Souri has joined #sparql
12:48:40 <bglimm> ... RDF assumes that if there are no triples, then there is no graph
12:49:25 <pgearon> +q
12:49:37 <bglimm> ... the difference is whether you do data management or not and I think we need a clear model for what we want
12:49:48 <LeeF> I thought we did have an emerging consensus model :)
12:50:15 <bglimm> ... I don't think there is one model that suits all situations
12:51:03 <sandro> andy: 1 -- all named graphs exist     [except RDF has no empty graphs]
12:51:03 <sandro> andy: 2 -- auto-create:   add+remove ... then exists?  (sql insert row)
12:51:03 <sandro> andy: 3 -- fixed dataset     (sql create table)
12:51:03 <sandro> andy: 4 -- explicit add new graphs
12:51:32 <LeeF> I'm not sure that the model that I thought was emerging is captured in those 4 :-)
12:51:58 <AxelPolleres> I hear:
12:51:59 <bglimm> AndyS: There might be even more model
12:51:59 <AxelPolleres> * OPTION 1: all named graphs exist
12:51:59 <AxelPolleres> * OPTION 2: created (explicitly or implicitly) graphs exist (whether empty or not)
12:52:00 <AxelPolleres> * OPTION 3: only graphs with triples in them exist (invalidates CREATE/DROP) = quads
12:52:40 <bglimm> LeeF: Model I heard emerging is that  graphs exist as an entity of their own
12:53:03 <bglimm> ... I haven't heard support for explicit  dropping of empty graphs
12:53:41 <bglimm> ... System can refuse queries, e.g., they can refuse queries to create a graph if they have just a fixed data set
12:53:46 <AxelPolleres> I had thought we are heading towards Option 2 so far...
12:53:54 <bglimm> AndyS: Implicit graph creation seems important to people
12:54:39 <LeeF> q?
12:54:41 <sandro> q?
12:55:01 <bglimm> ... It would be best if a processor can decide upfront whether it will reject the query and not generate a runtime error half way through processing a query
12:55:07 <SteveH> SteveH has joined #sparql
12:55:15 <AxelPolleres> ... pure quad stores need some extra triples to decribe  graphs for Option 2 to get around that
12:55:27 <AxelPolleres> ack ivan
12:55:27 <Zakim> ivan, you wanted to comment on non-silent if the graph exists and and create occurs
12:55:30 <bglimm> IvanH: I am not sure that there cannot be empty graphs. 
12:55:59 <LeeF> q+ ivan
12:56:10 <LeeF> ack pgearon
12:56:11 <bglimm> AndyS: There is just one empty set, so all empty graphs are the same under this view
12:56:53 <AndyS> I liked the suggestion of graph store as set of defaul graph + (name, graph) tuples
12:56:56 <LeeF> q+ ivan to comment on non-silent if the graph exists and and create occurs
12:57:25 <bglimm> pgearon: The fact that RDF does not have an idea about changing graphs, but the way we look at this in update means that graphs can evolve over time
12:57:40 <bglimm> ... from that point of view we can have different empty graphs
12:57:53 <sandro> zakim, who is here?
12:57:53 <Zakim> SW_(SPARQLF2F)8:00AM has not yet started, sandro
12:57:54 <Zakim> On IRC I see SteveH, Souri, dcharbon2, MattPerry, pgearon, Zakim, RRSAgent, ivan, AndyS, LeeF, AxelPolleres, bglimm, iv_an_ru, karl, sandro, AlexPassant, kasei, trackbot
#12:58:27 <LeeF> Present+ dcharbon2, Souri, MattPerry, AlexPassant
12:58:29 <bglimm> ... we are diverging here anyway from RDF because RDF itself does not consider any changes to a graph, but we do
12:59:08 <bglimm> AxelPolleres: Can I interpret this as support for having empty graphs? 
12:59:25 <bglimm> ... The fact that we have drop and create also seems to go in this direction
13:00:12 <bglimm> pgearon:  it would be odd to assume that everything that was not dropped exists
13:01:09 <AndyS> Test case: SELECT ?g { GRAPH ?g {} } => ? ; add quads (q,s,p,o) ; delete (q,s,p,o) ; SELECT ?g { GRAPH ?g {} } => ?
13:01:16 <bglimm> LeeF: The approach that all named graphs exists worries me a bit because this might prevent two graph stores with the same graphs
13:01:17 <AndyS> s/quads/quad
13:01:26 <sandro> lee: I'd like us to be supportive of the (unfortunate?) state of the world where the same named graph occurs with different contents in multiple quadstores.
13:01:33 <AxelPolleres> q?
13:01:34 <Souri> q+
13:01:56 <LeeF> s/two graph stores with the same graphs/two graph stores with the same graph names with different contents/
13:02:06 <LeeF> ack Souri
13:02:20 <dcharbon2> q+
13:02:24 <bglimm> Souri: If we don't have to explicitly create a graph, that would be more clear conceptually. 
13:02:28 <AndyS> q+ to ask souri if graph names are dynamic in RDF2RDB?
13:02:47 <AxelPolleres> q+ to ask whether we can narrow down to 2 options over all
13:02:50 <ivan> q-
13:02:57 <LeeF> ack dcharbon2
13:02:59 <LeeF> ack dcharbon
13:04:05 <bglimm> dcharbon2: Couldn't we codify that by assuming there is a graph of graphs (like a dataset) nd you can query this extra graph?
13:04:22 <AxelPolleres> "system gaph" seems to be  the way to encode empty graph existence in quad stores. 
13:04:30 <bglimm> Souri: We do not know which graphs are in the data. 
13:05:15 <bglimm> Sandro: Can you not query the data to see which graphs exist? 
13:05:29 <bglimm> Souri: We would have to do that for each query. 
13:05:38 <AlexPassant2> AlexPassant2 has joined #sparql
13:05:44 <AxelPolleres> q?
13:06:40 <bglimm> Souri: Every query would have to create a corresponding view
13:07:21 <sandro> souri: [[maybe?]]  the set of graphs which exist, in our RDB2RDF approach, is only defined for a particular query
13:07:27 <LeeF> ack AndyS
13:07:27 <Zakim> AndyS, you wanted to ask souri if graph names are dynamic in RDF2RDB?
13:09:04 <bglimm> SteveH: I like the approach that if you remove the last triple, the graph can disappear. 
13:09:21 <sandro> SteveH: A lot of the trivial implementation of sparql are pure quads, where removing the last quad removes the graph.
13:09:40 <AndyS> AndyS has joined #sparql
13:09:58 <Souri> q+
13:10:07 <bglimm> SteveH: This ould be implementation defined.
13:10:15 <bglimm> s/ould/would/
13:10:23 <sandro> q+ to argue against implementation defined, since it's pretty trivial to go either way
13:10:47 <bglimm> AxelPolleres: This all ends up in the question whether we allow for empty graphs or not
13:11:37 <bglimm> .... you could implicitly create a graph on insert and implicitly drop it when it is empty
13:11:58 <Souri> Souri has joined #sparql
13:13:54 <sandro> q-
13:14:05 <bglimm> AxelPolleres: I see 3 ways to go: 1) Having empty graphs (quads only) 2) not having them 3) allow both and service descriptions are used to declare what the store does
13:14:08 <AxelPolleres> q?
13:14:14 <AxelPolleres> ack Axel
13:14:14 <Zakim> AxelPolleres, you wanted to ask whether we can narrow down to 2 options over all
13:14:45 <bglimm> Sandro: A graph that you don't know is not the same as the empty graph
13:15:02 <bglimm> If you are asked to create it, then you know it is empty
13:15:12 <pgearon> q+
13:15:15 <bglimm> s/If/...If/
13:15:33 <LeeF> My thoughts are at: http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model
13:15:59 <bglimm> Souri: If we are querying an empty graph is that different from querying something that does not exist? 
13:16:13 <sandro> sandro: think about stores which can sometimes query the web....      what does CREATE mean in that case?   I think it means "I know this graph, and it's empty."
13:16:24 <bglimm> ... it gets difficult to distinguish the two situations
13:16:30 <dcharbon2> q+ if we allow a choice, don't we need to spec what happens in each case?
13:16:42 <dcharbon2> q+
13:16:51 <LeeF> ack souri
13:16:53 <AxelPolleres> Can we go around and ask what current implementations do on queries for "non-existinent/non-known" graphs? 
13:17:41 <bglimm> pgearon: Systems that want permissions on who can read and write to a graph are complicated when we assume that all possible graphs exist
13:18:03 <bglimm> ... If you have to explicitly create something, then setting permissions would be easier
13:18:31 <bglimm> Sandro: You could do that by setting this on the quad level
13:18:54 <AxelPolleres> seems Paul's use case needs "default" permissions then for implicit creation?  
13:19:11 <bglimm> pgearon: I know permissions are outside of the spec, but they are still necessary 
13:19:14 <AxelPolleres> q?
13:19:27 <ivan> ack pgearon 
13:19:58 <LeeF> Souri, I think the case that you are concerned about for RDBs can be handled by an engine that posits a universe that contains all possible graphs, many of which are empty -- then any FROM NAMED in a query always refers to an existing graph, and you can just do the natural thing (which is to treat nonexistent graphs as empty). The problem occurs if someone asks this query: SELECT ?g { GRAPH ?g { } }  -- what would you _like_ the results of that query to be in the RD
13:21:09 <bglimm> pgearon: If we have create permissions are easy. If we create implicitly it is more difficult
13:21:40 <bglimm> SteveH: You could just have a command for setting permission. I can't see how create makes a real difference
13:21:59 <sandro> SteveH: setting permission could implicitely create it.
13:22:31 <ivan> q?
13:22:37 <Souri> Lee, I agree. The query you mentioned would be a bit difficult to answer. We could return the SELECT distinct <graphURI> FROM all the relational views (needs a UNION). The semantics may be that "these are the non-empty graphs"
13:22:39 <bglimm> AndyS: I see you want CREATE so that you can set permission at creation time, but would you object to also have systems that do it differently?
13:22:43 <ivan> q+
13:22:51 <LeeF> ack dcharbon2
13:22:52 <LeeF> ack dcharbon
13:22:53 <bglimm> pgearon: No, but I would like to have CREATE in the language
13:23:05 <AxelPolleres> q+ to ask whether we have "graph created", "graph dropped" in the protocol?
13:24:14 <bglimm> dcharbon2: If the endpoint supports having empty graphs, we would have to define the behaviour in this case, e.g., getting a UR back for an empty but existing graph versus getting an empty answer
13:25:02 <bglimm> AndyS: There could be 2 different definitions, one for systems with bookkeeping and one for systems without
13:25:27 <sandro> "bookkeeping"
13:25:48 <AxelPolleres> q?
13:25:50 <Souri> q+
13:25:51 <sandro> andy: I like "bookkeeping" functions, which are perhaps optional.
13:26:00 <Souri> q-
13:26:06 <LeeF> ack ivan
13:26:20 <pgearon> +1 for andy's book keeping concept
13:27:52 <bglimm> IvanH: I don't understand what's happening. A graph has a URI, no data store knows whether that graph is empty or not. We only add a URI to our knowledge, we just add a URI to those graphs we know about, so create is probably not even the right keyword, it is more add
13:27:54 <SteveH> +1 to ivan 
13:28:43 <sandro> sandro: A very safe form of CREATE is where the URI is owned by this quadstore.
13:28:44 <AxelPolleres> q?
13:28:54 <bglimm> ... There is a process of minting a new fresh URI, but normally, you just add an existing URI to the store
13:29:04 <kasei> sandro, even when it's owned by you, someone else might have asserted triples in it previously, no?
13:29:12 <kasei> so, maybe just safeER.
13:29:25 <sandro> perhaps, kasei 
13:29:29 <AxelPolleres> ack axel
13:29:29 <Zakim> AxelPolleres, you wanted to ask whether we have "graph created", "graph dropped" in the protocol?
13:29:40 <bglimm> pgearon: I do create a local version of the graph that sits somewhere for a given URI, so there is a difference
13:30:27 <bglimm> AxelPolleres: Renaming CREATE into ADD solves Ivan's concern, but gives a slightly different view. 
13:31:14 <AxelPolleres> Can we go around and ask what current implementations do on queries for "non-existinent/non-known" graphs?
13:31:20 <bglimm> AndyS: I have a pure quad store and one where empty graphs can be in the store if it has been mentioned before
13:32:21 <bglimm> SteveH: 4Store has a difference between empty graphs and non-existing graphs (pure quad store), but we hide this difference from users as good as we can
13:32:29 <AxelPolleres> {GRAPH <g> {}}
13:32:38 <dcharbon2> Perhaps no one wants the answer to SELECT ?g WHERE { GRAPH ?g {} } if we assume all graphs exist - or we'd need to specify that you get nothing back in that case
13:32:51 <dcharbon2> else - it's an infinite list
13:32:57 <pgearon> what about SELECT * FROM <g> WHERE {}
13:33:05 <sandro> SteveH: 5store is a pure quadstore so it doesn't distinquish existing from empty.
13:33:30 <SteveH> ^ - non-existing
13:34:10 <bglimm> pgearon: mulgara is quadstore with bookkeeping, so you can query for empty graphs
13:34:27 <bglimm> ... if you select from a graph that does not exist it gives an error
13:35:14 <bglimm> LeeF: same as pgearon. If you specify a graph that is not in the graph store, then it's an error
13:36:24 <bglimm> dcharbon2: Stores I know of mostly don't have bookkeeping
13:36:55 <bglimm> Souri: Oracle has a triple store, no named graphs support
13:37:40 <bglimm> ... queries for non-existing graphs return empty results, we are planning to support named graphs
13:39:22 <bglimm> ... for security, we thought about having certain namespaces that are allowed for inserts, like private datasets for users
13:39:54 <bglimm> AxelPolleres: In that model if you ask for a model that does not exist would that give an error
13:40:02 <bglimm> Souri: Yes. 
13:40:53 <bglimm> ... if you don't have the privildges to see it, then it is an error
13:41:08 <bglimm> ... we say it doesn't exist