13:47:54 RRSAgent has joined #sparql 13:47:54 logging to http://www.w3.org/2009/03/31-sparql-irc 13:47:56 RRSAgent, make logs world 13:47:56 Zakim has joined #sparql 13:47:58 Zakim, this will be No Teleconference 13:47:58 I do not see a conference matching that name scheduled within the next hour, trackbot 13:47:59 Meeting: SPARQL Working Group Teleconference 13:47:59 Date: 31 March 2009 13:48:05 oh well, that was close 13:48:09 zakim, this will be SPARQL 13:48:09 ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 12 minutes 13:48:15 :-) 13:50:27 bijan has joined #sparql 13:53:55 SW_(SPARQL)10:00AM has now started 13:54:02 +??P5 13:54:06 zakim, ??p5 is me 13:54:06 +bijan; got it 13:54:47 just no one else there yet 13:54:49 i imagine :) 13:54:58 Except me :) 13:55:03 zakim, code? 13:55:03 the conference code is 77277 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), LeeF 13:55:21 LeeF: Another mancuian shall be joining the group soon 13:55:31 So we'll have more consistent coverage from here 13:56:03 bijan, excellent 13:56:12 +??P10 13:56:17 zakim, ??P10 is me 13:56:19 +AndyS; got it 13:56:39 zakim, who is on the phone? 13:56:39 On the phone I see bijan, AndyS 13:56:41 + +2 13:56:58 - +2 13:57:09 +john-l 13:57:41 +kasei 13:58:36 + +049261287aabb 13:58:46 Zakim, aabb is me 13:58:46 +SimonS; got it 13:58:53 +??P17 13:59:01 Zakim, please mute me 13:59:01 john-l should now be muted 13:59:15 zakim, ??p17 is me 13:59:16 +AlexPassant; got it 13:59:35 -AndyS 13:59:41 zakim, mute me 13:59:41 bijan should now be muted 13:59:42 SteveH has joined #sparql 13:59:52 zakim, dial ivan-voip 13:59:52 ok, ivan; the call is being made 13:59:53 +Ivan 14:00:00 LukeWM has joined #sparql 14:00:14 +??P20 14:00:19 zakim, ??P20 is me 14:00:19 +AndyS; got it 14:00:34 +??P21 14:00:43 Zakim, ??P21 is [Garlik] 14:00:43 +[Garlik]; got it 14:01:01 chimezie has joined #sparql 14:01:01 Very quiet on the phone or is it my connection? 14:01:10 Zakim: passcode? 14:01:19 AndyS: no, it's very quiet 14:01:21 noones talking, AFAICT 14:01:31 Zakim, what is the code? 14:01:31 the conference code is 77277 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), kjetil 14:01:41 +Lee_Feigenbaum 14:01:53 +Chimezie_Ogbuji 14:01:56 zakim, who's here? 14:01:56 On the phone I see bijan (muted), john-l (muted), kasei (muted), SimonS, AlexPassant, Ivan, AndyS, [Garlik], Lee_Feigenbaum, Chimezie_Ogbuji 14:01:58 On IRC I see chimezie, LukeWM, SteveH, bijan, Zakim, RRSAgent, AndyS, kasei, LeeF, AlexPassant, SimonS, ivan, AndyS_, kjetil, trackbot, iv_an_ru, john-l, sandro, KjetilK, ericP 14:02:11 Regrets: Axel, Souri 14:02:14 Chair: Lee Feigenbaum 14:02:15 +JanneS 14:02:19 something strange with my phone :| 14:02:23 +??P33 14:02:30 Zakim, ??P33 is me 14:02:33 +??P14 14:02:36 +kjetil; got it 14:02:44 zakim, ??P14 is Orri 14:02:48 +Orri; got it 14:03:51 Zakim, mute me 14:04:04 Scribenick: SteveH 14:04:05 kjetil should now be muted 14:04:07 JanneS has joined #sparql 14:04:39 topic: administrivia 14:04:43 PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-24 14:04:49 LeeF: PROPOSED approved mins from last week 14:05:02 +1 14:05:07 SteveH: 2nd 14:05:16 Nth 14:05:27 scribenick: SteveH 14:05:38 scribe: SteveH 14:05:42 RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-24 14:05:54 topic: F2F 14:05:55 Zakim, please dial ericP-office 14:05:55 ok, ericP; the call is being made 14:05:57 +EricP 14:06:02 -EricP 14:06:10 Zakim, please dial ericP-office 14:06:10 ok, ericP; the call is being made 14:06:12 +EricP 14:06:17 LeeF: set for F2F on 7th, cambridge and bristol 14:06:37 -> http://www.w3.org/2009/sparql/wiki/F2F1 14:06:50 LeeF: do we prefer web survey to wiki 14:06:54 looks like the3 wiki has it 14:07:05 zakim, who's here? 14:07:05 On the phone I see bijan (muted), john-l (muted), kasei (muted), SimonS, AlexPassant, Ivan, AndyS, [Garlik], Lee_Feigenbaum, Chimezie_Ogbuji, JanneS, kjetil (muted), Orri, EricP 14:07:08 On IRC I see JanneS, chimezie, LukeWM, SteveH, bijan, Zakim, RRSAgent, AndyS, kasei, LeeF, SimonS, ivan, AndyS_, kjetil, trackbot, iv_an_ru, john-l, sandro, KjetilK, ericP 14:07:10 LeeF: everybody to add status to wiki 14:08:21 LeeF: need to juggle scibe list for 7th april 14:08:37 LeeF: compliments on not messing up time change 14:08:59 AlexPassant has joined #sparql 14:09:05 q+ to ask about HTML5 14:09:11 zakim, unmute me 14:09:11 bijan should no longer be muted 14:09:20 q+ to say i implemented the SPARQL grammar with curis 14:09:37 ack bijan 14:09:37 bijan, you wanted to ask about HTML5 14:09:45 bijan: on CURIEs, don't think there's anything to talk about, WG has setup dependency on SPARQL re. CURIEs 14:09:59 AndyS: confused, SPARQL does not depend on CURIE 14:10:04 LeeF: OWL also does not 14:10:07 q+ 14:10:22 bijan: suggest not to delegate to CURIE spec 14:10:27 -> http://www.w3.org/2005/01/yacker/uploads/SPARQL_CURIE?lang=perl&markup=html SPARQL grammar with CURIEs 14:10:38 ack ericp 14:10:38 ericP, you wanted to say i implemented the SPARQL grammar with curis 14:10:45 ericP: ralph asked would they work, turns out they do 14:11:04 We would support prefix:path/to/something with curies, right? 14:11:08 ericP: ~103 changes a bit 14:11:12 LeeF: move to ML 14:11:20 ack ivan 14:11:45 ivan: from now on OLW makes normative ref. to SPARQL as far as prefix is concerned 14:11:56 ivan: is SPARQL wants to change that we have to be careful 14:12:00 s/OLW/OWL/ 14:12:41 bijan: HTML5 WG is considering RDFA, this group might have some input, it's in some sense relevent, wanted to raise 14:12:45 Specifically on production [98], [99], [100] 14:12:52 bijan, hints as to what we might want to sniff at? 14:13:00 zakim, mute me 14:13:00 bijan should now be muted 14:13:22 Well, for example, if RDFa is in HTML5 we might want to support querying it directly 14:13:30 LeeF: disucuss on ML if you have an opinion on HTML5+RDFa 14:13:53 -> http://www.w3.org/2009/sparql/track/ tracker for SPARQL WG 14:13:54 LeeF: we have tracker setup that keeps track of actions, ala DAWG v1 14:14:13 -> http://www.w3.org/2009/sparql/track/actions/open open actions 14:14:36 trackbot, close action-1 14:14:36 ACTION-1 Ask EricP to setup a WBS for the F2F closed 14:14:42 q+ 14:14:52 Zakim, unmute me 14:14:52 kjetil should no longer be muted 14:15:10 action-4: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0186.html 14:15:10 ACTION-4 Summarise the vocabularies (DARQ, SADDLE, voiD) notes added 14:15:21 trackbot, close action-4 14:15:21 ACTION-4 Summarise the vocabularies (DARQ, SADDLE, voiD) closed 14:15:54 q- 14:16:04 trackbot, close action-5 14:16:04 ACTION-5 Add security issues to query by reference feature closed 14:16:08 action-2: http://www.w3.org/2009/sparql/wiki/RedundandFeature:Parameterised_queries#Use_cases 14:16:09 ACTION-2 Update the wiki page with his experience (caveat: kjetil may be delayed in doing it) notes added 14:16:25 LeeF: features 14:16:26 trackbot, close action-2 14:16:26 ACTION-2 Update the wiki page with his experience (caveat: kjetil may be delayed in doing it) closed 14:16:37 topic: ExecCommentsAndWarning 14:16:43 LeeF: exec comments and warnings feature... 14:16:44 Topic: Features 14:17:01 Zakim, mute me 14:17:01 kjetil should now be muted 14:17:55 Orri: runtime exceptions, any possible number of errors, would like to be able to stream the results, with errors inline 14:18:21 Orri: would like to be able to send first row of results, but put errors after 14:18:25 q+ 14:18:47 orri: we have cases where we need to stream the results 14:18:49 ack SteveH 14:19:05 SteveH: Two of our internal engines do this using an ASCII-based result format 14:19:18 action-2: Whoops, wrong link, this is it: http://www.w3.org/2009/sparql/wiki/Feature:ReturnFormatKeyword#Related_Use_Cases.2FExtensions 14:19:18 ACTION-2 Update the wiki page with his experience (caveat: kjetil may be delayed in doing it) notes added 14:20:01 LeeF: my concern is that we don't have a lot of impl. experience, would need to play within the existing result format, dont see strainghtforward way to do that 14:20:10 AndyS: I can see straightforward way 14:20:19 iv_an_ru: I don't think it's difficult 14:20:27 LeeF: how about CONSTRUCT 14:20:30 Not me - that's Orri 14:20:32 q+ 14:20:38 q+ 14:20:58 iv_an_ru: could include triples in dedicated namespace, some kind of convention with triples 14:21:04 s/iv_an_ru/Orri 14:21:19 SteveH: we do it in RDF/XML using XML comments 14:21:21 ack SteveH 14:21:24 ack AndyS 14:21:49 AndyS: for SELECT, if it is a change to format to put in something other than a row, would be changing schema, so people may be affected 14:22:07 also we do same in SPARQL XML res 14:22:14 (comment that i) 14:22:33 LeeF: straw poll 14:23:15 zakim, who's here? 14:23:15 On the phone I see bijan (muted), john-l (muted), kasei (muted), SimonS, AlexPassant, Ivan, AndyS, [Garlik], Lee_Feigenbaum, Chimezie_Ogbuji, JanneS, kjetil (muted), Orri, EricP 14:23:18 On IRC I see AlexPassant, JanneS, chimezie, LukeWM, SteveH, bijan, Zakim, RRSAgent, AndyS, kasei, LeeF, SimonS, ivan, AndyS_, kjetil, trackbot, iv_an_ru, john-l, sandro, KjetilK, 14:23:20 ... ericP 14:23:25 -1, too early, compatibility issues 14:23:25 +1 14:23:26 0; but might support standarizing an xml ns URI for this use (outside spec) 14:23:26 0 14:23:27 0 14:23:27 0 14:23:28 0 14:23:29 0 (-1 if it includes deciding errors that can be reported) 14:23:30 0 14:23:31 -1 14:23:32 0 14:23:32 er.. - 14:23:33 0 14:23:34 0 14:23:34 0 14:23:40 Orri: +1 14:23:50 zakim, unmute me 14:23:50 bijan should no longer be muted 14:24:08 REAL VOTE: +0 14:24:11 0 14:24:11 zakim, mute me 14:24:11 bijan should now be muted 14:24:30 topic: query response linking 14:24:31 I would go +1 probably after examining the existing implementations 14:24:32 Topic: query response linking 14:24:40 -> http://www.w3.org/2009/sparql/wiki/Feature:Query_response_linking 14:25:13 SimonS: the idea is to add something to protocol to set links to additional information, eg. a licencse to an endpoint that prodiced, endpoint etc. 14:25:22 SimonS: can do it in SELECT, but not typed 14:25:32 SimonS: similar to HTML link tag 14:25:44 q+ 14:25:49 SimonS: has a number of relationship types that are listed, but we could do something else 14:26:00 SimonS: so it can be in CONSTRUCT 14:26:29 yes, was me 14:26:46 +DaveNewman 14:26:50 ivan: dont know all details, but there were discussions in HTML for categorising, wouldn't that cover it 14:27:04 +q 14:27:05 ivan: do we have to do anything, or rely on HTTP 14:27:10 q- 14:27:25 setting the http headers of a response is generally harder than changing the body content. 14:27:27 LeeF: would be a bit strange to do it in HTTP header for more expresivity 14:27:28 Isn't there a clog in the process of registering HTTP Link header? 14:27:30 q+ 14:27:40 ack SimonS 14:27:42 dnewman2 has joined #sparql 14:28:05 SimonS: I think having it in protocol would be better, we should have something like the thing in HTML4, should have something based on URIs 14:28:10 ack SteveH 14:28:40 SteveH: having this in the result format is wacky since it only applies to SELECT results, but nothing mandates that SPARQL be over HTTP 14:28:48 ... on balance I'd rather see it in protocol 14:29:13 LeeF: if we accept this, we still have plenty of lattitude, so discussion could come later 14:29:18 the wiki page gives an example of using it in an RDF response (construct/describe) 14:30:22 orri: I think the usecase is has to do with data being returned, might be licencing, eg. if we repurpose, then sth like CC you have to reference source, it's probably better in protocol than HTTP 14:30:22 q+ 14:30:31 ack me 14:31:06 kjetil: I think that I would have done it by having graph names for the licence, so this could be doe mostly at the endpoint without change to protocol 14:31:16 ... not in the general case, but for many it doesn't need to go in 14:31:27 LeeF: 1 argument is for having a standard place to look 14:31:40 LeeF: is there value in specific types of metadata 14:31:58 kjetil: thats a general problem with data discovery, a licence is just another triple 14:32:00 q+ 14:32:04 ack SteveH 14:32:22 If in protocol, it will likely get split from the results if stored or passed on. 14:32:37 SteveH: a bit concerned about oversimplification - consider the case in which an end point is serving data from multiple sources with multiple licenses 14:33:21 +1 14:33:23 0 14:33:23 0 14:33:23 -1 14:33:28 +1 14:33:30 +1 14:33:30 0 14:33:32 0 14:33:32 Zakim, mute me 14:33:32 kjetil should now be muted 14:33:32 -1 14:33:33 +1 14:33:35 -1 (trying to set priorities) 14:33:37 Orri: 0 14:33:39 -1 14:33:44 -1 14:33:44 0 14:33:45 0 14:34:03 Topic: query language features 14:34:12 subtopic: assignment 14:34:16 Topic: assignment 14:34:19 -> http://www.w3.org/2009/sparql/wiki/Feature:Assignment 14:35:01 agenda+ renaming feature wiki pages 14:35:18 AndyS: the idea is to have explicit statement when you want to bind a variable to a value, strongly related to expressions in subselects, similar but assgnments can be said to be clearer, assignment could be a syntactic way of doing the other thing 14:35:22 q+ 14:35:33 AndyS: implemented in ARQ, it's quite popular 14:36:04 LeeF: is assingment purely syntactic if we have susbselect and named projection 14:36:14 AndyS: not sure about scoping, but they're clearly related 14:36:15 ack SteveH 14:36:44 SteveH: Assignment as a native feature rather than syntactic sugar scares me - doesn't seem to fit into a query language 14:36:53 SteveH: ...given my background 14:37:22 -Orri 14:37:27 AndyS: similar thing is the ability to put an expression inline, syntactic sugar for putting a [something] in there 14:37:47 q+ 14:37:50 AndyS: it doesn't introduce a binding, but it's in the same space 14:37:50 http://www.w3.org/2009/sparql/wiki/Feature:ScalarExpressionsInTriplePatterns 14:37:58 ack ericP 14:38:13 ericP: I would argue that creating a varaible is doable in SQL, but you name it with the expression name 14:38:16 XQuery has lots of variables :) 14:38:19 My main concern (in addition to possible redundancy with subselects) is control of recursion which is handled 'naturaly' by sub-select and grouped graph patterns 14:38:20 For...Let... 14:38:24 ericP: in SPARQL we would just name it with a bound variable name 14:38:28 q+ to reply 14:38:45 AndyS: you cant write a recursive expression 14:38:55 But I share SteveH's inclination toward fear. But I also share his sense that it might be an unwarrented fear :) 14:39:03 +??P14 14:39:12 zakim, ??P14 is Orri 14:39:12 +Orri; got it 14:39:30 chimezie: doesn't it depend on evaluation model, you could assign to an expression that is refered to outside 14:39:37 AndyS: the prosoal doesnt cover that 14:39:45 s/prosoal/proposal 14:39:55 ack SteveH 14:39:55 SteveH, you wanted to reply 14:39:58 AndyS, can/could there be function calls on the right side of the assignment? Or do you implement that in ARQ? 14:40:01 SteveH: in SQL it doesn't *look* like a variable assignment 14:40:16 SteveH: +1 to Eric that you can do similar in SQL, but it doesn't look like assignment - it's the syntax that scares me since it looks like an assignment, it's non-obvious how it works 14:40:21 q+ 14:40:22 ... i don't know the scope. is it pure functional? 14:40:29 q+ to ask for pointers to examples 14:40:31 ... worried about user expectations 14:41:03 AndyS: can have functions on RHS 14:41:23 AndyS: these issues will all arise, but now talking about details of mechanism, quaestion is do we want this feature 14:41:29 zakim, unmute me 14:41:29 bijan should no longer be muted 14:41:32 ack bijan 14:41:32 bijan, you wanted to ask for pointers to examples 14:41:42 ack AndyS 14:41:50 bijan: wondering if andy has pointers to examples from users, having trouble wrapping mind around standard functions 14:41:58 http://www.w3.org/2009/sparql/wiki/Feature:Assignment 14:42:24 bijan: looking for app examples, where used in anger 14:42:44 If functions are allowed on right side, maybe those who map SPARQL to SQL could not evaluate such expressions? 14:42:47 AndyS: used particularly in the case where there's a CONTRCUT 14:42:53 -> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Mar/0009.html Holger's commets 14:43:00 zakim, mute me 14:43:00 bijan should now be muted 14:43:00 q? 14:43:09 Janne - yes and same as FILTER situation isn't it? 14:43:21 yup 14:43:24 LeeF: anyone else implemented it 14:43:33 SimonS: we did it but only internally - very useful 14:43:34 SimonS: we did it internally, but can't say anything about user requirements 14:43:48 LeeF: straw poll 14:43:49 -1 14:43:54 +1 14:43:56 +1 14:43:57 q+ 14:43:57 +1 14:44:00 -1 14:44:00 0 14:44:02 q- 14:44:02 0 14:44:05 +1 14:44:07 +0 14:44:09 +1 14:44:11 +1 14:44:14 0 14:44:14 +1 14:44:27 0 14:44:34 Orri: -1 un-query-language like 14:44:38 0 14:44:52 LeeF: fan of feature, but happy to be able to do it other ways 14:45:16 topic: accesing rdf lists 14:45:16 subtopic: accessing rdf lists 14:45:16 http://www.w3.org/2009/sparql/wiki/Feature:AccessingRdfLists 14:45:34 AndyS: desire i to access all memers of a list in a length-neutral way 14:45:47 AndyS: can do it with fixed length lists in some caes, but it gets burdensome 14:46:04 q+ to say this will be a bit difficult, but is probably the most important thing we could do for the semantic web 14:46:13 AndyS: have some way in lang. to get one member per row, could also do most of it with property paths, except that the tail is isself a list 14:46:21 AndyS: so you get duplicates 14:46:22 q+ 14:46:40 AndyS: implemented in ARQ, looks like rdfs:member, but applies to lists 14:46:58 AndyS: used where you don't have closed lists 14:47:16 Orri: we have general transitive subquery, maybe be macro expanded into subquery 14:47:22 orri: no special synta 14:47:22 Is that transitive subquery feature listed on the Wiki? 14:47:31 s/synta/syntax/ 14:47:33 q? 14:47:34 Orri: we would not mid making shorthand 14:47:36 ack ericP 14:47:36 ericP, you wanted to say this will be a bit difficult, but is probably the most important thing we could do for the semantic web 14:48:31 ericP: useful impl. requires ordered results, probably. added in two different implementations to get members of a list, to match any memmbers of a list, to treat as unordered, its not that hard to do, just hard to spec 14:48:33 q? 14:48:35 ack ivan 14:48:55 members(?x) ordered("1" "2") unordered("2" "1") 14:49:00 +1 to ivan's point 14:49:22 ivan: i really believe its important, I've seen several people defineing vocabs, wanted to use lists, but instead they do something convoluted because lists cannot be sparql'd 14:49:33 +1 wrt vocabulary design 14:49:33 ivan: so had negative effect on the way vocabs were defined 14:49:33 AndyS: assuming we had property paths, couldn't the fact tha the list tail is also a list be handled by excluding it from the results? 14:49:40 since the tail is always rdf:nil 14:49:48 s/AndyS:/AndyS, 14:50:12 chimezie: q for AndyS about property paths, if you had prop paths you could overcome by filtering out the tail 14:50:22 AndyS: it's the rdf:nil that's that issue 14:50:31 LeeF: any subset of the list, looks like a list 14:50:34 s/it's/it's not/ 14:50:35 (1 2 3) => (2 3) => (3) => () 14:50:41 I.e., lists aren't objects with distinct boundaries in RDF 14:50:54 chimezie: I'm pretty familiar with path-based, been able to get all the entries 14:51:11 LeeF: my experiance has been that I'm mostly querying for a specific menber 14:51:15 +1 to LeeF 14:51:16 http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0100.html 14:51:41 +q any example, where you do not know the head? 14:51:45 Redundant answers can also be a problem 14:51:55 ack SimonS 14:52:10 SimonS: can you give an example of realworld query where don't know the head 14:52:19 SimonS: whenever I query a list I know the head 14:52:26 q+ 14:52:43 AndyS: to some extent it's a corner case, but can produce a lot of questions 14:52:48 zakim, unmute me 14:52:48 bijan should no longer be muted 14:52:54 ack bijan 14:52:55 AndyS: if you try to get into explaining then it causes confusion 14:53:15 bijan: I would have thought that problem is that when you think you have the query, you're actually punching into the middle 14:53:26 bijan: you could end up querying the tail, that would be a worry 14:53:44 zakim, mute me 14:53:44 bijan should now be muted 14:53:58 +1 14:53:59 +1 14:54:01 +1 14:54:01 +1 14:54:02 +1 14:54:02 LeeF: strawpoll on rdf lists query mechanism 14:54:02 +1 14:54:04 +1 14:54:04 +1 14:54:04 +1 14:54:04 +1 14:54:06 +1 14:54:07 -1 (I'm not convinced that property-path based querying doesn't resolve the real world issue with accessinglists) 14:54:12 +1 14:54:17 (and I hate rdf:lists :)) 14:54:20 -1 ack with chimezie 14:54:25 Orri: +1 14:54:41 -1 (with Simon & Chime) 14:55:01 q+ 14:55:06 q+ to ask about the property path solution people 14:55:34 ivan: if it works with prop paths, the q I have is if prop paths doesn't do it would you still have -1 14:55:50 ?: if it doesn't I would 14:56:01 ack ivan 14:56:04 LeeF: I'm indifferent if we do property paths or not 14:56:08 q- 14:56:09 thanks 14:56:20 I had Ivan's question :) 14:56:23 ericP: +1 on having list access as a requirement, however we do it 14:56:34 ivan: if property paths work, then I happy to sump special syntax 14:56:36 q+ 14:56:38 Though, special syntax should be evaluated separately 14:56:50 orri: it seems that property paths would have to be extended 14:56:58 orri: email about that on the list 14:57:03 ack SteveH 14:57:03 Property Paths are way more heavyweight than special list handling 14:57:20 +1 SteveH 14:57:24 SteveH: counterpoint - in favor of accessing lists, not in favor of property paths 14:57:38 SteveH: in favor of accessing lists, opposed to property paths as they seem complicated 14:57:40 I could see implementations wanting to support lists but not property paths 14:57:46 yup 14:58:12 LeeF: things that don't cleanly fall into nice boxes, bijan asked if anyone would object to moving feature pages so they're not in feature: 14:58:21 don't all of our features start with F? 14:58:26 sorry, could only do 60mins today - cu 14:58:26 -JanneS 14:58:44 LeeF: rationale: feature: makes it hard to read, wouldn't change anything because of categories 14:59:01 +! 14:59:03 +1 14:59:03 MediaWiki is good that way 14:59:06 ivan: just minor, places where I've seen references to feature:, but will forward 14:59:15 +ℑ 14:59:21 +1 only if there is redirect, -1 if not 14:59:22 AndyS: I like them all coming up together 15:00:19 LeeF: inclined to say I don't really care 15:00:35 LeeF: bijan, if you want to do it go ahead 15:01:19 LeeF: next week will look at non-other boxes stuff, eg. XML syntax for queries, RDF synatx for SPARQL, semantics of SPARQL/OWL queries. may also look at other features 15:01:50 LeeF: aroudn end of next telecon, want survey for a couple of weeks to get formal positions on pioritising features 15:01:57 q+ 15:02:11 ack SteveH 15:02:39 condorcet voting 15:02:52 LeeF: outcome would be a small set of 3-4 things that we will do, plus a prioritised set of things we might do time permitting 15:03:05 zakim, mute me 15:03:05 bijan was already muted, bijan 15:03:50 AndyS: does that lead to the idea that you do the 3 or 4 things, then move on the other set, things in initial set, if they're orthogonal and there's enough energy then it's better to put them in the required set 15:03:57 AndyS: telecon is a contraint 15:04:16 Task forces! 15:04:31 LeeF: say we did XML SPARQL serialisation, somewhat orthogonal, if the groups interested were seperate in a some way then they could have seperate telecon 15:04:46 q+ 15:04:54 LeeF: task force of 1-3 people not always best 15:04:55 ack ivan 15:05:03 Bijan, can work but in our short timescale we have to come back together again. 15:05:11 q+ to suggest that the queue should be closed 15:05:12 AndyS: for sure 15:05:22 s/AndyS:/AndyS, 15:05:34 ivan: the problem I have is that, yes it works up to a certain point, but at some point all the results have to properly synchronised (in various ways), that is a major drawback somewhere down the line, we hould be careful 15:05:38 q+ 15:05:38 I was being somewhat ironic 15:05:52 LeeF: we've clearly indentifed some important features 15:06:18 SteveH: concern about task forces having decisions and then re-having those decisions with the main group 15:06:24 SteveH: concearned that TFs will have a discussion within the TF and have to have it again in the greater WG 15:06:55 LeeF: agreed, but I think we can get around it by documenting discussions, and not opening debate, and people can show up at task forces, aware and a little concerned but I think we can deal with it 15:07:09 -Ivan 15:07:13 ivan has left #sparql 15:07:17 -DaveNewman 15:07:17 RRSAgent, please draft minutes 15:07:17 I have made the request to generate http://www.w3.org/2009/03/31-sparql-minutes.html ericP 15:07:20 -john-l 15:07:22 -Chimezie_Ogbuji 15:07:25 -Orri 15:07:27 -Lee_Feigenbaum 15:07:30 -kasei 15:07:30 adjourned. 15:07:33 RRSAgent, please make log world-visible 15:07:34 -[Garlik] 15:07:35 -SimonS 15:07:38 -AlexPassant 15:07:39 -EricP 15:07:41 -kjetil 15:07:44 bijan, but not spelling :) 15:07:55 -AndyS 15:07:56 I never critique most people's orthography 15:07:58 -bijan 15:08:01 SW_(SPARQL)10:00AM has ended 15:08:02 Attendees were bijan, AndyS, +2, john-l, kasei, +049261287aabb, SimonS, AlexPassant, Ivan, [Garlik], Lee_Feigenbaum, Chimezie_Ogbuji, JanneS, kjetil, Orri, EricP, DaveNewman 15:08:02 Being of the orthographically challenged myself 15:08:09 TBL is a notable exception :) 15:08:14 bijan, it's probably a sign of something :) 15:08:50 Sign of extreme attractiveness? (Again, with the TBL exception ;)) 15:08:55 SteveH has joined #sparql 15:09:19 :) 15:09:24 People who may do F2F in Bristol - any requirements? 15:09:46 LukeWM has joined #sparql 15:09:51 caffein and wireless. ;-) 15:09:56 AndyS: somewhere to sit :) 15:10:01 oh yeah, and coffee 15:10:02 We have a nice coffee machine! 15:10:08 yeah, you do 15:10:19 Indeed you do 15:10:35 But we might be in the middle of a large move. That may be a + or - 15:10:56 Wireless or public wired will be provided. 15:11:05 large scale, or large distance? 15:11:22 Large scale - repacking the building. 15:11:27 ah, ok 15:12:16 packing problems are fun 15:12:24 Any recommendations for hotels? 15:13:16 Can get recommendations - there are close and nice - but not really both. 15:14:26 Thanks, I'm willing to compromise, at least to some extend... 15:14:40 As we will be on Boston time (4pm there = 9pm Bristol or later), that might be a factor 15:14:52 kasei has left #sparql 15:15:59 is it {close, cheap, nice} pick two, or pick one? 15:16:55 v close (walking) = 2 IIRC Does not affect me :-) 15:17:12 no :) advantages of hosting 15:17:44 I've stayed in a walking-close hotel, generic business hotel, was ok 15:18:16 Such a pretty town 15:19:05 Indeed 15:19:16 though, might take car, how is parking in city hotels/hp, AndyS? 15:19:21 nuts 15:24:52 Car works. 15:25:28 Hotels have car parks. Drive out of commute time is OK. 15:25:52 Drive during commute is bad if you don't know where you are going. 15:26:40 F2F day is 8am - 4pm (and a big "ha!" to 4pm) ==> 1pm=9pm UK. 15:28:41 1pm to 9pm is an odd schedule 15:29:28 socialise 0900 to 1200, work 1300-2100 :) 15:30:16 Or party 10pm-6am. Sleep. Work from 13:00. But I'm too old for that. 15:30:55 could maybe do it in US, but not with UK daylight 15:31:30 at least with that schedule I can arrive on wednesday, leave thursday evening 15:31:41 dont have to arrive night before 15:56:38 SteveH has left #sparql 16:31:53 AndyS, a technical question. I intend to extend SPARUL a bit, to introduce graph groups and security. 16:31:57 Graph group is a named collection of graph IRIs such that FROM is equivalent to FROM ... FROM . 16:32:50 Security is very traditional. User X Graph --> permissions. 16:34:10 So I'll need extra keywords and grammar for all that things and I don't want to get conflict with your potential extensions. 16:34:30 Are you planning something of the sort? 16:38:47 No specific plans. You will need "FROM GROUP " to differentiate from plain FROM. c.f. proposals/ideas for FROM DATASET 16:39:45 I guess you want up-front declaration. Security Coulf also be done without syntax in the way dataset assembled for a request. 16:39:54 (random thoughts mode) 16:50:26 I don't like both "graph group" and "dataset", they're too overloaded. "set" and "bag" are overloaded as well. Some exotics like "rucksack"? 16:57:35 SteveH has joined #sparql 19:08:04 LeeF has joined #sparql 21:15:52 LeeF_ has joined #sparql 22:01:23 LukeWM has joined #sparql 22:42:06 LukeWM has joined #sparql