Chatlog 2009-04-21

From SPARQL Working Group
Jump to: navigation, search

See original RRSAgent log and preview nicely formatted version.

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

<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:
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
14:03:29 <LeeF> RESOLVED: Approve minutes at
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>
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>
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> 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:
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:
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.
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> ->
14:37:48 <AxelPolleres> strawman from bijan: 
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>
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> ->
14:48:24 <AxelPolleres> Related here
14:48:51 <AxelPolleres>
14:49:03 <AxelPolleres>
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>
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>
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> -> 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> 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> -->
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>
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 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>
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.