Chatlog 2009-03-31

See original RRSAgent log and preview nicely formatted version.

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 [98], [99], [100]
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