Warning:
This wiki has been archived and is now read-only.
Chatlog 2009-04-21
From SPARQL Working Group
See original RRSAgent log and preview nicely formatted version.
Please justify/explain all edits to this page, in your "edit summary" text.
<LeeF> Present: axel, ericp, andys, steve, luke, lee, john-l, simon, janne, prateek, kasei, alex, dnewman2, kjetil, ywang4 13:55:55 <trackbot> Meeting: SPARQL Working Group Teleconference 13:55:56 <trackbot> Date: 21 April 2009 13:56:06 <LeeF> Chair: AxelPolleres 13:56:09 <LeeF> Scribe: LeeF 13:56:11 <LukeWM> LukeWM has joined #sparql 13:56:11 <LeeF> Scribenick: LeeF 13:56:26 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-04-21 13:56:40 <LeeF> Regrets: Chimezie, Bijan 14:02:46 <LeeF> AxelPolleres: plan today is to get through the rest of the features from the wiki and go over Web survey 14:03:05 <LeeF> ... survey will be open for 1.5 weeks or so, to give us an idea of where to go from the F2F topic on 14:03:10 <LeeF> topic: Admin 14:03:23 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-04-14 14:03:29 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-04-14 14:03:52 <LeeF> next meeting: one week from today, 28 Apr, will talk about F2F details 14:04:03 <LeeF> scribe for next meeting: Ivan M 14:04:29 <LeeF> topic: Liaisons 14:04:37 <ywang4> ywang4 has joined #sparql 14:04:55 <LeeF> AxelPolleres: rdf:text is basically finished, not sure when it will go to Last Call 14:05:07 <AxelPolleres> http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec 14:05:09 <LeeF> ... if we want to review it, it would be great 14:05:13 <AndyS> I volunteer (not exclusively) 14:05:34 <SteveH_> tentative volunteer, but I can't promise 14:05:38 <LeeF> ACTION: AndyS to review rdf:text 14:05:39 <trackbot> Created ACTION-8 - Review rdf:text [on Andy Seaborne - due 2009-04-28]. 14:05:44 <LeeF> ACTION: SteveH to try to review rdf:text 14:05:44 <trackbot> Created ACTION-9 - Try to review rdf:text [on Steve Harris - due 2009-04-28]. 14:05:57 <LeeF> AndyS: there will be substantive issues based on what I've seen 14:06:29 <Zakim> + +656304aacc 14:06:44 <LeeF> zakim, aacc is ywang4 14:06:44 <Zakim> +ywang4; got it 14:06:45 <AlexPassant> AlexPassant has joined #sparql 14:07:14 <Zakim> +??P39 14:07:15 <LeeF> AxelPolleres: RIF WG had F2F in Cambridge last week 14:07:25 <LeeF> ... plan is to go to LC by end of May 14:07:25 <AlexPassant> Zakim, ??P39 is me 14:07:25 <Zakim> +AlexPassant; got it 14:07:35 <LeeF> ... will appreciate SPARQL WG reviews then 14:07:43 <ericP> Zakim, please dial ericP-office 14:07:43 <Zakim> ok, ericP; the call is being made 14:07:45 <Zakim> +EricP 14:07:55 <LeeF> q+ to ask about 90 min. teleconference? 14:08:43 <LeeF> ericP: HCLS group is doing stuff with federated queries 14:10:37 <kjetil> ack LeeF 14:10:37 <Zakim> LeeF, you wanted to ask about 90 min. teleconference? 14:10:50 <JanneS> I'll drop out after 60, sorry 14:12:04 <LeeF> topic: introduction, Prateek 14:12:15 <LeeF> PrateekJain-WSU: PhD student at Wright State work wtih Amit Sheth 14:12:23 <LeeF> ... research is in the area of query rewriting with emphasis on SPARQL 14:12:35 <LeeF> ... trying to exploit semantic relationships within a knowledge base to automatically rewrite SPARQL 14:13:13 <LeeF> ... interested in rdf serialization of queries and path queries 14:13:44 <LeeF> topic: feature survey 14:13:53 <AxelPolleres> http://www.w3.org/2002/09/wbs/35463/features/ 14:14:04 <LeeF> AxelPolleres: Each organization can fill out the survey once 14:14:26 <LeeF> ...we will probably have around 8 features which we will aim for in the working group 14:14:41 <LeeF> ...the survey lists 31 features that survived the "interested for anyone" criteria 14:15:08 <LeeF> ...format of the survey was limited by what the WBS survey gave us 14:15:44 <LeeF> ...options for each feature are ranks 1 - 31 and "don't mind" and "don't want" 14:15:58 <LeeF> ...do not rank all features 14:16:06 <LeeF> ...rank up to the first 8 of your choices 14:16:13 <AndyS> q+ 14:16:19 <LeeF> ack AndyS 14:16:39 <SteveH_> q+ 14:16:55 <LeeF> AndyS: are you going to enforce the limit? 14:17:07 <AndyS> ack AndyS 14:17:14 <kjetil> q+ 14:17:24 <LeeF> LeeF: we will ask anyone who ranks more than 8 to adjust their choices to only rank 8 14:17:34 <LeeF> ack SteveH_ 14:18:20 <LeeF> SteveH_: Don't agree with only ranking 8 - if my top 4 don't get done, i don't get to express an opinion about the bottom half of things 14:18:38 <LeeF> q+ 14:18:52 <LeeF> q+ to say that i'd be happy with ranking more than 8, just not all 31 14:21:01 <kjetil> q+ to ask if the rank algorithm can't account for people ranking all 14:21:20 <kjetil> ack me 14:21:21 <LeeF> SteveH_: voting shouldn't have any different weight just because you rank 4 vs. ranking 30 14:21:22 <Zakim> kjetil, you wanted to ask if the rank algorithm can't account for people ranking all 14:21:23 <Zakim> +dnewman2 14:21:26 <LeeF> q- 14:21:46 <LeeF> kjetil: if we use ranking algorithm, people can rank as many as they which 14:22:12 <dnewman2> dnewman2 has joined #sparql 14:23:24 <AndyS> q+ 14:24:32 <john-l> I prefer using a ranking algorithm. 14:25:21 <LeeF> LeeF: I was concerned that organizations interested in 25 features should not be able to cast 'more' votes and influence things more than someone who casts less 14:25:29 <LeeF> AndyS: Concerned that everyone be playing by the same rules 14:25:48 <LeeF> AxelPolleres: i think if we use a threshold like 12 or so we can compromise 14:25:52 <SteveH_> LeeF, things like Condorcet don't give any advantage to ballot stuffers 14:27:11 <kjetil> Here's a site we can use for the final ballot: http://www.cs.cornell.edu/andru/civs.html 14:27:25 <john-l> I propose that we have every organization rank ALL of the features, and then use a Condorcet system to eliminate all but 8-12 winners. 14:27:35 <SteveH_> or, alternative: http://plugin.org.uk/rdf/condorcet/ 14:28:36 <LeeF> LeeF: I'm not comfortable at all with approving a specific ranking to drive things forwards 14:29:10 <SteveH_> we don't need the threashold 14:29:21 <LeeF> q? 14:29:29 <AndyS> ack me 14:29:56 <LeeF> SteveH_: with condorcet you're only voting against yourself 14:30:25 <LeeF> ... rank the features you want in the order you'd like them and then we can analyze the data 14:30:48 <kasei> hearing lots of interference on kjetil(?) 14:31:29 <SteveH_> for ref. http://en.wikipedia.org/wiki/Condorcet_Method 14:32:15 <ericP> no tactical voting? i quit! 14:32:30 <LeeF> SteveH_: with Condorcet there's no advantage at all to ranking fewer or more choices, nor to ranking two things the same 14:32:43 <LeeF> kjetil: it's just about the relative preference 14:34:45 <LeeF> LeeF: it's important to me that "all 1 votes" doesn't mean "everything is super important!" but instead "i don't care which of these we do, they're all equally important" - it sounds like people are on the same page about that 14:35:02 <LeeF> AxelPolleres: suggested deadline for filling out the survey is May 1 14:35:11 <kjetil> Zakim, mute me 14:35:11 <Zakim> kjetil should now be muted 14:35:18 <JanneS> the vote page has April-28 set as the deadline 14:35:27 <ericP> i would like to propose a new voting scheme 14:35:32 <ericP> it uses parameterized owl entailment 14:35:49 <LeeF> LeeF: encourages everyone to fill out the survey as soon as you feel ready to <LeeF> Topic: XML & RDF query serializations 14:36:22 <LeeF> -> http://www.w3.org/2009/sparql/wiki/SPARQLX 14:37:48 <AxelPolleres> strawman from bijan: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0089.html 14:38:14 <ericP> q+ to say i've had people use an XML expression of queries 14:38:15 <AndyS> That is SPARQL algebra in XML , not SPARQL AST 14:38:38 <LeeF> ericP: i've had people use XML version of queries for debugging in conjuncgtion with XSLT, can see some use of it 14:39:20 <LeeF> AndyS: abstract syntax need to be formally addressed if we do pragmas 14:39:24 <JanneS> http://www.w3.org/2009/sparql/wiki/Feature:Pragmas 14:40:28 <LeeF> AndyS: TopQuadrant uses an RDF serialization to store queries 14:40:46 <ericP> +1 to two 14:41:01 <SimonS> +1 on two 14:41:14 <ericP> i'm 0 on XML and -1 on RDF ('cause it's so concentious) 14:41:15 <AndyS> My requirement is to get the abstraction right and do XML, JSON, another 14:42:09 <SimonS> +q 14:42:17 <LeeF> ack ericP 14:42:17 <Zakim> ericP, you wanted to say i've had people use an XML expression of queries 14:42:30 <LeeF> ack SimonS 14:42:39 <LeeF> Prateek: we are looking at SPIN for some of our work 14:42:44 <ericP> q+ to warn of contentious issues 14:42:55 <LeeF> SimonS: can see use cases for RDF serialization of SPARQL, don't have any use cases for XML 14:43:25 <JanneS> was the motivation to query sparql via sparql? 14:43:49 <LeeF> ericP: i've seen this be contentious before - in particular the expression of a graph pattern in RDF - difficult space to work in 14:43:53 <LeeF> q? 14:43:55 <LeeF> ack ericP 14:43:55 <Zakim> ericP, you wanted to warn of contentious issues 14:43:56 <SimonS> kind of. Rather composing SPARQL queries at runtime from RDF data 14:44:00 <ericP> q- 14:44:32 <ericP> upshot: whatever we do, we don't want people expressing their data in RDF <LeeF> subtopic: RDF serialization of sparql queries <LeeF> summary: initial straw poll gives (+/0-): 1/9/3 14:45:00 <LeeF> AxelPolleres: straw poll on RDF serialization of SPARQL queries 14:45:01 <ericP> -1 14:45:02 <SteveH_> -1, it's a minefield 14:45:03 <AndyS> 0 14:45:03 <kjetil> 0 14:45:04 <PrateekJain-WSU> +1 14:45:05 <LukeWM> -1 14:45:05 <JanneS> sounds like closure to the extreme i.e. sparql query result could be a valid sparql query 14:45:07 <LeeF> 0 14:45:07 <john-l> 0 14:45:08 <AlexPassant> 0 14:45:09 <kasei> 0 14:45:09 <JanneS> 0 14:45:09 <AxelPolleres> 0 14:45:12 <SimonS> 0 would be nice, but difficult <LeeF> subtopic: XML serialization of queries (SPARQLX) <LeeF> summary: initial straw poll gives (+/0-): 4/10/0 14:45:39 <LeeF> AxelPolleres: straw poll on XML serialization of SPARQL queries 14:45:48 <john-l> +1 14:45:49 <AndyS> 0 14:45:50 <LukeWM> 0 14:45:51 <LeeF> 0 14:45:52 <SteveH_> 0, could be useful, but not huge usecases for us 14:45:52 <PrateekJain-WSU> +1 14:45:53 <ericP> 0 14:45:55 <JanneS> 0 14:45:56 <AxelPolleres> 0 14:45:56 <kasei> +1 14:45:58 <SimonS> -0 14:45:58 <kjetil> 0 14:46:00 <AlexPassant> 0 14:46:12 <LeeF> bijan is a +1 by proxy, I'm positive 14:47:32 <LeeF> topic: FunctionLibrary <LeeF> summary: initial straw poll gives (+/0-): 8/5/0 14:47:37 <LeeF> -> http://www.w3.org/2009/sparql/wiki/Feature:FunctionLibrary 14:48:24 <AxelPolleres> Related here http://www.w3.org/2005/rules/wiki/DTB 14:48:51 <AxelPolleres> http://www.w3.org/TR/xpath-functions/ 14:49:03 <AxelPolleres> http://jena.sourceforge.net/ARQ/library-function.html 14:49:31 <ericP> q+ to talk about existing extensibility 14:50:05 <LeeF> LeeF: this feature is about spending the working group's time expanding the core set of functions that query writers can expect to be interoperable between implementations 14:50:21 <LeeF> ericP: we did spend some time testing last time to make sure that extension functions work in a sane way 14:50:23 <SteveH_> +1 to ericP 14:50:41 <AndyS> Significant value. Reuse F&O where possible. Fix a set of functions expected everywhere - not too large to ensure universal coverage. 14:50:56 <SteveH_> +1 to AndyS too 14:52:22 <LeeF> AxelPolleres: the question here is whether the WG should expand the list of built-in functions 14:53:04 <LeeF> AxelPolleres: straw poll on working on extending function library 14:53:12 <AxelPolleres> 0 14:53:13 <SteveH_> +1 14:53:14 <kjetil> +1 14:53:14 <LeeF> =1 14:53:15 <kasei> +1 but low priority 14:53:16 <john-l> 0 14:53:17 <JanneS> +1 14:53:17 <LeeF> +1 even 14:53:17 <PrateekJain-WSU> +1 14:53:18 <ericP> 0 14:53:20 <SimonS> 0 14:53:23 <AndyS> +1 14:53:29 <LukeWM> +1 14:53:30 <AlexPassant> 0 14:53:46 <kjetil> (but yeah, at the end) 14:53:49 <AndyS> http://www.w3.org/2009/sparql/wiki/Feature:CreatingIrisAndLiterals 14:53:50 <LeeF> topic: FullText <LeeF> summary: initial straw poll gives (+/0-): 6/5/1 14:53:58 <kjetil> Zakim, unmute me 14:53:58 <Zakim> kjetil should no longer be muted 14:54:22 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:FullText 14:54:43 <LeeF> kjetil: most Web sites have search boxes... if you want to use a triple store for an application and SPARQL on top of that 14:54:51 <LeeF> ... you need someway to communicate a search down to SPARQL endpoint 14:54:56 <LeeF> s/someway/some way 14:55:10 <LeeF> ... we could standardize in several ways here 14:55:34 <LeeF> ... could have a function in function library 14:55:54 <LeeF> ... could also use xpath/xquery text functions 14:56:03 <SteveH_> q+ to ask about XPath fulltext v's regex 14:56:05 <LeeF> ... users might want to search more than just one literal 14:56:19 <AndyS> q+ to talke about XQ full text 14:56:20 <LeeF> q+ to ask about xpath compared with lucene and to note potential contention 14:56:25 <AxelPolleres> q+ to ask about redundancy wrt regex 14:56:30 <AndyS> q+ to say it's not a library function 14:56:37 <ericP> q- 14:56:39 <LeeF> kjetil: lots of possibilities but think this is important for interoperability 14:57:08 <LeeF> SteveH_: I read the xpath full text specification - more complicated than I thought it would be 14:57:12 <ericP> -> http://www.w3.org/TR/2008/CR-xpath-full-text-10-20080516/#section-ftcontainsexpr-examples xpath full text examples 14:57:38 <LeeF> ... this is more complex than just referring to xpath spec, because there's a lot there that is xpath-specific 14:57:49 <LeeF> ... on the other end of a scale, LIKE syntax is just syntactic sugar over regex 14:58:07 <AndyS> SteveH_: similarity to LIKE 14:58:26 <LeeF> ... would need to understand what we're talking about - the LIKE syntax is easy to standardize, full text feature will be a lot of work just to figure out what parts of the XPath full text doc are relevant and which aren't 14:58:40 <ericP> http://www.w3.org/2009/sparql/wiki/Feature:FullText doesn't mention regex 14:58:52 <ericP> what uses cases does regex not support? 14:58:57 <LeeF> kjetil: Virtuoso feels that it is harder to implement regular expressions than full text 14:59:01 <SteveH_> ericP, stemming for one 14:59:15 <LeeF> AndyS: i think XQuery full text is too big, too complicated 14:59:24 <LeeF> ... it's important to ensure that existing tools, not just lucene, can be used 14:59:38 <LeeF> q? 14:59:39 <LeeF> ack SteveH_ 14:59:40 <Zakim> SteveH_, you wanted to ask about XPath fulltext v's regex 14:59:41 <LeeF> ack AndyS 14:59:41 <Zakim> AndyS, you wanted to talke about XQ full text and to say it's not a library function 14:59:58 <LeeF> AndyS: this is not just a library function - it's not a restriction, since it's generative from an index 15:00:06 <LeeF> ... "find me all the things that match 'x'" 15:00:17 <LeeF> ... "find me all the URIs of documents that contain the following string" 15:00:53 <LeeF> ... concerned that scripting engines end up with a real burden to implement this 15:00:56 <SteveH_> not just smaller implementations, the only impl. of XPath fulltext i've seen is huge 15:00:56 <LeeF> ack LeeF 15:00:56 <Zakim> LeeF, you wanted to ask about xpath compared with lucene and to note potential contention 15:01:11 <ericP> the scripting people can be incomplete. doesn't really matter except for bragging rights 15:01:56 <kasei> ericP: it matters for portability between scripting and the bigger impls. 15:02:42 <ericP> kasei, i think that's an argument for then being sound, but not complete 15:03:29 <kjetil> q+ 15:03:34 <SimonS> q+ to say most existing implementations seem quite similar 15:03:48 <ericP> i was arguing that if the burden of implementation keeps some scripts from being complete, that's not a big cost. however, we'd like to see them interoperate even in their subsets 15:03:59 <LeeF> LeeF: i see a strong case for interoperability here, but also see a huge amount of work to standardize this well 15:04:15 <LeeF> AndyS: there are other things to consider as well, such as scoring of results 15:04:21 <SteveH_> I don't want to see a world where we end up just standardising lucene syntax 15:04:32 <LeeF> AxelPolleres: seems that xpath/xquery might be too heavy for us, as opposed to aligning what existing implementations do 15:04:45 <ericP> q+ to ask if lucene is a strict subset of xpath:ftcontains 15:04:46 <AndyS> ack to SteveH_ -- starting point only 15:05:12 <SteveH_> ericP, it's not no 15:05:25 <LeeF> q? 15:05:31 <LeeF> ack AxelPolleres 15:05:31 <Zakim> AxelPolleres, you wanted to ask about redundancy wrt regex 15:05:33 <LeeF> ack kjetil 15:06:08 <ericP> we'll have a hell of a fight if we want to standardize a non-xpath function if there's an xpath function nearby 15:06:10 <AndyS> Maybe good to add some clear syntax to make it easier to understand for query writers 15:06:17 <JanneS> (I need to leave, will be voting -1 for the full fledged proposal with XQuery and XPath Full Text 1.0, +1 if we add some syntactic sugar to ease interoperability with Lucene type of implementations) 15:06:25 <ericP> burden will be on us to prove that it's not covered by subsetting ftcontains 15:06:44 <AxelPolleres> q- 15:07:12 <LeeF> SimonS: most implementations I know are very close to or based on Lucene - that seems to be what people want 15:07:17 <LeeF> ... syntax extensions are similar as well 15:07:25 <SteveH_> or, what implemetors found it easiest to build 15:07:29 <JanneS> (uh, BasicFederatedQuery deserves the protocol extensions is my +1 for both, no comment on LimitPerResource yet) - bye 15:07:56 <Zakim> -JanneS 15:08:29 <LeeF> ericP: I think that if we try to standardize something analogous to an XQuery function (e.g. lucene:contains) then we will need to prove to the world & XQuery WG that we were not able to subset ft:contains to meet our needs 15:09:18 <Zakim> -ywang4 15:09:24 <LeeF> AndyS: to be pragmatic, i don't want to put an xquery parser inside my sparql impl 15:09:36 <ywang4> see you next time :) 15:09:40 <ywang4> ywang4 has left #sparql 15:10:02 <LeeF> SteveH_: it would be tough to separate e.g. how it refers to rdf literals rather than xml nodes 15:10:38 <AndyS> --> http://www.w3.org/TR/xpath-full-text-10/#id-grammar 15:10:39 <LeeF> AxelPolleres: straw poll on full text 15:10:45 <AxelPolleres> q? 15:10:47 <ericP> q- 15:10:48 <LeeF> ack SimonS 15:10:49 <Zakim> SimonS, you wanted to say most existing implementations seem quite similar 15:10:49 <LeeF> ack ericP 15:10:56 <SimonS> q- 15:11:00 <kjetil> +1 15:11:01 <ericP> 0 15:11:02 <SteveH_> 0 15:11:04 <AndyS> +1 15:11:08 <kasei> -1 15:11:08 <AxelPolleres> 0 15:11:10 <john-l> +1 15:11:10 <AlexPassant> +1 15:11:11 <PrateekJain-WSU> 0 15:11:11 <SimonS> +1 15:11:13 <LukeWM> +1 15:11:17 <LeeF> 0, against my better judgment which says +1 15:11:21 <ericP> nice 15:11:56 <ericP> i'm surprised. usally "better judgement" is aligned with discresion 15:11:58 <LeeF> topic: LimitPerResource <LeeF> summary: initial straw poll gives (+/0-): 4/6/2 15:12:28 <AlexPassant> http://www.w3.org/2009/sparql/wiki/Feature:LimitPerResource 15:13:12 <LeeF> AlexPassant: proposal is to find a way to limit solutions not by tuples but by distinct instances of a resource 15:13:19 <LeeF> ... example syntax on wiki page 15:13:42 <kjetil> q+ 15:13:49 <LeeF> ack kjetil 15:13:56 <LeeF> kjetil: this is the single most important feature for us 15:14:08 <LeeF> q+ to ask about relationship with subselect 15:14:25 <AxelPolleres> q+ on whether thisis an issue for surface syntax 15:14:29 <LeeF> kjetil: you don't know in advance how many rows you expect back 15:15:09 <AxelPolleres> q- 15:15:15 <SteveH_> q+ 15:15:30 <LeeF> LeeF: is it true that if sparql has subselects then limitperresource is syntactic sugar? 15:15:39 <LeeF> SteveH_: you also need grouping/limiting operations 15:16:25 <LeeF> ... in other cases besides http://www.w3.org/2009/sparql/wiki/Feature:LimitPerResource#Related_Use_Cases.2FExtensions you need a grouping operator 15:16:40 <LeeF> AxelPolleres: Alex & Kjetil would you be happy if this was subsumed by subselect? 15:16:48 <LeeF> kjetil: yes, if we do subselect 15:16:57 <AxelPolleres> let's do a strawpoll conditional to subselects 15:16:58 <LeeF> AlexPassant: yes, it's the capability itself that is important 15:17:14 <ericP> 0 15:17:16 <kjetil> +1 15:17:18 <AlexPassant> +1 15:17:18 <kasei> +1 15:17:19 <LeeF> AxelPolleres: straw poll - would you want LimitPerResource GIVEN that we do not do subselects 15:17:20 <AndyS> -1 15:17:21 <john-l> +1 15:17:21 <AxelPolleres> 0 15:17:22 <SteveH_> -1 15:17:25 <LeeF> 0 15:17:26 <LukeWM> 0 15:17:28 <PrateekJain-WSU> 0 15:17:31 <SimonS> 0 15:17:38 <SteveH_> [but we do do this a lot, but doing it without subselects would be crazy] 15:17:55 <LeeF> topic: Basic federated queries <LeeF> summary: initial straw poll gives (+/0-): 7/4/2 15:17:59 <kjetil> Zakim, mute me 15:17:59 <Zakim> kjetil should now be muted 15:18:03 <LeeF> http://www.w3.org/2009/sparql/wiki/Feature:BasicFederatedQuery 15:18:12 <LeeF> AndyS: goal is to find minimal features needed to make federation happen 15:19:01 <LeeF> ... what's the minimal needed for one sparql endpoint to call out to another to get some results back 15:19:24 <LeeF> ... related thing for sending CONSTRUCT query to another processor as part of the FROM clause to get data in - can do that now with long URLs 15:19:43 <LeeF> ... very related to query parameters 15:19:49 <LeeF> ... very related to subqueries 15:19:54 <ericP> q+ to say that he added the encode-this-and-append-to-graph-url functionality on the command line 15:20:01 <LeeF> ack LeeF 15:20:01 <Zakim> LeeF, you wanted to ask about relationship with subselect 15:20:06 <LeeF> ack SteveH_ 15:20:26 <LeeF> AndyS: overall task in federated query is to find the right place to get a certain piece of information 15:20:52 <LeeF> ... missing piece is the ability to actually make the call to a remote service, that's the minimum required piece 15:21:22 <LeeF> ... ARQ does with SERVICE keyword, Virtuoso does it with pragma attached to subselect - mechanism less important than the feature 15:21:22 <AxelPolleres> Axel: syntax to "execute federated query plans, yes? 15:21:38 <LeeF> ack ericP 15:21:38 <Zakim> ericP, you wanted to say that he added the encode-this-and-append-to-graph-url functionality on the command line 15:21:39 <ericP> ack me 15:21:39 <SimonS> q+ to say he does this using special named graphs 15:22:21 <LeeF> ericP: HCLS group does a lot of query federation using my command line stuff 15:22:31 <LeeF> ... useful but not top priority 15:22:43 <LeeF> SimonS: we define special named graphs that are evaluated remotely and then do subqueries against one or more remote endpoints 15:22:46 <LeeF> ... a lot of people use it 15:23:39 <LeeF> q? 15:23:40 <LeeF> ack SimonS 15:23:40 <Zakim> SimonS, you wanted to say he does this using special named graphs 15:23:47 <LeeF> AxelPolleres: straw poll on basic federated query 15:23:48 <SimonS> q- 15:23:49 <kasei> +1 15:23:50 <kjetil> +1 15:23:51 <LukeWM> -1 15:23:51 <SteveH_> 0, useful, but very very scary 15:23:51 <AndyS> +1 15:23:51 <ericP> +1 15:23:53 <SimonS> +1 15:23:54 <john-l> -1 15:23:55 <PrateekJain-WSU> +1 15:23:55 <AlexPassant> 0 15:23:56 <LeeF> 0 15:23:59 <AxelPolleres> 0 15:24:50 <ericP> john-l, i'm curious about your -1. issue of priorities, or serious concearns? 15:25:02 <LeeF> ericP, you're not concerned about Luke's -1? 15:25:16 <john-l> ericP, Just priorities. 15:25:27 <ericP> and LukeWM? 15:25:49 <LeeF> topic: query by reference and parameters 15:25:58 <LeeF> AxelPolleres: doesn't parameters need query by reference? 15:26:06 <ericP> LeeF, shoudl i talk about SPARQLfed grammar? 15:26:11 <LeeF> SimonS: Parameters are useful without query by reference, for example for distributed joins 15:26:49 <LukeWM> ericP, my -1 was because I've just not come across any use cases for it day to day 15:27:00 <ericP> roger 15:27:03 <ericP> tx 15:28:02 <LeeF> LeeF: query by ref might depend on parameters but not vice versa - params got some support, query by ref got no support (no +1s) 15:28:21 <LeeF> SteveH_: are you going to change the survey to not say "make 8 votes"? 15:28:41 <LeeF> AxelPolleres: yes, I will change the text to not be restricted to 8 votes 15:29:04 <LeeF> AxelPolleres: AOB? 15:29:14 <LeeF> Adjourned. # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000453