From SPARQL Working Group
Revision as of 21:53, 31 March 2009 by Lfeigenb
Please justify/explain all edits to this page, in your "edit summary" text.
<LeeF> Present: Lee, Andy, Steve, Luke, ivanh, iv_an_ru, orri, DaveNewman, kjetil, JanneS, bijan, ericp, alex, simon, kasei, chime, john 13:47:59 <trackbot> Meeting: SPARQL Working Group Teleconference 13:47:59 <trackbot> Date: 31 March 2009 13:48:09 <LeeF> zakim, this will be SPARQL 14:02:11 <LeeF> Regrets: Axel, Souri 14:02:14 <LeeF> Chair: Lee Feigenbaum 14:04:04 <LeeF> Scribenick: SteveH 14:04:39 <LeeF> topic: administrivia 14:04:43 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-24 14:04:49 <SteveH> LeeF: PROPOSED approved mins from last week 14:05:02 <kjetil> +1 14:05:07 <SteveH> SteveH: 2nd 14:05:16 <iv_an_ru> Nth 14:05:27 <SteveH> scribenick: SteveH 14:05:38 <SteveH> scribe: SteveH 14:05:42 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-24 14:05:54 <LeeF> topic: logistics <LeeF> summary: Please add your F2F status to the wiki at http://www.w3.org/2009/sparql/wiki/F2F1 14:06:17 <SteveH> LeeF: set for F2F on 6th and 7th of May, cambridge (U.S.) and bristol (U.K.) 14:06:37 <LeeF> -> http://www.w3.org/2009/sparql/wiki/F2F1 14:06:50 <SteveH> LeeF: do we prefer web survey to wiki 14:06:54 <ericP> looks like the wiki has it 14:07:10 <SteveH> LeeF: everybody to add status to wiki 14:08:21 <SteveH> LeeF: need to juggle scibe list for 7th april 14:08:37 <SteveH> LeeF: compliments on not messing up time change 14:08:59 <AlexPassant> AlexPassant has joined #sparql <LeeF> topic: Liaisons 14:09:05 <bijan> q+ to ask about HTML5 14:09:11 <bijan> zakim, unmute me 14:09:11 <Zakim> bijan should no longer be muted 14:09:20 <ericP> q+ to say i implemented the SPARQL grammar with curies 14:09:37 <kjetil> ack bijan 14:09:37 <Zakim> bijan, you wanted to ask about HTML5 14:09:45 <SteveH> bijan: on CURIEs, don't think there's anything to talk about, WG has setup dependency on SPARQL re. CURIEs 14:09:59 <SteveH> AndyS: confused, SPARQL does not depend on CURIE 14:10:04 <SteveH> LeeF: OWL also does not 14:10:07 <ivanh> q+ 14:10:22 <SteveH> bijan: suggest not to delegate to CURIE spec 14:10:27 <ericP> -> http://www.w3.org/2005/01/yacker/uploads/SPARQL_CURIE?lang=perl&markup=html SPARQL grammar with CURIEs 14:10:38 <LeeF> ack ericp 14:10:38 <Zakim> ericP, you wanted to say i implemented the SPARQL grammar with curis 14:10:45 <SteveH> ericP: ralph asked would they work, turns out they do 14:11:04 <john-l> We would support prefix:path/to/something with curies, right? 14:11:08 <SteveH> ericP: ~103 changes a bit 14:11:12 <SteveH> LeeF: move to ML 14:11:20 <LeeF> ack ivanh 14:11:45 <SteveH> ivanh: from now on OWL makes normative ref. to SPARQL as far as prefix is concerned 14:11:56 <SteveH> ivanh: is SPARQL wants to change that we have to be careful 14:12:41 <SteveH> bijan: HTML5 WG is considering RDFA, this group might have some input, it's in some sense relevent, wanted to raise 14:12:45 <bijan> Specifically on production , ,  14:12:52 <ericP> bijan, hints as to what we might want to sniff at? 14:13:00 <bijan> zakim, mute me 14:13:00 <Zakim> bijan should now be muted 14:13:22 <bijan> Well, for example, if RDFa is in HTML5 we might want to support querying it directly 14:13:30 <SteveH> LeeF: disucuss on ML if you have an opinion on HTML5+RDFa <LeeF> topic: tracker & actions 14:13:53 <LeeF> -> http://www.w3.org/2009/sparql/track/ tracker for SPARQL WG 14:13:54 <SteveH> LeeF: we have tracker setup that keeps track of actions, ala DAWG v1 14:14:13 <LeeF> -> http://www.w3.org/2009/sparql/track/actions/open open actions 14:14:36 <LeeF> trackbot, close action-1 14:14:36 <trackbot> ACTION-1 Ask EricP to setup a WBS for the F2F closed 14:14:42 <ivanh> q+ 14:14:52 <kjetil> Zakim, unmute me 14:14:52 <Zakim> kjetil should no longer be muted 14:15:10 <LeeF> action-4: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0186.html 14:15:10 <trackbot> ACTION-4 Summarise the vocabularies (DARQ, SADDLE, voiD) notes added 14:15:21 <LeeF> trackbot, close action-4 14:15:21 <trackbot> ACTION-4 Summarise the vocabularies (DARQ, SADDLE, voiD) closed 14:15:54 <ivanh> q- 14:16:04 <LeeF> trackbot, close action-5 14:16:04 <trackbot> ACTION-5 Add security issues to query by reference feature closed 14:19:18 <kjetil> action-2: Whoops, wrong link, this is it: http://www.w3.org/2009/sparql/wiki/Feature:ReturnFormatKeyword#Related_Use_Cases.2FExtensions 14:19:18 <trackbot> ACTION-2 Update the wiki page with his experience (caveat: kjetil may be delayed in doing it) notes added 14:16:26 <kjetil> trackbot, close action-2 14:16:26 <trackbot> ACTION-2 Update the wiki page with his experience (caveat: kjetil may be delayed in doing it) closed 14:16:37 <LeeF> topic: ExecCommentsAndWarning <LeeF> summary: initial straw poll gives (+/0/-): 1/12/2 14:17:01 <kjetil> Zakim, mute me 14:17:01 <Zakim> kjetil should now be muted 14:17:55 <SteveH> Orri: runtime exceptions, any possible number of errors, would like to be able to stream the results, with errors inline 14:18:21 <SteveH> Orri: would like to be able to send first row of results, but put errors after 14:18:25 <SteveH> q+ 14:18:47 <SteveH> orri: we have cases where we need to stream the results 14:18:49 <LeeF> ack SteveH 14:19:05 <LeeF> SteveH: Two of our internal engines do this using an ASCII-based result format 14:20:01 <SteveH> 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 <SteveH> Orri: I can see straightforward way 14:20:19 <SteveH> Orri: I don't think it's difficult 14:20:27 <SteveH> LeeF: how about CONSTRUCT 14:20:32 <SteveH> q+ 14:20:38 <AndyS> q+ 14:20:58 <SteveH> Orri: could include triples in dedicated namespace, some kind of convention with triples 14:21:19 <LeeF> SteveH: we do it in RDF/XML using XML comments 14:21:21 <kjetil> ack SteveH 14:21:24 <LeeF> ack AndyS 14:21:49 <SteveH> 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 <SteveH> also we do same in SPARQL XML res 14:22:14 <SteveH> (comment that i) 14:22:33 <SteveH> LeeF: straw poll 14:23:15 <LeeF> zakim, who's here? 14:23:15 <Zakim> On the phone I see bijan (muted), john-l (muted), kasei (muted), SimonS, AlexPassant, ivanh, AndyS, [Garlik], Lee_Feigenbaum, Chimezie_Ogbuji, JanneS, kjetil (muted), Orri, EricP 14:23:18 <Zakim> On IRC I see AlexPassant, JanneS, chimezie, LukeWM, SteveH, bijan, Zakim, RRSAgent, AndyS, kasei, LeeF, SimonS, ivanh, AndyS_, kjetil, trackbot, iv_an_ru, john-l, sandro, KjetilK, 14:23:20 <Zakim> ... ericP 14:23:25 <SteveH> -1, too early, compatibility issues 14:23:25 <bijan> +1 14:23:26 <kasei> 0; but might support standarizing an xml ns URI for this use (outside spec) 14:23:26 <kjetil> 0 14:23:27 <AlexPassant> 0 14:23:27 <john-l> 0 14:23:28 <chimezie> 0 14:23:29 <AndyS> 0 (-1 if it includes deciding errors that can be reported) 14:23:30 <ericP> 0 14:23:31 <LukeWM> -1 14:23:32 <ivanh> 0 14:23:32 <bijan> er.. - 14:23:33 <JanneS> 0 14:23:34 <bijan> 0 14:23:34 <SimonS> 0 14:23:40 <LeeF> Orri: +1 14:23:50 <bijan> zakim, unmute me 14:23:50 <Zakim> bijan should no longer be muted 14:24:08 <bijan> REAL VOTE: +0 14:24:11 <LeeF> 0 14:24:11 <bijan> zakim, mute me 14:24:11 <Zakim> bijan should now be muted 14:24:31 <bijan> I would go +1 probably after examining the existing implementations 14:24:30 <LeeF> topic: query response linking <LeeF> summary: initial straw poll gives (+/0/-): 4/7/5 14:24:40 <LeeF> -> http://www.w3.org/2009/sparql/wiki/Feature:Query_response_linking 14:25:13 <SteveH> 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 <SteveH> SimonS: can do it in SELECT, but not typed 14:25:32 <SteveH> SimonS: similar to HTML link tag 14:25:44 <ivanh> q+ 14:25:49 <SteveH> SimonS: has a number of relationship types that are listed, but we could do something else 14:26:00 <SteveH> SimonS: so it can be in CONSTRUCT 14:26:29 <SimonS> yes, was me 14:26:46 <Zakim> +DaveNewman 14:26:50 <SteveH> ivanh: dont know all details, but there were discussions in HTML for categorising, wouldn't that cover it 14:27:04 <SimonS> +q 14:27:05 <SteveH> ivanh: do we have to do anything, or rely on HTTP 14:27:10 <ivanh> q- 14:27:25 <kasei> setting the http headers of a response is generally harder than changing the body content. 14:27:27 <SteveH> LeeF: would be a bit strange to do it in HTTP header for more expresivity 14:27:28 <chimezie> Isn't there a clog in the process of registering HTTP Link header? 14:27:30 <SteveH> q+ 14:27:40 <LeeF> ack SimonS 14:27:42 <dnewman2> dnewman2 has joined #sparql 14:28:05 <SteveH> 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 <LeeF> ack SteveH 14:28:40 <LeeF> 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 <LeeF> ... on balance I'd rather see it in protocol 14:29:13 <SteveH> LeeF: if we accept this, we still have plenty of lattitude, so discussion could come later 14:29:18 <kasei> the wiki page gives an example of using it in an RDF response (construct/describe) 14:30:22 <SteveH> 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 <kjetil> q+ 14:30:31 <kjetil> ack me 14:31:06 <SteveH> 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 <SteveH> ... not in the general case, but for many it doesn't need to go in 14:31:27 <SteveH> LeeF: 1 argument is for having a standard place to look 14:31:40 <SteveH> LeeF: is there value in specific types of metadata 14:31:58 <SteveH> kjetil: thats a general problem with data discovery, a licence is just another triple 14:32:00 <SteveH> q+ 14:32:04 <LeeF> ack SteveH 14:32:22 <AndyS> If in protocol, it will likely get split from the results if stored or passed on. 14:32:37 <LeeF> 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 <kasei> +1 14:33:23 <SteveH> 0 14:33:23 <LukeWM> 0 14:33:23 <kjetil> -1 14:33:28 <chimezie> +1 14:33:30 <SimonS> +1 14:33:30 <dnewman2> 0 14:33:32 <john-l> 0 14:33:32 <kjetil> Zakim, mute me 14:33:32 <Zakim> kjetil should now be muted 14:33:32 <AndyS> -1 14:33:33 <AlexPassant> +1 14:33:35 <ivanh> -1 (trying to set priorities) 14:33:37 <LeeF> Orri: 0 14:33:39 <JanneS> -1 14:33:44 <ericP> -1 14:33:44 <LeeF> 0 14:33:45 <bijan> 0 14:34:16 <SteveH> Topic: assignment <LeeF> summary: initial straw poll gives (+/0/-): 7/6/3 14:34:19 <LeeF> -> http://www.w3.org/2009/sparql/wiki/Feature:Assignment 14:35:18 <SteveH> 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 <SteveH> q+ 14:35:33 <SteveH> AndyS: implemented in ARQ, it's quite popular 14:36:04 <SteveH> LeeF: is assingment purely syntactic if we have susbselect and named projection 14:36:14 <SteveH> AndyS: not sure about scoping, but they're clearly related 14:36:15 <LeeF> ack SteveH 14:36:44 <LeeF> SteveH: Assignment as a native feature rather than syntactic sugar scares me - doesn't seem to fit into a query language 14:36:53 <LeeF> SteveH: ...given my background 14:37:22 <Zakim> -Orri 14:37:27 <SteveH> AndyS: similar thing is the ability to put an expression inline, syntactic sugar for putting a [something] in there 14:37:47 <ericP> q+ 14:37:50 <SteveH> AndyS: it doesn't introduce a binding, but it's in the same space 14:37:50 <LeeF> http://www.w3.org/2009/sparql/wiki/Feature:ScalarExpressionsInTriplePatterns 14:37:58 <LeeF> ack ericP 14:38:13 <SteveH> ericP: I would argue that creating a varaible is doable in SQL, but you name it with the expression name 14:38:16 <bijan> XQuery has lots of variables :) 14:38:19 <chimezie> 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 <bijan> For...Let... 14:38:24 <SteveH> ericP: in SPARQL we would just name it with a bound variable name 14:38:28 <SteveH> q+ to reply 14:38:45 <SteveH> AndyS: you cant write a recursive expression 14:38:55 <bijan> But I share SteveH's inclination toward fear. But I also share his sense that it might be an unwarrented fear :) 14:39:03 <Zakim> +??P14 14:39:12 <LeeF> zakim, ??P14 is Orri 14:39:12 <Zakim> +Orri; got it 14:39:30 <SteveH> chimezie: doesn't it depend on evaluation model, you could assign to an expression that is refered to outside 14:39:37 <SteveH> AndyS: the prosoal doesnt cover that 14:39:45 <LeeF> s/prosoal/proposal 14:39:55 <kjetil> ack SteveH 14:39:55 <Zakim> SteveH, you wanted to reply 14:39:58 <JanneS> AndyS, can/could there be function calls on the right side of the assignment? Or do you implement that in ARQ? 14:40:01 <ericP> SteveH: in SQL it doesn't *look* like a variable assignment 14:40:16 <LeeF> 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 <AndyS> q+ 14:40:22 <ericP> ... i don't know the scope. is it pure functional? 14:40:29 <bijan> q+ to ask for pointers to examples 14:40:31 <ericP> ... worried about user expectations 14:41:03 <SteveH> AndyS: can have functions on RHS 14:41:23 <SteveH> AndyS: these issues will all arise, but now talking about details of mechanism, quaestion is do we want this feature 14:41:29 <bijan> zakim, unmute me 14:41:29 <Zakim> bijan should no longer be muted 14:41:32 <LeeF> ack bijan 14:41:32 <Zakim> bijan, you wanted to ask for pointers to examples 14:41:42 <kjetil> ack AndyS 14:41:50 <SteveH> bijan: wondering if andy has pointers to examples from users, having trouble wrapping mind around standard functions 14:41:58 <AndyS> http://www.w3.org/2009/sparql/wiki/Feature:Assignment 14:42:24 <SteveH> bijan: looking for app examples, where used in anger 14:42:44 <JanneS> If functions are allowed on right side, maybe those who map SPARQL to SQL could not evaluate such expressions? 14:42:47 <SteveH> AndyS: used particularly in the case where there's a CONTRCUT 14:42:53 <chimezie> -> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Mar/0009.html Holger's commets 14:43:00 <bijan> zakim, mute me 14:43:00 <Zakim> bijan should now be muted 14:43:00 <LeeF> q? 14:43:09 <AndyS> Janne - yes and same as FILTER situation isn't it? 14:43:21 <JanneS> yup 14:43:24 <SteveH> LeeF: anyone else implemented it 14:43:33 <LeeF> SimonS: we did it but only internally - very useful 14:43:34 <SteveH> SimonS: we did it internally, but can't say anything about user requirements 14:43:48 <SteveH> LeeF: straw poll 14:43:49 <SteveH> -1 14:43:54 <kjetil> +1 14:43:56 <kasei> +1 14:43:57 <SteveH> q+ 14:43:57 <AlexPassant> +1 14:44:00 <chimezie> -1 14:44:00 <LukeWM> 0 14:44:02 <SteveH> q- 14:44:02 <john-l> 0 14:44:05 <ericP> +1 14:44:07 <bijan> +0 14:44:09 <SimonS> +1 14:44:11 <AndyS> +1 14:44:14 <ivanh> 0 14:44:14 <JanneS> +1 14:44:27 <dnewman2> 0 14:44:34 <LeeF> Orri: -1 un-query-language like 14:44:38 <LeeF> 0 14:44:52 <SteveH> LeeF: fan of feature, but happy to be able to do it other ways 14:45:16 <LeeF> topic: accesing rdf lists <LeeF> summary: initial straw poll gives (+/0/-): 13/0/3 14:45:16 <LeeF> http://www.w3.org/2009/sparql/wiki/Feature:AccessingRdfLists 14:45:34 <SteveH> AndyS: desire i to access all memers of a list in a length-neutral way 14:45:47 <SteveH> AndyS: can do it with fixed length lists in some caes, but it gets burdensome 14:46:04 <ericP> 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 <SteveH> 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 <SteveH> AndyS: so you get duplicates 14:46:22 <ivanh> q+ 14:46:40 <SteveH> AndyS: implemented in ARQ, looks like rdfs:member, but applies to lists 14:46:58 <SteveH> AndyS: used where you don't have closed lists 14:47:16 <SteveH> Orri: we have general transitive subquery, maybe be macro expanded into subquery 14:47:22 <SteveH> orri: no special synta 14:47:22 <john-l> Is that transitive subquery feature listed on the Wiki? 14:47:31 <ivanh> s/synta/syntax/ 14:47:33 <LeeF> q? 14:47:34 <SteveH> Orri: we would not mid making shorthand 14:47:36 <LeeF> ack ericP 14:47:36 <Zakim> 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 <SteveH> 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 <LeeF> q? 14:48:35 <LeeF> ack ivanh 14:48:55 <ericP> members(?x) ordered("1" "2") unordered("2" "1") 14:49:00 <ericP> +1 to ivanh's point 14:49:22 <SteveH> ivanh: 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 <AlexPassant> +1 wrt vocabulary design 14:49:33 <SteveH> ivanh: so had negative effect on the way vocabs were defined 14:49:33 <chimezie> 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 <chimezie> since the tail is always rdf:nil 14:49:48 <LeeF> s/AndyS:/AndyS, 14:50:12 <SteveH> chimezie: q for AndyS about property paths, if you had prop paths you could overcome by filtering out the tail 14:50:22 <SteveH> AndyS: it's the rdf:nil that's that issue 14:50:31 <SteveH> LeeF: any subset of the list, looks like a list 14:50:34 <AndyS> s/it's/it's not/ 14:50:35 <ericP> (1 2 3) => (2 3) => (3) => () 14:50:41 <bijan> I.e., lists aren't objects with distinct boundaries in RDF 14:50:54 <SteveH> chimezie: I'm pretty familiar with path-based, been able to get all the entries 14:51:11 <SteveH> LeeF: my experiance has been that I'm mostly querying for a specific member 14:51:15 <SteveH> +1 to LeeF 14:51:16 <AndyS> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0100.html 14:51:41 <SimonS> +q any example, where you do not know the head? 14:51:45 <bijan> Redundant answers can also be a problem 14:51:55 <LeeF> ack SimonS 14:52:10 <SteveH> SimonS: can you give an example of realworld query where don't know the head 14:52:19 <SteveH> SimonS: whenever I query a list I know the head 14:52:26 <bijan> q+ 14:52:43 <SteveH> AndyS: to some extent it's a corner case, but can produce a lot of questions 14:52:48 <bijan> zakim, unmute me 14:52:48 <Zakim> bijan should no longer be muted 14:52:54 <LeeF> ack bijan 14:52:55 <SteveH> AndyS: if you try to get into explaining then it causes confusion 14:53:15 <SteveH> 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 <SteveH> bijan: you could end up querying the tail, that would be a worry 14:53:44 <bijan> zakim, mute me 14:53:44 <Zakim> bijan should now be muted 14:53:58 <ivanh> +1 14:53:59 <kjetil> +1 14:54:01 <ericP> +1 14:54:01 <bijan> +1 14:54:02 <AlexPassant> +1 14:54:02 <SteveH> LeeF: strawpoll on rdf lists query mechanism 14:54:02 <LukeWM> +1 14:54:04 <AndyS> +1 14:54:04 <john-l> +1 14:54:04 <SteveH> +1 14:54:04 <kasei> +1 14:54:06 <JanneS> +1 14:54:07 <chimezie> -1 (I'm not convinced that property-path based querying doesn't resolve the real world issue with accessinglists) 14:54:12 <dnewman2> +1 14:54:17 <bijan> (and I hate rdf:lists :)) 14:54:20 <SimonS> -1 ack with chimezie 14:54:25 <LeeF> Orri: +1 14:54:41 <LeeF> -1 (with Simon & Chime) 14:55:01 <ivanh> q+ 14:55:06 <bijan> q+ to ask about the property path solution people 14:55:34 <SteveH> ivanh: 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 <SteveH> ?: if it doesn't I would 14:56:01 <ivanh> ack ivanh 14:56:04 <SteveH> LeeF: I'm indifferent if we do property paths or not 14:56:08 <bijan> q- 14:56:09 <SteveH> thanks 14:56:20 <bijan> I had ivanh's question :) 14:56:23 <SteveH> ericP: +1 on having list access as a requirement, however we do it 14:56:34 <SteveH> ivanh: if property paths work, then I happy to sump special syntax 14:56:36 <SteveH> q+ 14:56:38 <bijan> Though, special syntax should be evaluated separately 14:56:50 <SteveH> orri: it seems that property paths would have to be extended 14:56:58 <SteveH> orri: email about that on the list 14:57:03 <LeeF> ack SteveH 14:57:03 <bijan> Property Paths are way more heavyweight than special list handling 14:57:20 <bijan> +1 SteveH 14:57:24 <LeeF> SteveH: counterpoint - in favor of accessing lists, not in favor of property paths 14:57:38 <ericP> SteveH: in favor of accessing lists, opposed to property paths as they seem complicated 14:57:40 <bijan> I could see implementations wanting to support lists but not property paths 14:57:46 <SteveH> yup <LeeF> topic: wiki maintenance 14:58:12 <SteveH> LeeF: bijan asked if anyone would object to moving feature pages so they're not in feature: 14:58:21 <ericP> don't all of our features start with F? 14:58:26 <JanneS> sorry, could only do 60mins today - cu 14:58:26 <Zakim> -JanneS 14:58:44 <SteveH> LeeF: rationale: feature: makes it hard to read, wouldn't change anything because of categories 14:59:01 <ericP> +! 14:59:03 <ericP> +1 14:59:03 <bijan> MediaWiki is good that way 14:59:06 <SteveH> ivanh: just minor, places where I've seen references to feature:, but will forward 14:59:15 <ericP> +ℑ 14:59:21 <kjetil> +1 only if there is redirect, -1 if not 14:59:22 <SteveH> AndyS: I like them all coming up together 15:00:19 <SteveH> LeeF: inclined to say I don't really care 15:00:35 <SteveH> LeeF: bijan, if you want to do it go ahead <LeeF> topic: next week and beyond 15:01:19 <SteveH> 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 <SteveH> LeeF: aroudn end of next telecon, want survey for a couple of weeks to get formal positions on pioritising features 15:01:57 <SteveH> q+ 15:02:11 <kjetil> ack SteveH 15:02:39 <kjetil> condorcet voting 15:02:52 <SteveH> 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 <bijan> zakim, mute me 15:03:05 <Zakim> bijan was already muted, bijan 15:03:50 <SteveH> 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 <SteveH> AndyS: telecon is a contraint 15:04:16 <bijan> Task forces! 15:04:31 <SteveH> 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 <ivanh> q+ 15:04:54 <SteveH> LeeF: task force of 1-3 people not always best 15:04:55 <LeeF> ack ivanh 15:05:03 <AndyS> Bijan, can work but in our short timescale we have to come back together again. 15:05:11 <ericP> q+ to suggest that the queue should be closed 15:05:12 <bijan> AndyS: for sure 15:05:22 <LeeF> s/AndyS:/AndyS, 15:05:34 <SteveH> ivanh: 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 <SteveH> q+ 15:05:38 <bijan> I was being somewhat ironic 15:05:52 <SteveH> LeeF: we've clearly indentifed some important features 15:06:18 <LeeF> SteveH: concern about task forces having decisions and then re-having those decisions with the main group 15:06:24 <ericP> SteveH: concearned that TFs will have a discussion within the TF and have to have it again in the greater WG 15:06:55 <SteveH> 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 <Zakim> -ivanh 15:07:13 <ivanh> ivanh has left #sparql 15:07:17 <Zakim> -DaveNewman 15:07:17 <ericP> RRSAgent, please draft minutes 15:07:17 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/31-sparql-minutes.html ericP 15:07:20 <Zakim> -john-l 15:07:22 <Zakim> -Chimezie_Ogbuji 15:07:25 <Zakim> -Orri 15:07:27 <Zakim> -Lee_Feigenbaum 15:07:30 <Zakim> -kasei 15:07:30 <LeeF> adjourned. # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000567