This wiki has been archived and is now read-only.

Chatlog 2010-03-16

From SPARQL Working Group
Jump to: navigation, search

See original RRSAgent log and preview nicely formatted version.

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

13:51:20 <RRSAgent> RRSAgent has joined #sparql
13:51:20 <RRSAgent> logging to http://www.w3.org/2010/03/16-sparql-irc
13:51:22 <trackbot> RRSAgent, make logs world
13:51:23 <Zakim> Zakim has joined #sparql
13:51:24 <trackbot> Zakim, this will be 77277
13:51:24 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 9 minutes
13:51:25 <trackbot> Meeting: SPARQL Working Group Teleconference
13:51:26 <trackbot> Date: 16 March 2010
13:51:26 <LeeF> zakim, this will be SPARQL
13:51:26 <Zakim> ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 9 minutes
13:51:34 <LeeF> Chair: LeeF
13:51:40 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-03-16
13:54:41 <ivan> Regrets: Ivan
13:56:36 <LeeF> Regrets +AxelPolleres
13:57:09 <Zakim> SW_(SPARQL)10:00AM has now started
13:57:16 <Zakim> +Lee_Feigenbaum
13:57:26 <LeeF> zakim, that's me!
13:57:26 <Zakim> I don't understand 'that's me!', LeeF
13:57:34 <LeeF> zakim, Lee_Feigenbaum is me
13:57:34 <Zakim> +LeeF; got it
13:57:57 <SteveH_> SteveH_ has joined #sparql
13:58:11 <Zakim> + +1.518.276.aaaa
13:58:16 <kasei> Zakim, aaaa is me
13:58:16 <Zakim> +kasei; got it
13:58:51 <Zakim> +[IPcaller]
13:59:06 <AndyS> zakim, IPCaller is me
13:59:08 <Zakim> +??P13
13:59:11 <SteveH_> Zakim, ??P13 is me
13:59:12 <Zakim> +AndyS; got it
13:59:18 <Zakim> + +49.238.aabb
13:59:20 <Zakim> +SteveH_; got it
13:59:53 <OlivierCorby> Zakim, aabb is me
13:59:53 <Zakim> +OlivierCorby; got it
14:00:15 <Souri> Souri has joined #sparql
14:00:30 <bglimm> -me fighting with the phone in Karlsruhe... It doesnät allow me to enter the code Öß)
14:00:31 <LeeF> Scribenick: SteveH_
14:00:36 <MattPerry> MattPerry has joined #sparql
14:01:04 <LeeF> zakim, who's on the phone?
14:01:04 <Zakim> On the phone I see LeeF, kasei, AndyS, SteveH_, OlivierCorby
14:01:11 <Zakim> + +1.603.897.aacc
14:01:19 <kasei> Zakim, mute me
14:01:19 <Zakim> kasei should now be muted
14:01:25 <Zakim> +??P16
14:01:39 <Zakim> +??P17
14:01:42 <AlexPassant> Zakim, ??P17 is me
14:01:42 <Zakim> +AlexPassant; got it
14:01:50 <dcharbon2> dcharbon2 has joined #sparql
14:01:50 <MattPerry> zakim, ??P16 is me
14:01:50 <Zakim> +MattPerry; got it
14:01:52 <AlexPassant> hi
14:01:57 <Souri> zakim, aacc us me
14:01:57 <Zakim> I don't understand 'aacc us me', Souri
14:02:05 <Prateek> Prateek has joined #sparql
14:02:06 <Souri> zakim, aacc is me
14:02:06 <Zakim> +Souri; got it
14:02:39 <Zakim> + +1.919.332.aadd
14:02:45 <Zakim> +Sandro
14:02:49 <dcharbon2> Zakim, aadd is me
14:02:49 <Zakim> +dcharbon2; got it
14:03:05 <Zakim> + +1.312.863.aaee
14:03:22 <dcharbon2> zakim, mute me
14:03:22 <Zakim> dcharbon2 should now be muted
14:03:32 <pgearon> Zakim, aaee is me
14:03:32 <Zakim> +pgearon; got it
14:03:48 <Zakim> + +1.216.444.aaff
14:04:00 <chimezie> chimezie has joined #sparql
14:04:24 <chimezie> Zakim, mute me
14:04:24 <Zakim> sorry, chimezie, I do not know which phone connection belongs to you
14:04:31 <chimezie> Zakim, who is on the phone?
14:04:31 <Zakim> On the phone I see LeeF, kasei (muted), AndyS, SteveH_, OlivierCorby, Souri, MattPerry, AlexPassant, dcharbon2 (muted), Sandro, pgearon, +1.216.444.aaff
14:04:36 <LeeF> zakim, aaff is chimezie
14:04:37 <Zakim> +chimezie; got it
14:04:41 <chimezie> ty
14:05:10 <chimezie> Zakim, mute me
14:05:10 <Zakim> chimezie should now be muted
14:05:19 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-03-09
14:06:10 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-03-09
14:06:17 <SteveH_> LeeF: minutes capture handling of blanknodes in delete
14:06:30 <SteveH_> LeeF: try to have short call next week, 2 days before f2f
14:06:55 <SteveH_> ... set for F2F, go over agenda on last time, logistical issues, 20 min call
14:07:00 <AndyS> can we restrict it to process thing please?
14:07:14 <LeeF> Next meeting: 2010-03-23 @ 14:00 UK / 10:00 EST (scribe: Matt) - NOTE ONE HOUR EARLIER THAN USUAL OUTSIDE OF THE US
14:07:29 <SteveH_> LeeF: 4 hours difference to UK
14:07:53 <SteveH_> LeeF: should look at comments at F2F
14:08:05 <Zakim> -AlexPassant
14:08:30 <SteveH_> LeeF: RDB2RDF, noting to worry about
14:08:34 <LeeF> http://www.w3.org/2009/sparql/wiki/F2F3_Agenda
14:08:43 <SteveH_> LeeF: agenda for F2F updated, ^
14:08:56 <Zakim> + +
14:08:58 <Zakim> +??P26
14:09:03 <AlexPassant> Zakim, ??PP26 is me
14:09:03 <Zakim> sorry, AlexPassant, I do not recognize a party named '??PP26'
14:09:04 <SteveH_> ... update on day 1, goal is to finalise language, what statements are in/out
14:09:07 <AlexPassant> Zakim, ?PP26 is me
14:09:07 <Zakim> sorry, AlexPassant, I do not recognize a party named '?PP26'
14:09:10 <SteveH_> ... seperaters, delimiters
14:09:11 <AlexPassant> Zakim, ??P26 is me
14:09:11 <Zakim> +AlexPassant; got it
14:09:31 <SteveH_> LeeF: testcases, update issues, concurrency, transactions etc.
14:09:43 <bglimm> bglimm has joined #sparql
14:09:45 <SteveH_> ... punt on the or have some sort of informative content (?)
14:09:46 <bglimm> Zakim, who is on the phone?
14:09:46 <Zakim> On the phone I see LeeF, kasei (muted), AndyS, SteveH_, OlivierCorby, Souri, MattPerry, dcharbon2 (muted), Sandro, pgearon, chimezie (muted), +, AlexPassant
14:10:00 <bglimm> Zakim, + is me
14:10:00 <Zakim> +bglimm; got it
14:10:06 <SteveH_> ... also a bit of time on a testsuite for update
14:10:17 <SteveH_> ... afternoon, open issues in protocol, HTTP update docs
14:10:23 <bglimm> Zakim, mute me
14:10:23 <Zakim> bglimm should now be muted
14:10:32 <SteveH_> ... protocol will be clearer when we've finished the update lang
14:10:46 <SteveH_> ... day 2 big block of time to resolve open query issues
14:11:05 <SteveH_> ... decide on minus v's not exists
14:11:21 <SteveH_> ... resolve handling of errors in aggreagates, group by
14:12:25 <SteveH_> ... property paths
14:12:33 <SteveH_> ... afternoon, entailment issues
14:12:35 <bglimm> Zakim, unmute me
14:12:35 <Zakim> bglimm should no longer be muted
14:12:43 <SteveH_> ... entailment moving ahead nicely
14:12:52 <SteveH_> noise on line
14:13:10 <LeeF> zakim, mute bglimm
14:13:10 <Zakim> bglimm should now be muted
14:13:19 <bglimm> Zakim, unmute me
14:13:19 <Zakim> bglimm should no longer be muted
14:13:38 <AndyS> zakim, who is speaking?
14:13:43 <LeeF> bglimm, we have to mute you because there's too much noise on your line
14:13:47 <LeeF> Zakim, mute bglimm
14:13:47 <Zakim> bglimm should now be muted
14:13:48 <bglimm> ok
14:13:49 <Zakim> AndyS, listening for 10 seconds I heard sound from the following: AndyS (14%), bglimm (74%)
14:14:30 <SteveH_> LeeF: entailment seems to have good progress, discuss status
14:14:35 <LeeF> bglimm, what I was saying is that I've seen very good progress on the entailment document over email and the entailment teleconferences, so we've set aside an hour to discuss with the whole group the status of the entailment work, but think that's in good shape and probably doesn't needmore time than that at the face to face
14:14:35 <SteveH_> .. doesn't need more time than that
14:14:54 <bglimm> seems reasonable
14:14:58 <SteveH_> ... 1h for service description issues, few hanging around, overall in good shape
14:15:18 <SteveH_> ... ambitious agenda, but important F2F
14:15:27 <SteveH_> .. finalising spec text, thinking about LC
14:15:34 <SteveH_> ... finalising spec text, thinking about LC
14:16:04 <SteveH_> AndyS: make sure time perm. features don't displace mandatory ones
14:16:19 <SteveH_> AndyS: eg. property paths last in query
14:16:31 <SteveH_> LeeF: I'm going to keen an eye on it
14:16:56 <SteveH_> LeeF: property paths, func. lib. for almost all intents are deliverables, seen no show stopping issues, good progress
14:17:17 <SteveH_> LeeF: do want to talk about them early on, more concerned with federated query, discusss and beginning
14:17:26 <SteveH_> ... maybe relabel some
14:17:51 <SteveH_> ... today, open issues for HTTP update, and property paths
14:18:03 <SteveH_> ... less open issues on http update
14:18:09 <chimezie> Zakim, unmute me
14:18:09 <Zakim> chimezie should no longer be muted
14:18:12 <SteveH_> ... improve visibility
14:18:15 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0521.html
14:18:43 <SteveH_> ... discussion around BASE URI for references and ?graph=
14:18:51 <SteveH_> ... not totaly swapped in
14:19:10 <LeeF> http://www.w3.org/2009/sparql/docs/http-rdf-update/
14:19:17 <AxelPolleres> AxelPolleres has joined #sparql
14:19:19 <SteveH_> chimezie: removed editorial notes re. type of RDF payload, whether doc described REST style
14:19:32 <SteveH_> ... impl. of protocol should interpret contnet-type headers appropriately
14:19:42 <SteveH_> ... issues around making base URIs clear
14:19:59 <SteveH_> ... how do you determine what the base URI is
14:20:20 <SteveH_> ... motivating usecase is where you you the ?graph=, in that scenario, depends how you interpret some RFC
14:20:43 <SteveH_> ... 2 sections that are relevant, "encapsulating entity", layered messages
14:21:08 <SteveH_> ... but it says that you can determine the base uri if there's [something]
14:21:24 <SteveH_> ... can be a way of tagging metadata for specific formats
14:21:39 <SteveH_> ... can say that ?graph= can specify the base URI
14:21:57 <SteveH_> ... or can have conservative reading, should have RFC as normative reference
14:22:10 <LeeF> http://foo.example.com/sparql?graph=g
14:22:12 <SteveH_> LeeF: goal of usecase is so that if do HTTP op like:
14:22:34 <SteveH_> ... is there a reading that the RFC lets us treat <g> as the base URI
14:23:01 <SteveH_> chimezie: language suggests we can provide a way to give it in context
14:23:09 <SteveH_> ... not neccesarily meant to support that
14:23:16 <SteveH_> ... matter of how much you want this usecase
14:23:18 <SteveH_> q+
14:23:27 <LeeF> <> a :NamedGraph
14:23:38 <LeeF> ack SteveH_
14:23:40 <SteveH_> ... in some situation you want the name of the graph...
14:24:00 <LeeF> SteveH_: we use this approach a lot - without the base URI being the bit after graph=, it would be almost impossible to use it
14:24:13 <LeeF> ... we have  a cache of a few million FOAF files, many of which use rdf:about="" to talk about the graph
14:24:19 <LeeF> ... if the graph had the SPARQL endpoint prefix, it would be unhelpful
14:24:52 <SteveH_> LeeF: I'd be surprised is anyone in the group who doesn't support that usecase
14:24:57 <SteveH_> ... does anyone not support?
14:25:15 <SteveH_> ... question is, can we suport that usecase
14:25:49 <SteveH_> ... do we hav a valid reading of the base URI stuff [to Sandro]
14:26:02 <SteveH_> sandro: there's a lot of people who might give it some thought
14:26:12 <SteveH_> ... formal way is as a editors comment in next draft
14:26:22 <SteveH_> LeeF: I think that's a good way to proceeed
14:26:50 <SteveH_> ... people looking at it from named graph p.o.v. will want it to work that way, but HTTP/REST people might not
14:27:06 <SteveH_> ... chimezie will put some text in that calls out this problem
14:27:16 <SteveH_> ... any more open issues?
14:27:23 <SteveH_> chimezie: no, not really
14:27:38 <SteveH_> ... issues-20 is relevant
14:27:50 <SteveH_> LeeF: hoping to resolve in update language
14:28:19 <AndyS> Different issue -- g must be an absolute URI? Hope so.
14:28:55 <SteveH_> +1 to AndyS 
14:28:59 <chimezie> if it isn't the next level of precedence would be the retrieval URI 
14:29:36 <SteveH_> LeeF: overall doc looks to be in good shape
14:29:45 <AndyS> Maybe not - ?graph=../otherPlace/graph1 - hmm
14:29:52 <SteveH_> ouch
14:30:05 <SteveH_> LeeF: have we discussed what testcases will look like
14:30:18 <SteveH_> chimezie: scope is well defined, I have some ideas
14:30:28 <SteveH_> .. not up to date on tools, e.g. EARL
14:31:29 <SteveH_> LeeF: will discuss testing at F2F
14:31:37 <LeeF> topic: property paths
14:31:39 <SteveH_> ... property paths:
14:31:57 <chimezie> Zakim, mute me
14:31:57 <Zakim> chimezie should now be muted
14:31:59 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0566.html
14:33:13 <SteveH_> AndyS: description of multi-path issues
14:33:23 <SteveH_> ... should you see duplicates of ways from A to B
14:33:27 <LeeF> :a foaf:knows :b .
14:33:27 <LeeF> :a foaf:knows :c .
14:33:27 <LeeF> :b foaf:knows :d .
14:33:27 <LeeF> :c foaf:knows :d .
14:33:27 <LeeF>    {?x foaf:knows{2} ?y}
14:33:35 <SteveH_> ... document is not clear
14:33:50 <SteveH_> ... related to this is cycles
14:34:12 <SteveH_> ... go round a loop and get back to where you started - those are important in the case of unbounded operators (*/+/,)
14:34:27 <SteveH_> ... in those cases you don't want infinite answers
14:34:44 <SteveH_> ... proposal is to define fixed length ones to triple expansions, define operators not to duplicate
14:34:58 <SteveH_> ... equivalent to "simple paths" in graph theory
14:35:12 <SteveH_> ... can get surprises, but it's a consequence of balance
14:35:19 <SteveH_> ... of intuition
14:35:45 <SteveH_> LeeF: so, fixed length property paths should be equiv to expansion pattern
14:35:54 <SteveH_> ... can you repeat description of cycles proposal
14:35:59 <SteveH_> AndyS: consider:
14:36:00 <AndyS> Consider ?x foaf:knows* ?y 
14:36:09 <SteveH_> ... on data above
14:36:24 <AndyS> :a foaf:knows* ?y
14:36:37 <SteveH_> ... so there's two paths from :a to :b
14:36:53 <SteveH_> s/:b/:c/
14:36:59 <LeeF> to :d actually
14:37:04 <bglimm> but how do you rewrite that into standard BGPs without knowing the graph?
14:37:16 <SteveH_> q+
14:37:29 <bglimm> ah, so the non-fixed length ones are not being rewritten
14:37:43 <LeeF> q+
14:37:46 <LeeF> ack SteveH_
14:37:47 <pgearon> q+
14:37:48 <SteveH_> AndyS: proposal is that operators won't return dups
14:38:21 <LeeF> SteveH_: What values does ?y take? :a (zero length), :b, :c, :d -- one of each as proposed
14:39:38 <LeeF> ack LeeF
14:40:09 <SteveH_> LeeF: was going to suggest not following same edge twice, need to thing about it
14:40:13 <LeeF> ack pgearon
14:40:26 <SteveH_> pgearon: add comment about unbounded ops
14:40:44 <SteveH_> ... agree with no dups, when loops are present
14:40:53 <SteveH_> ... don't see any reason to stop at 2
14:41:07 <SteveH_> ... if there's a loop, only the single result is relevant
14:42:50 <chimezie> Zakim, unmute me
14:42:50 <Zakim> chimezie should no longer be muted
14:43:02 <SteveH_> AndyS: might be possible to define it in terms of not going through the same node twice
14:43:10 <SteveH_> LeeF: might be worth sketching that out
14:43:17 <SteveH_> AndyS: yes
14:43:35 <SteveH_> chimezie: if you exlucde the dups, you have counter-intuative answers
14:43:48 <SteveH_> ... I assumed it wouldn't affect cases where you didn't have cycles
14:44:10 <SteveH_> LeeF: when you use a non-fixed operator, even without loops you can DISTINCT
14:44:20 <SteveH_> ... as a simple way to solve problem
14:44:37 <SteveH_> chimezie: I would agree that we should look at more direct soltuion to no loops
14:44:50 <SteveH_> LeeF: I will try to write that up, but don't know if I can
14:44:58 <SteveH_> ... leave open for ML discussion
14:45:19 <SteveH_> AndyS: would still get different cardinalities, but may be more consistent
14:45:26 <SteveH_> ... and maybe easier to implement
14:46:13 <SteveH_> LeeF: cycles and dups, continue discussions
14:46:15 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0568.html
14:46:22 <SteveH_> ... negated prop. classes
14:46:52 <SteveH_> AndyS: suggestion around neg clasess, other systems have something similar, it's quite natural
14:47:07 <SteveH_> ... exclude some properties, e.g. is rdf:type, want to find non-type connections
14:47:31 <SteveH_> ... wondering whether you need both forwards and backwards, not convinved in all cases, would be easier to impl. without backwards
14:47:45 <SteveH_> LeeF: can ask if there's any connection whatsoever?
14:47:56 <SteveH_> AndyS: yes
14:48:21 <SteveH_> LeeF: that's not the same as allowing varaibles, because you can't ak what the path is
14:48:33 <SteveH_> AndyS: don't have to decide how to return results
14:48:42 <SteveH_> ... it doesn't open /that/ can of worms
14:48:50 <SteveH_> LeeF: do you impl.?
14:49:05 <SteveH_> AndyS: experiementally, fixed direction case is  doable, and natural
14:49:24 <SteveH_> ... not done forwards and reverse, think I understood it, ran out of time
14:49:51 <SteveH_> chimezie: versa is most similar, we had negation, it was useful
14:50:00 <SteveH_> ... it was straightforward
14:50:13 <SteveH_> AndyS: did you allow negation of forwards and backwards at same time
14:50:15 <SteveH_> q+
14:50:32 <SteveH_> ... my feeling at the moment is that the fixed direction case is OK, mixed is not easy
14:50:39 <LeeF> ack SteveH_
14:50:55 <LeeF> SteveH_: what's the use case for the reverse direction?
14:51:00 <LeeF> ... in this scenario
14:52:26 <pgearon> +1
14:53:00 <SteveH_> LeeF: like to poll group on neg in property paths
14:53:12 <SteveH_> ... take Andy's email as a start, noodle on it a bit
14:53:20 <SteveH_> ... see if we can resolve at F2F
14:53:37 <LeeF> straw poll: gut feeling on including ! (negation operator) in property paths
14:53:48 <chimezie> +1 (but not both)
14:53:58 <SteveH_> +1 (but not both)
14:53:59 <AlexPassant> +1
14:54:03 <AndyS> +1
14:54:04 <OlivierCorby> +1
14:54:06 <chimezie> i.e., not negation for bidrectional paths
14:54:14 <LeeF> 0
14:54:15 <kasei> 0
14:54:21 <bglimm> -0 (seems making evaluation really harder)
14:54:23 <MattPerry> 0
14:55:24 <SteveH_> I change to 0
14:55:29 <SteveH_> scared!
14:55:34 <pgearon> I have to say 0
14:55:37 <AndyS> My impl is one Java class for the evaluator.
14:55:41 <sdas2> sdas2 has joined #sparql
14:56:31 <AndyS> q+
14:56:42 <LeeF> ack AndyS
14:56:52 <SteveH_> AndyS: impl. exp. would be good, but usecases also very useful
14:56:56 <LeeF> seconded - use cases here will let us know how useful this is
14:57:37 <SteveH_> LeeF: not going to talk about update, out of time
14:58:05 <SteveH_> AndyS: havent discusses binary/unary ^ operator
14:58:20 <SteveH_> ... preference for unary in WG, binary outside
14:58:40 <SteveH_> ... it's always a unary operator, q is if you can write short form
14:58:47 <bglimm> well, implementation experience is one thing, but I am also wondering whether that does not push BGP evaluation into higher complexity classes (regular expressions are so close to finite state automata and complement there causes an exponential blow up of the states, in OWL property negation makes reasoning undecidable, so all that raised some warnings to me)
14:59:05 <SteveH_> didn't hear andy
14:59:33 <bglimm> ah, to me they suggested a breakfast
14:59:48 <SteveH_> breakfast on 26th would make sense
14:59:58 <Zakim> -chimezie
15:00:00 <Zakim> -Souri
15:00:00 <Zakim> -SteveH_
15:00:01 <Zakim> -LeeF
15:00:02 <Zakim> -kasei
15:00:03 <Zakim> -Sandro
15:00:04 <Zakim> -bglimm
15:00:05 <Zakim> -MattPerry
15:00:05 <Zakim> -dcharbon2
15:00:05 <MattPerry> quit
15:00:07 <Zakim> -pgearon
15:00:09 <Zakim> -OlivierCorby
15:00:15 <kasei> AndyS, did you see my question regarding the RV-2 response?
15:00:16 <Zakim> -AndyS
15:00:41 <AndyS> Err - no - pointer to email?
15:00:44 <kasei> wondering if the @@ comments were for me, you, or somebody else (Steve?)
15:00:57 <kasei> no email... was in here yesterday at some point.
15:01:15 <kasei> I'd like to finish up that response and get it off if possible.
15:01:20 <AndyS> Ah - in the draft - @@ are "should be done (IMHO)"
15:01:41 <bglimm> If the SWIG does not plan for a dinner, I would suggest I reserve a table at some nearby restaurant, otherwise they might plan the evening?
15:02:09 <kasei> as in,  that's part of the response?
15:02:21 <AndyS> Mostly aggregates and the text so far didn't seen to cover it (steve?)  RV split his comments up and scatter aggs over the whole email.
15:03:07 <AndyS> we should add text there - @@ is W3C speak for "to be done"
15:03:32 <kasei> right. i was just wondering if that was for your benefit, or if somebody else should be looking at addressing the "to be done" state of things.
15:04:24 <AndyS> My part is done but if you think there is something I need to attend to then do say.  aggs is SteveH_
15:04:32 <AndyS> (sorry SteveH_)
15:04:39 <kasei> ah, ok. that's what I was after. thanks.
15:04:46 <kasei> SteveH_, still around?
15:04:49 <SteveH_> yeah, hi
15:04:52 <SteveH_> reading back
15:05:25 <AndyS> http://www.w3.org/2009/sparql/wiki/CommentResponse:RV-2
15:06:06 <AxelPolleres> AxelPolleres has joined #sparql
15:06:42 <SteveH_> I thought I'd addressed all the aggregate stuff
15:07:33 <kasei> I think AndyS filled out my summarization of the issues that Rob talked about, leaving room for more responses :)
15:08:53 <SteveH_> oh, he has some comments on issues 35,36,39,40
15:08:59 <SteveH_> I'll write some text for those
15:09:40 <kasei> thanks. appreciate it. can you ping me at some point after you do that?
15:11:45 <Zakim> -AlexPassant
15:11:47 <Zakim> SW_(SPARQL)10:00AM has ended
15:11:52 <Zakim> Attendees were LeeF, +1.518.276.aaaa, kasei, AndyS, +49.238.aabb, SteveH_, OlivierCorby, +1.603.897.aacc, AlexPassant, MattPerry, Souri, +1.919.332.aadd, Sandro, dcharbon2,
15:11:54 <Zakim> ... +1.312.863.aaee, pgearon, +1.216.444.aaff, chimezie, bglimm
15:13:27 <SteveH_> kasei, AndyS. updated wiki page
15:14:04 <kasei> ah, fantastic. thanks.
15:24:29 <OlivierCorby> OlivierCorby has left #sparql
16:26:29 <AxelPolleres> AxelPolleres has joined #sparql
16:57:20 <AxelPolleres> AxelPolleres has joined #sparql
17:08:15 <Zakim> Zakim has left #sparql
17:21:24 <ivan> ivan has joined #sparql
18:08:54 <ivan> ivan has joined #sparql