13:37:37 <RRSAgent> RRSAgent has joined #sparql
13:37:37 <RRSAgent> logging to http://www.w3.org/2010/10/19-sparql-irc
13:37:49 <Zakim> Zakim has joined #sparql
13:38:00 <AxelPolleres> trackbot, this will be sparql
13:38:00 <trackbot> Sorry, AxelPolleres, I don't understand 'trackbot, this will be sparql'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
13:38:08 <AxelPolleres> Zakim, this will be sparql
13:38:08 <Zakim> ok, AxelPolleres; I see SW_(SPARQL)10:00AM scheduled to start in 22 minutes
13:38:19 <AxelPolleres> Chair: Axel Polleres
13:39:19 <AxelPolleres> regrets: Steve Harris, Ivan Herman
13:39:33 <AxelPolleres> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-10-19 
13:40:10 <AxelPolleres> regrets: Steve Harris, Ivan Herman, Olivier Corby
13:48:48 <AxelPolleres> regrets: Steve Harris, Ivan Herman, Olivier Corby, Lee Feigenbaum
13:48:55 <ericP> heya Axel, i'll can come to the conf around 10 after
13:48:59 <ericP> 'zat work?
13:50:45 <cbuilara> cbuilara has joined #sparql
13:52:48 <AxelPolleres> eric, should be ok, that's when we just have finished admin stuff
13:52:57 <AxelPolleres> ... ideally, don't be later ;-)
13:53:26 <sandro> partial regrets, sorry.    I'll be able to call in for a bit in the middle.
13:58:21 <Zakim> SW_(SPARQL)10:00AM has now started
13:58:28 <Zakim> +??P3
13:59:03 <MattPerry> MattPerry has joined #sparql
13:59:26 <Zakim> +kasei
13:59:47 <bglimm> bglimm has joined #sparql
14:00:05 <Zakim> +MattPerry
14:00:29 <AxelPolleres> who is P3?
14:00:45 <cbuilara> me I think
14:00:56 <Zakim> +AxelPolleres
14:01:07 <cbuilara> I was the first in joining the call
14:01:16 <AxelPolleres> Zakim, ??P3 is cbuilara
14:01:16 <Zakim> +cbuilara; got it
14:01:28 <cbuilara> thanks
14:01:33 <Zakim> +??P12
14:01:36 <AndyS> zakim, ??P12 is me
14:01:36 <Zakim> +AndyS; got it
14:01:54 <chimezie> chimezie has joined #sparql
14:01:56 <AxelPolleres> Zakim, who is on the phone?
14:01:56 <Zakim> On the phone I see cbuilara (muted), kasei, MattPerry, AxelPolleres, AndyS
14:02:26 <AxelPolleres> Paul, will you be joining? (I have you on the list for scribing :-) )
14:02:38 <AxelPolleres> trackbot, start meeting
14:02:40 <trackbot> RRSAgent, make logs world
14:02:41 <Souri> Souri has joined #sparql
14:02:42 <trackbot> Zakim, this will be 77277
14:02:43 <trackbot> Meeting: SPARQL Working Group Teleconference
14:02:43 <trackbot> Date: 19 October 2010
14:02:44 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start 2 minutes ago
14:03:28 <AxelPolleres> Zakim, who is on the phone?
14:03:32 <Zakim> I notice SW_(SPARQL)10:00AM has restarted
14:03:38 <Zakim> On the phone I see cbuilara, kasei, MattPerry, AxelPolleres, AndyS, bglimm, Chimezie_Ogbuji, Souri
14:03:50 <bglimm> Zakim, mute me
14:04:04 <Zakim> bglimm should now be muted
14:04:04 <AxelPolleres> Zakim, who is on the phone?
14:04:08 <Zakim> +pgearon
14:04:10 <Zakim> On the phone I see cbuilara, kasei, MattPerry, AxelPolleres, AndyS, bglimm (muted), Chimezie_Ogbuji, Souri, pgearon
14:04:10 <chimezie> Zakim, mute me
14:04:17 <Zakim> Chimezie_Ogbuji should now be muted
14:04:24 <AxelPolleres> scribe: Paul Gearon
14:04:45 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Agenda-2010-10-19
14:04:49 <AxelPolleres> topic: admin
14:05:00 <AxelPolleres> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-10-12
14:05:30 <pgearon> seconded
14:05:31 <AxelPolleres> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-10-12
14:05:39 <AlexPassant> AlexPassant has joined #sparql
14:06:00 <AxelPolleres>  Next regular meeting: 2010-10-26 ...
14:06:06 <AndyS> Regrets for next time: AndyS
14:06:51 <pgearon> AxelPolleres: Already new comments on draft publications
14:07:16 <pgearon> goal to get to last call by the end of the year
14:07:17 <AxelPolleres> make clear in thadvertisements that we want to get to LC by end of the year
14:07:34 <AxelPolleres> ... to be discussed within chairs, suggestions for further advertisement welcome.
14:07:51 <Zakim> +[IPcaller]
14:08:06 <AlexPassant> I just joined
14:08:17 <AxelPolleres> Zakim, IPCaller is AlexPassant
14:08:17 <Zakim> +AlexPassant; got it
14:08:28 <AxelPolleres> topic: Federated Queries
14:09:08 <AxelPolleres> 1)  the "must be bound issue" (certainly, potentially bound
14:09:13 <AxelPolleres> 2)  error behavior (be it for {SERVICE t P} a) t not a service, b)
14:09:13 <AxelPolleres> call to t fails/returns error/query refused, or c) t unbound), 
14:09:13 <AxelPolleres> 3) incomplete/missing semantics definition (particularly for the case
14:09:13 <AxelPolleres> when t is a variavble
14:09:13 <AxelPolleres> 4) informal style
14:09:14 <AxelPolleres> 5)  "UNDEF" (i.e. UNBOUND/NULL) ... for BINDINGS is strange/nowhere
14:09:16 <AxelPolleres> explained
14:09:18 <AxelPolleres> 6) further editorial comments by Greg
14:11:10 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JulSep/0433.html
14:11:16 <AxelPolleres> (greg's mail)
14:11:28 <AxelPolleres> greg: examples are very domain specific
14:11:52 <kasei> SERVICE <sparql?default-graph=foo>
14:12:33 <AxelPolleres> 7) allow to add dataset as parameter?
14:12:44 <pgearon> kasei: don't see any reason not to allow this, since it already allowed in the protocol
14:12:57 <AndyS> Good idea -- use FROM, FROM NAMED (else need to construct SERVICE uri dynamically in SPARQL?) 
14:13:49 <pgearon> AxelPolleres: interested in feelings on these topics, rather than solutions at this stage
14:14:28 <ericP> Zakim, please dial ericP-office
14:14:28 <Zakim> ok, ericP; the call is being made
14:14:30 <Zakim> +EricP
14:14:40 <pgearon> AxelPolleres: on topic 2. Currently, if there is an error, then the entire service should fail. Perhaps this is not the best approach
14:14:54 <kasei> i'd want OPTIONAL { SERVICE <s> { ... } } to not cause the entire query to fail if the service call fails
14:15:00 <AxelPolleres> ad 2)  ... SERVICE SILENT?
14:16:16 <AndyS> +1 to kasei
14:16:44 <pgearon> ericP: yes, wrote that a service failure should result in total failure, else results will not be as constrained as clients think they are
14:17:04 <AxelPolleres> OPTIONAL { SERVICE SILENT would do that job, greg?
14:17:21 <NickH> NickH has joined #sparql
14:17:24 <pgearon> ericP: wrote that the query fails, . Perhaps say that the GroupGraphPattern in which the service appears fails to match
14:17:46 <pgearon> AxelPolleres: so it would leave all the variables unbound
14:17:51 <AxelPolleres> "fail" would leavea ll vars unbound, i.e.  = {} 
14:18:04 <Zakim> +??P38
14:18:09 <kasei> {}, not {{}}
14:18:18 <NickH> Zakim, ??P38 is me
14:18:18 <Zakim> +NickH; got it
14:18:52 <pgearon> ericP: no solutions, as opposed to one solution with no bindings
14:19:21 <pgearon> ericP: makes it more complicated, but there are use cases that justify it (I think)
14:19:31 <AxelPolleres> editors should make a proposal to the list...
14:19:51 <pgearon> AndyS: editors write something up and propose to the list, rather than detailed design here
14:19:56 <pgearon> ericP: seconded
14:20:25 <pgearon> AxelPolleres: no explicit actions yet, but will provide a general action to do this
14:20:27 <ericP> http://www.w3.org/2009/sparql/docs/fed/service#defn_service
14:20:51 <ericP> [[
14:20:52 <ericP>    If E is of the form SERVICE VAR {P}
14:20:52 <ericP>    Then
14:20:52 <ericP>        Let G := Join(G, Service(VAR, G, Transform(P)))
14:20:54 <ericP> ]]
14:20:58 <pgearon> point 3 - incomplete semantics
14:21:10 <ericP> [[
14:21:14 <ericP>      Let R be the empty multiset
14:21:14 <ericP>      foreach i in Ω(?var->i)
14:21:14 <ericP>         if i is an IRI
14:21:14 <ericP>           R := Union(R, Join( Invocation( i, vars ∩ bound, P, Bindings(G, vars) ) , Ω(?var->i) ) )
14:21:17 <ericP>         else
14:21:20 <ericP>           exection fails.
14:21:22 <ericP>      the result is R
14:21:25 <ericP> 	
14:21:27 <ericP> ]]
14:22:01 <pgearon> ericP: copied what was happening in the GraphGraphPattern. Hope AndyS can look it over and confirm that it appears OK
14:22:32 <pgearon> ericP: made it a binary operation
14:22:35 <AndyS> I'll take an action to look at it when the editors say "it's ready for you" (if not now)
14:22:58 <pgearon> ericP: will take this to text. In email
14:23:07 <kasei> q+
14:23:44 <pgearon> point 5 - UNDEF not defined clearly
14:24:06 <AxelPolleres> axel: 5) another approach from "UNDEF" would be "," ?
14:24:08 <pgearon> kasei: UNDEF doesn't bother me, but it requires a definition
14:24:17 <AndyS> ,, no!
14:24:28 <AxelPolleres> greg: UNDEF doesn't bother me... just explanation missing
14:24:54 <AndyS> not adjacent commas for absence
14:25:07 <AxelPolleres> greg: highlight again the examples are too specific.
14:25:14 <pgearon> kasei: informal style may change over time, but domain specificness is a current issue
14:25:32 <AxelPolleres> ... easier to grasp use cases would be better.
14:25:42 <pgearon> kasei: readers should not be required to understand "computational biology"  (the current use case)
14:26:07 <AxelPolleres> ... again something we leave to the editors...
14:26:35 <AxelPolleres> FWIW, I have some SERVICE example using a FOAF File and DBLP in my tutorial slides, maybe a start.
14:26:45 <pgearon> ericP: current use cases were cut-and-pasted because they were syntactically valid
14:27:35 <pgearon> AxelPolleres: Point 6 - further comments from Greg can be addressed in mail. Point 7 can be discussed in mail as well.
14:27:38 <kasei> q+
14:28:02 <AxelPolleres> subtopic: point 7)
14:28:50 <AndyS> Why not SERVICE <> { GRAPH <g> {...} }
14:28:55 <AxelPolleres> axel: personaly, the use case I see is that FROM/FROM NAMED wasn't allowed in subqwueries and allowing it in SERVICE would allow to circumvent this 
14:29:22 <pgearon> kasei: as it stands right now, service keyword is restricted to the graphs provided by the endpoint
14:29:27 <AxelPolleres> greg: only useful for service in the default graph
14:29:27 <Zakim> -AlexPassant
14:29:44 <pgearon> AndyS: this may not be the "default graph" but it certainly applies to services that provide a fixed dataset
14:29:56 <ericP> http://www.w3.org/2005/01/yacker?name=SPARQL_11&replace=1&lang=perl#prod-SPARQL_11-ServiceGraphPattern
14:30:11 <pgearon> +q
14:30:17 <AxelPolleres> eric: this is how it would look like with dataset clause
14:30:41 <kasei> q-
14:30:50 <AxelPolleres> ack pgearon
14:31:07 <Zakim> +??P40
14:31:10 <AlexPassant> Zakim, ??P40 is me
14:31:10 <Zakim> +AlexPassant; got it
14:31:20 <AxelPolleres> paul: wondering about interaction between fed doc and protocol 
14:31:22 <ericP> Definition: Evaluation of a Service Pattern
14:31:33 <ericP> [[
14:31:35 <ericP> where:Invocation(IRI, S, P, B) is an implementation of the SPARQL protocol 
14:31:35 <ericP>     * against endpoint IRI,
14:31:35 <ericP>     * with a SELECT of S, WHERE pattern P, and BINDINGS B,
14:31:35 <ericP>     * with no default-graph-uri or named-graph-uri (see SPARQL Protocol [SPROT] section 2.1.1.1),
14:31:37 <pgearon> pgearon: does this issue require some interaction between the service keyword and the protocol document?
14:31:38 <ericP> 	Execution failures cause the query to fail.
14:31:41 <ericP>       
14:31:43 <ericP> ]]
14:32:13 <AxelPolleres> D )
14:32:29 <AxelPolleres> q?
14:33:46 <pgearon> AxelPolleres: Carlos and Eric, please look into this. Will follow up in 2 weeks
14:33:56 <AxelPolleres> ACTION: Axel to ping carlos/eric in 2-3 weeks for progress on Fed query issues
14:33:56 <trackbot> Created ACTION-324 - Ping carlos/eric in 2-3 weeks for progress on Fed query issues [on Axel Polleres - due 2010-10-26].
14:34:27 <pgearon> new topic: Certainly bound vs. potentially bound
14:35:02 <pgearon> AxelPolleres: potentially bound is a syntactic definition. proposed to provide a stricter definition that requires binding
14:35:18 <pgearon> AxelPolleres: Use the mailing list for further discussion. kasei has some opinion there
14:35:40 <pgearon> new topic: test cases
14:36:01 <AxelPolleres> topic: test cases
14:36:07 <pgearon> ericP: how stable is the grammar right now?
14:36:21 <AxelPolleres> andyS: ISSUW-59 might still change the grammar
14:36:23 <pgearon> AndyS: issue-59 may change the grammar, but it is not super volatile
14:36:27 <Zakim> -EricP
14:36:49 <pgearon> AxelPolleres: fix the test case vocabulary
14:36:55 <AxelPolleres> http://www.w3.org/2009/sparql/docs/tests/README.html
14:37:28 <AxelPolleres>   ut:request for update actions
14:38:02 <AxelPolleres>  graphstore state
14:38:12 <AxelPolleres>  ut:data ut:graphData
14:39:03 <AxelPolleres>  ut:graphData [ ut:data graph  rdfs:label name ]
14:39:18 <pgearon> AxelPolleres:  ut:graphData can allow graphs to be named
14:39:35 <AndyS> This second use of ut:data should be changed.
14:39:41 <pgearon> AxelPolleres: some question on the domain of ut:data
14:39:53 <AxelPolleres>  ... ut:graph instead ut:data ?
14:40:25 <AxelPolleres> would that be ok?
14:40:35 <pgearon> AxelPolleres: Andy had a problem with reuse of ut:data, so I'm proposing to move to ut:graph
14:40:38 <NickH> nope
14:40:42 <AxelPolleres> Can you still hear me?
14:40:44 <AxelPolleres> :-)
14:40:58 <kasei> as long as all of the applicable tests are changed at the same time, I'm fine with mostly anything.
14:41:17 <NickH> sounds fine to me
14:41:22 <AxelPolleres> paul: also for using a new predicate.
14:41:48 <pgearon> AxelPolleres: will change the nested use of ut:data to ut:graph
14:41:56 <AxelPolleres> ACTION: Axel to chang nested use of ut:data to ut:graph
14:41:57 <trackbot> Created ACTION-325 - Chang nested use of ut:data to ut:graph [on Axel Polleres - due 2010-10-26].
14:42:24 <AxelPolleres> http://www.w3.org/2009/sparql/docs/tests/README.html#entailevaltests
14:42:31 <pgearon> AxelPolleres: updated test vocab will then be stable (IMO)
14:43:03 <AndyS> q+
14:43:48 <pgearon> AndyS: update vocab still. ut:result and others
14:44:12 <pgearon> AxelPolleres: this is longer, so voer entailments first and get back to it
14:44:13 <bglimm> seems ok
14:44:15 <bglimm> Zakim, unmute me
14:44:16 <Zakim> bglimm should no longer be muted
14:44:58 <pgearon> AxelPolleres: different entailment regimes for different graphs, may be possible, but would fix regime for the whole document
14:45:13 <bglimm> Zakim, mute me
14:45:13 <Zakim> bglimm should now be muted
14:45:26 <chimezie> breaking in and out, Axel
14:45:31 <pgearon> AxelPolleres: update use case descriptions
14:46:17 <kasei> AxelPolleres?
14:46:34 <chimezie> Zakim, unmute me
14:46:34 <Zakim> Chimezie_Ogbuji should no longer be muted
14:46:44 <AlexPassant> yes chimezie 
14:46:54 <NickH> oh dear
14:46:58 <kasei> heh
14:47:05 <pgearon> AxelPolleres may be having IP troubles
14:47:56 <AxelPolleres> AxelPolleres has joined #sparql
14:48:19 <AxelPolleres> ACTION: Axel to add a sentence in README.html that typically suffix .rq  .ru are to be sused for query and update request files
14:48:19 <trackbot> Created ACTION-326 - Add a sentence in README.html that typically suffix .rq  .ru are to be sused for query and update request files [on Axel Polleres - due 2010-10-26].
14:48:47 <AxelPolleres> mf:result for update TCs...
14:48:54 <chimezie> Zakim, mute me
14:48:54 <Zakim> Chimezie_Ogbuji should now be muted
14:49:02 <AxelPolleres> ... ut:success and ut:FAILUREMESSAGE
14:49:34 <pgearon> AxelPolleres: ut:FAILUREMESSSAGE  is defined in the protocol document
14:49:37 <AndyS> Note MIME registration for SPARQL Update suggests a extension.
14:50:09 <pgearon> AxelPolleres: looking for someone to define protocol test cases, and also a vocabulary for that
14:50:13 <AndyS> q+
14:50:32 <AxelPolleres> Andy, please go ahead...
14:50:36 <bglimm> yes
14:50:37 <chimezie> i can
14:50:38 <NickH> I can AndyS
14:50:42 <pgearon> AndyS: don't think that's a good idea, for 2 reasons
14:50:46 <AndyS> Axel can you hear me?
14:50:57 <pgearon> Axel unable to hear Andy. Everyone else hears him
14:50:58 <AxelPolleres> I will need to re-dail, I only hear my echo :-(
14:50:58 <chimezie> Axel, if you can see this it seems as if the communication is one way on your line
14:51:05 <Zakim> -AxelPolleres
14:52:52 <AxelPolleres> :-( hardware problem on the telephone :-(
14:53:16 <pgearon> AndyS - perhaps you can outline, and Axel will see it on IRC?
14:53:31 <AxelPolleres> hmmm, sincere apologies...
14:53:38 <AxelPolleres> let's try with chat...
14:53:51 <pgearon> AndyS: 2 problems. First, we need format stabilized so people can write test code parsing against it
14:53:54 <AxelPolleres> ... seems I can't solve the phone issue quickly.
14:54:17 <AxelPolleres> +1 on that.
14:54:40 <pgearon> AndyS: we have a list of errors in the README that don't make sense to me
14:55:04 <pgearon> AndyS: list - SUCCESS, REQUEST REFUSED, SYNTAX ERROR
14:55:19 <pgearon> AndyS: SYNTAX ERRORS should be in syntax errors
14:55:31 <pgearon> AndyS: what should the errors be targetting?
14:56:43 <AxelPolleres> the errors in the doc came from protocol
14:56:51 <AlexPassant> unexistent graph ?
14:57:26 <AxelPolleres> I'd be ok to go without ut:success and the errors for the moment... but we'd want to have test cases for protocol as well, I assume?
14:57:32 <Zakim> -Chimezie_Ogbuji
14:57:42 <pgearon> AndyS: insert data, and possibly other operations do automatic graph creation. Are there cases where all stores must signal an error in some conditions?
14:57:52 <AxelPolleres> we'd need someone voluteering for TCs and TC structure for protocol...
14:57:55 <AxelPolleres> any volunteer?
14:58:38 <pgearon> AndyS: is that an error for stores that can't tell the difference between no graph and empty graph
14:59:39 <pgearon> AndyS: made assumption that loading a graph that doesn't exist to automatically create the graph.
14:59:47 <AlexPassant> "In case no RDF data can be retrieved from documentURI, the SPARQL 1.1 Update service is expected to return failure."
14:59:52 <AlexPassant> I meant does not exist *remotely*
14:59:53 <pgearon> AndyS: propose taking this to email to get a definitive list
15:00:05 <AndyS> ah!  I understand now.
15:00:11 <AxelPolleres> for now, would people be ok with the update TC format, if we just drop the ut:success/ut:FAILORCODE stuff for updateEvaluationTests?
15:00:48 <AxelPolleres> agree to take this on email.
15:00:52 <AndyS> Yes. Haven't read it with all the changes but looks OK.
15:01:00 <AxelPolleres> sincere apologies for the technical problames again.
15:01:34 <AndyS> BTW need different syntax tests for query and update.
15:01:49 <AxelPolleres> Can others add support for that proposal with +1 ... "drop ut:success/ut:FAILORCODE for now for update TC format" ?
15:02:01 <AxelPolleres> if no opposition, I will implement this... 
15:02:15 <bglimm> Zakim, unmute me
15:02:15 <AlexPassant> I'll be at ISWC
15:02:16 <pgearon> telephone portion of this meeting appears to have wrapped up
15:02:17 <AndyS> +1
15:02:21 <Zakim> bglimm should no longer be muted
15:02:26 <AxelPolleres> but as I can't hear you, I;d like some support on the ICR
15:02:32 <AxelPolleres> s/ICR/IRC/
15:02:45 <pgearon> AndyS: when are people leaving for ISWC? How many meetings will be missed?
15:02:47 <bglimm> I leave on Friday 5th comming back on Mon 15th
15:02:55 <AlexPassant> be away for 2 telcos (5->21) 
15:02:57 <Zakim> -Souri
15:03:06 <pgearon> bglimm: going Friday, so only missing 1
15:03:16 <AlexPassant> AxelPolleres: fine with your proposal
15:03:33 <Zakim> -MattPerry
15:03:33 <AxelPolleres> ok, I have two supports... I will go ahead with that and send around mail.
15:03:42 <pgearon> thanks Axel
15:03:49 <AndyS> ADJOURNED
15:03:54 <pgearon> AndyS: we're now adjourned
15:03:59 <AxelPolleres> ACTION: Axel to drop ut:success and ut:FAILURECODES from update TC vocab. 
15:03:59 <trackbot> Created ACTION-327 - Drop ut:success and ut:FAILURECODES from update TC vocab.  [on Axel Polleres - due 2010-10-26].
15:04:35 <AxelPolleres> Thanks for keeping on, we seem at least to have some format for UC and entailment tests now... approval hopefully next time.
15:04:58 <Zakim> -bglimm
15:04:59 <NickH> bye all!
15:05:00 <AxelPolleres> Please, all TC providers, work through your unapproved TCs following this conclusion. 
15:05:02 <Zakim> -NickH
15:05:03 <AxelPolleres> THanks all!
15:05:06 <AxelPolleres> Bye
15:05:22 <Zakim> -kasei
15:05:25 <Zakim> -pgearon
15:05:28 <Zakim> -AndyS
15:05:34 <cbuilara> -cbuilara
15:05:41 <Zakim> -cbuilara
15:05:46 <cbuilara> bye
15:06:00 <Zakim> -AlexPassant
15:06:02 <Zakim> SW_(SPARQL)10:00AM has ended
15:06:03 <Zakim> Attendees were kasei, MattPerry, AxelPolleres, cbuilara, AndyS, bglimm, Chimezie_Ogbuji, Souri, pgearon, AlexPassant, EricP, NickH
15:07:03 <AndyS> Pls could someone agree (or disagree) to two comment responses.  Should not be controversial.
15:07:27 <AxelPolleres> AndyS, can you drop the links?
15:07:36 <AndyS> 2010OctDec/0117 and 0118
15:07:42 <AxelPolleres> I am in another call now... will look into it right afterwards.
15:10:12 <AxelPolleres> rrsagent, make records public 
15:31:00 <kasei> has there been agreement on an unbound variable in a GROUP BY leading to dropping of the group? don't recall how that worked out...
15:39:07 <kasei> AndyS?
15:43:50 <SteveH> kasei, I don't think it drops the group
15:44:07 <SteveH> it evaluates to an "error", and can be key'd like any other value
15:44:18 <kasei> oh. I was trying to make sense of the "Aggregates question" thread from a couple weeks ago...
15:44:45 <kasei> in particular, this: http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0040.html
15:45:01 <kasei> I thought I understood your answer to Axel as indicating that groups with unbound variables are dropped.
15:45:08 <kasei> I misunderstood that, then?
15:45:09 <SteveH> let me read...
15:45:19 <SteveH> it's not unknown for me to contradict myself :)
15:45:27 <kasei> :)
15:46:10 <kasei> but i couldn't make sense of Andy's follow-up later on in the thread...
15:47:20 <SteveH> kasei, http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0058.html
15:47:28 <SteveH> there's several things going on there
15:47:56 <SteveH> but ListEval(unbound) = error
15:48:16 <SteveH> however, projecting an error value, results in a dropped result
15:48:39 <kasei> ah
15:48:54 <kasei> so without projecting ?Q in that example, there would be two results?
15:49:51 <SteveH> [vague waving of hands] yeah, I think so
15:49:59 <kasei> haha. ok, thanks Steve
15:50:09 <SteveH> Aggregate() doesn't remove rows
15:51:11 <kasei> hrmm. wait. where does the ListEval in this case happen?
15:51:24 <kasei> in the grouping, right?
15:54:11 <kasei> I'm trying to sort out if the :group05 test is right.
15:54:55 <kasei> it does: SELECT ?s ?w { ?s :p ?v OPTIONAL { ?s :q ?w } } GROUP BY ?s ?w
15:56:10 <kasei> the results contain rows that have ?s bound and ?w unbound, but I'm not sure why that's different from Axel's example in email.
15:59:09 <SteveH> you can still make a group of (<a>, error)
15:59:13 <SteveH> AFAICR
16:02:23 <kasei> but it's then projected, just like it is in the email example.
16:18:31 <SteveH_> SteveH_ has joined #sparql
16:24:06 <AndyS> kasei
16:25:25 <AndyS> re: you can still make a group of (<a>, error) 
16:26:14 <AndyS> wrong way round: (error, {1,2,3})
16:26:15 <kasei> so what is it that causes the group to be dropped in Axel's example in the email?
16:26:33 <AndyS> No idea.
16:26:37 <kasei> heh
16:26:43 <kasei> ok
16:28:22 <AndyS> He is proposing the opposite case but I see no reason why that's more valuable.
16:28:44 <AndyS> I think my suggested modifications to the wording work.
16:28:53 <AndyS> Any issues you see?
16:33:01 <AndyS> What's your architectural issue?
16:34:16 <AndyS> kasei, have you followed the limit-by-resource discussion on semantic-web@w3?
16:35:35 <kasei> not sure about the architectural issue as I'm not sure I've fully understood the impact of errors on aggregates+projection yet.
16:35:46 <kasei> I've followed the limit-by-resource discussion a little bit, but not in depth.
16:36:09 <AndyS> I wonder if this might turn into a "easier to do than explain everytime" thing.  LIMIT 10 by ?x, or other similar syntax, looks quite easy to do.
16:36:37 <kasei> I tend to agree
16:36:52 <kasei> not thrilled about adding more syntax/features at this point, but this issue does come up a lot.
16:37:48 <AndyS> My feeling exactly.  Hard to balance small features and overrun with freeze for <small n> years.
16:49:35 <kasei> speak of the devil
16:49:42 <kasei> someone wants to talk to you about it on #swig
17:02:52 <Zakim> Zakim has left #sparql
18:31:37 <AndyS> AndyS has joined #sparql
18:51:41 <AxelPolleres> AxelPolleres has joined #sparql
19:21:05 <AxelPolleres> AxelPolleres has joined #sparql
20:22:51 <SteveH> SteveH has joined #sparql
20:43:27 <AndyS> Scanning sparql.org log files.  Recently rebooted to install latest joseki version : Of 2326 requests, 1715 involve SERVICE 
20:44:36 <AndyS> Some are used to add SPARQL 1.1 features to 1.0 endpoints!
21:16:45 <AxelPolleres> AxelPolleres has joined #sparql