SPARQL Working Group

Minutes of 06 May 2009

Present
Lee Feigenbaum, Eric Prud'hommeaux, Ivan Herman, Chime Ogbuji, Paul Gearon, Greg Williams, Yimin Wang, Axel Polleres, Alex Passant, Luke Wilson-Mawer, Steve Harris, Andy Seaborne, Birte Glimm, Bijan Parsia, Simon Schenk, Kendall Clark, Ivan Mikhailov, Kjetil Kjernsmo, John Clark
Scribe
Eric Prud'hommeaux, Simon Schenk, Greg Williams
IRC Log
Original and Editable Wiki Version
Resolutions
  1. To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein link
  2. The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others link
  3. (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0 link
  4. Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call link
Topics
  1. agenda

  2. feature discussion

    1. survey results

    2. Axel's Questions:

      1. Full-text search

      2. property paths

      3. ProjectExpressions & Assignment

      4. Basic federated queries

      5. LimitPerResource & Surface Syntax

      6. SPARQL/OWL

    3. Next steps after lunch break

    4. Feature decision

      RESOLVED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein

  3. Features & Rationale document

    Aim for first draft of http://www.w3.org/2009/sparql/docs/features/ at end of first week of June

  4. Naming and Modularity

    RESOLVED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others and RESOLVED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

  5. response to rdf:text

    RESOLVED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

<LeeF> Present: LeeF, ericP, ivanh, chimezie, pgearon, kasei, ywang4, axel, alex, LukeWM, steveh, andys, birte, bijan, SimonS, kendall, iv_an_ru, KjetilK, john-l
10:53:19 <RRSAgent> logging to http://www.w3.org/2009/05/06-sparql-irc

RRSAgent IRC Bot: logging to http://www.w3.org/2009/05/06-sparql-irc

10:53:19 <ericP> Zakim, please dial MIT262

Eric Prud'hommeaux: Zakim, please dial MIT262

10:53:19 <Zakim> ok, ericP; the call is being made

Zakim IRC Bot: ok, ericP; the call is being made

10:53:20 <Zakim> SW_(SPRQL-F2F)6:30AM has now started

Zakim IRC Bot: SW_(SPRQL-F2F)6:30AM has now started

11:09:15 <LeeF> zakim, who's here?

(No events recorded for 15 minutes)

Lee Feigenbaum: zakim, who's here?

11:09:15 <Zakim> On the phone I see Bristol, ivanh, MIT262, iv_an_ru

Zakim IRC Bot: On the phone I see Bristol, ivanh, MIT262, iv_an_ru

11:09:16 <Zakim> Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

Zakim IRC Bot: Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

11:09:17 <Zakim> On IRC I see LeeF, AndyS, bijan, RRSAgent, Kjetil_, Zakim, AlexPassant, SimonS, SteveH, LukeWM, AxelPolleres, ivanh, john-l, KjetilK, trackbot, iv_an_ru, kjetil, ericP

Zakim IRC Bot: On IRC I see LeeF, AndyS, bijan, RRSAgent, Kjetil_, Zakim, AlexPassant, SimonS, SteveH, LukeWM, AxelPolleres, ivanh, john-l, KjetilK, trackbot, iv_an_ru, kjetil, ericP

11:09:35 <LeeF> zakim, MIT262 has kasei, LeeF, ericP, pgearon

Lee Feigenbaum: zakim, MIT262 has kasei, LeeF, ericP, pgearon

11:09:35 <Zakim> +kasei, LeeF, ericP, pgearon; got it

Zakim IRC Bot: +kasei, LeeF, ericP, pgearon; got it

11:14:56 <AxelPolleres> Lee: goal, fix what we're gonna dfo the next 2 months and the next 15month

(No events recorded for 5 minutes)

Lee Feigenbaum: goal, fix what we're gonna dfo the next 2 months and the next 15month [ Scribe Assist by Axel Polleres ]

11:16:06 <ericP> scribenick: ericP

(Scribe set to Eric Prud'hommeaux)

11:16:11 <LeeF> Day 1, slot 1 - ericP

Lee Feigenbaum: Day 1, slot 1 - ericP

11:16:48 <LeeF> day 1, slot 2- Simon

Lee Feigenbaum: day 1, slot 2- Simon

11:17:01 <LeeF> day 1, slot 3 - kasei

Lee Feigenbaum: day 1, slot 3 - kasei

11:17:47 <LeeF> day 2 - slot 1 - paul

Lee Feigenbaum: day 2 - slot 1 - paul

11:17:50 <LeeF> day 2 - slot 2 - alex

Lee Feigenbaum: day 2 - slot 2 - alex

11:18:30 <LeeF> day 2 - slot 3 - kjetil

Lee Feigenbaum: day 2 - slot 3 - kjetil

11:20:24 <ericP> topic: agenda

1. agenda

11:20:45 <ericP> LeeF: pre-lunch we will have a knock-down, drag-out feature fight

Lee Feigenbaum: pre-lunch we will have a knock-down, drag-out feature fight

11:20:59 <ericP> ... after lunch:

... after lunch:

11:21:03 <ericP> ... .. name of doc

... .. name of doc

11:21:07 <ericP> ... .. rdf:text

... .. rdf:text

11:21:19 <ericP> ... .. template for editorial contributions

... .. template for editorial contributions

11:21:26 <ericP> ... .. tomorrow am:

... .. tomorrow am:

11:21:43 <ericP> ... .. features (subqueries/aggregates)

... .. features (subqueries/aggregates)

11:21:47 <KjetilK> we lost your picture

Kjetil Kjernsmo: we lost your picture

11:22:09 <AxelPolleres> do you still see us?

Axel Polleres: do you still see us?

11:22:17 <kasei> yes

Greg Williams: yes

11:22:18 <ericP> ... hope that alex and KjetilK

... hope that alex and KjetilK

11:22:47 <ericP> ... ... will have everything they need

... ... will have everything they need

<LeeF> topic: feature discussion

2. feature discussion

11:24:33 <ericP> subtopic: survey results

2.1. survey results

11:24:22 <AxelPolleres> http://www.w3.org/2002/09/wbs/35463/features/results

Axel Polleres: http://www.w3.org/2002/09/wbs/35463/features/results

11:24:33 <AxelPolleres> http://plugin.org.uk/misc/votes.svg

Axel Polleres: http://plugin.org.uk/misc/votes.svg

11:24:44 <SteveH> that's not the results

Steve Harris: that's not the results

11:24:51 <LeeF> http://www.w3.org/2002/09/wbs/35463/features/results

Lee Feigenbaum: http://www.w3.org/2002/09/wbs/35463/features/results

11:25:21 <ericP> LeeF: when using results, i've been looking at top-ten

Lee Feigenbaum: when using results, i've been looking at top-ten

11:25:54 <ericP> ... been looking at the don't want column, noting that Clark and Parsia seem to use it as others used don't mind

... been looking at the don't want column, noting that Clark and Parsia seem to use it as others used don't mind

11:26:14 <ericP> ... negation has ten votes in the top ten

... negation has ten votes in the top ten

11:26:49 <LeeF> LeeF has changed the topic to: F2F Agenda - http://www.w3.org/2009/sparql/wiki/F2F1_Agenda

Lee Feigenbaum: LeeF has changed the topic to: F2F Agenda - http://www.w3.org/2009/sparql/wiki/F2F1_Agenda

11:27:44 <ericP> LeeF: we agreed to updates, aggregates and subselects

Lee Feigenbaum: we agreed to updates, aggregates and subselects

11:28:06 <ericP> [reads through condorcet results]

[reads through condorcet results]

11:28:28 <SteveH> q+

Steve Harris: q+

11:28:33 <ivanh> zakim, mute me

Ivan Herman: zakim, mute me

11:28:33 <Zakim> ivanh should now be muted

Zakim IRC Bot: ivanh should now be muted

11:28:44 <SteveH> http://plugin.org.uk/misc/votes2.svg

Steve Harris: http://plugin.org.uk/misc/votes2.svg

11:28:45 <LeeF> ack SteveH

Lee Feigenbaum: ack SteveH

11:29:20 <ericP> SteveH: produced another graph which ranks don't-want below don't-mind

Steve Harris: produced another graph which ranks don't-want below don't-mind

11:29:34 <ericP> ... possibly a more fair representation

... possibly a more fair representation

11:30:33 <ericP> [note that these two do not differ in the top ten]

[note that these two do not differ in the top ten]

11:31:14 <ericP> SteveH: we used don't-want to indicate things that we thought would impede the standards process

Steve Harris: we used don't-want to indicate things that we thought would impede the standards process

11:32:56 <ericP> ericP: so don't-want is a consensus issue where don't-mind is not

Eric Prud'hommeaux: so don't-want is a consensus issue where don't-mind is not

11:33:07 <LeeF> -> http://www.w3.org/2009/sparql/wiki/User:Lee_Feigenbaum#Lee.27s_feature_proposal

Lee Feigenbaum: -> http://www.w3.org/2009/sparql/wiki/User:Lee_Feigenbaum#Lee.27s_feature_proposal

11:33:12 <ericP> SteveH: yeah, though we didn't agree before hand so it's open to interpretation

Steve Harris: yeah, though we didn't agree before hand so it's open to interpretation

11:34:24 <ericP> LeeF: service discription is not a magic bullet, it does give impls a way to supply features which didn't make the cut

Lee Feigenbaum: service discription is not a magic bullet, it does give impls a way to supply features which didn't make the cut

11:34:46 <ericP> ... it's not trivial but i think it's well-worth the work

... it's not trivial but i think it's well-worth the work

11:35:03 <ericP> ... DaRQ and SADL have been getting a bit of traction

... DaRQ and SADL have been getting a bit of traction

11:35:20 <ericP> ... i was surprised that project expressions came out so low

... i was surprised that project expressions came out so low

11:36:10 <SteveH> +1 to nescessity of ProjectExpressions

Steve Harris: +1 to nescessity of ProjectExpressions

11:36:35 <ericP> ... i called it a required feature, not because i wanted it, but because it seemed very strange to have aggregate projections but not scalar projections

... i called it a required feature, not because i wanted it, but because it seemed very strange to have aggregate projections but not scalar projections

11:36:56 <ericP> ... also, project appeared to have more consensus than the alternative assignment

... also, project appeared to have more consensus than the alternative assignment

11:37:25 <ericP> ... will amend this proposal with negation

... will amend this proposal with negation

11:37:44 <ericP> ... our deliverable should be "making negation less painful"

... our deliverable should be "making negation less painful"

11:37:56 <ericP> ... Time Permitting:

... Time Permitting:

11:38:24 <ericP> ... .. federated query, func lib, property paths

... .. federated query, func lib, property paths

11:38:43 <ericP> ... skipped assignment as i don't see consensus around it

... skipped assignment as i don't see consensus around it

11:39:00 <ericP> ... left full-text out due to tech and political constraints

... left full-text out due to tech and political constraints

11:40:08 <AxelPolleres> eric: safer to leave full-text out.

Eric Prud'hommeaux: safer to leave full-text out. [ Scribe Assist by Axel Polleres ]

11:40:10 <AndyS> q+ to ask EricP about IPR issues on full text

Andy Seaborne: q+ to ask EricP about IPR issues on full text

11:40:45 <ericP> ericP: full-text seems like it *could* have IPR so not worth including in charter if we're not likely to get to it

Eric Prud'hommeaux: full-text seems like it *could* have IPR so not worth including in charter if we're not likely to get to it

11:41:05 <ericP> AndyS, i don't know of any IPR, just that it seems marginally more dangerous than other spaces

AndyS, i don't know of any IPR, just that it seems marginally more dangerous than other spaces

11:41:13 <AndyS> ack

Andy Seaborne: ack

11:41:28 <AndyS> zakim, ack me

Andy Seaborne: zakim, ack me

11:41:28 <Zakim> AndyS, you wanted to ask EricP about IPR issues on full text

Zakim IRC Bot: AndyS, you wanted to ask EricP about IPR issues on full text

11:41:29 <Zakim> I see no one on the speaker queue

Zakim IRC Bot: I see no one on the speaker queue

11:41:56 <ericP> LeeF: added OWL 'cause i want SPARQL WG to tbe the first to use the extension mechanism

Lee Feigenbaum: added OWL 'cause i want SPARQL WG to tbe the first to use the extension mechanism

11:42:21 <ericP> LeeF: it's important that we don't go off and work on our pet features and expect a rubber stamp

Lee Feigenbaum: it's important that we don't go off and work on our pet features and expect a rubber stamp

11:42:44 <iv_an_ru> I'm afraid that we should say something about full text, at least as non-normative section that points to some full text query spec.

Ivan Mikhailov: I'm afraid that we should say something about full text, at least as non-normative section that points to some full text query spec.

11:42:50 <AxelPolleres> "don't want"s in the top-12 plus SurfaceSyntax: Update 1 (Clark&Parsia),

Axel Polleres: "don't want"s in the top-12 plus SurfaceSyntax: Update 1 (Clark&Parsia),

11:42:50 <AxelPolleres> BasicFederatedQueries 1 (Clark&Parsia),

Axel Polleres: BasicFederatedQueries 1 (Clark&Parsia),

11:42:50 <AxelPolleres> FunctionLibrary 1 (Clark&Parsia), ProjectExpression 1 (Clark&Parsia),

Axel Polleres: FunctionLibrary 1 (Clark&Parsia), ProjectExpression 1 (Clark&Parsia),

11:42:50 <AxelPolleres> PropertyPaths 1 (RPI), FullText 1 (Clark&Parsia),

Axel Polleres: PropertyPaths 1 (RPI), FullText 1 (Clark&Parsia),

11:42:50 <AxelPolleres> Assignment 1 (Garlik), SPARQL/OWL 1 (OpenLink), SurfaceSyntax 1 (Clark&Parsia)

Axel Polleres: Assignment 1 (Garlik), SPARQL/OWL 1 (OpenLink), SurfaceSyntax 1 (Clark&Parsia)

11:43:06 <ericP> ... OTOH, folks need to do the work. core features will require initiative

... OTOH, folks need to do the work. core features will require initiative

11:43:33 <ericP> ... i put SPARQL-OWL at the top of might-get-to list as i feel it will have energy

... i put SPARQL-OWL at the top of might-get-to list as i feel it will have energy

11:44:24 <ericP> ... property paths and basic fed query is likely to be the same players as other features

... property paths and basic fed query is likely to be the same players as other features

11:44:54 <AxelPolleres> birte arrived.

Axel Polleres: birte arrived.

11:44:57 <kasei> i should say that i (rpi) used "don't want" more as a "rank below everything else", not as a "I have big problems with this" ...

Greg Williams: i should say that i (rpi) used "don't want" more as a "rank below everything else", not as a "I have big problems with this" ...

11:45:05 <ericP> ... we should be conservative about surface syntax

... we should be conservative about surface syntax

11:45:07 <AxelPolleres> q?

Axel Polleres: q?

11:46:11 <ericP> birte: [intro] interested in owl ontologies (thesis topic)

Birte Glimm: [intro] interested in owl ontologies (thesis topic)

11:46:35 <ivanh> zakim, unmute me

Ivan Herman: zakim, unmute me

11:46:35 <Zakim> ivanh should no longer be muted

Zakim IRC Bot: ivanh should no longer be muted

11:46:59 <AndyS> zakim, who is on the phone?

Andy Seaborne: zakim, who is on the phone?

11:46:59 <Zakim> On the phone I see Bristol, ivanh, MIT262, iv_an_ru

Zakim IRC Bot: On the phone I see Bristol, ivanh, MIT262, iv_an_ru

11:47:00 <Zakim> MIT262 has kasei, LeeF, ericP, pgearon

Zakim IRC Bot: MIT262 has kasei, LeeF, ericP, pgearon

11:47:01 <Zakim> Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

Zakim IRC Bot: Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

11:47:27 <AxelPolleres> iv_an_ru, you wanted to say hi on the phone? do you hear us?

Axel Polleres: iv_an_ru, you wanted to say hi on the phone? do you hear us?

11:47:35 <iv_an_ru> Yes I hear you fine

Ivan Mikhailov: Yes I hear you fine

11:48:31 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/User:Axel_Polleres

Axel Polleres: http://www.w3.org/2009/sparql/wiki/User:Axel_Polleres

11:48:49 <ericP> subtopic: Axel's Questions:

2.2. Axel's Questions:

11:48:52 <KjetilK> q+

Kjetil Kjernsmo: q+

11:49:51 <ericP> AxelPolleres: do we need a surface syntax, or just use subqueries?

Axel Polleres: do we need a surface syntax, or just use subqueries?

11:50:16 <ericP> LeeF: is anyone uncomfortable with negation?

Lee Feigenbaum: is anyone uncomfortable with negation?

11:50:19 <KjetilK> q-

Kjetil Kjernsmo: q-

11:50:58 <ericP> AxelPolleres: i included objections in the question list

Axel Polleres: i included objections in the question list

11:51:43 <ericP> ... if we need an intuitve expression, would they still want another syntax?

... if we need an intuitve expression, would they still want another syntax?

11:52:37 <ericP> AndyS: note that FILTERs do not have the expected scope so don't behave as folks expect

Andy Seaborne: note that FILTERs do not have the expected scope so don't behave as folks expect

11:52:53 <ericP> ... so we should have negation as a separate features

... so we should have negation as a separate features

11:53:41 <AxelPolleres> Steve: difference between empty result or empty binding set needs to be considered... example pending

Steve Harris: difference between empty result or empty binding set needs to be considered... example pending [ Scribe Assist by Axel Polleres ]

11:53:57 <ericP> SteveH: share AndyS's concearn that FILTER negation may not behave as expected

Steve Harris: share AndyS's concearn that FILTER negation may not behave as expected

11:54:21 <ericP> AxelPolleres: should we sub-divide service description?

Axel Polleres: should we sub-divide service description?

11:54:30 <ericP> ... .. description of data set

... .. description of data set

11:54:39 <ericP> ... .. optimizer hints

... .. optimizer hints

11:54:42 <kasei> q+ to mention a fourth facet of service descriptions

Greg Williams: q+ to mention a fourth facet of service descriptions

11:54:48 <LukeWM> q+

Luke Wilson-Mawer: q+

11:54:49 <SteveH> q+ to talk about scope

Steve Harris: q+ to talk about scope

11:54:59 <ericP> ... .. entailment regimes

... .. entailment regimes

11:55:09 <LeeF> ack kasei

Lee Feigenbaum: ack kasei

11:55:09 <Zakim> kasei, you wanted to mention a fourth facet of service descriptions

Zakim IRC Bot: kasei, you wanted to mention a fourth facet of service descriptions

11:55:27 <LeeF> ack LukeWM

Lee Feigenbaum: ack LukeWM

11:55:38 <LeeF> kasei: also supported extension functions & supported language extensions

Greg Williams: also supported extension functions & supported language extensions [ Scribe Assist by Lee Feigenbaum ]

11:55:54 <iv_an_ru> IMHO service descriptions consists of optional properties only, so there's no technical need to sub-divide.

Ivan Mikhailov: IMHO service descriptions consists of optional properties only, so there's no technical need to sub-divide.

11:56:18 <ericP> LukeWM: do we decide what you can put in the service description? i.e. schema?

Luke Wilson-Mawer: do we decide what you can put in the service description? i.e. schema?

11:56:27 <AxelPolleres> lee: a core would make sense

Lee Feigenbaum: a core would make sense [ Scribe Assist by Axel Polleres ]

11:56:28 <iv_an_ru> yes

Ivan Mikhailov: yes

11:56:31 <ericP> LeeF: deciding on a core would encourage folks to impl and use it

Lee Feigenbaum: deciding on a core would encourage folks to impl and use it

11:56:32 <LeeF> ack SteveH

Lee Feigenbaum: ack SteveH

11:56:32 <Zakim> SteveH, you wanted to talk about scope

Zakim IRC Bot: SteveH, you wanted to talk about scope

11:56:54 <ericP> SteveH: [echoing LukeWM more assertively]

Steve Harris: [echoing LukeWM more assertively]

11:57:00 <AxelPolleres> steve: promoting of certain vocabs is not in the spirit of RDF

Steve Harris: promoting of certain vocabs is not in the spirit of RDF [ Scribe Assist by Axel Polleres ]

11:57:10 <ericP> ... these schemas (e.g. DaRQ) evolve

... these schemas (e.g. DaRQ) evolve

11:57:12 <LeeF> q?

Lee Feigenbaum: q?

11:57:18 <AndyS> q+

Andy Seaborne: q+

11:57:30 <iv_an_ru> 99% of service description issue is The Schema.

Ivan Mikhailov: 99% of service description issue is The Schema.

11:57:33 <ericP> ... we should just provide the dereferencing mechanism

... we should just provide the dereferencing mechanism

11:57:43 <ivanh> q+

Ivan Herman: q+

11:58:01 <AndyS> I disagree with the "99%" comment.  Finding the graph matters.

Andy Seaborne: I disagree with the "99%" comment. Finding the graph matters.

11:58:05 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS

11:58:17 <ericP> LeeF: is anyone's vote on service description conditional on any of these sub-features?

Lee Feigenbaum: is anyone's vote on service description conditional on any of these sub-features?

11:58:32 <iv_an_ru> AxelPolleres, we promote fn:, xsd: and some other namespaces anyway :)

Ivan Mikhailov: AxelPolleres, we promote fn:, xsd: and some other namespaces anyway :)

11:58:37 <KjetilK> q+

Kjetil Kjernsmo: q+

11:58:39 <ericP> AndyS: want to say "my dataset description is <there>"

Andy Seaborne: want to say "my dataset description is <there>"

11:58:45 <SimonS> q+

Simon Schenk: q+

11:58:45 <AxelPolleres> q+

Axel Polleres: q+

11:58:52 <kasei> +1 AndyS

Greg Williams: +1 AndyS

11:58:59 <iv_an_ru> +1 AndyS

Ivan Mikhailov: +1 AndyS

11:59:35 <LeeF> ack ivanh

Lee Feigenbaum: ack ivanh

11:59:41 <LeeF> q+ ericP to ask if anyone is opposed to standardizing the mechanism mainly/only & examples

Lee Feigenbaum: q+ ericP to ask if anyone is opposed to standardizing the mechanism mainly/only & examples

11:59:49 <iv_an_ru> One should be able to read authoritative service description, but w/o any obligations.

Ivan Mikhailov: One should be able to read authoritative service description, but w/o any obligations.

12:00:12 <SimonS> q-

Simon Schenk: q-

12:00:15 <ericP> ivanh: i don't disagree with AndyS and SteveH, but we should flush out features we enable

Ivan Herman: i don't disagree with AndyS and SteveH, but we should flush out features we enable

12:00:29 <LeeF> ack KjetilK

Lee Feigenbaum: ack KjetilK

12:00:43 <ericP> KjetilK: can't we do dataset descriptions with queries?

Kjetil Kjernsmo: can't we do dataset descriptions with queries?

12:00:54 <kasei> that could also be prohibitively expensive

Greg Williams: that could also be prohibitively expensive

12:00:57 <ericP> SteveH: doesn't give you the quantitative stuff

Steve Harris: doesn't give you the quantitative stuff

12:01:17 <ericP> AndyS: can put you in a loop.

Andy Seaborne: can put you in a loop.

12:01:23 <LeeF> q?

Lee Feigenbaum: q?

12:01:42 <ericP> ... might want to advertise the set of zip codes in the US

... might want to advertise the set of zip codes in the US

12:01:52 <iv_an_ru> I can't agree with dataset descriptions with queries, this will ban "select all' queries.

Ivan Mikhailov: I can't agree with dataset descriptions with queries, this will ban "select all' queries.

12:02:01 <LeeF> ack AxelPolleres

Lee Feigenbaum: ack AxelPolleres

12:02:20 <ericP> SteveH: seems we need a tiny features like "i do <this>"

Steve Harris: seems we need a tiny features like "i do <this>"

12:02:26 <Zakim> +??P9

Zakim IRC Bot: +??P9

12:02:31 <bijan> zakim, ??p9 is me

Bijan Parsia: zakim, ??p9 is me

12:02:31 <Zakim> +bijan; got it

Zakim IRC Bot: +bijan; got it

12:04:01 <LeeF> ack ericP

Lee Feigenbaum: ack ericP

12:04:01 <Zakim> ericP, you wanted to ask if anyone is opposed to standardizing the mechanism mainly/only and to ask if anyone is opposed to standardizing the mechanism mainly/only & examples

Zakim IRC Bot: ericP, you wanted to ask if anyone is opposed to standardizing the mechanism mainly/only and to ask if anyone is opposed to standardizing the mechanism mainly/only & examples

12:04:19 <AxelPolleres> steve: small set of properties, e.g. sparql:supports

Steve Harris: small set of properties, e.g. sparql:supports [ Scribe Assist by Axel Polleres ]

12:04:39 <AndyS> +1

Andy Seaborne: +1

12:04:42 <SteveH> +1

Steve Harris: +1

12:04:44 <LeeF> ericP: the impression I have is that if we provide the mechanism (e.g. DESCRIBE or something with endpoint URI) and some examples - we may flesh out some bits of a schema, but we don't want to decide on that /commit to that while deciding our feature set

Eric Prud'hommeaux: the impression I have is that if we provide the mechanism (e.g. DESCRIBE or something with endpoint URI) and some examples - we may flesh out some bits of a schema, but we don't want to decide on that /commit to that while deciding our feature set [ Scribe Assist by Lee Feigenbaum ]

12:04:48 <SimonS> +1

Simon Schenk: +1

12:04:50 <LeeF> <general love for Eric>

Lee Feigenbaum: <general love for Eric>

12:04:51 <KjetilK> 0

Kjetil Kjernsmo: 0

12:04:55 <AlexPassant> +1

Alex Passant: +1

12:05:22 <ericP> bijan: [gargled "hi"]

Bijan Parsia: [gargled "hi"]

12:05:38 <Zakim> -iv_an_ru

Zakim IRC Bot: -iv_an_ru

<LeeF> subsubtopic: Full-text search
12:05:49 <ericP> AxelPolleres: [re: full text search]

Axel Polleres: [re: full text search]

12:06:18 <ericP> ... some debate whether regex handles a useful subset of full text

... some debate whether regex handles a useful subset of full text

12:06:41 <ericP> ... i am now convinced that full-text is sufficiently different from regex

... i am now convinced that full-text is sufficiently different from regex

12:07:03 <LeeF> LARQ

Lee Feigenbaum: LARQ

12:07:11 <ericP> KjetilK: we have used LARQ and Viruoso

Kjetil Kjernsmo: we have used LARQ and Viruoso

12:07:33 <Zakim> +iv_an_ru

Zakim IRC Bot: +iv_an_ru

12:07:38 <ericP> ... main cost of migration is the full-text

... main cost of migration is the full-text

12:07:40 <AxelPolleres> Kjetil: LARC and Virtuoso provide very useful fulltext features, interoperability is low though and main cost of migration

Kjetil Kjernsmo: LARC and Virtuoso provide very useful fulltext features, interoperability is low though and main cost of migration [ Scribe Assist by Axel Polleres ]

12:07:46 <AndyS> LARQ -> http://jena.sourceforge.net/ARQ/lucene-arq.html

Andy Seaborne: LARQ -> http://jena.sourceforge.net/ARQ/lucene-arq.html

12:07:59 <ericP> ... our needs are a little bigger than regex

... our needs are a little bigger than regex

12:08:10 <iv_an_ru> full-text should be interoperable in its core.

Ivan Mikhailov: full-text should be interoperable in its core.

12:08:15 <AxelPolleres> Kjetil: we haven't used scores so far.

Kjetil Kjernsmo: we haven't used scores so far. [ Scribe Assist by Axel Polleres ]

12:08:36 <AndyS> q+ to comment on stemming

Andy Seaborne: q+ to comment on stemming

12:08:44 <ericP> SteveH: what proportion of the users are in your [expressivity] camp vs. those who need stemming and scoring

Steve Harris: what proportion of the users are in your [expressivity] camp vs. those who need stemming and scoring

12:09:18 <ericP> KjetilK: writing regex is generally difficult

Kjetil Kjernsmo: writing regex is generally difficult

12:09:46 <ericP> ... our use cases are *possible* with regex + \p

... our use cases are *possible* with regex + \p

12:09:47 <AxelPolleres> simon, can you put yourself on the q and explain your use case?

Axel Polleres: simon, can you put yourself on the q and explain your use case?

12:09:48 <iv_an_ru> regex is simply not for free text. Nothing to compare :)

Ivan Mikhailov: regex is simply not for free text. Nothing to compare :)

12:10:17 <iv_an_ru> Scoring is an unavoidable.

Ivan Mikhailov: Scoring is an unavoidable.

12:10:55 <SimonS> +q

Simon Schenk: +q

12:11:01 <AndyS> Agree - minimum is truncate results on score but returning score is nice

Andy Seaborne: Agree - minimum is truncate results on score but returning score is nice

12:11:13 <AndyS> q-

Andy Seaborne: q-

12:11:23 <ericP> ... fear we are making SPARQL harder to deploy and adopt

... fear we are making SPARQL harder to deploy and adopt

12:11:31 <ericP> SteveH: matter of perspective

Steve Harris: matter of perspective

12:11:36 <bijan> I'm confused as to why specing entailment regimes makes it more expensive to deploy SPARQL in general.

Bijan Parsia: I'm confused as to why specing entailment regimes makes it more expensive to deploy SPARQL in general.

12:11:39 <ericP> ... full-text is one of the harder things

... full-text is one of the harder things

12:11:55 <ericP> ... maybe 10-100 times harder than e.g. subselect

... maybe 10-100 times harder than e.g. subselect

12:11:56 <iv_an_ru> AndyS, returning score is unavoidable, at least to find out the threshold value to use for truncating.

Ivan Mikhailov: AndyS, returning score is unavoidable, at least to find out the threshold value to use for truncating.

12:12:21 <AndyS> Alternative is to pass the score trunctae point into matching.

Andy Seaborne: Alternative is to pass the score trunctae point into matching.

12:13:09 <iv_an_ru> ericP, we don't have to make the full-text mandatory part of every implementation, we just should specify that when implemented it should support some set of functions and some fixed syntax.

Ivan Mikhailov: ericP, we don't have to make the full-text mandatory part of every implementation, we just should specify that when implemented it should support some set of functions and some fixed syntax.

12:13:17 <ericP> KjetilK: every web site had a search box. need to be able to apt-get install and run

Kjetil Kjernsmo: every web site had a search box. need to be able to apt-get install and run

12:13:58 <ericP> AndyS: implementing Lucene may be more work than implementing SPARQL

Andy Seaborne: implementing Lucene may be more work than implementing SPARQL

12:14:13 <bijan> There are many lucene-esque toolkits as well

Bijan Parsia: There are many lucene-esque toolkits as well

12:14:48 <AxelPolleres> iv_an_ru? kjetil asks whether you have something on your fulltext solution?

Axel Polleres: iv_an_ru? kjetil asks whether you have something on your fulltext solution?

12:15:01 <KjetilK> iv_an_ru, what kind of solution have you built?

Kjetil Kjernsmo: iv_an_ru, what kind of solution have you built?

12:15:16 <KjetilK> iv_an_ru, and how expensive is it?

Kjetil Kjernsmo: iv_an_ru, and how expensive is it?

12:15:16 <iv_an_ru> We're using custom free-text,

Ivan Mikhailov: We're using custom free-text,

12:15:27 <iv_an_ru> That was really expensive, but fast :)

Ivan Mikhailov: That was really expensive, but fast :)

12:16:32 <iv_an_ru> Others will probably implement a cheaper free-text, because our FT provides special indexing of tags of XML documents in order to accelerate XPath queries.

Ivan Mikhailov: Others will probably implement a cheaper free-text, because our FT provides special indexing of tags of XML documents in order to accelerate XPath queries.

12:16:34 <AxelPolleres> Something like "?o contains <text condition> ?score .

Axel Polleres: Something like "?o contains <text condition> ?score .

12:16:39 <ericP> LeeF: who has something they would boot off the list in favor of full-text

Lee Feigenbaum: who has something they would boot off the list in favor of full-text

12:16:51 <AxelPolleres> " doesn't look terribly compatible with triple patterns, does it?

Axel Polleres: " doesn't look terribly compatible with triple patterns, does it?

12:17:03 <AndyS> (round table)

Andy Seaborne: (round table)

12:17:35 <iv_an_ru> AxelPollers, score etc should not be in triple patterns syntax, because options (score etc) can be numerous.

Ivan Mikhailov: AxelPollers, score etc should not be in triple patterns syntax, because options (score etc) can be numerous.

12:17:41 <LeeF> pgearon: we have it through lucene already

Paul Gearon: we have it through lucene already [ Scribe Assist by Lee Feigenbaum ]

12:18:09 <iv_an_ru> ?o <contains> "text pattern" --- for simple cases, a FILTER with function call for complications.

Ivan Mikhailov: ?o <contains> "text pattern" --- for simple cases, a FILTER with function call for complications.

12:18:16 <LeeF> kasei: I probably wouldn't implement it due to cost and lack of need, but would be happy for it to be an optional part of the language

Greg Williams: I probably wouldn't implement it due to cost and lack of need, but would be happy for it to be an optional part of the language [ Scribe Assist by Lee Feigenbaum ]

12:18:49 <LeeF> ericP: w3c tries to make coherent set of technologies, might shoehorn us into xpath full text expression

Eric Prud'hommeaux: w3c tries to make coherent set of technologies, might shoehorn us into xpath full text expression [ Scribe Assist by Lee Feigenbaum ]

12:19:03 <iv_an_ru> No doubt, FT should stay outside mandadory part of the language.

Ivan Mikhailov: No doubt, FT should stay outside mandadory part of the language.

12:19:28 <LeeF> ericP: community could do outside of WG

Eric Prud'hommeaux: community could do outside of WG [ Scribe Assist by Lee Feigenbaum ]

12:19:51 <AxelPolleres> would custom functions in FILTERs and ORDER BY work? Is a new syntax really needed?

Axel Polleres: would custom functions in FILTERs and ORDER BY work? Is a new syntax really needed?

12:19:54 <ericP> LukeWM: don't *disagree* with SteveH

Luke Wilson-Mawer: don't *disagree* with SteveH

12:20:05 <ericP> ... can see the user motivations for it

... can see the user motivations for it

12:20:32 <ericP> ... i wonder if we need to specify what happens behind the scenes

... i wonder if we need to specify what happens behind the scenes

12:21:32 <LeeF> ericP: we've never had to specify how something is implemented, but we would be expected to write down what the functionality is

Eric Prud'hommeaux: we've never had to specify how something is implemented, but we would be expected to write down what the functionality is [ Scribe Assist by Lee Feigenbaum ]

12:21:36 <AxelPolleres> luke: e.g. differences could be in whether stemming is done or only simple match

Luke Wilson-Mawer: e.g. differences could be in whether stemming is done or only simple match [ Scribe Assist by Axel Polleres ]

12:21:42 <LeeF> ericP: what a minimally conformant SPARQL implementation should do

Eric Prud'hommeaux: what a minimally conformant SPARQL implementation should do [ Scribe Assist by Lee Feigenbaum ]

12:21:43 <ericP> ... vs. just the syntax and leaving details to the service description

... vs. just the syntax and leaving details to the service description

12:22:26 <ericP> pgearon: i don't see full-text as being essential

Paul Gearon: i don't see full-text as being essential

12:22:52 <ericP> SteveH: i can't back it 'cause we wouldn't implement it

Steve Harris: i can't back it 'cause we wouldn't implement it

12:23:15 <ericP> KjetilK: couldn't you just spec a syntax?

Kjetil Kjernsmo: couldn't you just spec a syntax?

12:24:00 <ericP> LeeF: you have a cost porting between LARQ and Virtuoso

Lee Feigenbaum: you have a cost porting between LARQ and Virtuoso

12:24:31 <ericP> ... what if you had consistent expressivity, but varying surface syntax?

... what if you had consistent expressivity, but varying surface syntax?

12:24:35 <pgearon> If we do spec a syntax (which I don't mind) then this is why I'm +1 on service descriptions, so we can advertise whether or not this feature is available

Paul Gearon: If we do spec a syntax (which I don't mind) then this is why I'm +1 on service descriptions, so we can advertise whether or not this feature is available

12:24:37 <SteveH> it's bitten SQL badly

Steve Harris: it's bitten SQL badly

12:25:57 <ericP> KjetilK: if both systems meet our expressivity needs we can live with changing the surface syntax

Kjetil Kjernsmo: if both systems meet our expressivity needs we can live with changing the surface syntax

12:26:07 <pgearon> SteveH, I see your argument, but DESCRIBE already set this precedent

Paul Gearon: SteveH, I see your argument, but DESCRIBE already set this precedent

12:26:13 <ericP> ... ori noted that regex are much slower

... ori noted that regex are much slower

12:26:41 <AndyS> There are regex indexing schemes

Andy Seaborne: There are regex indexing schemes

12:26:50 <ericP> q+ to propose a "use xpath when possible" directive

q+ to propose a "use xpath when possible" directive

12:27:13 <LeeF> ack SimonS

Lee Feigenbaum: ack SimonS

12:27:23 <ericP> q-

q-

12:27:40 <ericP> AndyS: would be happy to see a syntax for free-text search

Andy Seaborne: would be happy to see a syntax for free-text search

12:28:00 <ericP> ... the work investment goes up radically

... the work investment goes up radically

12:28:24 <ericP> ... different engines have different features (e.g. scoring)

... different engines have different features (e.g. scoring)

12:29:02 <pgearon> +1

Paul Gearon: +1

12:29:03 <AxelPolleres> andy: worried about necessary effort

Andy Seaborne: worried about necessary effort [ Scribe Assist by Axel Polleres ]

12:29:05 <ivanh> +1

Ivan Herman: +1

12:29:15 <ericP> ... i don't think standards help beyond there

... i don't think standards help beyond there

12:29:38 <ericP> KjetilK: happy with magic predicates or a fILTER function

Kjetil Kjernsmo: happy with magic predicates or a fILTER function

12:29:47 <ericP> ... seems like a simple requirement

... seems like a simple requirement

12:30:08 <AndyS> Property functions imply an exuection model we don't have so I pref explciit syntax for full text search

Andy Seaborne: Property functions imply an exuection model we don't have so I pref explciit syntax for full text search

12:30:25 <ericP> SteveH: what user set is content with conjunctive word lists vs. stemming and ranking?

Steve Harris: what user set is content with conjunctive word lists vs. stemming and ranking?

12:30:51 <ericP> ... web sites care about stemming and ranking, which would be ugly as magic predicates

... web sites care about stemming and ranking, which would be ugly as magic predicates

12:31:06 <ericP> KjetilK: trying to give a good migration path to SPARQL

Kjetil Kjernsmo: trying to give a good migration path to SPARQL

12:32:27 <ericP> SimonS: we need at least scoring

Simon Schenk: we need at least scoring

12:32:54 <ericP> ... faceted browsing is a compelling use case

... faceted browsing is a compelling use case

12:33:05 <ericP> ... we need a ranked list as output

... we need a ranked list as output

12:33:23 <ericP> ... predicate functions work for that

... predicate functions work for that

12:33:25 <AndyS> q+ to note that predicate functions can bite

Andy Seaborne: q+ to note that predicate functions can bite

12:33:52 <SteveH> wonders if were talking about implied ordering or ?x :fulltext [ result: ?res ; :rank ?rank ]

Steve Harris: wonders if were talking about implied ordering or ?x :fulltext [ result: ?res ; :rank ?rank ]

12:34:07 <ericP> AlexPassant: fine with current regex

Alex Passant: fine with current regex

12:34:13 <AlexPassant> uses regexps on doapstore.org search

Alex Passant: uses regexps on doapstore.org search

12:34:14 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS

12:34:14 <Zakim> AndyS, you wanted to note that predicate functions can bite

Zakim IRC Bot: AndyS, you wanted to note that predicate functions can bite

12:34:24 <iv_an_ru> No implied ordering is possible.

Ivan Mikhailov: No implied ordering is possible.

12:34:59 <ericP> AndyS: predicate functions (graph patterns) can bite you as they require an undocumented order of execution

Andy Seaborne: predicate functions (graph patterns) can bite you as they require an undocumented order of execution

12:35:05 <iv_an_ru> I.e. it is possible but may cadd cost for no reason.

Ivan Mikhailov: I.e. it is possible but may cadd cost for no reason.

12:35:15 <ivanh> +1 to AndyS

Ivan Herman: +1 to AndyS

12:35:19 <AxelPolleres> andy: example by orri for why fulltext is order dependent... we have to be cautious about that

Andy Seaborne: example by orri for why fulltext is order dependent... we have to be cautious about that [ Scribe Assist by Axel Polleres ]

12:35:36 <ericP> SimonS: true. it's not ugly, but it's not exactly what you want

Simon Schenk: true. it's not ugly, but it's not exactly what you want

12:35:59 <bijan> Here's my response to the "around the room": It seems that there is a community for which full text is must have, another community which doesn't need it at all (most of the stuff I work on and the people I work with have little text in the datasets), and maybe some who could take it or leave it. (<---so very unprofound!) So, optional. I would be surprised if I'd implement it in either the RDF or the OWL systems I work on right now.

Bijan Parsia: Here's my response to the "around the room": It seems that there is a community for which full text is must have, another community which doesn't need it at all (most of the stuff I work on and the people I work with have little text in the datasets), and maybe some who could take it or leave it. (<---so very unprofound!) So, optional. I would be surprised if I'd implement it in either the RDF or the OWL systems I work on right now.

12:36:18 <ericP> birte: we would implement SPARQL + OWL, and full-text would be low on the weekend list

Birte Glimm: we would implement SPARQL + OWL, and full-text would be low on the weekend list

12:37:26 <ericP> ivanh: am now convinced this can be a huge job

Ivan Herman: am now convinced this can be a huge job

12:37:27 <LeeF> zakim, who's on the phone?

Lee Feigenbaum: zakim, who's on the phone?

12:37:27 <Zakim> On the phone I see Bristol, ivanh, MIT262, bijan, iv_an_ru

Zakim IRC Bot: On the phone I see Bristol, ivanh, MIT262, bijan, iv_an_ru

12:37:28 <Zakim> MIT262 has kasei, LeeF, ericP, pgearon

Zakim IRC Bot: MIT262 has kasei, LeeF, ericP, pgearon

12:37:29 <Zakim> Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

Zakim IRC Bot: Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

12:37:49 <bijan> Also, I have no expertise in this, so can't really help with the specification.

Bijan Parsia: Also, I have no expertise in this, so can't really help with the specification.

12:37:59 <LeeF> q?

Lee Feigenbaum: q?

12:38:09 <KjetilK> iv_an_ru: do you want to comment on fulltext?

Ivan Mikhailov: do you want to comment on fulltext? [ Scribe Assist by Kjetil Kjernsmo ]

12:38:10 <iv_an_ru> (I suspect I can only listen and type)

Ivan Mikhailov: (I suspect I can only listen and type)

12:38:21 <iv_an_ru> I've printed all comments already.

Ivan Mikhailov: I've printed all comments already.

12:38:38 <KjetilK> Zakim, unmute iv_an_ru

Kjetil Kjernsmo: Zakim, unmute iv_an_ru

12:38:38 <Zakim> iv_an_ru was not muted, KjetilK

Zakim IRC Bot: iv_an_ru was not muted, KjetilK

12:38:49 <bijan> (I don't even know what the different "levels" could be, i.e., what a "lite" version of the feature would be.)

Bijan Parsia: (I don't even know what the different "levels" could be, i.e., what a "lite" version of the feature would be.)

12:39:10 <iv_an_ru> I've muted myself 'cause the connection is prohibitively noisy.

Ivan Mikhailov: I've muted myself 'cause the connection is prohibitively noisy.

12:39:39 <AxelPolleres> axel: no objection, but if it affects execution order, i.e. doesn't fit into pred functionsd, it's a bit worrying me.

Axel Polleres: no objection, but if it affects execution order, i.e. doesn't fit into pred functionsd, it's a bit worrying me. [ Scribe Assist by Axel Polleres ]

12:40:19 <AndyS> I don't see why we are forced to use XQ/FT -- is it even mappable?

Andy Seaborne: I don't see why we are forced to use XQ/FT -- is it even mappable?

12:40:37 <SteveH> mappable to what?

Steve Harris: mappable to what?

12:40:39 <AxelPolleres> eric: easiest way to handle it would be to handle to ask implementers to use existing XPath functions

Eric Prud'hommeaux: easiest way to handle it would be to handle to ask implementers to use existing XPath functions [ Scribe Assist by Axel Polleres ]

12:40:55 <KjetilK> q+

Kjetil Kjernsmo: q+

12:41:20 <bijan> My *prima facie* reaction is to wonder why we wouldn't use XPath full text

Bijan Parsia: My *prima facie* reaction is to wonder why we wouldn't use XPath full text

12:41:25 <AxelPolleres> ... Xquery WG will ask us why we don't reuse their mechanism.

Axel Polleres: ... Xquery WG will ask us why we don't reuse their mechanism.

12:41:30 <bijan> (As a naive to fulltext person.)

Bijan Parsia: (As a naive to fulltext person.)

12:41:35 <SteveH> bijan, xpath fulltext is /very/ complex

Steve Harris: bijan, xpath fulltext is /very/ complex

12:41:43 <AxelPolleres> AndyS: I guess our user community would put it just the other way around.

Andy Seaborne: I guess our user community would put it just the other way around. [ Scribe Assist by Axel Polleres ]

12:41:45 <SteveH> and leans on XML heavily

Steve Harris: and leans on XML heavily

12:41:58 <LeeF> ack KjetilK

Lee Feigenbaum: ack KjetilK

12:42:15 <ericP> KjetilK: the stuff i advocate is much smaller than xpath full-text

Kjetil Kjernsmo: the stuff i advocate is much smaller than xpath full-text

12:42:21 <iv_an_ru> It's cheaper to extend XQ/FT with "RDF literal" type than to re-invent the whole bicycle.

Ivan Mikhailov: It's cheaper to extend XQ/FT with "RDF literal" type than to re-invent the whole bicycle.

12:42:25 <bijan> SteveH, Oh, I totally believe that. I'm just saying that it's a choice that needs explanation. That can go easy or that can go hard... :)

Bijan Parsia: SteveH, Oh, I totally believe that. I'm just saying that it's a choice that needs explanation. That can go easy or that can go hard... :)

12:42:27 <AxelPolleres> Bijan, honestly, it seems just too cumbersome.

Axel Polleres: Bijan, honestly, it seems just too cumbersome.

12:42:32 <ericP> ... would be happy with simple magic predicates

... would be happy with simple magic predicates

12:42:59 <ericP> ... and then say "if you want stemming et al, use xpath"

... and then say "if you want stemming et al, use xpath"

12:43:01 <ivanh> +1 to SteveH (although he was hardly audible)

Ivan Herman: +1 to SteveH (although he was hardly audible)

12:43:08 <iv_an_ru> I don't like magic predicates, but customers do :|

Ivan Mikhailov: I don't like magic predicates, but customers do :|

12:43:16 <LeeF> q+ to talk about magic predicates

Lee Feigenbaum: q+ to talk about magic predicates

12:43:21 <ericP> SteveH: i don't think there is such thing as a simpel magic predicate

Steve Harris: i don't think there is such thing as a simpel magic predicate

12:43:24 <AxelPolleres> Can someone point to an example where the execution order "kicks in"?

Axel Polleres: Can someone point to an example where the execution order "kicks in"?

12:44:13 <ericP> ... magpreds in full-text arena imply execution ordering and update of the result set to be ordered

... magpreds in full-text arena imply execution ordering and update of the result set to be ordered

12:44:14 <iv_an_ru> Can someone point to an example where the execution order "kicks in"? --- ?text <contains> ?text-pattern ;)

Ivan Mikhailov: Can someone point to an example where the execution order "kicks in"? --- ?text <contains> ?text-pattern ;)

12:44:29 <AndyS> Looking at http://jena.sourceforge.net/ARQ/lucene-arq.html

Andy Seaborne: Looking at http://jena.sourceforge.net/ARQ/lucene-arq.html

12:45:09 <ericP> KjetilK: how evil is a magic predicate compared to a filter function?

Kjetil Kjernsmo: how evil is a magic predicate compared to a filter function?

12:45:11 <AndyS>  Example: want doc URLs back in relevance order

Andy Seaborne: Example: want doc URLs back in relevance order

12:45:22 <iv_an_ru> IMHO, what's important is to keep "really" magic predicates (with side effects like new bindings) apart from plain "syntax sugar" for filtering functions.

Ivan Mikhailov: IMHO, what's important is to keep "really" magic predicates (with side effects like new bindings) apart from plain "syntax sugar" for filtering functions.

12:45:37 <ericP> SteveH: i expect you're better off with regex

Steve Harris: i expect you're better off with regex

12:46:00 <iv_an_ru> Whatever requires the order, should be written as a subselect with ORDER BY.

Ivan Mikhailov: Whatever requires the order, should be written as a subselect with ORDER BY.

12:46:04 <ericP> LeeF: we have avoided magic predicates to date

Lee Feigenbaum: we have avoided magic predicates to date

12:46:12 <SteveH> +1 to predicate functions being strange

Steve Harris: +1 to predicate functions being strange

12:46:23 <SimonS> +1 to ordering

Simon Schenk: +1 to ordering

12:46:32 <pgearon> LeeF, except "a" (for rdf:type)

Paul Gearon: LeeF, except "a" (for rdf:type)

12:46:33 <SteveH> we've deliberatly avoided predicate functions

Steve Harris: we've deliberatly avoided predicate functions

12:46:34 <ericP> ... ½ happy with that

... ½ happy with that

12:46:47 <SteveH> pgearon, a is in the syntax, not a function

Steve Harris: pgearon, a is in the syntax, not a function

12:46:52 <ericP> ... ½ of me notes that many impls add them anyways

... ½ of me notes that many impls add them anyways

12:46:55 <AndyS> They can be done right but there is scope for diviating from the declarative property paradigm

Andy Seaborne: They can be done right but there is scope for diviating from the declarative property paradigm

12:47:03 <pgearon> SteveH, that's fair

Paul Gearon: SteveH, that's fair

12:47:08 <ericP> ... we use it in anzo, but feel it's hideous

... we use it in anzo, but feel it's hideous

12:47:20 <ericP> ... would be happy if some group told us how to do us

... would be happy if some group told us how to do us

12:47:42 <ericP> ... but as chair of the SPARQL WG, i fear that group should not be us

... but as chair of the SPARQL WG, i fear that group should not be us

12:47:48 <SteveH> I have another issue with predicate functions, but I'll leave that

Steve Harris: I have another issue with predicate functions, but I'll leave that

12:47:49 <pgearon> We deliberately expressed as much as we can with triples.... which brought us to predicate functions

Paul Gearon: We deliberately expressed as much as we can with triples.... which brought us to predicate functions

12:48:03 <AxelPolleres> if we agree on  http://jena.sourceforge.net/ARQ/lucene-arq.html we also implicitly standarize property functions also for other use cases?

Axel Polleres: if we agree on http://jena.sourceforge.net/ARQ/lucene-arq.html we also implicitly standarize property functions also for other use cases?

12:48:22 <SteveH> AxelPolleres, it's a bit like a sanctioning

Steve Harris: AxelPolleres, it's a bit like a sanctioning

12:48:28 <AndyS> Axel, I am not proposing that - it assumes too much of the system.

Andy Seaborne: Axel, I am not proposing that - it assumes too much of the system.

12:48:32 <AxelPolleres> which would be ok, if we want that.

Axel Polleres: which would be ok, if we want that.

12:49:33 <ericP> [LeeF reads rest of Axel's list]

[LeeF reads rest of Axel's list]

12:49:54 <iv_an_ru> Whether we need "magic" or not is question of taste, but the "magic" of the service must be 100% documented by service description.

Ivan Mikhailov: Whether we need "magic" or not is question of taste, but the "magic" of the service must be 100% documented by service description.

12:50:08 <ericP> [ivanh would add questions on property paths]

[ivanh would add questions on property paths]

12:50:27 <ericP> subsubtopic: property paths
2.2.2. property paths
12:50:54 <ericP> ivanh: with negation and property paths, we can properly express lists?

Ivan Herman: with negation and property paths, we can properly express lists?

12:51:30 <ericP> LeeF: yes in the common case where you have a link the head of a list

Lee Feigenbaum: yes in the common case where you have a link the head of a list

12:53:21 <LeeF> ericP: if we use property paths we will be writing off some use cases that involve preventing people from injecting new items in closed lists

Eric Prud'hommeaux: if we use property paths we will be writing off some use cases that involve preventing people from injecting new items in closed lists [ Scribe Assist by Lee Feigenbaum ]

12:54:06 <ivanh> q+

Ivan Herman: q+

12:54:11 <AndyS> q+ to reply

Andy Seaborne: q+ to reply

12:54:41 <LeeF> q- leef

Lee Feigenbaum: q- leef

12:54:59 <bijan> It's not ensured in RDF or OWL Full

Bijan Parsia: It's not ensured in RDF or OWL Full

12:55:06 <LeeF> ericP: not sure how many use cases we're giving up if we don't have a mechanism to ensure a coherent list

Eric Prud'hommeaux: not sure how many use cases we're giving up if we don't have a mechanism to ensure a coherent list [ Scribe Assist by Lee Feigenbaum ]

12:55:40 <bijan> It's not really all that encouraged

Bijan Parsia: It's not really all that encouraged

12:55:47 <LeeF> q?

Lee Feigenbaum: q?

12:56:50 <LeeF> ack ivanh

Lee Feigenbaum: ack ivanh

12:57:13 <LeeF> ivanh: this (coherent lists) is true but not our job

Ivan Herman: this (coherent lists) is true but not our job [ Scribe Assist by Lee Feigenbaum ]

12:57:17 <iv_an_ru> Does somebody use closed lists?

Ivan Mikhailov: Does somebody use closed lists?

12:57:22 <AndyS> (is this "property paths" or "list access"?)

Andy Seaborne: (is this "property paths" or "list access"?)

12:57:39 <bijan> q+

Bijan Parsia: q+

12:57:54 <AxelPolleres> q+ to ask whether we talk about PropertyPaths or AccessingLists here

Axel Polleres: q+ to ask whether we talk about PropertyPaths or AccessingLists here

12:58:42 <AndyS> +1 to ivanh for the list access need in SPARQL point

Andy Seaborne: +1 to ivanh for the list access need in SPARQL point

12:58:46 <ericP> ivanh: the missing list access in SPARQL has a deleterious affect on SPARQL

Ivan Herman: the missing list access in SPARQL has a deleterious affect on SPARQL

12:58:52 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS

12:58:52 <Zakim> AndyS, you wanted to reply

Zakim IRC Bot: AndyS, you wanted to reply

12:59:14 <iv_an_ru> OTOH we don't have convenient features for selecting all items of a numbered list (?s ?p ?o filter (?p is of sort rdf:_N )) or for finding a position of ?o in a list ?s (i.e. to extract N from rdf:_N).

Ivan Mikhailov: OTOH we don't have convenient features for selecting all items of a numbered list (?s ?p ?o filter (?p is of sort rdf:_N )) or for finding a position of ?o in a list ?s (i.e. to extract N from rdf:_N).

12:59:23 <pgearon> +1 to ivanh for the list access need in SPARQL point

Paul Gearon: +1 to ivanh for the list access need in SPARQL point

12:59:26 <ericP> AndyS: you need to detect [list] cycles anyways

Andy Seaborne: you need to detect [list] cycles anyways

12:59:52 <bijan> +1 to killing rdf:list!

Bijan Parsia: +1 to killing rdf:list!

12:59:56 <KjetilK> +1 to scrapping it in RDF ;-)

Kjetil Kjernsmo: +1 to scrapping it in RDF ;-)

12:59:56 <SteveH> +1!!!

Steve Harris: +1!!!

13:00:01 <bijan> use XML Schema lists!

Bijan Parsia: use XML Schema lists!

13:00:05 <LeeF> q?

Lee Feigenbaum: q?

13:00:20 <LeeF> ack bijan

Lee Feigenbaum: ack bijan

13:00:38 <ericP> bijan: i didn't undstand ivanh's point about coherent lists

Bijan Parsia: i didn't undstand ivanh's point about coherent lists

13:00:54 <ericP> ... if we define list access, we can define coherent list access

... if we define list access, we can define coherent list access

13:00:57 <SteveH> +1 to bijan

Steve Harris: +1 to bijan

13:01:17 <ericP> ... i feel that lists in RDF are bad, so i don't mind their use being discouraged

... i feel that lists in RDF are bad, so i don't mind their use being discouraged

13:01:18 <LeeF> ack AxelPolleres

Lee Feigenbaum: ack AxelPolleres

13:01:19 <Zakim> AxelPolleres, you wanted to ask whether we talk about PropertyPaths or AccessingLists here

Zakim IRC Bot: AxelPolleres, you wanted to ask whether we talk about PropertyPaths or AccessingLists here

13:01:40 <ericP> AxelPolleres: we didn't start out with a priority of access lists

Axel Polleres: we didn't start out with a priority of access lists

13:01:49 <bijan> q+

Bijan Parsia: q+

13:01:59 <pgearon> I don't like lists, but they're used in OWL (eg. owl:intersectionOf) so they can't be avoided

Paul Gearon: I don't like lists, but they're used in OWL (eg. owl:intersectionOf) so they can't be avoided

13:02:00 <ericP> ... if we can get the common use case with property paths, then good

... if we can get the common use case with property paths, then good

13:02:30 <ericP> ... lists (are|are not)? the only way of expressing order

... lists (are|are not)? the only way of expressing order

13:02:33 <bijan> q-

Bijan Parsia: q-

13:02:58 <bijan> I'm fine with that

Bijan Parsia: I'm fine with that

13:03:13 <AndyS> Steve+Andy: There is rdf:Seq

Andy Seaborne: Steve+Andy: There is rdf:Seq

13:03:26 <AxelPolleres> Break!

Axel Polleres: Break!

13:03:40 <LeeF> +27min.

Lee Feigenbaum: +27min.

13:03:50 <Zakim> -ivanh

Zakim IRC Bot: -ivanh

13:04:01 <Zakim> -iv_an_ru

Zakim IRC Bot: -iv_an_ru

13:35:07 <LeeF> we're re-starting

(No events recorded for 31 minutes)

Lee Feigenbaum: we're re-starting

13:35:34 <LeeF> scribenick: SimonS

(Scribe set to Simon Schenk)

<LeeF> subsubtopic: ProjectExpressions & Assignment
2.2.3. ProjectExpressions & Assignment
13:35:52 <SimonS> AxelPolleres: continue discussion of questions

Axel Polleres: continue discussion of questions

13:35:52 <ivanh> zakim, dial ivanh-voip

Ivan Herman: zakim, dial ivanh-voip

13:35:52 <Zakim> ok, ivanh; the call is being made

Zakim IRC Bot: ok, ivanh; the call is being made

13:35:54 <Zakim> +ivanh

Zakim IRC Bot: +ivanh

13:36:03 <ivanh> zakim, mute me

Ivan Herman: zakim, mute me

13:36:03 <Zakim> ivanh should now be muted

Zakim IRC Bot: ivanh should now be muted

13:36:05 <AxelPolleres> continue with http://www.w3.org/2009/sparql/wiki/User:Axel_Polleres#ProjectExpressions

Axel Polleres: continue with http://www.w3.org/2009/sparql/wiki/User:Axel_Polleres#ProjectExpressions

13:36:12 <SimonS> AxelPolleres: ProjectExpressions

Axel Polleres: ProjectExpressions

13:36:37 <SimonS> there is redundancy between Assignment and ProjectExpressions

there is redundancy between Assignment and ProjectExpressions

13:36:47 <SimonS>  Questions: same expressiveness?

Questions: same expressiveness?

13:36:59 <SimonS> ...don't want, why?

...don't want, why?

13:37:10 <LeeF> Clark & Parsia stated a preference for assignment because ProjectExpressions may be too complex for their use cases (not sure what those use cases look like)

Lee Feigenbaum: Clark & Parsia stated a preference for assignment because ProjectExpressions may be too complex for their use cases (not sure what those use cases look like)

13:37:50 <ericP> q?

Eric Prud'hommeaux: q?

13:38:04 <SimonS> SteveH: should not be an expressivity difference, but as SPARQL similar to SQL, do it similarly.

Steve Harris: should not be an expressivity difference, but as SPARQL similar to SQL, do it similarly.

13:38:08 <ericP> q+ to say that it's an tedium difference

Eric Prud'hommeaux: q+ to say that it's an tedium difference

13:38:52 <SimonS> AxelPolleres: also redundant for ScalarExpressionsIn*

Axel Polleres: also redundant for ScalarExpressionsIn*

13:38:57 <AndyS>  Roughly:  { pattern1 assign pattern 2 } is equiv to { { SELECT assign { pattern1 } pattern 2 }

Andy Seaborne: Roughly: { pattern1 assign pattern 2 } is equiv to { { SELECT assign { pattern1 } pattern 2 }

13:39:22 <SimonS> AxelPolleres: Objection against syntax rather than assignment per se?

Axel Polleres: Objection against syntax rather than assignment per se?

13:39:30 <AxelPolleres> q?

Axel Polleres: q?

13:39:40 <SimonS> SteveH: true, due to background in relational databases.

Steve Harris: true, due to background in relational databases.

13:39:46 <LeeF> zakim, who's on the phone?

Lee Feigenbaum: zakim, who's on the phone?

13:39:46 <Zakim> On the phone I see Bristol, ivanh (muted), MIT262, bijan

Zakim IRC Bot: On the phone I see Bristol, ivanh (muted), MIT262, bijan

13:39:47 <Zakim> MIT262 has kasei, LeeF, ericP, pgearon

Zakim IRC Bot: MIT262 has kasei, LeeF, ericP, pgearon

13:39:49 <Zakim> Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

Zakim IRC Bot: Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

13:39:52 <ericP> ack me

Eric Prud'hommeaux: ack me

13:39:52 <Zakim> ericP, you wanted to say that it's an tedium difference

Zakim IRC Bot: ericP, you wanted to say that it's an tedium difference

13:40:36 <SimonS> ericP: sees extra select as noise, would like more crisp syntax using let.

Eric Prud'hommeaux: sees extra select as noise, would like more crisp syntax using let.

13:40:42 <SimonS> q+

q+

13:40:42 <LeeF> q+ to note that assignment is not always more terse

Lee Feigenbaum: q+ to note that assignment is not always more terse

13:41:12 <SimonS> SteveH: does not think assignment will be often used

Steve Harris: does not think assignment will be often used

13:42:24 <Zakim> +iv_an_ru

Zakim IRC Bot: +iv_an_ru

13:42:51 <SimonS> steveH: will happen in subqueries anyway and will be needed to project out, so directly do it in projection.

Steve Harris: will happen in subqueries anyway and will be needed to project out, so directly do it in projection.

13:43:10 <SimonS> ericP: but if you do not have subquery, you will need additional subquery.

Eric Prud'hommeaux: but if you do not have subquery, you will need additional subquery.

13:43:20 <iv_an_ru> I'd like to have LET in SQL, but not in SPARQL :)

Ivan Mikhailov: I'd like to have LET in SQL, but not in SPARQL :)

13:43:31 <AndyS> --> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Mar/0009.html from TopQuadrant

Andy Seaborne: --> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Mar/0009.html from TopQuadrant

13:43:54 <SimonS> ericP: how many people do want to push their constraints down to the binding of the variable?

Eric Prud'hommeaux: how many people do want to push their constraints down to the binding of the variable?

13:44:10 <AndyS> Works well with CONSTRUCT.

Andy Seaborne: Works well with CONSTRUCT.

13:44:50 <SimonS> SteveH: Prefer having subqueries, LET would be abbreviation only, maybe not often used.

Steve Harris: Prefer having subqueries, LET would be abbreviation only, maybe not often used.

13:44:57 <LeeF> -> http://pastebin.com/f1a90a229 comparison of simple use of projection vs. aggregate

Lee Feigenbaum: -> http://pastebin.com/f1a90a229 comparison of simple use of projection vs. aggregate

13:45:20 <SimonS> Axel: Don't see the difference, logically

Axel Polleres: Don't see the difference, logically

13:45:26 <kendall> hi LeeF

Kendall Clark: hi LeeF

13:46:02 <SimonS> AxelPolleres: mean LET ?X = SELECT... vs SELEXT .. as ?X

Axel Polleres: mean LET ?X = SELECT... vs SELEXT .. as ?X

13:46:25 <SimonS> SteveH: refers to ?X=3

Steve Harris: refers to ?X=3

13:46:57 <SimonS> AndyS: various forms of assignments. Logical vs. relational algebra. Semantics are compatible.

Andy Seaborne: various forms of assignments. Logical vs. relational algebra. Semantics are compatible.

13:47:15 <SimonS> SteveH: LET looks like assignment, but logically it can't be.

Steve Harris: LET looks like assignment, but logically it can't be.

13:47:45 <SimonS> ...want to avoid misleading syntax

...want to avoid misleading syntax

13:48:04 <LeeF> q?

Lee Feigenbaum: q?

13:48:12 <SimonS> AxelPolleres: Really everything subsumed by project expressions.

Axel Polleres: Really everything subsumed by project expressions.

13:48:18 <SteveH> SELECT 3 as ?x => ?x := 3

Steve Harris: SELECT 3 as ?x => ?x := 3

13:48:24 <KjetilK> ack SimonS

Kjetil Kjernsmo: ack SimonS

13:48:29 <AndyS> Scoping issues?

Andy Seaborne: Scoping issues?

13:49:21 <SimonS> SimonS: prefers LET syntax as crisper

Simon Schenk: prefers LET syntax as crisper

13:49:26 <SimonS> ...and shorter

...and shorter

13:49:43 <LeeF> is LET { <var> := <expr> } (theoretically) identical to { SELECT <expr> AS <var> }?

Lee Feigenbaum: is LET { <var> := <expr> } (theoretically) identical to { SELECT <expr> AS <var> }?

13:49:50 <KjetilK> ack LeeF

Kjetil Kjernsmo: ack LeeF

13:49:50 <Zakim> LeeF, you wanted to note that assignment is not always more terse

Zakim IRC Bot: LeeF, you wanted to note that assignment is not always more terse

13:49:53 <SimonS> SteveH: emphasizes misunderstandability of Assignment

Steve Harris: emphasizes misunderstandability of Assignment

13:50:10 <LeeF> http://pastebin.com/f1a90a229

Lee Feigenbaum: http://pastebin.com/f1a90a229

13:50:36 <SimonS> LeeF: Uses both in different cases.

Lee Feigenbaum: Uses both in different cases.

13:50:48 <AxelPolleres> Zakim, who is on the phone?

Axel Polleres: Zakim, who is on the phone?

13:50:48 <Zakim> On the phone I see Bristol, ivanh (muted), MIT262, bijan, iv_an_ru

Zakim IRC Bot: On the phone I see Bristol, ivanh (muted), MIT262, bijan, iv_an_ru

13:50:49 <Zakim> MIT262 has kasei, LeeF, ericP, pgearon

Zakim IRC Bot: MIT262 has kasei, LeeF, ericP, pgearon

13:50:50 <Zakim> Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

Zakim IRC Bot: Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS

13:51:00 <AndyS> { pattern1 LET (?x := ?a+?b) pattern 2 } is equiv to { { SELECT (?a+?b AS ?x)  { pattern1 } pattern 2 } - need to have patten1 under select.

Andy Seaborne: { pattern1 LET (?x := ?a+?b) pattern 2 } is equiv to { { SELECT (?a+?b AS ?x) { pattern1 } pattern 2 } - need to have patten1 under select.

13:51:04 <SimonS> ...thinks the language should be kept minimal, however.

...thinks the language should be kept minimal, however.

13:51:06 <kendall> (oh, man, what a joy pastebin is in this context; no more crappy code pastes into IRC)

Kendall Clark: (oh, man, what a joy pastebin is in this context; no more crappy code pastes into IRC)

13:51:38 <LeeF> thanks, AndyS

Lee Feigenbaum: thanks, AndyS

13:52:03 <SimonS> SteveH: ProjectExpressions is Superset of Assignment. Or Maybe not?

Steve Harris: ProjectExpressions is Superset of Assignment. Or Maybe not?

13:52:10 <AndyS> http://pastebin.com/m694e180b

Andy Seaborne: http://pastebin.com/m694e180b

13:52:24 <AxelPolleres> Lee: Is there anybody who wants assignment, but not project expressions?

Lee Feigenbaum: Is there anybody who wants assignment, but not project expressions? [ Scribe Assist by Axel Polleres ]

13:52:38 <KjetilK> Zakim, Bristol has SimonS, SteveH, KjetilK, LukeWM, AndyS, AxelPolleres, AlexPassant, bglimm

Kjetil Kjernsmo: Zakim, Bristol has SimonS, SteveH, KjetilK, LukeWM, AndyS, AxelPolleres, AlexPassant, bglimm

13:52:42 <Zakim> +KjetilK, AxelPolleres, AlexPassant, bglimm; got it

Zakim IRC Bot: +KjetilK, AxelPolleres, AlexPassant, bglimm; got it

13:52:54 <SimonS> AndyS: example easier to use Assignment, if we assign something, then do something with it.

Andy Seaborne: example easier to use Assignment, if we assign something, then do something with it.

13:53:33 <SimonS> LeeF: Are we discussing whether to do both or one over the other?

Lee Feigenbaum: Are we discussing whether to do both or one over the other?

13:54:00 <AxelPolleres> SimonS: I think we should have one of them

Simon Schenk: I think we should have one of them [ Scribe Assist by Axel Polleres ]

13:54:23 <AxelPolleres> Steve: We should have only projectExpressions

Steve Harris: We should have only projectExpressions [ Scribe Assist by Axel Polleres ]

13:54:52 <iv_an_ru> Maybe "LET ?x is a shorthand for ?a+?b" ... do something with ?x

Ivan Mikhailov: Maybe "LET ?x is a shorthand for ?a+?b" ... do something with ?x

13:54:57 <SimonS> SteveH: ordering issues with Assigment

Steve Harris: ordering issues with Assigment

13:55:21 <iv_an_ru> No circular assignments in any case, so no ordering headache.

Ivan Mikhailov: No circular assignments in any case, so no ordering headache.

13:55:51 <SimonS> AndyS: agree, but we have control if it gets into the algebra.

Andy Seaborne: agree, but we have control if it gets into the algebra.

13:56:03 <AxelPolleres> ordering issues with assignment would be nesting issues with projectExpressions/subqueries.

Axel Polleres: ordering issues with assignment would be nesting issues with projectExpressions/subqueries.

13:56:08 <SimonS> ...fine, if value-based, not reference based.

...fine, if value-based, not reference based.

13:56:45 <SimonS> SteveH: thinks this is exactly the kind of misunderstandings he means.

Steve Harris: thinks this is exactly the kind of misunderstandings he means.

13:57:01 <kendall> C&P prefers explicit LET syntax for assignment, fwiw

Kendall Clark: C&P prefers explicit LET syntax for assignment, fwiw

13:57:03 <SimonS> Axelpolleres: In the case of subselect you have the same problem with nesting

Axel Polleres: In the case of subselect you have the same problem with nesting

13:57:17 <kendall> But we won't object to project expressions (though I find them much harder to read FWIW)

Kendall Clark: But we won't object to project expressions (though I find them much harder to read FWIW)

13:57:39 <SimonS> AndyS: We will have to discuss this for aggregates as well

Andy Seaborne: We will have to discuss this for aggregates as well

13:58:12 <SimonS> AxelPolleres: aggregate proposal means allow selects as expressions, but not require project expressions.

Axel Polleres: aggregate proposal means allow selects as expressions, but not require project expressions.

13:58:38 <SimonS> SteveH: then we loose some powerful subqueries

Steve Harris: then we loose some powerful subqueries

14:00:06 <SimonS> SimonS: Aren't subqueries possible without project?

Simon Schenk: Aren't subqueries possible without project?

14:00:12 <SimonS> SteveH: no

Steve Harris: no

14:00:26 <SimonS> AndyS: not sure SteveH is right

Andy Seaborne: not sure SteveH is right

14:01:12 <SimonS> pgearon: don't care which one is chosen.

Paul Gearon: don't care which one is chosen.

14:01:45 <SimonS> LeeF: Think we need ProjectExpressions, would not object to Assignment in addition

Lee Feigenbaum: Think we need ProjectExpressions, would not object to Assignment in addition

14:02:17 <SimonS> LeeF: cost to do both seems non trivial, but not huge

Lee Feigenbaum: cost to do both seems non trivial, but not huge

14:02:27 <kendall> ivanh: I resemble that remark!

Ivan Herman: I resemble that remark! [ Scribe Assist by Kendall Clark ]

14:02:51 <SteveH> q+

Steve Harris: q+

14:03:12 <SimonS> ericP: Thinks, it does not make sense to emulate SQL.

Eric Prud'hommeaux: Thinks, it does not make sense to emulate SQL.

14:03:28 <ivanh> ack SteveH

Ivan Herman: ack SteveH

14:03:38 <SimonS> SteveH: agrees, but wants to stay close to relational algebra. Take good bits of SQL, but not bad ones.

Steve Harris: agrees, but wants to stay close to relational algebra. Take good bits of SQL, but not bad ones.

14:03:56 <SimonS> ericP: SQL does a lot in selects

Eric Prud'hommeaux: SQL does a lot in selects

14:04:00 <LeeF> SPARQL looks like SQL. When I teach SPARQL to new people, they have a strong expectation that it has other SQL-like capabilities - so there is an education cost to things that diverge from that

Lee Feigenbaum: SPARQL looks like SQL. When I teach SPARQL to new people, they have a strong expectation that it has other SQL-like capabilities - so there is an education cost to things that diverge from that

14:04:06 <SimonS> ... unkeen on emulating exactly that

... unkeen on emulating exactly that

14:04:21 <SimonS> ... e.g. subqueries don't share variable names etc.

... e.g. subqueries don't share variable names etc.

14:04:29 <SimonS> ... Not so good to optimize

... Not so good to optimize

14:04:44 <SimonS> ... e.g. UNIONS would be n subselects in SQL

... e.g. UNIONS would be n subselects in SQL

14:04:56 <iv_an_ru> We shouldn't try to share variable names either.

Ivan Mikhailov: We shouldn't try to share variable names either.

14:04:58 <kendall> -1 on emulating SQL; -10 for reasons of pedagogic utility (sorry, LeeF)

Kendall Clark: -1 on emulating SQL; -10 for reasons of pedagogic utility (sorry, LeeF)

14:05:05 <iv_an_ru> (I meen between sub-selects)

Ivan Mikhailov: (I meen between sub-selects)

14:05:06 <SimonS> ... what exactly of SQL do you want to reuse?

... what exactly of SQL do you want to reuse?

14:05:26 <SimonS> SteveH: makes sense to be similar to SQL, as people know it.

Steve Harris: makes sense to be similar to SQL, as people know it.

14:05:28 <iv_an_ru> I'd like to reuse the runtime ;)

Ivan Mikhailov: I'd like to reuse the runtime ;)

14:05:37 <ivanh> +1 to kendall; sparql is not sql, and we should not take the relationships between the two too far

Ivan Herman: +1 to kendall; sparql is not sql, and we should not take the relationships between the two too far

14:05:38 <SimonS> ... want to reuse composability from relational algebra

... want to reuse composability from relational algebra

14:06:00 <SimonS> ... i.e. brackets around query, project out results

... i.e. brackets around query, project out results

14:06:12 <kendall> competing with SQL, in any sense, is a game we will always lose IMO -- "they" have a massive lead in just about every sense

Kendall Clark: competing with SQL, in any sense, is a game we will always lose IMO -- "they" have a massive lead in just about every sense

14:06:17 <SimonS> Axel: Don't we lose this with FILTER in OPTIONAL?

Axel Polleres: Don't we lose this with FILTER in OPTIONAL?

14:06:19 <iv_an_ru> SimonS, make sense to be identical to SQL or noticeable distinct, but not similar --- "Stroustrup's law".

Ivan Mikhailov: SimonS, make sense to be identical to SQL or noticeable distinct, but not similar --- "Stroustrup's law".

14:06:36 <iv_an_ru> +1

Ivan Mikhailov: +1

14:06:55 <kendall> but how best do that is the question, of course

Kendall Clark: but how best do that is the question, of course

14:07:12 <SimonS> AndyS: reusability refers to idea of layered  joins

Andy Seaborne: reusability refers to idea of layered joins

14:07:49 <SimonS> SteveH: usually one starts with simpler logical units of a query to compose a more complicated one. Easy and natural.

Steve Harris: usually one starts with simpler logical units of a query to compose a more complicated one. Easy and natural.

14:08:47 <kendall> for my $$, we already are "enough like SQL" that we ought to play some distinguishing moves for this phase of SPARQL evolution; which is one non-self-interested reason to push stuff like svc descriptions, inference regimes, etc.

Kendall Clark: for my $$, we already are "enough like SQL" that we ought to play some distinguishing moves for this phase of SPARQL evolution; which is one non-self-interested reason to push stuff like svc descriptions, inference regimes, etc.

14:08:53 <SimonS> ericP: consents to go with the relational closure approach.

Eric Prud'hommeaux: consents to go with the relational closure approach.

14:09:38 <SimonS> AxelPolleres: back to ProjectExpressions. Seem to be strongly wanted, no objections. Can do assignment, if time allows.

Axel Polleres: back to ProjectExpressions. Seem to be strongly wanted, no objections. Can do assignment, if time allows.

14:09:49 <SimonS> SteveH: Does not capture my concerns.

Steve Harris: Does not capture my concerns.

14:10:08 <LeeF> What I hear is: Steve feels strongly about not incluing assignment. Kendall feels strongly about having assignment

Lee Feigenbaum: What I hear is: Steve feels strongly about not incluing assignment. Kendall feels strongly about having assignment

14:10:12 <SimonS> ... have to define Assignments in terms of projections.

... have to define Assignments in terms of projections.

14:10:24 <SimonS> Axel: Would somebody object to dropping Assignment?

Axel Polleres: Would somebody object to dropping Assignment?

14:10:44 <kendall> we might object if project expressions don't subsume assignment semantically

Kendall Clark: we might object if project expressions don't subsume assignment semantically

14:10:45 <iv_an_ru> I don't like assignment

Ivan Mikhailov: I don't like assignment

14:10:46 <SimonS> Kendall: maybe

Kendall Clark: maybe

14:10:50 <kendall> if they do, then we wouldn't

Kendall Clark: if they do, then we wouldn't

14:11:17 <kendall> thanks, Simon! :)

Kendall Clark: thanks, Simon! :)

14:11:27 <kendall> NP

Kendall Clark: NP

14:11:51 <kendall> so, LeeF, if someone would write an email showing that PEs subsume assignment, I'd be happy to let "LET" go :)

Kendall Clark: so, LeeF, if someone would write an email showing that PEs subsume assignment, I'd be happy to let "LET" go :)

14:12:06 <kendall> well, i mean, assuming that I find the email convincing :>

Kendall Clark: well, i mean, assuming that I find the email convincing :>

<LeeF> subsubtopic: Basic federated queries
2.2.4. Basic federated queries
14:11:42 <SimonS> AxelPolleres: LimitPerResource

Axel Polleres: LimitPerResource

14:11:58 <SimonS> ...still OK to drop it, if subsumed by subselects?

...still OK to drop it, if subsumed by subselects?

14:12:11 <SteveH> q+

Steve Harris: q+

14:12:14 <SimonS> ...remarks for basic federated queries?

...remarks for basic federated queries?

14:12:32 <ericP> q+ to say that the Health Care and Life Sciences WG uses them a lot

Eric Prud'hommeaux: q+ to say that the Health Care and Life Sciences WG uses them a lot

14:13:10 <kendall> and we'll keep using them in Pellet-Jena, so it's not a big deal

Kendall Clark: and we'll keep using them in Pellet-Jena, so it's not a big deal

14:13:33 <AndyS> q+

Andy Seaborne: q+

14:14:23 <SimonS> SimonS: separate marking part of query to be evaluated at one EP from choosing the EP.

Simon Schenk: separate marking part of query to be evaluated at one EP from choosing the EP.

14:14:23 <kendall> (FWIW, I want LET because I think the queries are more explicitly clear with them than w/out them)

Kendall Clark: (FWIW, I want LET because I think the queries are more explicitly clear with them than w/out them)

14:15:16 <SimonS> AndyS: coming back to kendall: do things that are not in SQL but are useful. e.g. simple federated query is just to get the connectivity going.

Andy Seaborne: coming back to kendall: do things that are not in SQL but are useful. e.g. simple federated query is just to get the connectivity going.

14:15:16 <LeeF> ACTION: SteveH to write up how/whether assignment is subsumed by projected expressions + subqueries (tentative, with LukeWM)

ACTION: SteveH to write up how/whether assignment is subsumed by projected expressions + subqueries (tentative, with LukeWM)

14:15:16 <trackbot> Created ACTION-13 - Write up how/whether assignment is subsumed by projected expressions + subqueries (tentative, with LukeWM) [on Steve Harris - due 2009-05-13].

Trackbot IRC Bot: Created ACTION-13 - Write up how/whether assignment is subsumed by projected expressions + subqueries (tentative, with LukeWM) [on Steve Harris - due 2009-05-13].

14:15:33 <SimonS> SteveH: feature is needed.

Steve Harris: feature is needed.

14:15:55 <SimonS> ... but: concerns about triggering remote requests from inside DMZ

... but: concerns about triggering remote requests from inside DMZ

14:16:15 <SimonS> ... hence, SPARQL without federation should be allowed.

... hence, SPARQL without federation should be allowed.

14:16:21 <ericP> ack SteveH

Eric Prud'hommeaux: ack SteveH

14:16:26 <SimonS> Axel: same as FROM?

Axel Polleres: same as FROM?

14:16:30 <AndyS> ack AndyS

Andy Seaborne: ack AndyS

14:16:32 <KjetilK> +1 to SteveH

Kjetil Kjernsmo: +1 to SteveH

14:16:49 <SimonS> SteveH: in FROM you do not have to dereference URIs.

Steve Harris: in FROM you do not have to dereference URIs.

14:17:09 <pgearon> FROM doesn't specify that URLs should be dereferenced. But I note that most implementations go and do just this

Paul Gearon: FROM doesn't specify that URLs should be dereferenced. But I note that most implementations go and do just this

14:17:15 <SimonS> AndyS: Endpoint can reject any query, if it wants to.

Andy Seaborne: Endpoint can reject any query, if it wants to.

14:17:44 <SimonS> SteveH: want to make sure SPARQL does not sound dangerous per se to security people.

Steve Harris: want to make sure SPARQL does not sound dangerous per se to security people.

14:18:18 <SimonS> ...if it is in core, then it should be switched off by default. or have separate language SPARQL+Federation.

...if it is in core, then it should be switched off by default. or have separate language SPARQL+Federation.

14:18:35 <pgearon> Security is going to be much more important when we look at how this interacts with Updates

Paul Gearon: Security is going to be much more important when we look at how this interacts with Updates

14:18:48 <ericP> ack me

Eric Prud'hommeaux: ack me

14:18:48 <Zakim> ericP, you wanted to say that the Health Care and Life Sciences WG uses them a lot

Zakim IRC Bot: ericP, you wanted to say that the Health Care and Life Sciences WG uses them a lot

14:18:52 <AxelPolleres> sounds to me that this is an issue, but doesn't impete working on the feature

Axel Polleres: sounds to me that this is an issue, but doesn't impete working on the feature

14:19:22 <SimonS> LeeF: mark security as an issue, but may work on this feature.

Lee Feigenbaum: mark security as an issue, but may work on this feature.

14:19:33 <kendall> +1 re: security

Kendall Clark: +1 re: security

14:19:42 <LeeF> ISSUE: How to specify BasicFederatedQuery in a way that acknowledges optional nature of feature & security issues

ISSUE: How to specify BasicFederatedQuery in a way that acknowledges optional nature of feature & security issues

14:19:42 <trackbot> Created ISSUE-1 - How to specify BasicFederatedQuery in a way that acknowledges optional nature of feature & security issues ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/1/edit .

Trackbot IRC Bot: Created ISSUE-1 - How to specify BasicFederatedQuery in a way that acknowledges optional nature of feature & security issues ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/1/edit .

14:19:42 <SimonS> SteveH: have compliance to SPARQL and "SPARQL-F"

Steve Harris: have compliance to SPARQL and "SPARQL-F"

14:20:00 <SimonS> AndyS: you can reject any query today.

Andy Seaborne: you can reject any query today.

14:20:06 <iv_an_ru> I've implemented graph-level security recently and found it relatively cheap, so I don't worry too much.

Ivan Mikhailov: I've implemented graph-level security recently and found it relatively cheap, so I don't worry too much.

14:20:25 <AxelPolleres> sounds like some of the candidate core features for service descriptions then?

Axel Polleres: sounds like some of the candidate core features for service descriptions then?

14:20:41 <SimonS> Kjetil: useful to be able to refuse to evaluate query.

Kjetil Kjernsmo: useful to be able to refuse to evaluate query.

14:21:10 <kendall> I think federation should be non-standardized and an area of vendor "competitive advantage"...It's super use-case specific in our experience, to boot

Kendall Clark: I think federation should be non-standardized and an area of vendor "competitive advantage"...It's super use-case specific in our experience, to boot

14:21:34 <SimonS> LeeF: coformance is important, but we can postpone that.

Lee Feigenbaum: coformance is important, but we can postpone that.

14:22:02 <SimonS> I think if it is vendor specific, you can not use it on the semantic WEB

I think if it is vendor specific, you can not use it on the semantic WEB

14:22:13 <iv_an_ru> competitive implenetaitons of non-standardized fedaration is Bad Thing.

Ivan Mikhailov: competitive implenetaitons of non-standardized fedaration is Bad Thing.

<LeeF> subsubtopic: LimitPerResource & Surface Syntax
2.2.5. LimitPerResource & Surface Syntax
14:22:14 <SimonS> AxelPolleres: LimitByResource

Axel Polleres: LimitByResource

14:23:05 <SimonS> Kjetil: Without LimitByResource, working on multiple datasources becomes more difficult.

Kjetil Kjernsmo: Without LimitByResource, working on multiple datasources becomes more difficult.

14:23:16 <KjetilK> - LimitClause  	  ::=    	'LIMIT' INTEGER

Kjetil Kjernsmo: - LimitClause ::= 'LIMIT' INTEGER

14:23:16 <KjetilK> + LimitClause  	  ::=    	'LIMIT' Var? INTEGER

Kjetil Kjernsmo: + LimitClause ::= 'LIMIT' Var? INTEGER

14:23:17 <SimonS> SteveH: possible with SubSelects

Steve Harris: possible with SubSelects

14:23:23 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:LimitPerResource

Axel Polleres: http://www.w3.org/2009/sparql/wiki/Feature:LimitPerResource

14:23:37 <SimonS> Kjetil: can't be simpler than limit by resource.

Kjetil Kjernsmo: can't be simpler than limit by resource.

14:23:58 <SimonS> SteveH: more complex requirements than covered by current proposal.

Steve Harris: more complex requirements than covered by current proposal.

14:24:18 <AxelPolleres> limit is always "distinct", yes? (otherwise doesn't make sense, does it?)

Axel Polleres: limit is always "distinct", yes? (otherwise doesn't make sense, does it?)

14:24:20 <SimonS> Kjetil: then use subselects, but we want it simple.

Kjetil Kjernsmo: then use subselects, but we want it simple.

14:24:39 <SimonS> AxelPolleres: Why not limit by variable list

Axel Polleres: Why not limit by variable list

14:24:43 <SimonS> ...?

...?

14:24:47 <kendall> iv_an_ru: I obviously don't agree

Ivan Mikhailov: I obviously don't agree [ Scribe Assist by Kendall Clark ]

14:24:50 <SimonS> video is gone.

video is gone.

14:25:04 <AxelPolleres> LIMIT ?x ?y INTEGER ?

Axel Polleres: LIMIT ?x ?y INTEGER ?

14:25:10 <AxelPolleres> q?

Axel Polleres: q?

14:25:12 <SimonS> SteveH: Seems to be redundant, so leave it

Steve Harris: Seems to be redundant, so leave it

14:25:29 <SimonS> Kjetil: Want this one simple syntax for our use case.

Kjetil Kjernsmo: Want this one simple syntax for our use case.

14:26:53 <kendall> in fact, competitive implementations of non-standard federation can be a good thing if it clarifies the market such that standardization can happy in a subsequent phase; premature standardization can do the opposite: cloud & foreclose the market, etc

Kendall Clark: in fact, competitive implementations of non-standard federation can be a good thing if it clarifies the market such that standardization can happy in a subsequent phase; premature standardization can do the opposite: cloud & foreclose the market, etc

14:26:59 <SimonS> Kjetil: You only care e.g. about distinct subjects. For example only have 10 resources plus their descriptions

Kjetil Kjernsmo: You only care e.g. about distinct subjects. For example only have 10 resources plus their descriptions

14:27:29 <iv_an_ru> Why not DESCRIBE with appropriate flags?

Ivan Mikhailov: Why not DESCRIBE with appropriate flags?

14:27:49 <SimonS> SteveH: does not see the difference. Use Aggregates?

Steve Harris: does not see the difference. Use Aggregates?

14:28:13 <SimonS> Kjetil: perhaps possible.

Kjetil Kjernsmo: perhaps possible.

14:28:27 <SimonS> Axel: If subselect have LIMIT + aggregates.

Axel Polleres: If subselect have LIMIT + aggregates.

14:28:42 <SimonS> SteveH: think we need better examples than in the wiki.

Steve Harris: think we need better examples than in the wiki.

14:29:00 <SimonS> Kjetil: Really need aggregate plus limit.

Kjetil Kjernsmo: Really need aggregate plus limit.

14:29:34 <SimonS> SteveH: also want things like "up to three eMail adresses"

Steve Harris: also want things like "up to three eMail adresses"

14:29:38 <iv_an_ru> kendall, _cooperative_ implementations of non-standard federation can be a good thing. Like AndyS and I kept SPARUL syntax in sync even if started it independently.

Ivan Mikhailov: kendall, _cooperative_ implementations of non-standard federation can be a good thing. Like AndyS and I kept SPARUL syntax in sync even if started it independently.

14:30:01 <SimonS> agree, iv_an_ru

agree, iv_an_ru

14:30:07 <kendall> eh...not convinced

Kendall Clark: eh...not convinced

14:30:11 <LeeF> q?

Lee Feigenbaum: q?

14:30:21 <kendall> that's only true if the market really wants one thing, and the cooperating parties are workin on that one thing

Kendall Clark: that's only true if the market really wants one thing, and the cooperating parties are workin on that one thing

14:30:28 <kendall> which i don't believe in this case

Kendall Clark: which i don't believe in this case

14:30:32 <iv_an_ru> We've seen enough "browser wars", don't want "sparql web-service endpoint wars" even if I win.

Ivan Mikhailov: We've seen enough "browser wars", don't want "sparql web-service endpoint wars" even if I win.

14:30:35 <kendall> so, whatever, we don't have to agree about this :>

Kendall Clark: so, whatever, we don't have to agree about this :>

14:30:42 <SimonS> AlexPassant: Would prefer concentrating of subqueries plus aggregates

Alex Passant: Would prefer concentrating of subqueries plus aggregates

14:31:09 <SimonS> Axel: Anyone else arguing for extra syntax?

Axel Polleres: Anyone else arguing for extra syntax?

14:31:52 <SimonS> LeeF: Negation is an example, which is possible, but painful.

Lee Feigenbaum: Negation is an example, which is possible, but painful.

14:32:09 <SteveH> I don't think all cases of Negation can be done curretnly

Steve Harris: I don't think all cases of Negation can be done curretnly

14:32:09 <SimonS> ... If there is not a consensus for special syntax.

... If there is not a consensus for special syntax.

14:32:23 <SimonS> ... we can do it later, as for negation.

... we can do it later, as for negation.

14:32:39 <LukeWM> q+

Luke Wilson-Mawer: q+

14:33:15 <LeeF> SteveH, you're probably right, but Bob MacGregor made a habit of trying to find such cases and didn't yet succeed (on sparql-dev and dawg-comments)

Lee Feigenbaum: SteveH, you're probably right, but Bob MacGregor made a habit of trying to find such cases and didn't yet succeed (on sparql-dev and dawg-comments)

14:33:51 <LeeF> ack LukeWM

Lee Feigenbaum: ack LukeWM

14:34:03 <SteveH> ?x a :A UNSAID { ?x a :B } is at least hard, though not impossible

Steve Harris: ?x a :A UNSAID { ?x a :B } is at least hard, though not impossible

14:34:07 <SimonS> LukeWM: There is difference between adding surface syntax for old and new features. For old ones there are lots of use cases.

Luke Wilson-Mawer: There is difference between adding surface syntax for old and new features. For old ones there are lots of use cases.

14:34:09 <AndyS> Try writing intersection using cross product and negation.  It can be done (apparantly).  But it is very hard to get right.

Andy Seaborne: Try writing intersection using cross product and negation. It can be done (apparantly). But it is very hard to get right.

14:34:26 <LeeF> SteveH, AndyS, I agree re: very hard, that's not what i was saying :)

Lee Feigenbaum: SteveH, AndyS, I agree re: very hard, that's not what i was saying :)

14:35:04 <SimonS> Kjetil: If time allows and subselects + aggregates are done, maybe come back?

Kjetil Kjernsmo: If time allows and subselects + aggregates are done, maybe come back?

14:35:31 <SimonS> SteveH: Object. Will not have user experience by then.

Steve Harris: Object. Will not have user experience by then.

14:36:09 <SimonS> SteveH: use case means real users in the field

Steve Harris: use case means real users in the field

14:36:57 <SimonS> Axel: Objection to dropping?

Axel Polleres: Objection to dropping?

14:37:01 <SimonS> Kjetil: no.

Kjetil Kjernsmo: no.

14:37:12 <SimonS> Axel: Next one is SurfaceSyntax

Axel Polleres: Next one is SurfaceSyntax

14:37:22 <SimonS> ... what is surface syntax?

... what is surface syntax?

14:37:24 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0195.html

Axel Polleres: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0195.html

14:38:35 <SimonS> ... disjunction in FILTER (IN or BETWEEN)

... disjunction in FILTER (IN or BETWEEN)

14:39:03 <SimonS> ... path operators for concatenation etc

... path operators for concatenation etc

14:39:12 <SimonS> ... needed anyway for property paths

... needed anyway for property paths

14:39:22 <SimonS> ... allow commas in expression lists

... allow commas in expression lists

14:39:30 <SimonS> ... oppinions?

... oppinions?

14:39:46 <AndyS> q+ to worry about the feature overall

Andy Seaborne: q+ to worry about the feature overall

14:39:48 <AxelPolleres> q+ on IN

Axel Polleres: q+ on IN

14:39:53 <SimonS> SteveH: like IN, rely on it as an optimization.

Steve Harris: like IN, rely on it as an optimization.

14:39:59 <SimonS> ... comma probably useful

... comma probably useful

14:40:28 <SimonS> ... regarding IN: possibly gives list access if specified right, if right hand side is a list.

... regarding IN: possibly gives list access if specified right, if right hand side is a list.

14:40:48 <SimonS> Axel: but that is a different feature

Axel Polleres: but that is a different feature

14:41:13 <SimonS> AndyS: all things possible using dynamic dispatch

Andy Seaborne: all things possible using dynamic dispatch

14:41:25 <SimonS> Axel: Also IN SELECT ...?

Axel Polleres: Also IN SELECT ...?

14:41:30 <KjetilK> DefaultDescribeResult is also doable as SurfaceSyntax

Kjetil Kjernsmo: DefaultDescribeResult is also doable as SurfaceSyntax

14:41:42 <SimonS> SteveH: means SQL style IN.

Steve Harris: means SQL style IN.

14:41:56 <Zakim> -iv_an_ru

Zakim IRC Bot: -iv_an_ru

14:41:58 <SimonS> Axel: with subselects it is no longer syntactic sugar.

Axel Polleres: with subselects it is no longer syntactic sugar.

14:42:44 <SteveH> SteveH: yes it is :)

Steve Harris: yes it is :) [ Scribe Assist by Steve Harris ]

14:42:48 <AxelPolleres> IN range, IN subselect, IN lists

Axel Polleres: IN range, IN subselect, IN lists

14:43:15 <SimonS> Axel: three possibilities - IN range, IN subselect, IN list.

Axel Polleres: three possibilities - IN range, IN subselect, IN list.

14:43:48 <SimonS> SteveH: depends on how range is expressed. Could be a list.

Steve Harris: depends on how range is expressed. Could be a list.

14:44:06 <kasei> i would support "IN range", but generally not any of the other 3 surface syntaxes

Greg Williams: i would support "IN range", but generally not any of the other 3 surface syntaxes

14:44:17 <SimonS> ... not advocating this, just pointing it out.

... not advocating this, just pointing it out.

14:44:19 <LeeF> q?

Lee Feigenbaum: q?

14:44:58 <SimonS> AndyS: feature is surface syntax. Not comfortable with putting it under SurfaceSyntax. Discussion too open.

Andy Seaborne: feature is surface syntax. Not comfortable with putting it under SurfaceSyntax. Discussion too open.

14:45:00 <ericP> q+ to propose a feature called "query language"

Eric Prud'hommeaux: q+ to propose a feature called "query language"

14:45:02 <ericP> q-

Eric Prud'hommeaux: q-

14:45:22 <AndyS> ack me

Andy Seaborne: ack me

14:45:27 <SimonS> Axel: left are IN between, commas.

Axel Polleres: left are IN between, commas.

14:45:30 <Zakim> AndyS, you wanted to worry about the feature overall

Zakim IRC Bot: AndyS, you wanted to worry about the feature overall

14:45:35 <LeeF>  FYI: I'm building http://www.w3.org/2009/sparql/wiki/FeatureProposal as I listen to the conversation

Lee Feigenbaum: FYI: I'm building http://www.w3.org/2009/sparql/wiki/FeatureProposal as I listen to the conversation

14:45:55 <KjetilK> q+ to ask whether we have agreed on the definition of surface syntax?

Kjetil Kjernsmo: q+ to ask whether we have agreed on the definition of surface syntax?

14:46:17 <SimonS> SteveH: IN with constants on the right is easy.

Steve Harris: IN with constants on the right is easy.

14:46:35 <SimonS> LeeF: not have a generic SurfaceSyntax item

Lee Feigenbaum: not have a generic SurfaceSyntax item

14:47:12 <SimonS> ... changing SurfaceSyntac to Commas and IN in FeatureProposal

... changing SurfaceSyntac to Commas and IN in FeatureProposal

14:47:56 <SimonS> AndyS: can drop commas, nobody would complain.

Andy Seaborne: can drop commas, nobody would complain.

14:48:11 <SimonS> LeeF: do it, if time permits.

Lee Feigenbaum: do it, if time permits.

14:49:13 <SimonS> Axel: objections to Commas if time allowed?

Axel Polleres: objections to Commas if time allowed?

14:49:41 <SimonS> SteveH: commas in select alone do not help, also need it in limit etc.

Steve Harris: commas in select alone do not help, also need it in limit etc.

<LeeF> subsubtopic: SPARQL/OWL
2.2.6. SPARQL/OWL
14:50:30 <SimonS> Axel: next one is SPARQL/OWL

Axel Polleres: next one is SPARQL/OWL

14:51:03 <SimonS> LeeF: Important to have. Who objects and why?

Lee Feigenbaum: Important to have. Who objects and why?

14:51:44 <KjetilK> q-

Kjetil Kjernsmo: q-

14:51:54 <Zakim> +Chimezie_Ogbuji

Zakim IRC Bot: +Chimezie_Ogbuji

14:51:54 <KjetilK> q+ to say something negative

Kjetil Kjernsmo: q+ to say something negative

14:52:07 <chimezie> Zakim, mute me

Chime Ogbuji: Zakim, mute me

14:52:07 <Zakim> Chimezie_Ogbuji should now be muted

Zakim IRC Bot: Chimezie_Ogbuji should now be muted

14:52:09 <SimonS> ... discuss other entailment regimes.

... discuss other entailment regimes.

14:52:12 <SimonS> ... do one.

... do one.

14:52:18 <AndyS> If the goal to prove the extension point, makes sense to me to look at a simpler one (first). SPARQL/OWL has value in itself - not a proof point.

Andy Seaborne: If the goal to prove the extension point, makes sense to me to look at a simpler one (first). SPARQL/OWL has value in itself - not a proof point.

14:52:24 <SimonS> ... if it goes well, maybe do another one or two.

... if it goes well, maybe do another one or two.

14:52:31 <bglimm> q+

Birte Glimm: q+

14:52:43 <SteveH> q+

Steve Harris: q+

14:52:53 <bijan> q+ to say my main goal is force commonality on existing implementations

Bijan Parsia: q+ to say my main goal is force commonality on existing implementations

14:52:59 <bijan> er...one of my main goals

Bijan Parsia: er...one of my main goals

14:53:03 <KjetilK> ack me

Kjetil Kjernsmo: ack me

14:53:05 <Zakim> KjetilK, you wanted to say something negative

Zakim IRC Bot: KjetilK, you wanted to say something negative

14:53:10 <Zakim> -Bristol

Zakim IRC Bot: -Bristol

14:53:24 <KjetilK> do you hear us?

Kjetil Kjernsmo: do you hear us?

14:53:26 <AxelPolleres> we need to redial it seems

Axel Polleres: we need to redial it seems

14:53:26 <LeeF> that will be a lesson to saying something negative about SPARQL/OWL

Lee Feigenbaum: that will be a lesson to saying something negative about SPARQL/OWL

14:54:20 <SteveH> we have a dependency on AndyS's knowledge of the phone :)

Steve Harris: we have a dependency on AndyS's knowledge of the phone :)

14:55:22 <iv_an_ru> We've added optional commas to select list syntax because SQL people wrote them.

Ivan Mikhailov: We've added optional commas to select list syntax because SQL people wrote them.

14:55:39 <Zakim> +??P0

Zakim IRC Bot: +??P0

14:55:47 <SteveH> iv_an_ru, any idea what it did to the class of your parser?

Steve Harris: iv_an_ru, any idea what it did to the class of your parser?

14:55:57 <SteveH> iv_an_ru, is it still in LL1?

Steve Harris: iv_an_ru, is it still in LL1?

14:56:01 <KjetilK> Zakim, ??P0 is Bristol

Kjetil Kjernsmo: Zakim, ??P0 is Bristol

14:56:01 <Zakim> +Bristol; got it

Zakim IRC Bot: +Bristol; got it

14:56:01 <LeeF> zakim, ??P0 is Bristol

Lee Feigenbaum: zakim, ??P0 is Bristol

14:56:02 <Zakim> I already had ??P0 as Bristol, LeeF

Zakim IRC Bot: I already had ??P0 as Bristol, LeeF

14:56:06 <iv_an_ru> Yes of course.

Ivan Mikhailov: Yes of course.

14:56:36 <iv_an_ru> It's still LALR1 because commas are either optional delimiters of the list or nested in (...)

Ivan Mikhailov: It's still LALR1 because commas are either optional delimiters of the list or nested in (...)

14:56:46 <bijan> There are OWL Profiles

Bijan Parsia: There are OWL Profiles

14:56:55 <bijan> OWL RL is explicitly designed to work for forward chaining

Bijan Parsia: OWL RL is explicitly designed to work for forward chaining

14:56:57 <SimonS> Kjetil: Have OWL users, have some simple inferences, which take forever

Kjetil Kjernsmo: Have OWL users, have some simple inferences, which take forever

14:57:08 <SimonS> SteveH: just specify results only.

Steve Harris: just specify results only.

14:57:24 <SimonS> Axel: purpose is being able to specify what it means to support OWL.

Axel Polleres: purpose is being able to specify what it means to support OWL.

14:57:32 <LeeF> q?

Lee Feigenbaum: q?

14:57:37 <LeeF> ack bglimm

Lee Feigenbaum: ack bglimm

14:57:47 <iv_an_ru> Moreover, it may be convenient to "invert" the informal description of the grammar and say that commas are not required as soon as select list stays unambiguous.

Ivan Mikhailov: Moreover, it may be convenient to "invert" the informal description of the grammar and say that commas are not required as soon as select list stays unambiguous.

14:57:59 <bijan> Kjetil, it's not clear to me that the inferences are "simple".

Bijan Parsia: Kjetil, it's not clear to me that the inferences are "simple".

14:58:11 <SimonS> Birte: There needs to be some way of telling users that results will not only be subgraph matching. Have users how need that.

Birte Glimm: There needs to be some way of telling users that results will not only be subgraph matching. Have users how need that.

14:58:34 <AxelPolleres> q+ to speak about why we need more refined notions of entailment even.

Axel Polleres: q+ to speak about why we need more refined notions of entailment even.

14:58:37 <SimonS> Kjetil: Is it that important?

Kjetil Kjernsmo: Is it that important?

14:59:01 <bijan> I'll note that RacerPro has it's own query language, NRQL

Bijan Parsia: I'll note that RacerPro has it's own query language, NRQL

14:59:10 <SimonS> Birte: There is no standardized OWL query language, so use SPARQL.

Birte Glimm: There is no standardized OWL query language, so use SPARQL.

14:59:32 <ivanh> q+

Ivan Herman: q+

14:59:34 <SimonS> ...instead of inventing another one.

...instead of inventing another one.

14:59:44 <iv_an_ru> +1, the best advantage of SPARQL is the very fact of being implemented.

Ivan Mikhailov: +1, the best advantage of SPARQL is the very fact of being implemented.

15:00:09 <iv_an_ru> Implementation of something is more convenient than spec of everything.

Ivan Mikhailov: Implementation of something is more convenient than spec of everything.

15:00:11 <LeeF> iv_an_ru, +30 to that (i think lessons from SPARQL v1 prove that out nicely)

Lee Feigenbaum: iv_an_ru, +30 to that (i think lessons from SPARQL v1 prove that out nicely)

15:00:26 <SimonS> Axel: support having OWL entailment regime, but DERI wants something more fine grained.

Axel Polleres: support having OWL entailment regime, but DERI wants something more fine grained.

15:00:46 <SimonS> ...want to be able to say, "we support subset A, but not subsetB"

...want to be able to say, "we support subset A, but not subsetB"

15:00:53 <SimonS> ...also interested in RIF rules.

...also interested in RIF rules.

15:01:01 <AndyS> Liitle house example --> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0069.html

Andy Seaborne: Liitle house example --> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0069.html

15:01:23 <AndyS> q+

Andy Seaborne: q+

15:01:30 <SimonS> ...sometimes one just does not want to have full OWL on the Web, as it results in nonsense results.

...sometimes one just does not want to have full OWL on the Web, as it results in nonsense results.

15:02:13 <SimonS> Kjetil: OWL is too slow today.

Kjetil Kjernsmo: OWL is too slow today.

15:02:23 <SimonS> SteveH: not everybody needs to do OWL.

Steve Harris: not everybody needs to do OWL.

15:02:39 <bijan> I'd like to address the OWL's too slow issue

Bijan Parsia: I'd like to address the OWL's too slow issue

15:02:40 <SimonS> AndyS: The point is being able to layer algebra on top of OWL inferencing.

Andy Seaborne: The point is being able to layer algebra on top of OWL inferencing.

15:03:07 <LeeF> ack AxelPolleres

Lee Feigenbaum: ack AxelPolleres

15:03:07 <Zakim> AxelPolleres, you wanted to comment on IN and to speak about why we need more refined notions of entailment even.

Zakim IRC Bot: AxelPolleres, you wanted to comment on IN and to speak about why we need more refined notions of entailment even.

15:03:12 <LeeF> ack SteveH

Lee Feigenbaum: ack SteveH

15:03:13 <AxelPolleres> ack SteveH

Axel Polleres: ack SteveH

15:03:30 <LeeF> ack bijan

Lee Feigenbaum: ack bijan

15:03:30 <Zakim> bijan, you wanted to say my main goal is force commonality on existing implementations

Zakim IRC Bot: bijan, you wanted to say my main goal is force commonality on existing implementations

15:03:34 <SimonS> SteveH: OWL is not a special case. Regime includes RDFS and others.

Steve Harris: OWL is not a special case. Regime includes RDFS and others.

15:03:54 <SimonS> bijan: OWL fast for many users/datasets/reasoners.

Bijan Parsia: OWL fast for many users/datasets/reasoners.

15:04:09 <SimonS> ... number of OWL2 profiles, which improve that even more.

... number of OWL2 profiles, which improve that even more.

15:04:38 <SimonS> ... need to take care of inconsistencies in the dataset for such entailment regime.

... need to take care of inconsistencies in the dataset for such entailment regime.

15:05:06 <SimonS> ... main objective is make OWL query engines use SPARQL and become interoperable

... main objective is make OWL query engines use SPARQL and become interoperable

15:05:34 <LeeF> q?

Lee Feigenbaum: q?

15:05:38 <LeeF> ack ivanh

Lee Feigenbaum: ack ivanh

15:06:08 <bijan> OWL Profiles: http://www.w3.org/TR/owl2-profiles/

Bijan Parsia: OWL Profiles: http://www.w3.org/TR/owl2-profiles/

15:06:29 <SimonS> ivanh: OWL is not only huge DL reasoning with hundrets of classes. There are smaller profiles and smaller features useful on their own

Ivan Herman: OWL is not only huge DL reasoning with hundrets of classes. There are smaller profiles and smaller features useful on their own

15:06:58 <SimonS> ... discussion at WWW with LOD community.

... discussion at WWW with LOD community.

15:07:12 <SimonS> ... They are starting to consider OWL as adding value

... They are starting to consider OWL as adding value

15:07:39 <SimonS> ... Need RDFS as well, which can not correctly be descibed in SPARQL today.

... Need RDFS as well, which can not correctly be descibed in SPARQL today.

15:07:54 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS

15:07:59 <SimonS> ... goal: describe SPARQL on top of OWL and RDFS reasoning

... goal: describe SPARQL on top of OWL and RDFS reasoning

15:08:29 <SimonS> AndyS: bijan to give a brief sketch of what is needed; scoping?

Andy Seaborne: bijan to give a brief sketch of what is needed; scoping?

15:08:45 <SimonS> bijan: inconsistencies

Bijan Parsia: inconsistencies

15:09:01 <SimonS> ... syntactically higher order variables, e.g. in predicate positions

... syntactically higher order variables, e.g. in predicate positions

15:09:28 <SimonS> ... BNodes

... BNodes

15:09:42 <SimonS> ... derive additional information from them?

... derive additional information from them?

15:09:43 <pgearon> +1 for not deriving new bnodes!

Paul Gearon: +1 for not deriving new bnodes!

15:10:29 <SimonS> ... restrict range of variables in order to guarantee finite results

... restrict range of variables in order to guarantee finite results

15:10:56 <SimonS> AndyS: summarize in email please

Andy Seaborne: summarize in email please

15:11:14 <LeeF> ACTION: bijan to send mail about issues in BGP matching that must be considered when specifying OWL in SPARQL semantics

ACTION: bijan to send mail about issues in BGP matching that must be considered when specifying OWL in SPARQL semantics

15:11:14 <trackbot> Created ACTION-14 - Send mail about issues in BGP matching that must be considered when specifying OWL in SPARQL semantics [on Bijan Parsia - due 2009-05-13].

Trackbot IRC Bot: Created ACTION-14 - Send mail about issues in BGP matching that must be considered when specifying OWL in SPARQL semantics [on Bijan Parsia - due 2009-05-13].

15:11:53 <ivanh> q+

Ivan Herman: q+

15:12:12 <SimonS> Axel: Define Entailment regime for OWL, subregimes for OWL EL and the like time permits?

Axel Polleres: Define Entailment regime for OWL, subregimes for OWL EL and the like time permits?

15:12:54 <SimonS> bijan: Issues should be the same for all, also for RIF. Describe abstractly.

Bijan Parsia: Issues should be the same for all, also for RIF. Describe abstractly.

15:13:27 <SimonS> ericP: include relationship of OWL to RDF? e.g. using graph API with DL

Eric Prud'hommeaux: include relationship of OWL to RDF? e.g. using graph API with DL

15:13:32 <SteveH> I wonder if we can call it SPARQL/Entailment instead?

Steve Harris: I wonder if we can call it SPARQL/Entailment instead?

15:13:46 <SteveH>  /OWL is a little specific

Steve Harris: /OWL is a little specific

15:14:03 <LeeF> SteveH, I already updated it :)

Lee Feigenbaum: SteveH, I already updated it :)

15:14:11 <LeeF> (not sure if the new wording is best)

Lee Feigenbaum: (not sure if the new wording is best)

15:14:16 <SteveH> :)

Steve Harris: :)

15:14:39 <SimonS> bijan: need that, e.g. for BNodes.

Bijan Parsia: need that, e.g. for BNodes.

15:14:45 <bglimm> updated to what?

Birte Glimm: updated to what?

15:14:56 <LeeF> bglimm, see http://www.w3.org/2009/sparql/wiki/FeatureProposal

Lee Feigenbaum: bglimm, see http://www.w3.org/2009/sparql/wiki/FeatureProposal

15:15:02 <SteveH> LeeF, http://www.w3.org/2009/sparql/wiki/User:Lee_Feigenbaum#Lee.27s_feature_proposal is unchanged

Steve Harris: LeeF, http://www.w3.org/2009/sparql/wiki/User:Lee_Feigenbaum#Lee.27s_feature_proposal is unchanged

15:15:06 <bijan> SteveH, that could be reasonable.

Bijan Parsia: SteveH, that could be reasonable.

15:15:09 <LeeF> SteveH, see http://www.w3.org/2009/sparql/wiki/FeatureProposal

Lee Feigenbaum: SteveH, see http://www.w3.org/2009/sparql/wiki/FeatureProposal

15:15:20 <LeeF> ack ivanh

Lee Feigenbaum: ack ivanh

15:15:39 <SimonS> ivanh: for subsets like RL the situation may be even simpler.

Ivan Herman: for subsets like RL the situation may be even simpler.

15:15:43 <bijan> Right, for simpler regimes it'll be simpler

Bijan Parsia: Right, for simpler regimes it'll be simpler

15:15:58 <bijan> But then the regime would meet the criteria inherently

Bijan Parsia: But then the regime would meet the criteria inherently

15:16:22 <AxelPolleres> q+ to ask (chair-hat-off) about SPARQL/RIF in/out of scope here, if we find volunteers?

Axel Polleres: q+ to ask (chair-hat-off) about SPARQL/RIF in/out of scope here, if we find volunteers?

15:16:37 <SimonS> ivanh: for the records - we need to allow to clearly define the capabilities of an endpoint. Needs service descriptions.

Ivan Herman: for the records - we need to allow to clearly define the capabilities of an endpoint. Needs service descriptions.

15:16:43 <LeeF> ack AxelPolleres

Lee Feigenbaum: ack AxelPolleres

15:16:43 <Zakim> AxelPolleres, you wanted to ask (chair-hat-off) about SPARQL/RIF in/out of scope here, if we find volunteers?

Zakim IRC Bot: AxelPolleres, you wanted to ask (chair-hat-off) about SPARQL/RIF in/out of scope here, if we find volunteers?

15:16:58 <AndyS> q+ to note UC for multiple entailment in one query

Andy Seaborne: q+ to note UC for multiple entailment in one query

15:17:01 <ivanh> q?

Ivan Herman: q?

15:17:04 <ivanh> q+

Ivan Herman: q+

15:17:29 <SimonS> Axel: also extend to RIF? Seems closey related. Would that be in the scope of SPARQL/entailment, time allowed?

Axel Polleres: also extend to RIF? Seems closey related. Would that be in the scope of SPARQL/entailment, time allowed?

15:17:40 <AndyS> What would SPARQL/RIF involve?

Andy Seaborne: What would SPARQL/RIF involve?

15:17:40 <SimonS> LeeF: included in modified feature proposal.

Lee Feigenbaum: included in modified feature proposal.

15:18:40 <ericP> from a fashion perspective, we have a chance to develop more styles if we go madly off in all directions at once

Eric Prud'hommeaux: from a fashion perspective, we have a chance to develop more styles if we go madly off in all directions at once

15:18:40 <SimonS> AndyS: service descriptions do not cover multiple regimes in a single query.

Andy Seaborne: service descriptions do not cover multiple regimes in a single query.

15:19:01 <SimonS> ivanh: not sure this is useful.

Ivan Herman: not sure this is useful.

15:19:11 <chimezie> I'm not even sure if that can be done in a sound way

Chime Ogbuji: I'm not even sure if that can be done in a sound way

15:19:12 <bijan> I think its' pretty clear that having multiple *is* useful. I think it's useful at least :)

Bijan Parsia: I think its' pretty clear that having multiple *is* useful. I think it's useful at least :)

15:19:24 <chimezie> i.e., specific entailment regimes for specific parts of the active graph

Chime Ogbuji: i.e., specific entailment regimes for specific parts of the active graph

15:19:29 <SteveH> I have used multiple in one query

Steve Harris: I have used multiple in one query

15:19:38 <SteveH> not sure how it realtes/comflicts with decriptions though

Steve Harris: not sure how it realtes/comflicts with decriptions though

15:19:49 <bijan> chimezie, I thought it was for different BGPs

Bijan Parsia: chimezie, I thought it was for different BGPs

15:20:09 <bijan> Then it's just querying the *whole* graph under different semantics and combining the results under the algebra

Bijan Parsia: Then it's just querying the *whole* graph under different semantics and combining the results under the algebra

15:20:17 <AndyS> One way - different graphs with different entailment in one datasets. (There may be other ways - just an example - but this is no syntax way)

Andy Seaborne: One way - different graphs with different entailment in one datasets. (There may be other ways - just an example - but this is no syntax way)

15:20:18 <SimonS> ... reg. Axel's question: OWL is clearly described in RDF, hence also in SPARQL. For RIF, this does not hold. Hence, need additional syntax or protocol.

... reg. Axel's question: OWL is clearly described in RDF, hence also in SPARQL. For RIF, this does not hold. Hence, need additional syntax or protocol.

15:20:18 <bijan> Which will be sound

Bijan Parsia: Which will be sound

15:20:53 <AxelPolleres> http://www.w3.org/2005/rules/wiki/SWC

Axel Polleres: http://www.w3.org/2005/rules/wiki/SWC

15:21:01 <chimezie> I interpreted that differently (i.e., I thought they were talking about parts of teh graph rather than parts of the query)

Chime Ogbuji: I interpreted that differently (i.e., I thought they were talking about parts of teh graph rather than parts of the query)

15:21:09 <bijan> Ah.

Bijan Parsia: Ah.

15:21:13 <SteveH> I agree with ericP

Steve Harris: I agree with ericP

15:21:14 <SimonS> I like and have used multiple graphs as AndyS proposes.

I like and have used multiple graphs as AndyS proposes.

15:21:25 <SteveH> (pre Garlik)

Steve Harris: (pre Garlik)

15:21:29 <AxelPolleres> q?

Axel Polleres: q?

15:21:35 <AndyS> ack me

Andy Seaborne: ack me

15:21:35 <Zakim> AndyS, you wanted to note UC for multiple entailment in one query

Zakim IRC Bot: AndyS, you wanted to note UC for multiple entailment in one query

15:21:38 <LeeF> ack ivanh

Lee Feigenbaum: ack ivanh

15:22:04 <SimonS> Axel: in above link, semantics of RIF+RDF is specified, includes entailed RDF triples

Axel Polleres: in above link, semantics of RIF+RDF is specified, includes entailed RDF triples

15:22:10 <bijan> q+

Bijan Parsia: q+

15:22:23 <SimonS> ivanh: does not include encoding RIF rules in RDF.

Ivan Herman: does not include encoding RIF rules in RDF.

15:22:24 <chimezie> By reference to a RIF ruleset, ivanh

Chime Ogbuji: By reference to a RIF ruleset, ivanh

15:22:38 <SimonS> ... so how do I give endpoint the rules it needs.

... so how do I give endpoint the rules it needs.

15:22:55 <SimonS> AndyS: different issue - ParametrizedInference

Andy Seaborne: different issue - ParametrizedInference

15:23:38 <SimonS> SimonS: disagree

Simon Schenk: disagree

15:24:44 <chimezie> My impression is (as Bijan suggested) many of the issues that will need to be addressed on the path towards an OWL-DL entailment regime, will be re-usable for other regimes (including RIF+RDF).  As long as we aren't explicitely ruling out the possiblity of investigating taking that further step once the details for SPARQL-DL are worked out

Chime Ogbuji: My impression is (as Bijan suggested) many of the issues that will need to be addressed on the path towards an OWL-DL entailment regime, will be re-usable for other regimes (including RIF+RDF). As long as we aren't explicitely ruling out the possiblity of investigating taking that further step once the details for SPARQL-DL are worked out

15:24:52 <SimonS> ... Today, many endpoints do inferencing without being parametrized.

... Today, many endpoints do inferencing without being parametrized.

15:25:20 <chimezie> +1 on explicitly excluding further regimes ..

Chime Ogbuji: +1 on explicitly excluding further regimes ..

15:25:23 <SimonS> Axel: Want do define what it means to evaluate a SPARQL query together with some RIF rules. Would not want to exclude it.

Axel Polleres: Want do define what it means to evaluate a SPARQL query together with some RIF rules. Would not want to exclude it.

15:25:29 <ivanh> chimezie, I would not talk about SPARQL-DL but SPARQL-OWL

Ivan Herman: chimezie, I would not talk about SPARQL-DL but SPARQL-OWL

15:25:33 <bijan> q-

Bijan Parsia: q-

15:25:37 <LeeF> q?

Lee Feigenbaum: q?

<LeeF> subtopic: Next steps after lunch break

2.3. Next steps after lunch break

15:25:59 <LeeF> http://www.w3.org/2009/sparql/wiki/FeatureProposal

Lee Feigenbaum: http://www.w3.org/2009/sparql/wiki/FeatureProposal

15:26:52 <bijan> I may be asleep this evening :)

Bijan Parsia: I may be asleep this evening :)

15:26:56 <SimonS> LeeF: everybody have a look at the list during lunch break

Lee Feigenbaum: everybody have a look at the list during lunch break

15:27:26 <KjetilK> q+ to ask about ProjectExpression as required

Kjetil Kjernsmo: q+ to ask about ProjectExpression as required

15:27:45 <SimonS> ... and need to think about order

... and need to think about order

15:28:06 <bijan> It looks good to me

Bijan Parsia: It looks good to me

15:28:18 <bijan> q+

Bijan Parsia: q+

15:28:29 <ivanh> :;-)

Ivan Herman: :;-)

15:28:50 <SimonS> Kjetil: Should project expressions really be required?

Kjetil Kjernsmo: Should project expressions really be required?

15:29:04 <SimonS> SteveH: hardly possible to do aggregates and subqueires without.

Steve Harris: hardly possible to do aggregates and subqueires without.

15:29:11 <bijan> On queue!

Bijan Parsia: On queue!

15:29:15 <LeeF> q?

Lee Feigenbaum: q?

15:29:23 <KjetilK> ack me

Kjetil Kjernsmo: ack me

15:29:24 <Zakim> KjetilK, you wanted to ask about ProjectExpression as required

Zakim IRC Bot: KjetilK, you wanted to ask about ProjectExpression as required

15:29:28 <chimezie> We have a person on queue

Chime Ogbuji: We have a person on queue

15:29:36 <LeeF> ack bijan

Lee Feigenbaum: ack bijan

15:30:17 <SimonS> bijan: What if we find out something is harder to do than expected?

Bijan Parsia: What if we find out something is harder to do than expected?

15:30:23 <SimonS> ... do we have a strategy there?

... do we have a strategy there?

15:30:43 <SimonS> LeeF: Use the usual W3C excuse... ;-)

Lee Feigenbaum: Use the usual W3C excuse... ;-)

15:31:05 <bijan> I love lead pipes!

Bijan Parsia: I love lead pipes!

15:31:24 <AndyS> We had the lead pipes at our house removed last month

Andy Seaborne: We had the lead pipes at our house removed last month

15:31:49 <SimonS> LeeF: break.

Lee Feigenbaum: break.

15:36:38 <LeeF> chimezie, sorry, did not notice that you joined on the phone!

Lee Feigenbaum: chimezie, sorry, did not notice that you joined on the phone!

15:38:00 <AxelPolleres> chime, we are having the break for one hour, would be good if you checked as all the others http://www.w3.org/2009/sparql/wiki/FeatureProposal and have objections/concenrs ready when we continue.

Axel Polleres: chime, we are having the break for one hour, would be good if you checked as all the others http://www.w3.org/2009/sparql/wiki/FeatureProposal and have objections/concenrs ready when we continue.

15:46:17 <chimezie> AxelPolleres�:� will do

(No events recorded for 8 minutes)

Chime Ogbuji: AxelPolleres�:� will do

15:46:34 <chimezie> LeeF�:� np :)

Chime Ogbuji: LeeF�:� np :)

16:33:48 <LeeF> chimezie, bijan, iv_an_ru we're starting back up

(No events recorded for 47 minutes)

Lee Feigenbaum: chimezie, bijan, iv_an_ru we're starting back up

16:33:54 <LeeF> please join if you can/intend to :)

Lee Feigenbaum: please join if you can/intend to :)

16:34:59 <AxelPolleres> Extremely useful for people new to W3C telecons/IRC: http://www.w3.org/2009/CommonScribe/manual.html (if you haven't been pointet at yet)

Axel Polleres: Extremely useful for people new to W3C telecons/IRC: http://www.w3.org/2009/CommonScribe/manual.html (if you haven't been pointet at yet)

16:35:43 <kasei> scribenick: kasei

(Scribe set to Greg Williams)

<LeeF> subtopic: Feature decision

2.4. Feature decision

Summary: RESOLVED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein

<LeeF> summary: RESOLVED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein
16:35:55 <LeeF> http://www.w3.org/2009/sparql/wiki/FeatureProposal

Lee Feigenbaum: http://www.w3.org/2009/sparql/wiki/FeatureProposal

16:36:59 <kasei> LeeF: regarding "in order" of time-permitting features, might extend timeline for required features, not for time-permitting

Lee Feigenbaum: regarding "in order" of time-permitting features, might extend timeline for required features, not for time-permitting

16:37:34 <kasei> ... assuming get through required features, need to decide which time-permitting features

... assuming get through required features, need to decide which time-permitting features

16:38:27 <kasei> ... overlap of work for some features, not others (bgp entailment). makes sense to do some work in parallel.

... overlap of work for some features, not others (bgp entailment). makes sense to do some work in parallel.

16:39:08 <SteveH> +1

Steve Harris: +1

16:39:10 <AxelPolleres> +1

Axel Polleres: +1

16:39:10 <KjetilK> +1

Kjetil Kjernsmo: +1

16:39:19 <kasei> ... inclinded to remove ordering, in charter note time permitting features, and punt on choosing until it comes up later

... inclinded to remove ordering, in charter note time permitting features, and punt on choosing until it comes up later

16:39:20 <AlexPassant> +1, fair enough

Alex Passant: +1, fair enough

16:39:25 <SimonS>  +1

Simon Schenk: +1

16:40:11 <kasei> AndyS: may be contention of WG when coming together with features toward the end

Andy Seaborne: may be contention of WG when coming together with features toward the end

16:41:51 <kasei> LeeF: should be default that things are rec track, but should be aware lots of ancillary work, chance we'll have to make some things WG notes

Lee Feigenbaum: should be default that things are rec track, but should be aware lots of ancillary work, chance we'll have to make some things WG notes

16:42:09 <AxelPolleres> q+

Axel Polleres: q+

16:42:14 <LeeF> ack AxelPolleres

Lee Feigenbaum: ack AxelPolleres

16:42:56 <kasei> AxelPolleres: would it make sense to mention a point in time to decide rec track features?

Axel Polleres: would it make sense to mention a point in time to decide rec track features?

16:43:46 <kasei> ... not sure has to be in charter

... not sure has to be in charter

16:43:54 <bglimm> q+

Birte Glimm: q+

16:44:10 <LeeF> ack bglimm

Lee Feigenbaum: ack bglimm

16:44:13 <kasei> LeeF: don't want entailment work to come back to WG to get response "sorry, that'll be WG note"

Lee Feigenbaum: don't want entailment work to come back to WG to get response "sorry, that'll be WG note"

16:45:26 <kasei> bglimm: people interested in entialment regimes won't contribute much to the other query language features

Birte Glimm: people interested in entialment regimes won't contribute much to the other query language features

16:45:55 <kendall> There's an obvious denial of service strategy from a disinterested majority against the "time-permitting" work items that's bothersome

Kendall Clark: There's an obvious denial of service strategy from a disinterested majority against the "time-permitting" work items that's bothersome

16:46:15 <kasei> LeeF: don't want to sacrifice required features for time-permitting ones, but don't want required features to be unnecessary obstacles to the time-permittings.

Lee Feigenbaum: don't want to sacrifice required features for time-permitting ones, but don't want required features to be unnecessary obstacles to the time-permittings.

16:47:04 <kasei> ... open issues on required features shouldn't prevent discussion of time-permitting features

... open issues on required features shouldn't prevent discussion of time-permitting features

16:47:18 <bglimm> q+

Birte Glimm: q+

16:47:53 <ericP> +1 to deathmarch

Eric Prud'hommeaux: +1 to deathmarch

16:47:59 <SteveH> -1 to deathmarch

Steve Harris: -1 to deathmarch

16:48:10 <LeeF> ack bglimm

Lee Feigenbaum: ack bglimm

16:49:05 <kasei> bglimm: if people working on required parts can't spend time on coordination of time-permitting features, unlikely to work in the end...

Birte Glimm: if people working on required parts can't spend time on coordination of time-permitting features, unlikely to work in the end...

16:50:00 <kasei> ... is it worth working on these features if unlikely to have time to review at the end

... is it worth working on these features if unlikely to have time to review at the end

16:50:21 <kendall> fwiw, I don't think it's entirely true that inference people, say, won't work on required features, since implementations count as working on them.

Kendall Clark: fwiw, I don't think it's entirely true that inference people, say, won't work on required features, since implementations count as working on them.

16:50:45 <LeeF> kendall, I think that bglimm is mainly speaking for herself

Lee Feigenbaum: kendall, I think that bglimm is mainly speaking for herself

16:51:38 <kasei> SteveH: tends to be contentious issues that take up most time

Steve Harris: tends to be contentious issues that take up most time

16:51:39 <kendall> as am I

Kendall Clark: as am I

16:52:07 <kasei> LeeF: don't mean to imply that people won't have time to review time-permitting features

Lee Feigenbaum: don't mean to imply that people won't have time to review time-permitting features

16:52:13 <bglimm> I am mainly speaking for myself

Birte Glimm: I am mainly speaking for myself

16:52:26 <kasei> ... is acknowledgement that it's a worthwhile effort

... is acknowledgement that it's a worthwhile effort

16:52:47 <SteveH> +1 if I wasn't willing to read it, I wouldn't support it being a feature

Steve Harris: +1 if I wasn't willing to read it, I wouldn't support it being a feature

16:53:00 <LeeF> q?

Lee Feigenbaum: q?

16:53:01 <kasei> LeeF: also, other source of feedback. imagine that there will be non-trivial feedback re: entialment from outside the WG

Lee Feigenbaum: also, other source of feedback. imagine that there will be non-trivial feedback re: entialment from outside the WG

16:53:22 <kendall> steveh, thanks for saying that :)

Kendall Clark: steveh, thanks for saying that :)

16:55:17 <kasei> LeeF: asked everyone to look at current feature proposal to see if we're near consensus

Lee Feigenbaum: asked everyone to look at current feature proposal to see if we're near consensus

16:55:44 <KjetilK> q+

Kjetil Kjernsmo: q+

16:55:48 <kasei> AndyS: from pov of writing the charter, wondering if its as clear as we can make it

Andy Seaborne: from pov of writing the charter, wondering if its as clear as we can make it

16:56:03 <kasei> ... established that there is quite a bit of connection between some features

... established that there is quite a bit of connection between some features

16:56:31 <kasei> ... (subqueries, aggregation, proj. exprs.)

... (subqueries, aggregation, proj. exprs.)

16:58:28 <kasei> LeeF: won't hash out charter text, but will need to be explicit abotu what will be in charter

Lee Feigenbaum: won't hash out charter text, but will need to be explicit abotu what will be in charter

16:59:44 <kasei> ... relatively happy with current list

... relatively happy with current list

17:01:05 <kasei> pgearon: happy, but note we haven't discussed update yet.

Paul Gearon: happy, but note we haven't discussed update yet.

17:01:12 <AndyS> +1 -- update is underdiscussed

Andy Seaborne: +1 -- update is underdiscussed

17:02:05 <kasei> SteveH: ambitious, but can't think of anything to remove

Steve Harris: ambitious, but can't think of anything to remove

17:02:45 <kasei> AndyS: ambitious, but don't think it will push out all time-permitting features. also notes lack of update discussion.

Andy Seaborne: ambitious, but don't think it will push out all time-permitting features. also notes lack of update discussion.

17:03:18 <kasei> ... re: BasicFederatedQuery, would spend time working on it

... re: BasicFederatedQuery, would spend time working on it

17:04:16 <kasei> KjetilK: too bad full text didn't reach consensus (would like a vote as a time-permitting feature)

Kjetil Kjernsmo: too bad full text didn't reach consensus (would like a vote as a time-permitting feature)

17:04:17 <KjetilK> Specify a simple, optional freetext query syntax and semantics.

Kjetil Kjernsmo: Specify a simple, optional freetext query syntax and semantics.

17:04:18 <kendall> update being underdiscussed, particularly w/r/t security implications, worries me

Kendall Clark: update being underdiscussed, particularly w/r/t security implications, worries me

17:04:29 <SteveH> +1 to kendall

Steve Harris: +1 to kendall

17:04:42 <KjetilK> +1

Kjetil Kjernsmo: +1

17:04:44 <kasei> LeeF: poll on (possibly simple) full text feature

Lee Feigenbaum: poll on (possibly simple) full text feature

17:04:45 <pgearon> +1

Paul Gearon: +1

17:04:48 <AlexPassant> 0

Alex Passant: 0

17:04:49 <LukeWM> 0

Luke Wilson-Mawer: 0

17:04:50 <kasei> 0

0

17:04:52 <SimonS> +1

Simon Schenk: +1

17:04:53 <AxelPolleres> 0

Axel Polleres: 0

17:04:53 <SteveH> -1 too complex

Steve Harris: -1 too complex

17:04:53 <bglimm> 0

Birte Glimm: 0

17:04:58 <john-l> +1

John Clark: +1

17:04:58 <ericP> -1

Eric Prud'hommeaux: -1

17:05:01 <kendall> -1

Kendall Clark: -1

17:05:07 <AndyS> +1 only as far as syntax,  -1 for spec results or text QL

Andy Seaborne: +1 only as far as syntax, -1 for spec results or text QL

17:05:18 <SteveH> kendall, day 2 has a slot on update, FWIW, but I share your concerns

Steve Harris: kendall, day 2 has a slot on update, FWIW, but I share your concerns

17:05:49 <LeeF> 0

Lee Feigenbaum: 0

17:06:17 <kendall> can't shake the thought of sparql injection attacks (and hard to see how we can implement, over http, the standard defense)

Kendall Clark: can't shake the thought of sparql injection attacks (and hard to see how we can implement, over http, the standard defense)

17:06:22 <kasei> ... based on previous criteria, doesn't seem to be enough consensus.

... based on previous criteria, doesn't seem to be enough consensus.

17:06:57 <AndyS> kendall, agreed - one reson I prefer 2 languages, not one mega language of QL+U

Andy Seaborne: kendall, agreed - one reson I prefer 2 languages, not one mega language of QL+U

17:07:12 <pgearon> kendall, I share you concerns. OTOH, the most consistent complaint I hear about SPARQL is the lack of Update

Paul Gearon: kendall, I share you concerns. OTOH, the most consistent complaint I hear about SPARQL is the lack of Update

17:07:13 <kasei> KjetilK: lack of consensus is clear. don't need to spend more time on it.

Kjetil Kjernsmo: lack of consensus is clear. don't need to spend more time on it.

17:07:32 <kendall> but it doesn't have to be in the language

Kendall Clark: but it doesn't have to be in the language

17:07:37 <kendall> it could be in the protocol

Kendall Clark: it could be in the protocol

17:07:46 <kendall> or, as andy says, in something entirely separate

Kendall Clark: or, as andy says, in something entirely separate

17:07:57 <kendall> (those may be isomorphic, in which case i don't care which)

Kendall Clark: (those may be isomorphic, in which case i don't care which)

17:08:36 <kasei> ... possible to have something about DefaultDescribeResults in a note?

... possible to have something about DefaultDescribeResults in a note?

17:09:09 <AndyS> q+

Andy Seaborne: q+

17:09:15 <kasei> LeeF: would be willing to consider it, but don't want to publish a note that hasn't had enough WG review.

Lee Feigenbaum: would be willing to consider it, but don't want to publish a note that hasn't had enough WG review.

17:09:45 <kasei> AndyS: member submission would be a good route

Andy Seaborne: member submission would be a good route

17:09:50 <AndyS> ack me

Andy Seaborne: ack me

17:09:58 <LeeF> ack KjetilK

Lee Feigenbaum: ack KjetilK

17:09:58 <KjetilK> ack me

Kjetil Kjernsmo: ack me

17:10:42 <kasei> AlexP: ok with required. for time-permittion, priority would be entailment extensions.

Alex Passant: ok with required. for time-permittion, priority would be entailment extensions.

17:11:17 <kasei> SimonS: ambitious, but ok. if only time to do one time-permittion, want federated query.

Simon Schenk: ambitious, but ok. if only time to do one time-permittion, want federated query.

17:11:41 <kendall> KjetilK: as long as we're all a little bit unhappy in roughly the same measure, then that's how we know we're making standards! :>

Kjetil Kjernsmo: as long as we're all a little bit unhappy in roughly the same measure, then that's how we know we're making standards! :> [ Scribe Assist by Kendall Clark ]

17:12:09 <kasei> bglimm: fine with the list. priority features is entailment.

Birte Glimm: fine with the list. priority features is entailment.

17:12:28 <KjetilK> q+ to ask if we are in the same situation with FunctionLibrary as SurfaceSyntax with regards to IPR

Kjetil Kjernsmo: q+ to ask if we are in the same situation with FunctionLibrary as SurfaceSyntax with regards to IPR

17:12:53 <kasei> AxelPolleres: didn't talk much about function library. should we spend more time discussing?

Axel Polleres: didn't talk much about function library. should we spend more time discussing?

17:13:37 <kasei> AndyS: nervous about things like restricting to xpath functions.

Andy Seaborne: nervous about things like restricting to xpath functions.

17:14:13 <kasei> AxelPolleres: should we scope to looking into only certain functions?

Axel Polleres: should we scope to looking into only certain functions?

17:14:23 <kasei> AndyS: no

Andy Seaborne: no

17:14:37 <LeeF> "Common functions dealing with core SPARQL types including IRIs, literals, numbers, and strings" ?

Lee Feigenbaum: "Common functions dealing with core SPARQL types including IRIs, literals, numbers, and strings" ?

17:15:17 <kasei> Kjetil: if we leave it unscoped, would that be problematic for the charter?

Kjetil Kjernsmo: if we leave it unscoped, would that be problematic for the charter?

17:15:46 <AndyS> q+

Andy Seaborne: q+

17:15:52 <LeeF> ack KjetilK

Lee Feigenbaum: ack KjetilK

17:15:52 <Zakim> KjetilK, you wanted to ask if we are in the same situation with FunctionLibrary as SurfaceSyntax with regards to IPR

Zakim IRC Bot: KjetilK, you wanted to ask if we are in the same situation with FunctionLibrary as SurfaceSyntax with regards to IPR

17:16:03 <kasei> ericP: would make it challenging for IP issues.

Eric Prud'hommeaux: would make it challenging for IP issues.

17:16:40 <AxelPolleres> XPath + RIF DTB (has iri-string conversion which can be used for iri construction)

Axel Polleres: XPath + RIF DTB (has iri-string conversion which can be used for iri construction)

17:17:26 <kasei> ... motivation to make it easy for new groups to join the WG.

... motivation to make it easy for new groups to join the WG.

17:17:57 <AxelPolleres> ISSUE: scope of functions to be clarified further for the charter

ISSUE: scope of functions to be clarified further for the charter

17:17:58 <trackbot> Created ISSUE-2 - Scope of functions to be clarified further for the charter ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/2/edit .

Trackbot IRC Bot: Created ISSUE-2 - Scope of functions to be clarified further for the charter ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/2/edit .

17:18:47 <AxelPolleres> s/functions/function library/

Axel Polleres: s/functions/function library/

17:18:48 <kasei> LeeF: punt on IP issues until writing charter

Lee Feigenbaum: punt on IP issues until writing charter

17:19:16 <LeeF> chimezie, are you around?

Lee Feigenbaum: chimezie, are you around?

17:19:20 <LeeF> john-l, are you around?

Lee Feigenbaum: john-l, are you around?

17:19:31 <chimezie> I'm here, on IRC at least

Chime Ogbuji: I'm here, on IRC at least

17:19:57 <LeeF> chimezie, are you happy (enough) with the proposal for WG features as it currently exists at http://www.w3.org/2009/sparql/wiki/FeatureProposal ?

Lee Feigenbaum: chimezie, are you happy (enough) with the proposal for WG features as it currently exists at http://www.w3.org/2009/sparql/wiki/FeatureProposal ?

17:20:57 <LeeF> PROPOSED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein

PROPOSED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein

17:21:13 <chimezie> It doesn't include BNode reference (which is important for us), but time-constraints , etc..

Chime Ogbuji: It doesn't include BNode reference (which is important for us), but time-constraints , etc..

17:21:26 <SteveH> seconded

Steve Harris: seconded

17:21:31 <AxelPolleres> +1

Axel Polleres: +1

17:21:33 <chimezie> So, yes, looks good  :)

Chime Ogbuji: So, yes, looks good :)

17:21:33 <ericP> +1

Eric Prud'hommeaux: +1

17:21:37 <KjetilK> threeonded

Kjetil Kjernsmo: threeonded

17:21:37 <LeeF> thanks, chimezie

Lee Feigenbaum: thanks, chimezie

17:22:05 <bglimm> Leef, you could call OWL Flavors, OWL Profiles since this is what they are called in the OWL standard

Birte Glimm: Leef, you could call OWL Flavors, OWL Profiles since this is what they are called in the OWL standard

17:22:05 <bijan> +1 (before going home)

Bijan Parsia: +1 (before going home)

17:22:13 <pgearon> +1

Paul Gearon: +1

17:22:52 <bglimm> +1

Birte Glimm: +1

17:23:03 <kasei> LeeF: does anyone abstain or object to propsal?

Lee Feigenbaum: does anyone abstain or object to propsal?

17:23:05 <AndyS> +1

Andy Seaborne: +1

17:23:09 <SimonS> +1

Simon Schenk: +1

17:23:10 <LeeF> RESOLVED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein

RESOLVED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein

17:23:15 <LeeF> No abstentions or objections

Lee Feigenbaum: No abstentions or objections

<LeeF> topic: Features & Rationale document

3. Features & Rationale document

Summary: Aim for first draft of http://www.w3.org/2009/sparql/docs/features/ at end of first week of June

<LeeF> summary: Aim for first draft of http://www.w3.org/2009/sparql/docs/features/ at end of first week of June
17:24:05 <kasei> LeeF: want to give time to KjetilK and Alex re: rationale document

Lee Feigenbaum: want to give time to KjetilK and Alex re: rationale document

17:24:30 <AlexPassant> Features doc currently at: http://www.w3.org/2009/sparql/docs/features/

Alex Passant: Features doc currently at: http://www.w3.org/2009/sparql/docs/features/

17:24:58 <kasei> KjetilK: start puting down description of features on wiki

Kjetil Kjernsmo: start puting down description of features on wiki

17:25:28 <kasei> ... will use wiki for collab. environment. at some point will freeze page and put into a more formal document.

... will use wiki for collab. environment. at some point will freeze page and put into a more formal document.

17:26:05 <AndyS> q+

Andy Seaborne: q+

17:26:17 <kasei> AlexP: for each feature: motivation, description, proposed syntax, discussion

Alex Passant: for each feature: motivation, description, proposed syntax, discussion

17:26:42 <kasei> Steve: we aren't chartered to discuss syntax (?)

Steve Harris: we aren't chartered to discuss syntax (?)

17:27:06 <kasei> LeeF: intention is to do a more involved document later on. question  is whether to discuss any syntax now.

Lee Feigenbaum: intention is to do a more involved document later on. question is whether to discuss any syntax now.

17:27:32 <kasei> KjetilK: examples are important. useful, but maybe should be "examples" not "proposed syntax"

Kjetil Kjernsmo: examples are important. useful, but maybe should be "examples" not "proposed syntax"

17:27:40 <LeeF> +1 to Andy - examples only based on existing implementations is a good idea

Lee Feigenbaum: +1 to Andy - examples only based on existing implementations is a good idea

17:27:50 <kasei> AndyS: must be existing implementations, not just "examples".

Andy Seaborne: must be existing implementations, not just "examples".

17:28:12 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS

17:28:48 <kasei> ... would help to ask for particular things needed for the document. lots of existing wiki content.

... would help to ask for particular things needed for the document. lots of existing wiki content.

17:30:02 <kasei> KjetilK: descriptions might belong before motivations.

Kjetil Kjernsmo: descriptions might belong before motivations.

17:31:00 <kasei> LeeF: next issue - naming.

Lee Feigenbaum: next issue - naming.

17:31:29 <SimonS> SPARQL 2010

Simon Schenk: SPARQL 2010

17:31:30 <kasei> ... "2.0" and "1.1". are there others?

... "2.0" and "1.1". are there others?

17:31:54 <kasei> ... update may have another name, but what name for the core language?

... update may have another name, but what name for the core language?

17:32:09 <SteveH> also federated might have a different name...

Steve Harris: also federated might have a different name...

17:32:55 <AxelPolleres> Axel: getting back to F+R Schedule

Axel Polleres: getting back to F+R Schedule [ Scribe Assist by Axel Polleres ]

17:33:04 <kasei> ... would be great to have something in 4 weeks.

... would be great to have something in 4 weeks.

17:33:11 <AxelPolleres> LeeF: reasonable within 4 weeks?

Lee Feigenbaum: reasonable within 4 weeks? [ Scribe Assist by Axel Polleres ]

17:33:31 <AxelPolleres> Kjetil&Alex agree.

Axel Polleres: Kjetil&Alex agree.

17:33:45 <AlexPassant> +1 first week of june

Alex Passant: +1 first week of june

17:34:11 <kasei> KjetilK: have one day a week. telecon + editing document.

Kjetil Kjernsmo: have one day a week. telecon + editing document.

17:34:40 <kasei> Alex: 1 day a week.

Alex Passant: 1 day a week.

17:35:39 <kasei> LeeF: first draft doesn't need to be huge. touch on everything, but can then hear from the WG and from outside.

Lee Feigenbaum: first draft doesn't need to be huge. touch on everything, but can then hear from the WG and from outside.

17:36:32 <kasei> AxelPolleres: don't have to write it all yourselves. ask for content, can discuss on telecon.

Axel Polleres: don't have to write it all yourselves. ask for content, can discuss on telecon.

<LeeF> topic: Naming and Modularity

4. Naming and Modularity

Summary: RESOLVED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others and RESOLVED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

<LeeF> summary: RESOLVED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others and RESOLVED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0
17:36:52 <kasei> LeeF: back to naming. what do people prefer?

Lee Feigenbaum: back to naming. what do people prefer?

17:37:02 <kasei> ericP: don't care

Eric Prud'hommeaux: don't care

17:37:09 <AxelPolleres> Axel: "feature champions" should be asked for help to put concrete text, where necessary, editor doesn't imply Alex and Kjetil write all by themselves. Use the wiki!

Axel Polleres: "feature champions" should be asked for help to put concrete text, where necessary, editor doesn't imply Alex and Kjetil write all by themselves. Use the wiki! [ Scribe Assist by Axel Polleres ]

17:37:27 <kasei> pgearon: if update is in it, 2.0, otherwise 1.1.

Paul Gearon: if update is in it, 2.0, otherwise 1.1.

17:37:38 <kasei> kasei: 1.1, not strong preference.

Greg Williams: 1.1, not strong preference.

17:37:38 <AlexPassant> +1 for pgearon

Alex Passant: +1 for pgearon

17:38:06 <kasei> ericP: wondering about pgearon's opinion

Eric Prud'hommeaux: wondering about pgearon's opinion

17:38:19 <kasei> pgearon: update is a big feature. 2.0 signifies this.

Paul Gearon: update is a big feature. 2.0 signifies this.

17:38:27 <kasei> LeeF: 2.0

Lee Feigenbaum: 2.0

17:38:41 <kasei> LukeWM: don't care

Luke Wilson-Mawer: don't care

17:39:06 <kasei> SteveH: feel strongly 1.1, update should be a different language (so should federated query)

Steve Harris: feel strongly 1.1, update should be a different language (so should federated query)

17:39:24 <kendall> steveh: what marketing point do you want to make with "1.1" name?

Steve Harris: what marketing point do you want to make with "1.1" name? [ Scribe Assist by Kendall Clark ]

17:39:31 <kasei> AndyS: agrees with SteveH. had strong input about calling things 2.0 (based on OWL) -- bad idea.

Andy Seaborne: agrees with SteveH. had strong input about calling things 2.0 (based on OWL) -- bad idea.

17:39:33 <kendall> (sorry i can't dial-in, feel free to ignore me!)

Kendall Clark: (sorry i can't dial-in, feel free to ignore me!)

17:40:09 <kasei> ... keep query language 1.1, wouldn't expect compliance to involve implementing update.

... keep query language 1.1, wouldn't expect compliance to involve implementing update.

17:40:19 <kendall> AndyS: calling sparql anything based on OWL is dumb -- +1

Andy Seaborne: calling sparql anything based on OWL is dumb -- +1 [ Scribe Assist by Kendall Clark ]

17:40:21 <kasei> KjetilK: 1.1. update as seperate. SPARQL/OWL seperate.

Kjetil Kjernsmo: 1.1. update as seperate. SPARQL/OWL seperate.

17:40:50 <kasei> AlexP: 2.0 with update, otherwise 1.1.

Alex Passant: 2.0 with update, otherwise 1.1.

17:41:21 <kasei> SimonS: keep update seperate. meant "2010". even if many followup WGs, no problem.

Simon Schenk: keep update seperate. meant "2010". even if many followup WGs, no problem.

17:41:53 <kasei> bglimm: no strong opinion. probably 1.1 with update/federated separate. (2.0 if all in one.)

Birte Glimm: no strong opinion. probably 1.1 with update/federated separate. (2.0 if all in one.)

17:42:22 <SteveH> q+

Steve Harris: q+

17:42:31 <LeeF> ack SteveH

Lee Feigenbaum: ack SteveH

17:42:43 <kasei> AxelPolleres: 1.1 is good, would not keep federation separate, but update separate.

Axel Polleres: 1.1 is good, would not keep federation separate, but update separate.

17:43:14 <kasei> SteveH: update should be separate. SQL got this wrong.

Steve Harris: update should be separate. SQL got this wrong.

17:43:30 <kasei> LeeF: seems to be consensus on that. does anyone think otherwise?

Lee Feigenbaum: seems to be consensus on that. does anyone think otherwise?

17:43:50 <kendall> fwiw, i think "1.1" is a dumb name

Kendall Clark: fwiw, i think "1.1" is a dumb name

17:43:57 <john-l> Leef, you prefer 2.0?

John Clark: Leef, you prefer 2.0?

17:44:03 <LeeF> vastly

Lee Feigenbaum: vastly

17:44:04 <AxelPolleres> Axel: SPARQL 2010 and keeping all in one would be along the lines of SQL 99. I personally like SPARQL1.1 and SPARQL/Update separate.

Axel Polleres: SPARQL 2010 and keeping all in one would be along the lines of SQL 99. I personally like SPARQL1.1 and SPARQL/Update separate. [ Scribe Assist by Axel Polleres ]

17:44:15 <LeeF> i'm happy with 2010 also fwiw :)

Lee Feigenbaum: i'm happy with 2010 also fwiw :)

17:44:17 <LeeF> q+ yimin

Lee Feigenbaum: q+ yimin

17:44:20 <kasei> ericP: worries about what keeping update separate looks like.

Eric Prud'hommeaux: worries about what keeping update separate looks like.

17:44:26 <john-l> I prefer 2010.

John Clark: I prefer 2010.

17:44:47 <kendall> SPARQL 2010: The Sadistic Satyr

Kendall Clark: SPARQL 2010: The Sadistic Satyr

17:44:54 <kasei> ... issues with keeping grammar together or separate.

... issues with keeping grammar together or separate.

17:45:32 <kasei> ... trying to work out mechanics of what is meant by "separate language". one doc for query with section for update?

... trying to work out mechanics of what is meant by "separate language". one doc for query with section for update?

17:45:37 <AndyS> Much laughter over  "The Speedy Squirrel"

Andy Seaborne: Much laughter over "The Speedy Squirrel"

17:45:47 <kasei> ... second document with only additions to grammar?

... second document with only additions to grammar?

17:46:26 <kasei> ... care about distinction between sparql and update with protocol and also branding on products.

... care about distinction between sparql and update with protocol and also branding on products.

17:47:10 <kasei> SteveH: imagining two langs would share grammar. core sparql would error if you tried to use update.

Steve Harris: imagining two langs would share grammar. core sparql would error if you tried to use update.

17:48:05 <AndyS> q+

Andy Seaborne: q+

17:48:12 <kasei> pgearon: was also expecting update to be a strict superset. insert-select, delete-select use the select we've already got.

Paul Gearon: was also expecting update to be a strict superset. insert-select, delete-select use the select we've already got.

17:48:44 <AndyS> ack me

Andy Seaborne: ack me

17:48:46 <LeeF> ack yimin

Lee Feigenbaum: ack yimin

17:49:15 <kasei> yimin:  expereince with users having trouble with many different varieties of OWL (DL, ...). trouble differentiating.

Yimin Wang: expereince with users having trouble with many different varieties of OWL (DL, ...). trouble differentiating.

17:49:54 <kasei> ... consideration for ease of users. would like to have update in the same language.

... consideration for ease of users. would like to have update in the same language.

17:50:02 <kendall> (what users are these? i don't recognize 'yimin')

Kendall Clark: (what users are these? i don't recognize 'yimin')

17:50:20 <kendall> AH

Kendall Clark: AH

17:50:22 <pgearon> +q

Paul Gearon: +q

17:50:22 <kendall> thanks, LeeF

Kendall Clark: thanks, LeeF

17:50:30 <kasei> ericP: SQL has sublanguages, but users don't think of them.

Eric Prud'hommeaux: SQL has sublanguages, but users don't think of them.

17:50:39 <LeeF> ack pgearon

Lee Feigenbaum: ack pgearon

17:50:41 <kendall> I think that's a pretty awfula analogy

Kendall Clark: I think that's a pretty awfula analogy

17:50:56 <ericP> thank you

Eric Prud'hommeaux: thank you

17:51:23 <kasei> pgearon: if we didn't split the language into parts, select can't go through the http protocol with http GET.

Paul Gearon: if we didn't split the language into parts, select can't go through the http protocol with http GET.

17:51:35 <AndyS> I like "SPARQL" as the overall name and SPARQL/(sub-part)

Andy Seaborne: I like "SPARQL" as the overall name and SPARQL/(sub-part)

17:51:51 <kasei> ... delete-select through "PUT"? would be nice through "DELETE", but tricky to resolve proper http methods.

... delete-select through "PUT"? would be nice through "DELETE", but tricky to resolve proper http methods.

17:52:10 <kendall> (i'm always amazed people deploy real systems where "users" are expected to write SPARQL by hand. This is cruel and unusual punishment!)

Kendall Clark: (i'm always amazed people deploy real systems where "users" are expected to write SPARQL by hand. This is cruel and unusual punishment!)

17:53:15 <AxelPolleres> (kendall, people write a lot of SQL, don't they?)

Axel Polleres: (kendall, people write a lot of SQL, don't they?)

17:53:19 <kasei> ... can't put insert, delete through GET. need alignment with protocol. update touches on many things, frustrating that it's last on the schedule.

... can't put insert, delete through GET. need alignment with protocol. update touches on many things, frustrating that it's last on the schedule.

17:53:56 <kendall> Axel: no, they don't

Axel Polleres: no, they don't [ Scribe Assist by Kendall Clark ]

17:54:04 <kendall> programmers don't even write that much SQL these days

Kendall Clark: programmers don't even write that much SQL these days

17:54:33 <SteveH> I like Andy's proposal

Steve Harris: I like Andy's proposal

17:54:41 <kasei> AxelPolleres: no particular preference.

Axel Polleres: no particular preference.

17:55:13 <AndyS> (was not my proposal - I just liked it)

Andy Seaborne: (was not my proposal - I just liked it)

17:55:21 <kasei> SteveH: branding "SPARQL/Query", "SPARQL/Update", ...

Steve Harris: branding "SPARQL/Query", "SPARQL/Update", ...

17:55:29 <kendall> +1

Kendall Clark: +1

17:55:32 <kasei> LeeF: do we need a specific name for the work this WG is doing?

Lee Feigenbaum: do we need a specific name for the work this WG is doing?

17:55:51 <AxelPolleres> SteveH: SPARQL = SPARQL/Query SPARQL/Update

Steve Harris: SPARQL = SPARQL/Query SPARQL/Update [ Scribe Assist by Axel Polleres ]

17:56:33 <AndyS> http://www.w3.org/SPARQL/1.1

Andy Seaborne: http://www.w3.org/SPARQL/1.1

17:56:45 <LeeF> PROPOSED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others

PROPOSED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others

17:56:49 <SteveH> http://www.w3.org/SPARQL/Query/1.1 surely

Steve Harris: http://www.w3.org/SPARQL/Query/1.1 surely

17:56:58 <KjetilK> SPARQL 1.1 = SPARQL/Query 1.1  SPARQL/Update 1.0 etc

Kjetil Kjernsmo: SPARQL 1.1 = SPARQL/Query 1.1 SPARQL/Update 1.0 etc

17:57:08 <ericP> +1 to megillah (SP?) proposal

Eric Prud'hommeaux: +1 to megillah (SP?) proposal

17:57:12 <kendall> SPARQL/Inference (We can hope!!)

Kendall Clark: SPARQL/Inference (We can hope!!)

17:57:57 <SteveH> isn't this WG a megillah?

Steve Harris: isn't this WG a megillah?

17:57:58 <AxelPolleres> rdf-sparql-query11/ , rdf-sparql-update/ rdf-sparql-entailments/, rdf-sparql-protocol11/

Axel Polleres: rdf-sparql-query11/ , rdf-sparql-update/ rdf-sparql-entailments/, rdf-sparql-protocol11/

17:58:07 <AndyS> .g seems to agree on spelling

Andy Seaborne: .g seems to agree on spelling

17:58:15 <SteveH> federated also

Steve Harris: federated also

17:58:20 <KjetilK> +1

Kjetil Kjernsmo: +1

17:58:20 <AndyS> +1

Andy Seaborne: +1

17:58:23 <LeeF> RESOLVED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others

RESOLVED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others

17:58:29 <SteveH> +1, as long as federated is seperate

Steve Harris: +1, as long as federated is seperate

17:58:40 <AxelPolleres> +1

Axel Polleres: +1

17:58:55 <bglimm> +1

Birte Glimm: +1

17:59:10 <kasei> ericP: tempted not to number overall SPARQL.

Eric Prud'hommeaux: tempted not to number overall SPARQL.

17:59:11 <AndyS> Are we using Apache Ivy to import all the docs?

Andy Seaborne: Are we using Apache Ivy to import all the docs?

17:59:21 <kendall> +[1.1,2.0]

Kendall Clark: +[1.1,2.0]

17:59:26 <kendall> hah

Kendall Clark: hah

17:59:32 <kasei> LeeF: no number for everything, numbered components (update, query)

Lee Feigenbaum: no number for everything, numbered components (update, query)

17:59:46 <LeeF> PROPOSED: The version of SPARQL query lanaguage worked on by this working group is called SPARQL/Query 1.1

PROPOSED: The version of SPARQL query lanaguage worked on by this working group is called SPARQL/Query 1.1

18:00:00 <ericP> i second

Eric Prud'hommeaux: i second

18:00:02 <AndyS> +i

Andy Seaborne: +i

18:00:05 <KjetilK> +1

Kjetil Kjernsmo: +1

18:00:10 <kendall> why the 1.1 bit?

Kendall Clark: why the 1.1 bit?

18:00:10 <pgearon> +1

Paul Gearon: +1

18:00:26 <LeeF> PROPOSED: The version of SPARQL query lanaguage worked on by this working group are called SPARQL/Query 1.1 and SPARQL/Update 1.0

PROPOSED: The version of SPARQL query lanaguage worked on by this working group are called SPARQL/Query 1.1 and SPARQL/Update 1.0

18:00:30 <kendall> previous version "SPARQL", this version "SPARQL/Query"

Kendall Clark: previous version "SPARQL", this version "SPARQL/Query"

18:00:34 <ericP> i second

Eric Prud'hommeaux: i second

18:00:35 <SteveH> what about federated

Steve Harris: what about federated

18:01:25 <LeeF> PROPOSED: The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

PROPOSED: The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

18:01:33 <ericP> i object

Eric Prud'hommeaux: i object

18:02:59 <kasei> ericP: regarding "safety" of implementation. safety means datastore isn't updated. doesn't execute remote queries.

Eric Prud'hommeaux: regarding "safety" of implementation. safety means datastore isn't updated. doesn't execute remote queries.

18:03:37 <kasei> SteveH: importantly, doesn't make any GET requests. current standard doesn't force you to GET on a FROM<...>.

Steve Harris: importantly, doesn't make any GET requests. current standard doesn't force you to GET on a FROM<...>.

18:03:56 <kasei> ... no network requests from the endpoint.

... no network requests from the endpoint.

18:03:59 <AndyS> q+

Andy Seaborne: q+

18:04:26 <kasei> ... concern is around admins installing software and not having to worry about the server making requests.

... concern is around admins installing software and not having to worry about the server making requests.

18:04:59 <kasei> ericP: wouldn't that mean addressing FROM?

Eric Prud'hommeaux: wouldn't that mean addressing FROM?

18:05:23 <kasei> SteveH: ideally, yes. but there are many stores that don't GET on a FROM.

Steve Harris: ideally, yes. but there are many stores that don't GET on a FROM.

18:06:10 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS

18:06:10 <kasei> ... want to implemented federated sparql, but also want to have a public endpoint that doesn't do that.

... want to implemented federated sparql, but also want to have a public endpoint that doesn't do that.

18:06:25 <kasei> AndyS: difference between what is in the spec and what compliance with the spec is.

Andy Seaborne: difference between what is in the spec and what compliance with the spec is.

18:06:40 <kasei> ... "if you implement feature X, this is what occurs"

... "if you implement feature X, this is what occurs"

18:07:55 <kasei> ericP: so you are seeking alignment between the branding name and the security policies?

Eric Prud'hommeaux: so you are seeking alignment between the branding name and the security policies?

18:08:36 <KjetilK> +q to say that we need a version number for the megillah to distinguish it from the previous version?

Kjetil Kjernsmo: +q to say that we need a version number for the megillah to distinguish it from the previous version?

18:08:48 <kasei> SteveH: bet there are plenty of people who deploy SPARQL servers without realizing the implications

Steve Harris: bet there are plenty of people who deploy SPARQL servers without realizing the implications

18:09:51 <AndyS> How about writing specific text in the future docs that says "This set of featurs is safe" +details

Andy Seaborne: How about writing specific text in the future docs that says "This set of featurs is safe" +details

18:09:52 <kasei> ericP: if we have an identifier for a "safe" version of SPARQL, should address "FROM" at the same time.

Eric Prud'hommeaux: if we have an identifier for a "safe" version of SPARQL, should address "FROM" at the same time.

18:10:45 <kasei> ... should safety be deeper than the branding name, with saddle and configuration options?

... should safety be deeper than the branding name, with saddle and configuration options?

18:11:35 <kasei> ... if we identify network safe operations, people can implement/use the safe version.

... if we identify network safe operations, people can implement/use the safe version.

18:11:51 <SimonS> +1 to AndyS' proposal of marking safe features

Simon Schenk: +1 to AndyS' proposal of marking safe features

18:12:10 <kasei> SteveH: that you have to explicitly ban those features is a security problem.

Steve Harris: that you have to explicitly ban those features is a security problem.

18:13:03 <kasei> ericP: suggest SteveH lobby for text that deals with safe operations, a "SPARQL/Safe" name.

Eric Prud'hommeaux: suggest SteveH lobby for text that deals with safe operations, a "SPARQL/Safe" name.

18:13:32 <LeeF> SPARQL/DangerDangerDanger

Lee Feigenbaum: SPARQL/DangerDangerDanger

18:13:58 <AxelPolleres> would it make sense to define an "endpoint set" similar to "dataset"? would that help?

Axel Polleres: would it make sense to define an "endpoint set" similar to "dataset"? would that help?

18:13:59 <kasei> ... what you want requires such detail that we can't address it now.

... what you want requires such detail that we can't address it now.

18:14:06 <KjetilK> +1 to not rule it out

Kjetil Kjernsmo: +1 to not rule it out

18:14:14 <LeeF> q?

Lee Feigenbaum: q?

18:14:27 <LeeF> PROPOSED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

PROPOSED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

18:14:50 <AxelPolleres> ... and systems have freedom how to treat that as they are free to fix the dataset.

Axel Polleres: ... and systems have freedom how to treat that as they are free to fix the dataset.

18:15:22 <AndyS>  Suggest: This WG acknowledges that there are security issues in federated query and the WG will continue to be careful about this.

Andy Seaborne: Suggest: This WG acknowledges that there are security issues in federated query and the WG will continue to be careful about this.

18:15:41 <KjetilK> +1

Kjetil Kjernsmo: +1

18:15:49 <kasei> LeeF: any abstentions or objections?

Lee Feigenbaum: any abstentions or objections?

18:15:49 <pgearon> +1

Paul Gearon: +1

18:15:52 <AxelPolleres> +1

Axel Polleres: +1

18:15:52 <LeeF> RESOLVED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

RESOLVED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

18:16:02 <SteveH> can we have an issue along the lines of what AndyS wrote

Steve Harris: can we have an issue along the lines of what AndyS wrote

18:16:03 <KjetilK> ack me

Kjetil Kjernsmo: ack me

18:16:03 <Zakim> KjetilK, you wanted to say that we need a version number for the megillah to distinguish it from the previous version?

Zakim IRC Bot: KjetilK, you wanted to say that we need a version number for the megillah to distinguish it from the previous version?

18:16:06 <bglimm> +1

Birte Glimm: +1

18:16:52 <kasei> KjetilK: what should title of features document be?

Kjetil Kjernsmo: what should title of features document be?

18:17:34 <kasei> ... "yeah, I'm happy"

... "yeah, I'm happy"

18:18:45 <ericP> topic: response to rdf:text

5. response to rdf:text

Summary: RESOLVED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

<LeeF> summary: RESOLVED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call
18:18:30 <kasei> LeeF: next up, response to rdf:text

Lee Feigenbaum: next up, response to rdf:text

18:18:41 <kasei> ... tomorrow dive into features

... tomorrow dive into features

18:19:09 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/rdf_text_LC_WG_comment

Axel Polleres: http://www.w3.org/2009/sparql/wiki/rdf_text_LC_WG_comment

18:19:30 <AxelPolleres> http://www.w3.org/TR/rdf-text/

Axel Polleres: http://www.w3.org/TR/rdf-text/

18:19:37 <kasei> AxelPolleres: current response, based on comments by AndyS.

Axel Polleres: current response, based on comments by AndyS.

18:19:48 <kasei> ... interop problems with SPARQL.

... interop problems with SPARQL.

18:20:45 <kasei> ... rdf:text a datatype for plain/lang literals useful for OWL/RIF.

... rdf:text a datatype for plain/lang literals useful for OWL/RIF.

18:21:12 <kasei> ... with current defintion, too strong regarding semantic equivalence literals

... with current defintion, too strong regarding semantic equivalence literals

18:22:10 <kasei> ... document proposes rdf graph serializations do not use rdf:text. AndyS observed also affects SPARQL.

... document proposes rdf graph serializations do not use rdf:text. AndyS observed also affects SPARQL.

18:22:34 <kasei> ... str/datatype/lang functions would also be affected

... str/datatype/lang functions would also be affected

18:23:19 <kasei> ... point out problems with rdf:text. suggest to editors to add section mentioning interop issues with sparql.

... point out problems with rdf:text. suggest to editors to add section mentioning interop issues with sparql.

18:23:52 <kasei> ... suggest clarify interactions with sparql.

... suggest clarify interactions with sparql.

18:24:12 <kasei> ... rdf:text should affect D-entailment

... rdf:text should affect D-entailment

18:24:22 <ericP> q+ to check a use case

Eric Prud'hommeaux: q+ to check a use case

18:24:50 <kasei> LeeF: if not using D-entailment, datatype() would return rdf:text, no lang(), ...

Lee Feigenbaum: if not using D-entailment, datatype() would return rdf:text, no lang(), ...

18:25:15 <kasei> AxelPolleres: with D-entailment, rdf:text literals would entail the non-dt literal

Axel Polleres: with D-entailment, rdf:text literals would entail the non-dt literal

18:25:21 <ericP> q-

Eric Prud'hommeaux: q-

18:25:36 <kasei> AndyS: no such thing as D-entailment. class of entailments.

Andy Seaborne: no such thing as D-entailment. class of entailments.

18:25:39 <LeeF> q+ to ask about if rdf:text literals are allowed in SPARQL queries and if so what they mean when

Lee Feigenbaum: q+ to ask about if rdf:text literals are allowed in SPARQL queries and if so what they mean when

18:25:54 <SteveH> q+ to ask meta-question

Steve Harris: q+ to ask meta-question

18:27:11 <kasei> ... literals have lang or dt, not both. code relies on this.

... literals have lang or dt, not both. code relies on this.

18:27:47 <kasei> AxelPolleres: want to say rdf:text is only syntactic.

Axel Polleres: want to say rdf:text is only syntactic.

18:28:20 <kasei> AndyS: you've introduced a new problem. haven't heard answers to previously brought up problems

Andy Seaborne: you've introduced a new problem. haven't heard answers to previously brought up problems

18:30:33 <kasei> AxelPolleres: if your data doesn't have rdf:text in it, you won't get it out of the functions.

Axel Polleres: if your data doesn't have rdf:text in it, you won't get it out of the functions.

18:30:55 <bglimm> q+

Birte Glimm: q+

18:31:45 <kasei> AndyS: i can't sort out based on the current spec what a sparql processor should do

Andy Seaborne: i can't sort out based on the current spec what a sparql processor should do

18:32:08 <kasei> LeeF: I keep thinking of rdf:text nodes int he graph

Lee Feigenbaum: I keep thinking of rdf:text nodes int he graph

18:32:56 <kasei> ... would you need to prohibit literal constants in queries that are typed as rdf:text?

... would you need to prohibit literal constants in queries that are typed as rdf:text?

18:32:56 <LeeF> FILTER(lang("foo@en"^^rdf:text))

Lee Feigenbaum: FILTER(lang("foo@en"^^rdf:text))

18:33:30 <LeeF> INSERT { <a> <b> "foo@en"^^rdf:text } ...

Lee Feigenbaum: INSERT { <a> <b> "foo@en"^^rdf:text } ...

18:33:36 <kasei> ericP: no reason somebody would assert such a query in RDF right now

Eric Prud'hommeaux: no reason somebody would assert such a query in RDF right now

18:34:02 <kasei> ... we can ignore it if there's no use case for writing some literal has datatype rdf:text.

... we can ignore it if there's no use case for writing some literal has datatype rdf:text.

18:34:55 <bglimm> q-

Birte Glimm: q-

18:35:13 <LeeF> ack me

Lee Feigenbaum: ack me

18:35:13 <Zakim> LeeF, you wanted to ask about if rdf:text literals are allowed in SPARQL queries and if so what they mean when

Zakim IRC Bot: LeeF, you wanted to ask about if rdf:text literals are allowed in SPARQL queries and if so what they mean when

18:35:28 <kasei> AndyS: need to give guidance for tools that generate this (data, queries?)

Andy Seaborne: need to give guidance for tools that generate this (data, queries?)

18:36:28 <kasei> ... it's legal and generates confusion.

... it's legal and generates confusion.

18:36:43 <kasei> ... rdf:text doc doesn't make it clear what to do.

... rdf:text doc doesn't make it clear what to do.

18:36:52 <kasei> ... suggestions is to have a section for sparql issues.

... suggestions is to have a section for sparql issues.

18:37:13 <kasei> ericP: shouldn't be a "sparql" section

Eric Prud'hommeaux: shouldn't be a "sparql" section

18:38:32 <kasei> ... what you can learn from SPARQL you can also find through a graph api

... what you can learn from SPARQL you can also find through a graph api

18:39:19 <kasei> AndyS: if you turned it into an RDF graph, you wouldn't see rdf:text

Andy Seaborne: if you turned it into an RDF graph, you wouldn't see rdf:text

18:40:08 <kasei> ericP: what behaviour for an owl restriction for things with rdf:text datatype. does it have any members?

Eric Prud'hommeaux: what behaviour for an owl restriction for things with rdf:text datatype. does it have any members?

18:40:58 <kasei> AndyS: half the text in the spec tries to stop you from doing that.

Andy Seaborne: half the text in the spec tries to stop you from doing that.

18:41:39 <kasei> ... not a sparql-specific issue.

... not a sparql-specific issue.

18:42:12 <kasei> ... other than new issues, where are we on current text?

... other than new issues, where are we on current text?

18:42:36 <kasei> AxelPolleres: would not require a new section

Axel Polleres: would not require a new section

18:43:43 <kasei> AndyS: removing the discussion of codepoints would be a good start

Andy Seaborne: removing the discussion of codepoints would be a good start

18:44:24 <AxelPolleres> EricP, are you talking about http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#IRIs_vs._URIs now?

Axel Polleres: EricP, are you talking about http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#IRIs_vs._URIs now?

18:44:49 <kasei> ericP: sparql went with IRI for allowable values. would like discussion on iri vs. uris.

Eric Prud'hommeaux: sparql went with IRI for allowable values. would like discussion on iri vs. uris.

18:45:09 <kasei> ... sparql made decision on intent of rdf core

... sparql made decision on intent of rdf core

18:45:53 <kasei> ... allowing iri resources (kanji, arabic in urls, etc.)

... allowing iri resources (kanji, arabic in urls, etc.)

18:46:10 <kasei> ... draw text from sparql spec

... draw text from sparql spec

18:46:22 <AndyS> q?

Andy Seaborne: q?

18:46:35 <kasei> AxelPolleres: would like concrete suggestion

Axel Polleres: would like concrete suggestion

18:46:42 <ericP> http://www.w3.org/TR/rdf-sparql-query/#docTerminology

Eric Prud'hommeaux: http://www.w3.org/TR/rdf-sparql-query/#docTerminology

18:47:20 <ericP> \http://www.w3.org/TR/rdf-sparql-query/#QSynIRI

Eric Prud'hommeaux: \http://www.w3.org/TR/rdf-sparql-query/#QSynIRI

18:47:58 <ericP> scribenick: ericP

(Scribe set to Eric Prud'hommeaux)

18:48:03 <ericP> ack SteveH

ack SteveH

18:48:03 <Zakim> SteveH, you wanted to ask meta-question

Zakim IRC Bot: SteveH, you wanted to ask meta-question

18:48:38 <ericP> SteveH: i didn't see how rdf:text solved the problem

Steve Harris: i didn't see how rdf:text solved the problem

18:49:10 <ericP> ... the right way to do this was to change RDF and attempt to isolate the other specs from those changes as best you can

... the right way to do this was to change RDF and attempt to isolate the other specs from those changes as best you can

18:49:38 <ericP> AxelPolleres: i think only the semantic equivalence is a problem

Axel Polleres: i think only the semantic equivalence is a problem

18:50:10 <ericP> ... we started with symbols spaces which were not the same as RDF's

... we started with symbols spaces which were not the same as RDF's

18:50:21 <ericP> OWL was doing something similar

OWL was doing something similar

18:50:31 <ericP> AxelPolleres, OWL was doing something similar

AxelPolleres, OWL was doing something similar

18:51:23 <ericP> SteveH: as it stands, rdf:text changes RDF

Steve Harris: as it stands, rdf:text changes RDF

18:51:40 <ericP> ... which means that those hundreds of RDF impls are technically incorrect

... which means that those hundreds of RDF impls are technically incorrect

18:52:14 <ericP> AxelPolleres: the alternative serialization is only present in RIF

Axel Polleres: the alternative serialization is only present in RIF

18:52:51 <ericP> ... there is a combined semantics of RIF and RDF graphs

... there is a combined semantics of RIF and RDF graphs

18:55:12 <ericP> AndyS: by putting the language info into a lexical form, it's not behaving like other datatype [extensions]

Andy Seaborne: by putting the language info into a lexical form, it's not behaving like other datatype [extensions]

18:56:02 <SteveH> q-

Steve Harris: q-

18:56:11 <ericP> what's FILTER ("@"^^rdf:text == false) ?

what's FILTER ("@"^^rdf:text == false) ?

18:56:19 <ericP> or FILTER (""^^rdf:text == false) ?

or FILTER (""^^rdf:text == false) ?

18:57:42 <AndyS> http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#FILTERs

Andy Seaborne: http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#FILTERs

18:58:36 <AxelPolleres> ""^^rdf:text

Axel Polleres: ""^^rdf:text

18:59:50 <AxelPolleres> ""^^xs:integer

Axel Polleres: ""^^xs:integer

19:00:05 <AndyS> FILTER(""^^xs:string)

Andy Seaborne: FILTER(""^^xs:string)

19:00:10 <AndyS> FILTER("false"^^xs:string)

Andy Seaborne: FILTER("false"^^xs:string)

19:00:23 <AxelPolleres> FILTER(""^^xs:integer)

Axel Polleres: FILTER(""^^xs:integer)

19:00:46 <AxelPolleres> FILTER ("@"^^rdf:text == false)

Axel Polleres: FILTER ("@"^^rdf:text == false)

19:03:32 <AndyS> http://www.w3.org/TR/rdf-sparql-query/#ebv

Andy Seaborne: http://www.w3.org/TR/rdf-sparql-query/#ebv

19:16:27 <AxelPolleres> eric, are you typing in http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment ?

(No events recorded for 12 minutes)

Axel Polleres: eric, are you typing in http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment ?

19:17:16 <AndyS> I hope that the replies from the OWL/RIF will include references to specific text

Andy Seaborne: I hope that the replies from the OWL/RIF will include references to specific text

19:17:57 <ericP> http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#Proposal

http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#Proposal

19:31:41 <LeeF> PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

(No events recorded for 13 minutes)

PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

19:31:56 <ericP> second

second

19:32:08 <AndyS> http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=753

Andy Seaborne: http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=753

19:34:55 <LeeF> PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=754 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last Call

PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=754 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last Call

19:44:24 <AxelPolleres> http://www.w3.org/TR/2009/WD-rdf-text-20090421/

(No events recorded for 9 minutes)

Axel Polleres: http://www.w3.org/TR/2009/WD-rdf-text-20090421/

19:44:30 <AndyS> http://www.w3.org/TR/2009/WD-rdf-text-20090421/#Relationship_with_Plain_Literals_and_xs:string

Andy Seaborne: http://www.w3.org/TR/2009/WD-rdf-text-20090421/#Relationship_with_Plain_Literals_and_xs:string

19:55:38 <kasei> scribenick: kasei

(No events recorded for 11 minutes)

(Scribe set to Greg Williams)

19:55:55 <kasei> LeeF: suggests sending comments without suggested text

Lee Feigenbaum: suggests sending comments without suggested text

19:56:47 <kasei> AndyS: text regarding rdf:text not appearing in sparql xml results should go along with similar text on rdf graph serializations.

Andy Seaborne: text regarding rdf:text not appearing in sparql xml results should go along with similar text on rdf graph serializations.

20:00:27 <AxelPolleres>  PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

Axel Polleres: PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

20:01:10 <AndyS> http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758

Andy Seaborne: http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758

20:01:33 <LeeF> PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

20:01:48 <AxelPolleres> +1

Axel Polleres: +1

20:01:52 <bglimm> +1

Birte Glimm: +1

20:01:57 <pgearon> +1

Paul Gearon: +1

20:02:11 <LeeF> RESOLVED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

RESOLVED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

20:02:41 <kasei> LeeF: either AndyS or LeeF should send the comments

Lee Feigenbaum: either AndyS or LeeF should send the comments

20:03:05 <LeeF> ACTION: LeeF to send SPARQL WG response http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 to OWL WG and RIF WG re: rdf:text

ACTION: LeeF to send SPARQL WG response http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 to OWL WG and RIF WG re: rdf:text

20:03:05 <trackbot> Created ACTION-15 - Send SPARQL WG response http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 to OWL WG and RIF WG re: rdf:text [on Lee Feigenbaum - due 2009-05-13].

Trackbot IRC Bot: Created ACTION-15 - Send SPARQL WG response http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 to OWL WG and RIF WG re: rdf:text [on Lee Feigenbaum - due 2009-05-13].

<LeeF> Adjourned for the day.

Lee Feigenbaum: Adjourned for the day.

20:04:01 <Zakim> -MIT262

Zakim IRC Bot: -MIT262

20:04:07 <Zakim> -Bristol

Zakim IRC Bot: -Bristol

20:04:08 <Zakim> SW_(SPRQL-F2F)6:30AM has ended

Zakim IRC Bot: SW_(SPRQL-F2F)6:30AM has ended

20:04:10 <Zakim> Attendees were kasei, ericP, LeeF, pgearon, yimin, KjetilK, AlexPassant, AndyS, AxelPolleres, SimonS, bglimm, LukeWM

Zakim IRC Bot: Attendees were kasei, ericP, LeeF, pgearon, yimin, KjetilK, AlexPassant, AndyS, AxelPolleres, SimonS, bglimm, LukeWM



Formatted by CommonScribe


This revision (#1) generated 2009-05-19 06:01:17 UTC by 'lfeigenb', comments: 'Initial cleaned up minutes. Thanks to all the scribes.'