Chatlog 2009-04-07

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: LeeF, Axel, Ivanh, Chime, SteveH, LukeWM, John-l, kasei, ywang4, dnewman, bijan, simon, KjetilK
13:51:58 <trackbot> Meeting: SPARQL Working Group Teleconference
13:51:58 <trackbot>  Date: 07 April 2009
14:00:48 <AxelPolleres> scribe: Axel Polleres
14:00:54 <LeeF> Chair: LeeF
14:00:54 <LeeF> Scribenick: AxelPolleres
14:00:58 <AxelPolleres> scribenick: Axel Polleres
14:01:10 <AxelPolleres> topic: Admin
14:02:11 <LeeF> Regrets: ericP, AndyS, AlexP
14:02:49 <AxelPolleres> LeeF: rearrangement on agenda, bijan joining later, so we shuffle a bit
14:02:52 <LeeF> PROPOSED: Approve minutes at
14:03:19 <AxelPolleres> no objections.
14:03:28 <LeeF> RESOLVED: Approve minutes at
14:04:05 <LeeF> next meeting: 14-April
14:04:09 <LeeF> regrets next time: ivanh, axel
14:04:22 <AxelPolleres> LeeF: next meeting, 14th, regrets ivanh & Axel
14:04:50 <AxelPolleres> ... last teleconf to discuss new features. THen we start with consensus reaching and consolidation.
14:05:05 <KjetilK> Zakim, what is the code?
14:05:05 <Zakim> the conference code is 77277 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), KjetilK
14:05:08 <AxelPolleres> ... pls check features to be discussed and send your thoughts!
14:05:21 <AxelPolleres> topic: liaisons
14:05:42 <AxelPolleres>
14:05:44 <LeeF> Axel: OWL WG and RIF WG discussing rdf:text datatype
14:05:59 <Zakim> + +1.479.864.aaaa
14:06:04 <KjetilK> Zakim, aaaa is me
14:06:04 <Zakim> +KjetilK; got it
14:06:12 <KjetilK> Zakim, mute me
14:06:12 <Zakim> KjetilK should now be muted
14:07:02 <LeeF> Axel: might want SPARQL WG to review last call draft
14:08:05 <AxelPolleres> ACTION: Axel to send a pointer to the mailinglist for rdf:text, when it's up to LC
14:08:08 <trackbot> Created ACTION-7 - Send a pointer to the mailinglist for rdf:text, when it's up to LC [on Axel Polleres - due 2009-04-14].
14:09:08 <AxelPolleres> LeeF: ControlOfDescribeQueries next week.
14:09:15 <LeeF> topic: Xproc
<LeeF> summary: initial straw poll gives (+/0/-): 0/0/13
14:09:18 <LeeF> ->
14:10:20 <Zakim> +Chimezie_Ogbuji
14:10:39 <SteveH> q+
14:11:10 <ivanh> -> XPROC draft
14:11:54 <AxelPolleres> Lee: looks like more related to RDF Core and XProc WG's. we can't do it alone.
14:12:00 <Zakim> +DaveNewman
14:12:03 <AxelPolleres> q+
14:12:11 <LeeF> ack SteveH
14:12:38 <AxelPolleres> Steve: on RDF/XML, XProc is solved and no problem. 
14:13:13 <LeeF> ack AxelPolleres
14:13:22 <SteveH> ...that's not what I meant
14:13:32 <SteveH> I meant that RDF/XML is not our problem
14:13:34 <AxelPolleres> ...
14:13:55 <ivanh> q+
14:13:55 <dnewman2> dnewman2 has joined #sparql
14:14:00 <LeeF> AxelPolleres: DERI working on pipes tool - workflow for RDF, includes SPARQL - XML serialization, we will align with XProc
14:14:26 <AxelPolleres>
14:15:22 <LeeF> LeeF: Does DERI think this is something we should pursue?
14:15:42 <LeeF> AxelPolleres: Not in the core of our charter, would be better joint with XProc or XQuery folks, maybe people volunteering as a note
14:15:46 <LeeF> ack ivanh
14:16:29 <AxelPolleres> (those comments chairhat-offf)
14:17:04 <AxelPolleres> Leef: strawpoll on Xproc?? 
14:16:38 <ivanh> -1
14:16:40 <KjetilK> -1 (out of scope)
14:16:41 <SteveH> -1, not our problem
14:16:41 <ywang4> -1
14:16:43 <john-l> -1
14:16:44 <kasei> -1
14:16:44 <ywang4> -1
14:16:44 <chimezie> -1
14:16:44 <LukeWM> -1
14:16:46 <AxelPolleres> ivanh: also think that this is not in the charter.
14:16:50 <SimonS> -1 out of scope
14:16:54 <dnewman2> -1
14:16:55 <LeeF> -1
14:17:12 <AxelPolleres> -1 out of scope
14:17:29 <LeeF> topic: XML literal results
<LeeF> summary: initial straw poll gives (+/0/-): 1/5/6
14:17:30 <LeeF>
14:18:19 <SteveH> q+ to ask about XML Schema
14:18:27 <AxelPolleres> LeeF: xml literals in results are currently encoded/escaped in SPARQL results.
14:18:41 <AxelPolleres> ... proposed here is unescaped XML in results
14:19:11 <LeeF> -> EricP
14:19:53 <AxelPolleres> ... probably no implementation does it right now, but probably just because it is not compliant.
14:20:06 <LeeF> ack SteveH
14:20:06 <Zakim> SteveH, you wanted to ask about XML Schema
14:20:35 <ivanh> q+
14:20:47 <AxelPolleres> steve: that would push us out of XML sparql result XSD. 
14:21:04 <AxelPolleres> Lee: we could using any content, but that's probably not helpful.
14:21:24 <AxelPolleres> q+ to ask about anytype in XML schema
14:21:38 <LeeF> ack ivanh
14:22:04 <AxelPolleres> ivanh: issues around schema and RDF/XML were more complex than that.
14:22:20 <AxelPolleres> ... has there been a user request in this respect?
14:23:13 <LeeF> ack AxelPolleres
14:23:13 <Zakim> AxelPolleres, you wanted to ask about anytype in XML schema
14:24:58 <AxelPolleres> Axel: seems doable in XML Schema
14:25:19 <AxelPolleres> Lee: but not very helpful, w/o a mechanism to also specify which XML schema is meant there.
14:25:20 <SteveH> -1, too complex
14:25:22 <KjetilK> +1 (if the submitter can justify it further, I much prefer XML to be addressable with XPath)
14:25:26 <kasei> 0
14:25:27 <ivanh> -1 priorities
14:25:28 <ywang4> -1
14:25:30 <chimezie> -1 low priority
14:25:33 <john-l> 0
14:25:35 <AxelPolleres> ... strawpoll on allowing unescaped XML?
14:25:35 <LukeWM> -1 
14:25:38 <AxelPolleres> 0
14:25:40 <dnewman2> 0
14:25:40 <SimonS> -1
14:25:40 <LeeF> 0
14:26:24 <KjetilK> Zakim, unmute me
14:26:24 <Zakim> KjetilK should no longer be muted
14:27:51 <AxelPolleres> Kjetil: sees potential in XML in results for being XPath processable. Likes to postpone this, because we may be talking about different things here, needs clarification.
14:28:01 <AxelPolleres> ... next week problematic for me.
14:28:53 <AxelPolleres> s/this,/ControlOfDescribeQueries,/
14:29:04 <LeeF>
14:29:17 <KjetilK> Zakim: mute me
14:29:21 <LeeF> topic: SurfaceSyntax
<LeeF> summary: initial straw poll give (+/0/-): 10/3/0  (much support "time permitting")
14:29:25 <AxelPolleres> LeeF: let's look at surface syntax
14:29:34 <LeeF>
14:30:37 <AxelPolleres> ... this is about "syntactic sugar" to be definable in terms of the current spec.
14:32:39 <AxelPolleres> ... assignments, evaluated expressions partially overlap.
14:32:52 <AxelPolleres> ... scalarExpressions.
14:33:09 <ivanh> q+
14:33:20 <AxelPolleres> ... my idea is treating these at once.
14:33:20 <SteveH> q+
14:33:23 <AxelPolleres> q+
14:33:27 <LeeF> ack ivanh
14:33:45 <AxelPolleres> ivanh: these are low-priority things.
14:33:55 <LeeF> q+ to note educational / learning aspect
14:34:42 <LeeF> ack SteveH
14:34:49 <AxelPolleres> ivanh: syntactic sugar may give impression of huge changes, where there aren't
14:35:10 <AxelPolleres> steve: agree with ivanh mostly.
14:35:44 <KjetilK> q+
14:36:23 <dnewman2> +q
14:36:25 <LeeF> ack AxelPolleres
14:36:27 <AxelPolleres> ... we should avoid "syntactic nightmare" extension
14:36:44 <SteveH> "syntactic nightmare" lack of extension, really
14:37:23 <LeeF> ?s :p `3 + 4`
14:37:40 <SteveH> you can't do that with a filter...
14:37:41 <LeeF> ?s :p `?o + 4`
14:37:45 <Zakim> +??P6
14:37:49 <bijan> zakim, ??P6 is me
14:37:49 <Zakim> +bijan; got it
14:37:52 <bijan> zakim, mute me
14:37:52 <Zakim> bijan should now be muted
14:38:44 <LeeF> q?
14:39:52 <LeeF> ack LeeF
14:39:52 <Zakim> LeeF, you wanted to note educational / learning aspect
14:40:12 <AxelPolleres> LeeF: scalar in construct could be a synt sugar subfeature of assignment.
14:40:30 <bijan> I'll note that good surface syntax can reveal optimization oppourtunities
14:40:32 <AxelPolleres> ... that is why I count it in "surface syntax"
14:40:45 <LeeF> ack KjetilK
14:41:23 <AxelPolleres> Kjetil: we shouldn't under-estimate the power of writing  things quickly.
14:41:28 <SteveH> Garlik use ?x = ... || ?x = ... a lot
14:41:55 <chimezie> We also have had numerous requests for IN support
14:42:00 <LeeF> ack dnewman
14:42:02 <AxelPolleres> ... IN is an axemaple of that.
14:42:24 <AxelPolleres> dave: from an end user perspective this is very attractive.
14:42:48 <AxelPolleres> ... aligns in certain respects with SQL. would support it.
14:43:05 <AxelPolleres> LeeF: any othe opinions?
14:43:19 <ivanh> 0
14:43:20 <KjetilK> +1 (but, yeah, lets do it at the end)
14:43:23 <bijan> 0
14:43:24 <SteveH> 0, it's too broad
14:43:25 <kasei> +1
14:43:26 <chimezie> +1
14:43:27 <dnewman2> +1
14:43:29 <SimonS> +1 agree with Kjetil and Dave, do it at the end
14:43:36 <john-l> 0
14:43:39 <LukeWM> +1 for at the end
14:43:39 <AxelPolleres> strawpoll: is work on surface syntax in general in scope of the WG?
14:43:45 <LeeF> +1 time permitting
14:43:51 <KjetilK> Zakim, mute me
14:43:51 <Zakim> KjetilK should now be muted
14:43:51 <AxelPolleres> +1
14:43:53 <ywang4> +1
14:44:07 <SteveH> +1, time permitting, probably
14:44:08 <ywang4> and i think it should be a bit more
14:44:29 <AxelPolleres> (obvious and consensual surface syntax features only)
14:44:39 <bijan> zakim, unmute me
14:44:39 <Zakim> bijan should no longer be muted
14:44:54 <LeeF> topic: SPARQL/OWL
<LeeF> summary: initial straw poll gives (+/0/-): 7/5/0
14:44:55 <LeeF>
14:44:58 <AxelPolleres> topic: sparql/owl
14:45:51 <AxelPolleres> bijan: a document which specifies which additional inferneces/answers on BGP patterns you should get under various OWL/OWL2 entailment regimes
14:45:53 <ivanh> q+
14:46:15 <AxelPolleres> LeeF: would we do it for one flavor of OWL?
14:46:49 <AxelPolleres> Bijan: my goal would be conjunctive queries. tend to look on existing implementations and reflect what they DO.
14:46:52 <AxelPolleres> q+
14:47:14 <AxelPolleres> ... with as much OWL as they can possibly handle
14:48:17 <AxelPolleres> ... kaon2 supports SPARQL with non-distiguished variables, over OWL2 w/o nominals, pellet supports all of SPARQL, Hermit will support as much as KOAN2.
14:48:20 <chimezie> q+ about relationship with general specification of entailment
14:48:27 <chimezie> q+
14:48:37 <AxelPolleres> ... racer pro supports NRQL, overlaps greatly with SPARQL.
14:49:09 <KjetilK> q+
14:49:11 <LukeWM> q+
14:49:13 <AxelPolleres> ... Quonto is an OLWLQL implementation, OWLGraph supports SPARQL. 
14:49:23 <LeeF> ack ivanh
14:49:47 <AxelPolleres> ivanh: what is the different in semantics we are talking about?
14:50:05 <LeeF> -> Extending SPARQL Basic Graph Pattern Matching
14:50:20 <AxelPolleres> bijan: achievable goal is: if you turn on inference, you get more answers.
14:50:47 <AxelPolleres> ... it is not entirely clear ore desirable. certain meta-modeling in RDF are impossible to implement.
14:51:09 <AxelPolleres> ... e.g. redefining rdf:type.
14:51:49 <AxelPolleres> ... trey to restrict myself on queries that are reasonable in terms of both OWL and RDF.
14:52:25 <Zakim> -ywang4
14:52:35 <ywang4> gonna leave, cheers
14:52:42 <AxelPolleres> ivanh: are all queries you send to a OWL reasoner encodable in SPARQL or not?
14:52:44 <LeeF> take care, ywang4
14:52:53 <LeeF> see you next week
14:53:00 <AxelPolleres> bijan: standard conjunctive queries yes fully covered by SPARQL.
14:53:09 <ywang4> see you guys :)
14:53:14 <ywang4> ywang4 has left #sparql
14:53:15 <AxelPolleres> ... SPARQL intuitivelty also allows asking about the SCHEMA.
14:53:34 <AxelPolleres> ... I think we can get a reasonable fraction of that.
14:53:51 <AxelPolleres> ivanh: how much work and energy will it take?
14:54:08 <AxelPolleres> bijan: mostly done from a paper I have, technically not difficult, transfer to spec.
14:54:09 <LeeF> ack AxelPolleres
14:55:04 <LeeF> ack chimezie
14:55:32 <AxelPolleres> Axel: linking,describing that on the wiki on the feature page, also that summary you gave would be extremly helpful.
14:56:30 <AxelPolleres> bijan: schema queries doable to some extent, standard syntax for that.
14:57:09 <AxelPolleres> bijan: use that entailment in queries qwould be something to standardize. 
14:57:38 <AxelPolleres> q+
14:58:21 <AxelPolleres> Leef: mechanism to know which entailment is "done"
14:58:23 <ivanh> q+
14:58:37 <LeeF> ack KjetilK
14:59:11 <chimezie> I'm wondering whether we can afford to do both this proposal as well as something like ParameterizedInference (which seems like the general case)
14:59:17 <AxelPolleres> kjetil: implementations that do simple bw-chaining, would that proposal influence them?
14:59:30 <chimezie> or whether there is overlap between the two
15:00:11 <AxelPolleres> bijan: OWL has an OWL RL subprofile implementable in rules, QL implementable by rule expansion, OWL EL implementable in combination
15:00:31 <ivanh> q-
15:00:36 <AxelPolleres> ... not sure whether this is answering your question.
15:01:12 <AxelPolleres> kjetil: would it cover to know "which profile is used by a certain engine"?
15:01:29 <KjetilK> Zakim, mute me
15:01:29 <Zakim> KjetilK should now be muted
15:01:33 <LeeF> ack LukeWM
15:01:37 <AxelPolleres> bijan: tell what you have is a separate issue 
15:02:03 <kasei> bijan: based on the sparql-dl paper, it seems that you define a ast->triples conversion, but I didn't see the (presumably desirable) sparql syntax->ast conversion.
15:02:31 <LeeF> ack AxelPolleres
15:03:10 <LeeF> AxelPolleres: is bnode coreference solved?
15:03:20 <LeeF> bijan: persists as an open issue, think I have a reasonable solution
15:03:50 <LeeF> ... think best way to get interoperability is to treat bnodes as local names
15:04:07 <ivanh> q+
15:04:22 <LeeF> zakim, close the queue
15:04:22 <Zakim> ok, LeeF, the speaker queue is closed
15:05:02 <LeeF> AxelPolleres: in terms of metaqueries, would you restrict certain queries?
15:05:27 <LeeF> bijan: two possibilies. 1) might need to restrict queries. 2) restrict answers, so e.g. if ?C subclass ?D
15:05:32 <LeeF> ... you could restrict answers to atomic classes only
15:05:37 <LeeF> ... to avoid infinite trivial answers
15:06:33 <SimonS> +q to ask whether syntactic restrictions are possible in SPARQL1 entailment regimes
15:07:13 <LeeF> bijan: algebra stays the same, it does operations on a tuple level
15:07:40 <AxelPolleres> ... only BGP.
15:08:32 <LeeF> ivanh: do any other features affect this?
15:08:39 <LeeF> bijan: i don't think so since none of them trouch BGP matching semantics
15:08:56 <LeeF> ivanh: would this be a separate document?
15:08:58 <LeeF> bijan: yes
15:09:57 <LeeF> SimonS: is it possible to restrict syntax within an entailment regime?
15:10:21 <LeeF> bijan: you can implement this by saying that for queries that you think are syntactically malformed you return nothing
15:11:10 <bijan> +1
15:11:11 <ivanh> 1 (with the hope it will work out:-)
15:11:15 <KjetilK> +1 (since it is allready almost there, and it covers the simple stuff)
15:11:16 <LukeWM> 0
15:11:22 <dnewman2> +0
15:11:23 <LeeF> zakim, who's here?
15:11:23 <Zakim> On the phone I see john-l, kasei (muted), ivanh, AxelPolleres, Lee_Feigenbaum, ??P24, SimonS, KjetilK (muted), Chimezie_Ogbuji, DaveNewman, bijan
15:11:25 <SimonS> +1
15:11:26 <Zakim> ??P24 has SteveH, LukeWM
15:11:27 <Zakim> On IRC I see dnewman2, LukeWM, SteveH, ivanh, RRSAgent, chimezie, kasei, AxelPolleres, bijan, SimonS, LeeF, KjetilK, iv_an_ru, Zakim, trackbot, john-l, ericP
15:11:29 <john-l> 0
15:11:33 <kasei> +1
15:11:35 <LeeF> +1
15:11:45 <chimezie> 0 (I still don't have a grasp on the relationship between this feature and the other entailment features requests)
15:11:46 <SteveH> 0, I like, but my org has no use for it sadly
15:11:52 <AxelPolleres> 0.5 thinking that this is only solvable in cinjunciton with Param Inference and need to get clearer about the issues.
15:12:08 <AxelPolleres> +1 (but in principle positive... ok)
15:12:12 <AxelPolleres> ok ok ok ;-)
15:12:20 <chimezie> bijan: okay I will :)
15:13:40 <LeeF> Encourage discussion of other features on the mailing list
<LeeF> Adjourned.