IRC log of sparql on 2010-02-23

Timestamps are in UTC.

14:42:09 [RRSAgent]
RRSAgent has joined #sparql
14:42:09 [RRSAgent]
logging to
14:42:11 [trackbot]
RRSAgent, make logs world
14:42:11 [Zakim]
Zakim has joined #sparql
14:42:13 [trackbot]
Zakim, this will be 77277
14:42:13 [Zakim]
ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 18 minutes
14:42:14 [trackbot]
Meeting: SPARQL Working Group Teleconference
14:42:14 [trackbot]
Date: 23 February 2010
14:42:16 [LeeF]
zakim, this will be SPARQL
14:42:16 [Zakim]
ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 18 minutes
14:42:25 [LeeF]
14:42:39 [LeeF]
Regrets: AlexP
14:42:49 [OlivierCorby]
OlivierCorby has joined #sparql
14:47:31 [AxelPolleres]
AxelPolleres has joined #sparql
14:54:30 [dcharbon2]
dcharbon2 has joined #sparql
14:55:38 [Zakim]
SW_(SPARQL)10:00AM has now started
14:55:45 [Zakim]
14:55:55 [LeeF]
zakim, Lee_Feigenbaum is me
14:55:55 [Zakim]
+LeeF; got it
14:55:57 [LeeF]
Chair: LeeF
14:56:40 [LeeF]
dcharbon2, any update on whether you'll be able to make the face to face in March?
14:56:42 [Zakim]
14:57:57 [Zakim]
14:58:09 [AndyS]
zakim, ??P8 is me
14:58:09 [Zakim]
+AndyS; got it
14:58:29 [MattPerry]
MattPerry has joined #sparql
14:58:56 [Zakim]
14:59:07 [dcharbon2]
Hi Lee, I'm working on arranging the travel - it hinges on having a customer to talk to while I'm in Boston. The outlook is good at this point, but still not fixed
14:59:12 [Zakim]
14:59:21 [Zakim]
+ +1.603.897.aaaa
14:59:31 [Zakim]
14:59:35 [Prateek]
Prateek has joined #sparql
15:00:04 [LeeF]
zakim, aaaa is MattPerry
15:00:04 [Zakim]
+MattPerry; got it
15:00:34 [LeeF]
zakim, who's on the phone?
15:00:34 [Zakim]
On the phone I see LeeF, bglimm, AndyS, pgearon, OlivierCorby, MattPerry, kasei
15:00:45 [bglimm]
Zakim, mute me
15:00:45 [Zakim]
bglimm should now be muted
15:00:56 [kasei]
Zakim, mute me
15:00:56 [Zakim]
kasei should now be muted
15:01:39 [LeeF]
Before we get started, suggest people take a look at last week's minutes -
15:01:43 [chimezie]
chimezie has joined #sparql
15:02:17 [Zakim]
15:02:18 [Zakim]
+ +1.919.332.aabb
15:02:32 [dcharbon2]
zakim, aabb is me
15:02:32 [Zakim]
+dcharbon2; got it
15:03:01 [kasei]
not really
15:03:02 [bglimm]
15:03:07 [kasei]
15:03:07 [bglimm]
Zakim, unmute me
15:03:16 [Zakim]
bglimm should no longer be muted
15:03:23 [kasei]
scribenick: kasei
15:03:41 [Zakim]
15:03:45 [ivan]
zakim, dial ivan-voip
15:03:47 [Zakim]
15:03:50 [SteveH]
Zakim, ??P34 is SteveH
15:04:03 [Zakim]
ok, ivan; the call is being made
15:04:07 [Zakim]
15:04:13 [Zakim]
+SteveH; got it
15:04:25 [Zakim]
15:04:27 [AxelPolleres]
Zakim, I don't know who I am ;-)
15:04:31 [Zakim]
I'm glad that smiley is there, AxelPolleres
15:06:07 [kasei]
topic: admin
15:06:08 [LeeF]
PROPOSED: Approve minutes at
15:06:38 [LeeF]
RESOLVED: Approve minutes at
15:06:53 [sandro]
15:07:16 [AxelPolleres]
ouch, I can't be there next week!
15:07:17 [kasei]
LeeF: update on f2f. axel and lee to start coming up with agenda
15:07:35 [AxelPolleres]
... so regrets
15:07:37 [kasei]
... nail down big open issues, use f2f time to sort through them. work on test cases.
15:07:53 [chimezie]
Zakim, mute me
15:07:53 [Zakim]
Chimezie_Ogbuji should now be muted
15:07:56 [kasei]
... start to think about last call.
15:08:24 [kasei]
LeeF: some new comments coming in. doing pretty well at dealing with them.
15:08:38 [kasei]
... will do a once over on the comments next week to make sure we're in good shape.
15:08:56 [kasei]
topic: liaisons
15:09:19 [kasei]
topic: update
15:09:34 [kasei]
LeeF: pgearon sent out an email summarizing open issues.
15:09:55 [kasei]
... I'll summarize my understanding of the issues, then let pgearon take over.
15:09:57 [AndyS]
Paul's email:
15:10:09 [kasei]
pgearon: some discussion on mailing list, but didn't see concensus on them.
15:10:37 [kasei]
LeeF: issue in editor's draft about ambiguous delete syntax
15:10:49 [kasei]
... proposal to seperate update statements in single request with semicolons.
15:10:57 [LeeF]
15:11:08 [kasei]
... discussion on the list, most up to date from AndyS.
15:11:38 [AxelPolleres]
q+ to mention small side issue, which is why not allow the same shortcut that we allwo for INSERT/DELETE for CONSTRUCT as well?
15:11:39 [kasei]
... summary: shortcut form (deletes everything matched in the pattern)
15:11:46 [LeeF]
instead of the shortcut being "DELETE { template }" it would be "DELETE WHERE { template pattern }"
15:11:57 [kasei]
... DELETE WHERE { template pattern }
15:11:57 [SteveH]
15:11:59 [AxelPolleres]
aside from that +1 to make WEHRE obligatory
15:12:13 [AxelPolleres]
15:12:25 [ivan]
15:12:32 [kasei]
pgearon: nothing to add to this summary
15:12:33 [LeeF]
ack SteveH
15:12:54 [kasei]
SteveH: wanted to emphatically add +1, been playing with this recently and much more pleasant to deal with
15:13:12 [SteveH]
15:13:40 [kasei]
SteveH: as human found easier to process visually with semicolons
15:13:47 [ivan]
+1 to SteveH
15:13:54 [sandro]
as a human, wouldn't you put each on its own line?
15:14:10 [kasei]
LeeF: hearing general agreement for DELETE WHERE as shortcut form
15:14:18 [SteveH]
sandro, yeah, but I have newlines in there anyway
15:14:19 [ivan]
15:14:22 [AxelPolleres]
@Steve... similar/related to question for ',' in SELECT?
15:14:28 [AndyS]
s/triple patterns/quad templates/
15:14:35 [kasei]
... advice to editor is shortcut form should be DELETE WHERE
15:15:03 [kasei]
... summarizing steveh, semicolons aren't necessary but nice to have
15:15:34 [kasei]
... probably just a matter of taste. any other strong feelings?
15:15:39 [AxelPolleres]
-1 to require
15:15:41 [AndyS]
15:15:51 [pgearon]
+1 for allowing (not requiring)
15:15:53 [kasei]
ivan: thought steve was wanting to allow, not require.
15:16:04 [AxelPolleres]
0 to allow
15:16:05 [kasei]
SteveH: wanted to allow, not forbit.
15:16:17 [SteveH]
require not forbid
15:16:25 [kasei]
AndyS: don't like them. if you append a statement, you have to go back to add semicolons.
15:16:32 [LeeF]
ack AndyS
15:16:32 [pgearon]
15:16:37 [kasei]
15:16:37 [LeeF]
ack pgearon
15:16:40 [kasei]
(sorry steve)
15:16:44 [kasei]
15:16:54 [kasei]
pgearon: if we're talking about allowing, doesn't matter if it's there or not.
15:17:09 [kasei]
SteveH: not talking about allowing, but requiring.
15:17:27 [kasei]
pgearon: if it's optional, people who find it appealing can use it, others dont' have to.
15:17:44 [kasei]
SteveH: then queries written by others are hard to read. doesn't help anybody.
15:18:01 [kasei]
... not an opinion from others. just a personal preference.
15:18:25 [kasei]
LeeF: inclined to proceed without requiring them.
15:18:33 [LeeF]
15:18:54 [kasei]
axel: all on the same side on not wanting to require them, but what about allowing?
15:19:07 [kasei]
LeeF: no strong agreement on making them optional. don't want to float that as a suggestion.
15:19:14 [LeeF]
ack AxelPolleres
15:19:14 [Zakim]
AxelPolleres, you wanted to mention small side issue, which is why not allow the same shortcut that we allwo for INSERT/DELETE for CONSTRUCT as well?
15:19:41 [kasei]
Axel: shortcut notation for DELETE, why not also for CONSTRUCT?
15:19:42 [SteveH]
+1 to AxelPolleres
15:20:02 [kasei]
LeeF: decided not to because it doesn't accomplish anything. it's a noop.
15:20:05 [AndyS]
q+ to ask about protocol
15:20:14 [kasei]
... discussion about this on the mailing list.
15:20:25 [ivan]
just for my understanding: CONSTRUCT WHERE XXX would mean CONSTRUCT {?s ?p ?o} WHERE XXX
15:20:41 [kasei]
Axel: allowing arbitrary where patterns, unclear what it means. if you only allow restricted templates, it looks reasonable.
15:20:42 [SteveH]
ivan, I thin it's
15:20:44 [LeeF]
ack AndyS
15:20:44 [Zakim]
AndyS, you wanted to ask about protocol
15:20:53 [SteveH]
15:21:07 [kasei]
AndyS: unclear about the proposal. construct returns a result. what is the return type from construct?
15:21:14 [LeeF]
I believe the proposal is "CONSTRUCT WHERE { XXX }"""
15:21:34 [ivan]
15:21:37 [kasei]
LeeF: shortcut form would limit what's in the where clause.
15:21:59 [kasei]
AndyS: slightly different restriction. pattern would have to be triple patterns. in DELETE the pattern allows quad patterns.
15:22:12 [kasei]
Axel: having quad patterns in CONSTRUCT would be worth discussing.
15:22:33 [kasei]
LeeF: we don't have any way to return quad results. can't point at any syntax.
15:22:53 [kasei]
... discussed quads in construct in the past, and not in a position to do it right now.
15:22:53 [SteveH]
15:23:00 [LeeF]
ack SteveH
15:23:36 [kasei]
SteveH: seems like a natural thing to do. leaves it open for next WG when there is a quad syntax they can point at.
15:23:52 [kasei]
LeeF: falls within syntactic sugar. does anybody have reservations about this?
15:24:04 [kasei]
AndyS: entirely around protocol issues.
15:24:11 [kasei]
LeeF: not sure I see them. what are they?
15:24:38 [kasei]
AndyS: setting expectations that we can return quads. happy to return quads, but that affects protocol and APIs.
15:25:04 [kasei]
LeeF: so it's an expectation thing.
15:25:35 [kasei]
SteveH: if we say it's not a valid 1.1 query if it includes the GRAPH keyword, don't see the problem.
15:25:41 [AxelPolleres]
we would essentially need to push forward to rubbber-stamp NQuads or TriG ... to be able to return something... is that the concern?
15:25:46 [LeeF]
zakim, who's on the phone?
15:25:46 [Zakim]
On the phone I see LeeF, bglimm, AndyS, pgearon, OlivierCorby, MattPerry, kasei, Sandro, dcharbon2, Chimezie_Ogbuji (muted), SteveH, Ivan, AxelPolleres
15:25:57 [SteveH]
AxelPolleres, if we allowed GRAPH, yeah
15:26:00 [ivan]
15:26:04 [kasei]
LeeF: are others indifferent? passively in favor?
15:26:12 [LeeF]
ack ivan
15:26:15 [AndyS]
q+ about NQ and TriG
15:26:26 [kasei]
ivan: like CONSTRUCT shortcut, but nervous about quad issue.
15:26:26 [AndyS]
q+ to speak to NQ and TriG
15:26:33 [AxelPolleres]
yes, I am afraid that is beyond our scope. :-(
15:26:36 [kasei]
... we don't have a standard in this direction. we shouldn't get into that.
15:26:51 [pgearon]
15:27:02 [LeeF]
ack AndyS
15:27:02 [Zakim]
AndyS, you wanted to speak to NQ and TriG
15:27:05 [kasei]
... that's a SPARQL 2 issue. if we have a WG that handles quad issue, SPARQL can come back and deal with it. not the other way around.
15:27:09 [AxelPolleres]
15:27:37 [kasei]
AndyS: both nquads and trig aren't sufficiently defined to work as reliable transfer formats. details like bnodes.
15:27:50 [LeeF]
15:27:55 [kasei]
... solvable problems, but not enough detail right now for interop.
15:28:14 [kasei]
LeeF: taking as a given that there aren't any sufficient quad formats at this time.
15:28:27 [LeeF]
ack pgearon
15:28:34 [kasei]
AndyS: wanted to raise issue that we're raising expectations.
15:28:34 [AndyS]
ack me
15:28:38 [SteveH]
15:29:04 [kasei]
pgearon: agree that quad format will be coming. we should look at doing something when that happens. until then can't consider it.
15:29:14 [kasei]
... future WG should deal with it.
15:29:17 [AndyS]
Good news: the SPARQL spec already has triple template.
15:29:23 [kasei]
... symmetry between CONSTRUCT and insertion.
15:29:46 [kasei]
... already have graphs inside pattern. can insert into multiple graphs at the same time. want symmetry with CONSTRUCT.
15:29:51 [LeeF]
ack AxelPolleres
15:30:27 [kasei]
Axel: maybe we could resolve that like sparql 1 did triple patterns (literals in subject position).
15:30:36 [AndyS]
Different issue - literals in subject can't be stopped due to variables.
15:30:51 [AndyS]
and owl:sameAs :-)
15:30:51 [kasei]
... spec shouldn't say it supports GRAPH in CONSTRUCT, but could still allow the shortcut.
15:30:56 [LeeF]
15:30:59 [LeeF]
ack SteveH
15:31:00 [ivan]
15:31:24 [kasei]
SteveH: can see AndyS' concern, but don't agree.
15:31:31 [AxelPolleres] also allows more than current RDF allows.
15:31:34 [kasei]
... does raise expectation, but INSERT does that all on its own.
15:31:40 [LeeF]
ack ivan
15:32:08 [kasei]
ivan: not in favor of that. shouldn't do anything which will make it possible later to add it. but not kosher to add it now.
15:32:17 [kasei]
LeeF: don't understand why not kosher now?
15:32:26 [kasei]
ivan: talking about GRAPH in CONSTRUCT.
15:32:35 [chimezie]
Zakim, unmute me
15:32:35 [Zakim]
Chimezie_Ogbuji should no longer be muted
15:32:40 [AxelPolleres]
I asked (not suggested ;-) ) Why wouldn't it be kosher with leaving the return format undefined?
15:32:45 [SteveH]
AndyS, yeah, well you know my opinion on the optional WHERE...
15:32:57 [AxelPolleres]
... but fair enough to not go that far
15:33:20 [kasei]
LeeF: even if spec says CONSTRUCT has to use triple patterns, leads people to think they can use more complex patterns.
15:33:29 [AndyS]
I'd say don't have WHERE at all - it adds nothing and the {} are more than enough.
15:33:41 [kasei]
... straw poll to see where people stand?
15:33:42 [SteveH]
AndyS, yeah, except that it's needed in INSERT shortcut
15:34:13 [LeeF]
straw poll: support for adding a CONSTRUCT WHERE { triple patterns } construct as a short cut for CONSTRUCT {XXX} WHERE {XXX}
15:34:16 [SteveH]
15:34:22 [ivan]
15:34:26 [LeeF]
15:34:28 [AxelPolleres]
15:34:30 [dcharbon2]
15:34:31 [MattPerry]
15:34:32 [bglimm]
15:34:32 [kasei]
15:34:34 [AndyS]
15:34:34 [chimezie]
15:34:41 [pgearon]
15:34:53 [kasei]
LeeF: reasonable concensus in favor of adding shortcut.
15:35:14 [pgearon]
15:35:15 [SteveH]
15:35:39 [AndyS]
Added to my ToDo list. Steve and I can work the detailed chnages out later.
15:35:54 [LeeF]
ACTION: Steve to work with Andy to add CONSTRUCT WHERE { triple pattern } shortcut to query spec
15:35:55 [trackbot]
Created ACTION-200 - Work with Andy to add CONSTRUCT WHERE { triple pattern } shortcut to query spec [on Steve Harris - due 2010-03-02].
15:36:11 [kasei]
pgearon: wanted to confirm that shortcut will be like selecting *.
15:36:28 [AndyS]
Concrete example?
15:36:44 [kasei]
having trouble following this and scribing :\
15:36:58 [kasei]
LeeF: request for more details on mailing list
15:37:07 [LeeF]
15:37:13 [kasei]
... next update issue is ISSUE-20.
15:37:25 [kasei]
... graph aware vs. quad stores vs. update.
15:37:32 [SteveH]
15:37:47 [kasei]
... not sure exactly what it means. graphs that exist without anything in them.
15:38:00 [kasei]
... creating empty graphs and droping potentially empty graphs.
15:38:19 [kasei]
... what's the current state of the update spec?
15:38:29 [LeeF]
ack pgearon
15:38:33 [kasei]
pgearon: right now we allow graphs that have nothing in them.
15:38:50 [kasei]
... create graph will create a named graph with nothing in it.
15:39:06 [LeeF]
ack SteveH
15:39:07 [kasei]
... nothing in spec says INSERT into a graph that doesn't exist will succeed, but note talking about it.
15:39:26 [kasei]
SteveH: to halves to this. distinction between empty graph and a non-existent graph. no strong feelings on this.
15:39:44 [kasei]
... do feel strongly that it shouldn't be error to try to insert a triple into a graph that doesn't exist.
15:39:54 [kasei]
... should create the graph. strong user feedback that this should work.
15:40:20 [kasei]
LeeF: so shouldn't require the graph is created before triples can be put into it?
15:40:23 [kasei]
SteveH: yes.
15:40:34 [kasei]
pgearon: current spec says error if the graph doesn't exist.
15:40:44 [kasei]
pgearon, did I get that right?
15:40:48 [AndyS]
+1 to SteveH : example INSERT { GRAPH ?g { <s> <p> <o> } WHERE { ... ?g .... } } -- can't create ?g at present.
15:40:57 [SteveH]
AndyS, exactly that case
15:40:59 [kasei]
LeeF: does anybody think UPDATE shouldn't have CREATE and DROP?
15:41:12 [SteveH]
DROP, yes, CREATE, don't care
15:41:20 [SteveH]
yes = should have
15:41:21 [kasei]
sandro: is there some way to find out if an empty graph exists?
15:41:39 [AxelPolleres]
Steve, you mean CREATE could be implicit by inserting?
15:41:40 [LeeF]
ASK FROM NAMED g1 { GRAPH <g1> { } }
15:41:46 [SteveH]
AxelPolleres, yes
15:42:03 [kasei]
LeeF: not clear if, in this query, g1 exists or not.
15:42:29 [kasei]
AndyS: GRAPH with empty pattern asks if g1 is in the dataset names, regardless if there are any triples.
15:42:46 [kasei]
LeeF: if g1 doesn't exist in store, unclear what the query should do.
15:43:02 [kasei]
AndyS: that will always return true.
15:43:15 [kasei]
LeeF: my impl would reject query if g1 doesnt' exist. but that's the FROM NAMED part.
15:43:33 [kasei]
... short answer is not strictly according to the standard.
15:44:02 [AndyS]
ASK { GRAPH ?g { } }
15:44:25 [kasei]
LeeF: depends on impl-defined details.
15:44:32 [AxelPolleres]
this query asks "is this graph in the dataset"
15:44:37 [kasei]
... doesn't ask what graphs are potentially available.
15:45:05 [kasei]
didn't catch that last bit from chimezie(?)
15:45:13 [AndyS]
15:45:17 [LeeF]
ack AndyS
15:45:30 [chimezie]
You can determine if the dataset that is active for the query includes a named graph (even if it is empty)
15:45:38 [kasei]
AndyS: sandro's question is good, raises larger question: what about conditional things in update generally?
15:45:55 [kasei]
... pre conditions? do we need an IF statement?
15:46:14 [kasei]
... at the moment you can kind of do it with multiple requests modulo atomicity issues.
15:46:17 [kasei]
... is that acceptable?
15:46:20 [chimezie]
In which case, I don't think we *do* need to have a way to create and drop graphs (but that is orthogonal with the implicit behavior SteveH wants)
15:46:38 [kasei]
LeeF: speaking for myself, acceptable. anything more significant would be a big change from where we are right now.
15:46:41 [chimezie]
s/I don't think/I do think
15:47:26 [kasei]
chimezie: seems like we do have a distinction between not having a graph and having a named graph that's empty.
15:47:33 [kasei]
... can't determine if a dataset has a named graph.
15:47:38 [AxelPolleres]
q+ to ask about graphstore vs default dataset
15:47:41 [kasei]
... need to have ops for creating and dropping graphs.
15:47:52 [kasei]
... can still have default behaviour of creating graphs implicitly.
15:47:57 [LeeF]
ack AxelPolleres
15:47:57 [Zakim]
AxelPolleres, you wanted to ask about graphstore vs default dataset
15:48:36 [kasei]
Axel: akward that we don't have anythign specified that if i insert something it isn't guaranteed to be in the default dataset.
15:48:51 [kasei]
LeeF: default dataset isn't a standardized concept in SPARQL 1.0.
15:49:15 [kasei]
Axel: do we want that to be undefined? what would be a usecase for doing an insert and a subsequent query doesn't get an answer?
15:49:57 [kasei]
LeeF: my thought on broader question, only way to provide a guarantee would be to revise query spec and provide formal notion of default dataset.
15:50:07 [kasei]
... more than we can handle at this point.
15:50:33 [AndyS]
Disagree - it's defined as "what the impl chooses to provide" - a common usage.
15:50:37 [kasei]
... if spec had said from day 1 an impl needs to have a universal graph, would have implemented that, but that's not the case.
15:51:06 [kasei]
AndyS: i think default dataset concept is defined in the protocol document.
15:51:20 [kasei]
LeeF: there's no concept of what the default dataset *is*. up to the implementation.
15:52:00 [SteveH]
SteveH has joined #sparql
15:52:04 [kasei]
Axel: motivated by question about inserting into a named graph, then pose a query to the default dataset, should you get back the inserted graph?
15:52:18 [kasei]
... by not having specified the behaviour, we wouldn't have this guarantee.
15:52:37 [kasei]
... LeeF convinced me that there's not a universal desired behaviour.
15:53:22 [kasei]
missed most of that, AndyS
15:53:25 [AxelPolleres]
... at least there are implementations that don't do that (as ther default dataeset is always empty)
15:53:33 [AxelPolleres]
15:53:36 [kasei]
noisy office all of a sudden.
15:54:04 [kasei]
LeeF: like to know if the rest of the group shares SteveH's preference?
15:54:07 [AxelPolleres]
AndyS: default dataset = graphstore is still a common use case
15:54:15 [pgearon]
I think it's always clear where the data is going
15:54:20 [kasei]
... is it always explicit where the triples end up?
15:54:29 [kasei]
SteveH: yes. either a graph keyword or going into the default graph.
15:54:37 [kasei]
LeeF: and the default graph already exists?
15:54:40 [kasei]
SteveH: yes.
15:54:49 [kasei]
thanks Axel
15:54:49 [AndyS]
Can we draft proposal (devil, detail etc)?
15:54:50 [SteveH]
15:55:00 [kasei]
pgearon: not sure what insertion into default graph as union of other graphs means.
15:55:10 [kasei]
chimezie: agree that's a problem.
15:55:12 [AndyS]
15:55:16 [LeeF]
ack SteveH
15:55:25 [AxelPolleres]
so, if you an implementation doesn't have a default graph, what if you insert into it?
15:55:32 [kasei]
SteveH: same situation. no default graph, just a union.
15:55:37 [kasei]
... haven't decided what to do.
15:55:55 [SteveH]
ack me
15:55:57 [kasei]
pgearon: more general problem than just this issue.
15:55:58 [LeeF]
ack AndyS
15:56:10 [kasei]
AndyS: graphs might be read only anyway.
15:56:37 [kasei]
LeeF: hearing general concesus that shouldn't be an error to insert into a graph that doesn't exist.
15:56:38 [AxelPolleres]
I'd suppose that implementations could reject insertions into the default graph?
15:56:50 [AxelPolleres]
(those that don't have a default graph)
15:56:55 [kasei]
... since current draft is the other way around, let's make it a proposal.
15:57:28 [LeeF]
PROPOSE: SPARQL Update should make it legal to insert triples into a graph that does not yet exist, with the result being that the graph now exists and has those triples in it
15:57:33 [SteveH]
15:57:37 [dcharbon2]
15:57:39 [AxelPolleres]
15:57:40 [MattPerry]
15:57:41 [pgearon]
15:57:44 [LeeF]
15:57:48 [chimezie]
15:57:49 [ivan]
15:57:49 [AndyS]
15:57:49 [kasei]
15:57:52 [bglimm]
15:57:58 [LeeF]
RESOLVED: SPARQL Update should make it legal to insert triples into a graph that does not yet exist, with the result being that the graph now exists and has those triples in it
15:58:05 [AxelPolleres]
(exception being the default graph...)
15:58:29 [kasei]
LeeF: heard that create and drop should stick around. might return when we continue discussion about datasets.
15:58:35 [kasei]
... will discuss with protocol issues.
15:58:43 [AndyS]
and LOAD ... INTO ...
15:59:16 [kasei]
LeeF: didn't get to blank nodes in template for delete, and dataset clauses.
15:59:21 [kasei]
... will do them next week.
15:59:24 [AxelPolleres]
just to put it in again... regrets for next week from me, BTW
15:59:55 [Zakim]
15:59:58 [pgearon]
16:00:05 [pgearon]
yes, I'm comfortable with that
16:00:14 [kasei]
LeeF: will follow up with pgearon.
16:00:28 [bglimm]
16:00:30 [Zakim]
16:00:31 [Zakim]
16:00:31 [Zakim]
16:00:32 [AxelPolleres]
bye all
16:00:35 [AndyS]
16:00:37 [Zakim]
16:00:42 [kasei]
pointer to the scribe instructions for posting?
16:00:43 [Zakim]
16:00:47 [Zakim]
16:00:53 [Zakim]
16:00:57 [Zakim]
16:00:57 [AxelPolleres]
16:00:59 [Zakim]
16:01:01 [Zakim]
16:01:10 [kasei]
16:01:11 [Zakim]
16:01:13 [Zakim]
16:01:15 [Zakim]
SW_(SPARQL)10:00AM has ended
16:01:17 [Zakim]
Attendees were LeeF, bglimm, AndyS, pgearon, OlivierCorby, +1.603.897.aaaa, kasei, MattPerry, Sandro, +1.919.332.aabb, dcharbon2, Chimezie_Ogbuji, Ivan, SteveH, AxelPolleres
16:01:29 [AxelPolleres]
(quite self-explanatory, if you have trouble, I'll still be around for some minutes on IRC)
16:01:54 [kasei]
thanks axel. i did it once before, so I'm sure I can manage again.
16:07:47 [kasei]
hmmm... actually
16:08:12 [kasei]
Axel, is all of this necessary? must I include the "present: ..." line, or is Zakim's attendees list enough?
16:08:17 [AxelPolleres]
AxelPolleres has left #sparql
16:33:09 [LeeF]
kasei, you do need the present: line
16:33:52 [kasei]
really? i tried looking at earlier minutes, and didn't see it being used.
16:34:29 [kasei]
can i regenerate the page?
16:38:13 [LeeF]
16:38:16 [LeeF]
maybe something changed
16:38:20 [LeeF]
you used to need the present: line
16:38:31 [LeeF]
if the process succeeded without it, then you didn't need it :)
16:38:57 [LeeF]
minutes look OK to me as is :)
16:39:21 [kasei]
ok, good to know.
16:39:22 [kasei]
16:55:14 [AndyS_]
AndyS_ has joined #sparql
17:05:26 [AndyS]
AndyS has joined #sparql
18:17:35 [Zakim]
Zakim has left #sparql
19:25:50 [SteveH]
SteveH has joined #sparql
20:58:42 [bglimm]
bglimm has joined #sparql
22:46:28 [AndyS]
AndyS has joined #sparql
23:02:49 [bglimm]
bglimm has joined #sparql