Chatlog 2009-05-06

See original RRSAgent log and preview nicely formatted version.

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

<LeeF> Present: LeeF, 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> RRSAgent has joined #sparql
10:53:19 <RRSAgent> logging to http://www.w3.org/2009/05/06-sparql-irc
10:53:19 <ericP> Zakim, please dial MIT262
10:53:19 <Zakim> ok, ericP; the call is being made
10:53:20 <Zakim> SW_(SPRQL-F2F)6:30AM has now started
11:08:15 <LeeF> LeeF has joined #sparql
11:09:15 <LeeF> zakim, who's here?
11:09:15 <Zakim> On the phone I see Bristol, ivanh, MIT262, iv_an_ru
11:09:16 <Zakim> 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
11:09:35 <LeeF> zakim, MIT262 has kasei, LeeF, ericP, pgearon
11:09:35 <Zakim> +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
11:16:00 <pgearon> pgearon has joined #sparql
11:16:06 <ericP> scribenick: ericP 
11:16:08 <kasei> kasei has joined #sparql
11:16:11 <LeeF> Day 1, slot 1 - ericP
11:16:48 <LeeF> day 1, slot 2- Simon
11:17:01 <LeeF> day 1, slot 3 - kasei
11:17:47 <LeeF> day 2 - slot 1 - paul
11:17:50 <LeeF> day 2 - slot 2 - alex
11:18:30 <LeeF> day 2 - slot 3 - kjetil
11:20:24 <ericP> topic: agenda
11:20:45 <ericP> LeeF: pre-lunch we will have a knock-down, drag-out feature fight
11:20:59 <ericP> ... after lunch:
11:21:03 <ericP> ... .. name of doc
11:21:07 <ericP> ... .. rdf:text
11:21:19 <ericP> ... .. template for editorial contributions
11:21:26 <ericP> ... .. tomorrow am:
11:21:43 <ericP> ... .. features (subqueries/aggregates)
11:21:47 <KjetilK> we lost your picture
11:22:09 <AxelPolleres> do you still see us?
11:22:17 <kasei> yes
11:22:18 <ericP> ... hope that alex and KjetilK 
11:22:47 <ericP> ... ... will have everything they need
<LeeF> topic: feature discussion
11:24:33 <ericP> subtopic: survey results
11:24:22 <AxelPolleres> http://www.w3.org/2002/09/wbs/35463/features/results
11:24:33 <AxelPolleres> http://plugin.org.uk/misc/votes.svg
11:24:44 <SteveH> that's not the results
11:24:51 <LeeF> 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
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
11:26:14 <ericP> ... 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
11:27:44 <ericP> LeeF: we agreed to updates, aggregates and subselects
11:28:06 <ericP> [reads through condorcet results]
11:28:28 <SteveH> q+
11:28:33 <ivanh> zakim, mute me
11:28:33 <Zakim> ivanh should now be muted
11:28:44 <SteveH> http://plugin.org.uk/misc/votes2.svg
11:28:45 <LeeF> ack SteveH
11:29:20 <ericP> SteveH: produced another graph which ranks don't-want below don't-mind
11:29:34 <ericP> ... possibly a more fair representation
11:30:33 <ericP> [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
11:32:56 <ericP> ericP: 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
11:33:12 <ericP> SteveH: 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
11:34:46 <ericP> ... 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
11:35:20 <ericP> ... i was surprised that project expressions came out so low
11:36:10 <SteveH> +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
11:36:56 <ericP> ... also, project appeared to have more consensus than the alternative assignment
11:37:25 <ericP> ... will amend this proposal with negation
11:37:44 <ericP> ... our deliverable should be "making negation less painful"
11:37:56 <ericP> ... Time Permitting:
11:38:24 <ericP> ... .. federated query, func lib, property paths
11:38:43 <ericP> ... skipped assignment as i don't see consensus around it
11:39:00 <ericP> ... left full-text out due to tech and political constraints
11:40:08 <AxelPolleres> eric: safer to leave full-text out.
11:40:10 <AndyS> 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
11:41:05 <ericP> AndyS, i don't know of any IPR, just that it seems marginally more dangerous than other spaces
11:41:13 <AndyS> ack
11:41:28 <AndyS> zakim, ack me
11:41:28 <Zakim> AndyS, you wanted to ask EricP about IPR issues on full text
11:41:29 <Zakim> 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
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
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.
11:42:50 <AxelPolleres> "don't want"s in the top-12 plus SurfaceSyntax: Update 1 (Clark&Parsia),
11:42:50 <AxelPolleres> BasicFederatedQueries 1 (Clark&Parsia),
11:42:50 <AxelPolleres> FunctionLibrary 1 (Clark&Parsia), ProjectExpression 1 (Clark&Parsia),
11:42:50 <AxelPolleres> PropertyPaths 1 (RPI), FullText 1 (Clark&Parsia),
11:42:50 <AxelPolleres> 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
11:43:33 <ericP> ... 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
11:44:54 <AxelPolleres> 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" ...
11:45:05 <ericP> ... we should be conservative about surface syntax
11:45:07 <AxelPolleres> q?
11:46:11 <ericP> birte: [intro] interested in owl ontologies (thesis topic)
11:46:35 <ivanh> zakim, unmute me
11:46:35 <Zakim> ivanh should no longer be muted
11:46:59 <AndyS> zakim, who is on the phone?
11:46:59 <Zakim> On the phone I see Bristol, ivanh, MIT262, iv_an_ru
11:47:00 <Zakim> MIT262 has kasei, LeeF, ericP, pgearon
11:47:01 <Zakim> 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?
11:47:35 <iv_an_ru> Yes I hear you fine
11:48:31 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/User:Axel_Polleres
11:48:49 <ericP> subtopic: Axel's Questions:
11:48:52 <KjetilK> q+
11:49:51 <ericP> AxelPolleres: do we need a surface syntax, or just use subqueries?
11:49:57 <karl> karl has joined #sparql
11:50:16 <ericP> LeeF: is anyone uncomfortable with negation?
11:50:19 <KjetilK> q-
11:50:58 <ericP> AxelPolleres: i included objections in the question list
11:51:43 <ericP> ... 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
11:52:53 <ericP> ... 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
11:53:57 <ericP> SteveH: share AndyS's concearn that FILTER negation may not behave as expected
11:54:21 <ericP> AxelPolleres: should we sub-divide service description?
11:54:30 <ericP> ... .. description of data set
11:54:39 <ericP> ... .. optimizer hints
11:54:42 <kasei> q+ to mention a fourth facet of service descriptions
11:54:48 <LukeWM> q+
11:54:49 <SteveH> q+ to talk about scope
11:54:59 <ericP> ... .. entailment regimes
11:55:09 <LeeF> ack kasei
11:55:09 <Zakim> kasei, you wanted to mention a fourth facet of service descriptions
11:55:27 <LeeF> ack LukeWM
11:55:38 <LeeF> kasei: also supported extension functions & supported language extensions
11:55:54 <iv_an_ru> 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?
11:56:27 <AxelPolleres> lee: a core would make sense
11:56:28 <iv_an_ru> yes
11:56:31 <ericP> LeeF: deciding on a core would encourage folks to impl and use it
11:56:32 <LeeF> ack SteveH
11:56:32 <Zakim> SteveH, you wanted to talk about scope
11:56:54 <ericP> SteveH: [echoing LukeWM more assertively]
11:57:00 <AxelPolleres> steve: promoting of certain vocabs is not in the spirit of RDF
11:57:10 <ericP> ... these schemas (e.g. DaRQ) evolve
11:57:12 <LeeF> q?
11:57:18 <AndyS> q+
11:57:30 <iv_an_ru> 99% of service description issue is The Schema.
11:57:33 <ericP> ... we should just provide the dereferencing mechanism
11:57:43 <ivanh> q+
11:58:01 <AndyS> I disagree with the "99%" comment.  Finding the graph matters.
11:58:05 <LeeF> ack AndyS
11:58:17 <ericP> LeeF: 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 :)
11:58:37 <KjetilK> q+
11:58:39 <ericP> AndyS: want to say "my dataset description is <there>"
11:58:45 <SimonS> q+
11:58:45 <AxelPolleres> q+
11:58:52 <kasei> +1 AndyS
11:58:59 <iv_an_ru> +1 AndyS
11:59:35 <LeeF> ack ivanh
11:59:41 <LeeF> 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.
12:00:12 <SimonS> q-
12:00:15 <ericP> ivanh: i don't disagree with AndyS and SteveH, but we should flush out features we enable
12:00:29 <LeeF> ack KjetilK
12:00:43 <ericP> KjetilK: can't we do dataset descriptions with queries?
12:00:54 <kasei> that could also be prohibitively expensive
12:00:57 <ericP> SteveH: doesn't give you the quantitative stuff
12:01:17 <ericP> AndyS: can put you in a loop.
12:01:23 <LeeF> q?
12:01:42 <ericP> ... 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.
12:02:01 <LeeF> ack AxelPolleres
12:02:20 <ericP> SteveH: seems we need a tiny features like "i do <this>"
12:02:26 <Zakim> +??P9
12:02:31 <bijan> zakim, ??p9 is me
12:02:31 <Zakim> +bijan; got it
12:04:01 <LeeF> 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
12:04:19 <AxelPolleres> steve: small set of properties, e.g. sparql:supports
12:04:39 <AndyS> +1
12:04:42 <SteveH> +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
12:04:48 <SimonS> +1
12:04:50 <LeeF> <general love for Eric>
12:04:51 <KjetilK> 0
12:04:55 <AlexPassant> +1
12:05:22 <ericP> bijan: [gargled "hi"]
12:05:38 <Zakim> -iv_an_ru
<LeeF> subsubtopic: Full-text search
12:05:49 <ericP> AxelPolleres: [re: full text search]
12:06:18 <ericP> ... 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
12:07:03 <LeeF> LARQ
12:07:11 <ericP> KjetilK: we have used LARQ and Viruoso
12:07:33 <Zakim> +iv_an_ru
12:07:38 <ericP> ... 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
12:07:46 <AndyS> LARQ -> http://jena.sourceforge.net/ARQ/lucene-arq.html
12:07:59 <ericP> ... our needs are a little bigger than regex
12:08:10 <iv_an_ru> full-text should be interoperable in its core.
12:08:15 <AxelPolleres> Kjetil: we haven't used scores so far.
12:08:36 <AndyS> 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
12:09:18 <ericP> KjetilK: writing regex is generally difficult
12:09:46 <ericP> ... 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?
12:09:48 <iv_an_ru> regex is simply not for free text. Nothing to compare :)
12:10:17 <iv_an_ru> Scoring is an unavoidable.
12:10:55 <SimonS> +q
12:11:01 <AndyS> Agree - minimum is truncate results on score but returning score is nice
12:11:13 <AndyS> q-
12:11:23 <ericP> ... fear we are making SPARQL harder to deploy and adopt
12:11:31 <ericP> SteveH: 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.
12:11:39 <ericP> ... full-text is one of the harder things
12:11:55 <ericP> ... 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.
12:12:21 <AndyS> 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.
12:13:17 <ericP> KjetilK: 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
12:14:13 <bijan> 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?
12:15:01 <KjetilK> iv_an_ru, what kind of solution have you built?
12:15:16 <KjetilK> iv_an_ru, and how expensive is it?
12:15:16 <iv_an_ru> We're using custom free-text,
12:15:27 <iv_an_ru> 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.
12:16:34 <AxelPolleres> 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
12:16:51 <AxelPolleres> " doesn't look terribly compatible with triple patterns, does it?
12:17:03 <AndyS> (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.
12:17:41 <LeeF> pgearon: we have it through lucene already
12:18:09 <iv_an_ru> ?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
12:18:49 <LeeF> ericP: w3c tries to make coherent set of technologies, might shoehorn us into xpath full text expression 
12:19:03 <iv_an_ru> No doubt, FT should stay outside mandadory part of the language.
12:19:28 <LeeF> ericP: community could do outside of WG
12:19:51 <AxelPolleres> 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
12:20:05 <ericP> ... can see the user motivations for it
12:20:32 <ericP> ... 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
12:21:36 <AxelPolleres> luke: e.g. differences could be in whether stemming is done or only simple match
12:21:42 <LeeF> ericP: what a minimally conformant SPARQL implementation should do
12:21:43 <ericP> ... 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
12:22:52 <ericP> SteveH: i can't back it 'cause we wouldn't implement it
12:23:15 <ericP> KjetilK: couldn't you just spec a syntax?
12:24:00 <ericP> LeeF: you have a cost porting between LARQ and Virtuoso
12:24:31 <ericP> ... 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
12:24:37 <SteveH> 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
12:26:07 <pgearon> SteveH, I see your argument, but DESCRIBE already set this precedent
12:26:13 <ericP> ... ori noted that regex are much slower
12:26:41 <AndyS> There are regex indexing schemes
12:26:50 <ericP> q+ to propose a "use xpath when possible" directive
12:27:13 <LeeF> ack SimonS
12:27:23 <ericP> q-
12:27:40 <ericP> AndyS: would be happy to see a syntax for free-text search
12:28:00 <ericP> ... the work investment goes up radically
12:28:24 <ericP> ... different engines have different features (e.g. scoring)
12:29:02 <pgearon> +1
12:29:03 <AxelPolleres> andy: worried about necessary effort
12:29:05 <ivanh> +1
12:29:15 <ericP> ... i don't think standards help beyond there
12:29:38 <ericP> KjetilK: happy with magic predicates or a fILTER function
12:29:47 <ericP> ... seems like a simple requirement
12:29:50 <bglimm> bglimm has joined #sparql
12:30:08 <AndyS> 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?
12:30:51 <ericP> ... 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
12:32:27 <ericP> SimonS: we need at least scoring
12:32:54 <ericP> ... faceted browsing is a compelling use case
12:33:05 <ericP> ... we need a ranked list as output
12:33:23 <ericP> ... predicate functions work for that
12:33:25 <AndyS> 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 ]
12:34:07 <ericP> AlexPassant: fine with current regex
12:34:13 <AlexPassant> uses regexps on doapstore.org search
12:34:14 <LeeF> ack AndyS
12:34:14 <Zakim> AndyS, you wanted to note that predicate functions can bite
12:34:24 <iv_an_ru> 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
12:35:05 <iv_an_ru> I.e. it is possible but may cadd cost for no reason.
12:35:15 <ivanh> +1 to AndyS
12:35:19 <AxelPolleres> andy: example by orri for why fulltext is order dependent... we have to be cautious about that
12:35:36 <ericP> SimonS: 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.
12:36:18 <ericP> birte: 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
12:37:27 <LeeF> zakim, who's on the phone?
12:37:27 <Zakim> On the phone I see Bristol, ivanh, MIT262, bijan, iv_an_ru
12:37:28 <Zakim> MIT262 has kasei, LeeF, ericP, pgearon
12:37:29 <Zakim> 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.
12:37:59 <LeeF> q?
12:38:09 <KjetilK> iv_an_ru: do you want to comment on fulltext?
12:38:10 <iv_an_ru> (I suspect I can only listen and type)
12:38:21 <iv_an_ru> I've printed all comments already.
12:38:38 <KjetilK> Zakim, unmute iv_an_ru
12:38:38 <Zakim> 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.)
12:39:10 <iv_an_ru> 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.
12:40:19 <AndyS> I don't see why we are forced to use XQ/FT -- is it even mappable?
12:40:37 <SteveH> 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
12:40:55 <KjetilK> q+
12:41:20 <bijan> 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.
12:41:30 <bijan> (As a naive to fulltext person.)
12:41:35 <SteveH> bijan, xpath fulltext is /very/ complex
12:41:43 <AxelPolleres> AndyS: I guess our user community would put it just the other way around.
12:41:45 <SteveH> and leans on XML heavily
12:41:58 <LeeF> ack KjetilK
12:42:15 <ericP> KjetilK: 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.
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... :)
12:42:27 <AxelPolleres> Bijan, honestly, it seems just too cumbersome.
12:42:32 <ericP> ... would be happy with simple magic predicates
12:42:59 <ericP> ... and then say "if you want stemming et al, use xpath"
12:43:01 <ivanh> +1 to SteveH (although he was hardly audible)
12:43:08 <iv_an_ru> I don't like magic predicates, but customers do :|
12:43:16 <LeeF> q+ to talk about magic predicates
12:43:21 <ericP> SteveH: 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"?
12:44:13 <ericP> ... 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 ;)
12:44:29 <AndyS> 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?
12:45:11 <AndyS>  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.
12:45:37 <ericP> SteveH: 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.
12:46:04 <ericP> LeeF: we have avoided magic predicates to date
12:46:12 <SteveH> +1 to predicate functions being strange
12:46:23 <SimonS> +1 to ordering
12:46:32 <pgearon> LeeF, except "a" (for rdf:type)
12:46:33 <SteveH> we've deliberatly avoided predicate functions
12:46:34 <ericP> ... ½ happy with that
12:46:47 <SteveH> pgearon, a is in the syntax, not a function
12:46:52 <ericP> ... ½ 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
12:47:03 <pgearon> SteveH, that's fair
12:47:08 <ericP> ... 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
12:47:42 <ericP> ... 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
12:47:49 <pgearon> 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?
12:48:22 <SteveH> 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.
12:48:32 <AxelPolleres> which would be ok, if we want that.
12:49:33 <ericP> [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.
12:50:08 <ericP> [ivanh would add questions on property paths]
12:50:27 <ericP> subsubtopic: property paths
12:50:54 <ericP> ivanh: 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
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
12:54:06 <ivanh> q+
12:54:11 <AndyS> q+ to reply
12:54:41 <LeeF> q- leef
12:54:59 <bijan> 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
12:55:40 <bijan> It's not really all that encouraged
12:55:47 <LeeF> q?
12:56:50 <LeeF> ack ivanh
12:57:13 <LeeF> ivanh: this (coherent lists) is true but not our job
12:57:17 <iv_an_ru> Does somebody use closed lists?
12:57:22 <AndyS> (is this "property paths" or "list access"?)
12:57:39 <bijan> q+
12:57:54 <AxelPolleres> 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
12:58:46 <ericP> ivanh: the missing list access in SPARQL has a deleterious affect on SPARQL
12:58:52 <LeeF> ack AndyS
12:58:52 <Zakim> 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).
12:59:23 <pgearon> +1 to ivanh for the list access need in SPARQL point
12:59:26 <ericP> AndyS: you need to detect [list] cycles anyways
12:59:52 <bijan> +1 to killing rdf:list!
12:59:56 <KjetilK> +1 to scrapping it in RDF ;-)
12:59:56 <SteveH> +1!!!
13:00:01 <bijan> use XML Schema lists!
13:00:05 <LeeF> q?
13:00:20 <LeeF> ack bijan
13:00:38 <ericP> bijan: 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
13:00:57 <SteveH> +1 to bijan
13:01:17 <ericP> ... i feel that lists in RDF are bad, so i don't mind their use being discouraged
13:01:18 <LeeF> ack AxelPolleres
13:01:19 <Zakim> 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
13:01:49 <bijan> 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
13:02:00 <ericP> ... 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
13:02:33 <bijan> q-
13:02:58 <bijan> I'm fine with that
13:03:13 <AndyS> Steve+Andy: There is rdf:Seq
13:03:26 <AxelPolleres> Break!
13:03:40 <LeeF> +27min.
13:03:50 <Zakim> -ivanh
13:04:01 <Zakim> -iv_an_ru
13:35:07 <LeeF> we're re-starting
13:35:34 <LeeF> scribenick: SimonS
<LeeF> subsubtopic: ProjectExpressions & Assignment
13:35:52 <SimonS> AxelPolleres: continue discussion of questions
13:35:52 <ivanh> zakim, dial ivanh-voip
13:35:52 <Zakim> ok, ivanh; the call is being made
13:35:54 <Zakim> +ivanh
13:36:03 <ivanh> zakim, mute me
13:36:03 <Zakim> ivanh should now be muted
13:36:05 <AxelPolleres> continue with http://www.w3.org/2009/sparql/wiki/User:Axel_Polleres#ProjectExpressions
13:36:12 <SimonS> AxelPolleres: ProjectExpressions
13:36:37 <SimonS> there is redundancy between Assignment and ProjectExpressions
13:36:47 <SimonS>  Questions: same expressiveness?
13:36:59 <SimonS> ...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) 
13:37:50 <ericP> q?
13:38:04 <SimonS> SteveH: 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
13:38:52 <SimonS> AxelPolleres: also redundant for ScalarExpressionsIn*
13:38:57 <AndyS>  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?
13:39:30 <AxelPolleres> q?
13:39:40 <SimonS> SteveH: true, due to background in relational databases.
13:39:46 <LeeF> zakim, who's on the phone?
13:39:46 <Zakim> On the phone I see Bristol, ivanh (muted), MIT262, bijan
13:39:47 <Zakim> MIT262 has kasei, LeeF, ericP, pgearon
13:39:49 <Zakim> Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS
13:39:52 <ericP> ack me
13:39:52 <Zakim> 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.
13:40:42 <SimonS> q+
13:40:42 <LeeF> q+ to note that assignment is not always more terse 
13:41:12 <SimonS> SteveH: does not think assignment will be often used
13:42:24 <Zakim> +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.
13:43:10 <SimonS> ericP: 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 :)
13:43:31 <AndyS> --> 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?
13:44:10 <AndyS> Works well with CONSTRUCT.
13:44:50 <SimonS> SteveH: 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
13:45:08 <kendall> kendall has joined #sparql
13:45:20 <SimonS> Axel: Don't see the difference, logically
13:45:26 <kendall> hi LeeF
13:46:02 <SimonS> AxelPolleres: mean LET ?X = SELECT... vs SELEXT .. as ?X
13:46:25 <SimonS> SteveH: refers to ?X=3
13:46:57 <SimonS> AndyS: 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.
13:47:45 <SimonS> ...want to avoid misleading syntax
13:48:04 <LeeF> q?
13:48:12 <SimonS> AxelPolleres: Really everything subsumed by project expressions.
13:48:18 <SteveH> SELECT 3 as ?x => ?x := 3
13:48:24 <KjetilK> ack SimonS
13:48:29 <AndyS> Scoping issues?
13:49:21 <SimonS> SimonS: prefers LET syntax as crisper
13:49:26 <SimonS> ...and shorter
13:49:43 <LeeF> is LET { <var> := <expr> } (theoretically) identical to { SELECT <expr> AS <var> }?
13:49:50 <KjetilK> ack LeeF
13:49:50 <Zakim> LeeF, you wanted to note that assignment is not always more terse
13:49:53 <SimonS> SteveH: emphasizes misunderstandability of Assignment
13:50:10 <LeeF> http://pastebin.com/f1a90a229
13:50:36 <SimonS> LeeF: Uses both in different cases. 
13:50:48 <AxelPolleres> Zakim, who is on the phone?
13:50:48 <Zakim> On the phone I see Bristol, ivanh (muted), MIT262, bijan, iv_an_ru
13:50:49 <Zakim> MIT262 has kasei, LeeF, ericP, pgearon
13:50:50 <Zakim> 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.
13:51:04 <SimonS> ...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)
13:51:38 <LeeF> thanks, AndyS
13:52:03 <SimonS> SteveH: ProjectExpressions is Superset of Assignment. Or Maybe not?
13:52:10 <AndyS> http://pastebin.com/m694e180b
13:52:24 <AxelPolleres> Lee: Is there anybody who wants assignment, but not project expressions? 
13:52:38 <KjetilK> Zakim, Bristol has SimonS, SteveH, KjetilK, LukeWM, AndyS, AxelPolleres, AlexPassant, bglimm
13:52:42 <Zakim> +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.
13:53:33 <SimonS> LeeF: 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
13:54:23 <AxelPolleres> Steve: We should have only projectExpressions
13:54:52 <iv_an_ru> Maybe "LET ?x is a shorthand for ?a+?b" ... do something with ?x
13:54:57 <SimonS> SteveH: ordering issues with Assigment
13:55:21 <iv_an_ru> 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.
13:56:03 <AxelPolleres> ordering issues with assignment would be nesting issues with projectExpressions/subqueries.
13:56:08 <SimonS> ...fine, if value-based, not reference based.
13:56:45 <SimonS> SteveH: thinks this is exactly the kind of misunderstandings he means.
13:57:01 <kendall> 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
13:57:17 <kendall> 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
13:58:12 <SimonS> AxelPolleres: aggregate proposal means allow selects as expressions, but not require project expressions.
13:58:38 <SimonS> SteveH: then we loose some powerful subqueries
14:00:06 <SimonS> SimonS: Aren't subqueries possible without project?
14:00:12 <SimonS> SteveH: no
14:00:26 <SimonS> AndyS: not sure SteveH is right
14:01:12 <SimonS> pgearon: don't care which one is chosen.
14:01:45 <SimonS> LeeF: 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
14:02:27 <kendall> ivanh: I resemble that remark!
14:02:51 <SteveH> q+
14:03:12 <SimonS> ericP: Thinks, it does not make sense to emulate SQL.
14:03:28 <ivanh> 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.
14:03:56 <SimonS> ericP: 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
14:04:06 <SimonS> ... unkeen on emulating exactly that
14:04:21 <SimonS> ... e.g. subqueries don't share variable names etc.
14:04:29 <SimonS> ... Not so good to optimize
14:04:44 <SimonS> ... e.g. UNIONS would be n subselects in SQL
14:04:56 <iv_an_ru> 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)
14:05:05 <iv_an_ru> (I meen between sub-selects)
14:05:06 <SimonS> ... 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.
14:05:28 <iv_an_ru> 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
14:05:38 <SimonS> ... want to reuse composability from relational algebra
14:06:00 <SimonS> ... 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
14:06:17 <SimonS> Axel: 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".
14:06:36 <iv_an_ru> +1
14:06:55 <kendall> but how best do that is the question, of course
14:07:12 <SimonS> AndyS: 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.
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.
14:08:53 <SimonS> ericP: 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.
14:09:49 <SimonS> SteveH: 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
14:10:12 <SimonS> ... have to define Assignments in terms of projections.
14:10:24 <SimonS> Axel: Would somebody object to dropping Assignment?
14:10:44 <kendall> we might object if project expressions don't subsume assignment semantically
14:10:45 <iv_an_ru> I don't like assignment
14:10:46 <SimonS> Kendall: maybe
14:10:50 <kendall> if they do, then we wouldn't
14:11:17 <kendall> thanks, Simon! :)
14:11:27 <kendall> 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 :)
14:12:06 <kendall> well, i mean, assuming that I find the email convincing :>
<LeeF> subsubtopic: Basic federated queries
14:11:42 <SimonS> AxelPolleres: LimitPerResource
14:11:58 <SimonS> ...still OK to drop it, if subsumed by subselects?
14:12:11 <SteveH> q+
14:12:14 <SimonS> ...remarks for basic federated queries?
14:12:32 <ericP> 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
14:13:33 <AndyS> q+
14:14:23 <SimonS> SimonS: 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)
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.
14:15:16 <LeeF> 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].
14:15:33 <SimonS> SteveH: feature is needed.
14:15:55 <SimonS> ... but: concerns about triggering remote requests from inside DMZ
14:16:15 <SimonS> ... hence, SPARQL without federation should be allowed.
14:16:21 <ericP> ack SteveH 
14:16:26 <SimonS> Axel: same as FROM?
14:16:30 <AndyS> ack AndyS
14:16:32 <KjetilK> +1 to SteveH
14:16:49 <SimonS> SteveH: 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
14:17:15 <SimonS> AndyS: 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.
14:18:18 <SimonS> ...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
14:18:48 <ericP> ack me
14:18:48 <Zakim> 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
14:19:22 <SimonS> LeeF: mark security as an issue, but may work on this feature.
14:19:33 <kendall> +1 re: security
14:19:42 <LeeF> 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 .
14:19:42 <SimonS> SteveH: have compliance to SPARQL and "SPARQL-F"
14:20:00 <SimonS> AndyS: 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.
14:20:25 <AxelPolleres> 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.
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
14:21:34 <SimonS> LeeF: 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
14:22:13 <iv_an_ru> competitive implenetaitons of non-standardized fedaration is Bad Thing.
<LeeF> subsubtopic: LimitPerResource & Surface Syntax
14:22:14 <SimonS> AxelPolleres: LimitByResource
14:23:05 <SimonS> Kjetil: Without LimitByResource, working on multiple datasources becomes more difficult.
14:23:16 <KjetilK> - LimitClause  	  ::=    	'LIMIT' INTEGER
14:23:16 <KjetilK> + LimitClause  	  ::=    	'LIMIT' Var? INTEGER
14:23:17 <SimonS> SteveH: possible with SubSelects
14:23:23 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:LimitPerResource
14:23:37 <SimonS> Kjetil: can't be simpler than limit by resource.
14:23:58 <SimonS> SteveH: more complex requirements than covered by current proposal.
14:24:18 <AxelPolleres> 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.
14:24:39 <SimonS> AxelPolleres: Why not limit by variable list
14:24:43 <SimonS> ...?
14:24:47 <kendall> iv_an_ru: I obviously don't agree
14:24:50 <SimonS> video is gone.
14:25:04 <AxelPolleres> LIMIT ?x ?y INTEGER ? 
14:25:10 <AxelPolleres> q?
14:25:12 <SimonS> SteveH: Seems to be redundant, so leave it
14:25:29 <SimonS> Kjetil: 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
14:26:59 <SimonS> Kjetil: 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?
14:27:49 <SimonS> SteveH: does not see the difference. Use Aggregates?
14:28:13 <SimonS> Kjetil: perhaps possible.
14:28:27 <SimonS> Axel: If subselect have LIMIT + aggregates.
14:28:42 <SimonS> SteveH: think we need better examples than in the wiki.
14:29:00 <SimonS> Kjetil: Really need aggregate plus limit.
14:29:34 <SimonS> SteveH: 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.
14:30:01 <SimonS> agree, iv_an_ru
14:30:07 <kendall> eh...not convinced
14:30:11 <LeeF> 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
14:30:28 <kendall> 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.
14:30:35 <kendall> so, whatever, we don't have to agree about this :>
14:30:42 <SimonS> AlexPassant: Would prefer concentrating of subqueries plus aggregates
14:31:09 <SimonS> Axel: Anyone else arguing for extra syntax?
14:31:52 <SimonS> LeeF: 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
14:32:09 <SimonS> ... If there is not a consensus for special syntax.
14:32:23 <SimonS> ... we can do it later, as for negation.
14:32:39 <LukeWM> 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)
14:33:51 <LeeF> ack LukeWM
14:34:03 <SteveH> ?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.
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.
14:34:26 <LeeF> 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?
14:35:31 <SimonS> SteveH: Object. Will not have user experience by then.
14:36:09 <SimonS> SteveH: use case means real users in the field
14:36:57 <SimonS> Axel: Objection to dropping?
14:37:01 <SimonS> Kjetil: no.
14:37:12 <SimonS> Axel: Next one is SurfaceSyntax
14:37:22 <SimonS> ... what is surface syntax?
14:37:24 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0195.html
14:38:35 <SimonS> ... disjunction in FILTER (IN or BETWEEN)
14:39:03 <SimonS> ... path operators for concatenation etc
14:39:12 <SimonS> ... needed anyway for property paths
14:39:22 <SimonS> ... allow commas in expression lists
14:39:30 <SimonS> ... oppinions?
14:39:46 <AndyS> q+ to worry about the feature overall
14:39:48 <AxelPolleres> q+ on IN
14:39:53 <SimonS> SteveH: like IN, rely on it as an optimization.
14:39:59 <SimonS> ... comma probably useful
14:40:28 <SimonS> ... 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
14:41:13 <SimonS> AndyS: all things possible using dynamic dispatch
14:41:25 <SimonS> Axel: Also IN SELECT ...?
14:41:30 <KjetilK> DefaultDescribeResult is also doable as SurfaceSyntax
14:41:42 <SimonS> SteveH: means SQL style IN. 
14:41:56 <Zakim> -iv_an_ru
14:41:58 <SimonS> Axel: with subselects it is no longer syntactic sugar.
14:42:44 <SteveH> SteveH: yes it is :)
14:42:48 <AxelPolleres> IN range, IN subselect, IN lists
14:43:15 <SimonS> Axel: three possibilities - IN range, IN subselect, IN list.
14:43:48 <SimonS> SteveH: 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
14:44:17 <SimonS> ... not advocating this, just pointing it out.
14:44:19 <LeeF> q?
14:44:58 <SimonS> AndyS: 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"
14:45:02 <ericP> q-
14:45:22 <AndyS> ack me
14:45:27 <SimonS> Axel: left are IN between, commas.
14:45:30 <Zakim> 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
14:45:55 <KjetilK> 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.
14:46:35 <SimonS> LeeF: not have a generic SurfaceSyntax item
14:47:12 <SimonS> ... changing SurfaceSyntac to Commas and IN in FeatureProposal
14:47:56 <SimonS> AndyS: can drop commas, nobody would complain.
14:48:11 <SimonS> LeeF: do it, if time permits.
14:49:13 <SimonS> Axel: objections to Commas if time allowed?
14:49:41 <SimonS> SteveH: commas in select alone do not help, also need it in limit etc.
<LeeF> subsubtopic: SPARQL/OWL
14:50:30 <SimonS> Axel: next one is SPARQL/OWL
14:50:43 <chimezie> chimezie has joined #sparql
14:51:03 <SimonS> LeeF: Important to have. Who objects and why?
14:51:28 <PovAddict> PovAddict has joined #sparql
14:51:44 <KjetilK> q-
14:51:54 <Zakim> +Chimezie_Ogbuji
14:51:54 <KjetilK> q+ to say something negative
14:52:07 <chimezie> Zakim, mute me
14:52:07 <Zakim> Chimezie_Ogbuji should now be muted
14:52:09 <SimonS> ... discuss other entailment regimes. 
14:52:12 <SimonS> ... 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.
14:52:24 <SimonS> ... if it goes well, maybe do another one or two.
14:52:31 <bglimm> q+
14:52:43 <SteveH> q+
14:52:53 <bijan> q+ to say my main goal is force commonality on existing implementations
14:52:59 <bijan> er...one of my main goals
14:53:03 <KjetilK> ack me
14:53:05 <Zakim> KjetilK, you wanted to say something negative
14:53:10 <Zakim> -Bristol
14:53:24 <KjetilK> do you hear us?
14:53:26 <AxelPolleres> we need to redial it seems
14:53:26 <LeeF> 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 :)
14:55:22 <iv_an_ru> We've added optional commas to select list syntax because SQL people wrote them.
14:55:39 <Zakim> +??P0
14:55:47 <SteveH> 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?
14:56:01 <KjetilK> Zakim, ??P0 is Bristol
14:56:01 <Zakim> +Bristol; got it
14:56:01 <LeeF> zakim, ??P0 is Bristol
14:56:02 <Zakim> I already had ??P0 as Bristol, LeeF
14:56:06 <iv_an_ru> 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 (...)
14:56:46 <bijan> There are OWL Profiles
14:56:55 <bijan> 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
14:57:08 <SimonS> SteveH: just specify results only.
14:57:24 <SimonS> Axel: purpose is being able to specify what it means to support OWL.
14:57:32 <LeeF> q?
14:57:37 <LeeF> 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.
14:57:59 <bijan> 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.
14:58:34 <AxelPolleres> q+ to speak about why we need more refined notions of entailment even.
14:58:37 <SimonS> Kjetil: Is it that important?
14:59:01 <bijan> 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.
14:59:32 <ivanh> q+
14:59:34 <SimonS> ...instead of inventing another one.
14:59:44 <iv_an_ru> +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.
15:00:11 <LeeF> 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.
15:00:46 <SimonS> ...want to be able to say, "we support subset A, but not subsetB"
15:00:53 <SimonS> ...also interested in RIF rules.
15:01:01 <AndyS> Liitle house example --> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0069.html
15:01:23 <AndyS> q+
15:01:30 <SimonS> ...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.
15:02:23 <SimonS> SteveH: not everybody needs to do OWL.
15:02:39 <bijan> 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.
15:03:07 <LeeF> 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.
15:03:12 <LeeF> ack SteveH
15:03:13 <AxelPolleres> ack SteveH
15:03:30 <LeeF> ack bijan
15:03:30 <Zakim> 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.
15:03:54 <SimonS> bijan: OWL fast for many users/datasets/reasoners.
15:04:09 <SimonS> ... 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.
15:05:06 <SimonS> ... main objective is make OWL query engines use SPARQL and become interoperable
15:05:34 <LeeF> q?
15:05:38 <LeeF> ack ivanh
15:06:08 <bijan> 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
15:06:58 <SimonS> ... discussion at WWW with LOD community.
15:07:12 <SimonS> ... 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.
15:07:54 <LeeF> ack AndyS
15:07:59 <SimonS> ... 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?
15:08:45 <SimonS> bijan: inconsistencies
15:09:01 <SimonS> ... syntactically higher order variables, e.g. in predicate positions
15:09:28 <SimonS> ... BNodes 
15:09:42 <SimonS> ... derive additional information from them?
15:09:43 <pgearon> +1 for not deriving new bnodes!
15:10:29 <SimonS> ... restrict range of variables in order to guarantee finite results
15:10:56 <SimonS> AndyS: 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
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].
15:11:53 <ivanh> q+
15:12:12 <SimonS> Axel: 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.
15:13:27 <SimonS> ericP: 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?
15:13:46 <SteveH>  /OWL is a little specific
15:14:03 <LeeF> SteveH, I already updated it :)
15:14:11 <LeeF> (not sure if the new wording is best)
15:14:16 <SteveH> :)
15:14:39 <SimonS> bijan: need that, e.g. for BNodes.
15:14:45 <bglimm> updated to what?
15:14:56 <LeeF> 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
15:15:06 <bijan> SteveH, that could be reasonable.
15:15:09 <LeeF> SteveH, see http://www.w3.org/2009/sparql/wiki/FeatureProposal
15:15:20 <LeeF> ack ivanh
15:15:39 <SimonS> ivanh: for subsets like RL the situation may be even simpler.
15:15:43 <bijan> Right, for simpler regimes it'll be simpler
15:15:58 <bijan> 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?
15:16:37 <SimonS> ivanh: for the records - we need to allow to clearly define the capabilities of an endpoint. Needs service descriptions.
15:16:43 <LeeF> 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?
15:16:58 <AndyS> q+ to note UC for multiple entailment in one query
15:17:01 <ivanh> q?
15:17:04 <ivanh> q+
15:17:29 <SimonS> Axel: 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?
15:17:40 <SimonS> LeeF: 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
15:18:40 <SimonS> AndyS: service descriptions do not cover multiple regimes in a single query.
15:19:01 <SimonS> ivanh: not sure this is useful.
15:19:11 <chimezie> 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 :)
15:19:24 <chimezie> i.e., specific entailment regimes for specific parts of the active graph
15:19:29 <SteveH> I have used multiple in one query
15:19:38 <SteveH> not sure how it realtes/comflicts with decriptions though
15:19:49 <bijan> 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
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)
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.
15:20:18 <bijan> Which will be sound
15:20:53 <AxelPolleres> 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)
15:21:09 <bijan> Ah.
15:21:13 <SteveH> I agree with ericP 
15:21:14 <SimonS> I like and have used multiple graphs as AndyS proposes.
15:21:25 <SteveH> (pre Garlik)
15:21:29 <AxelPolleres> q?
15:21:35 <AndyS> ack me
15:21:35 <Zakim> AndyS, you wanted to note UC for multiple entailment in one query
15:21:38 <LeeF> ack ivanh
15:22:04 <SimonS> Axel: in above link, semantics of RIF+RDF is specified, includes entailed RDF triples
15:22:10 <bijan> q+
15:22:23 <SimonS> ivanh: does not include encoding RIF rules in RDF.
15:22:24 <chimezie> By reference to a RIF ruleset, ivanh
15:22:38 <SimonS> ... so how do I give endpoint the rules it needs.
15:22:55 <SimonS> AndyS: different issue - ParametrizedInference
15:23:38 <SimonS> SimonS: 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 
15:24:52 <SimonS> ... Today, many endpoints do inferencing without being parametrized.
15:25:20 <chimezie> +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.
15:25:29 <ivanh> chimezie, I would not talk about SPARQL-DL but SPARQL-OWL
15:25:33 <bijan> q-
15:25:37 <LeeF> q?
<LeeF> subtopic: Next steps after lunch break
15:25:59 <LeeF> http://www.w3.org/2009/sparql/wiki/FeatureProposal
15:26:52 <bijan> I may be asleep this evening :)
15:26:56 <SimonS> LeeF: everybody have a look at the list during lunch break
15:27:26 <KjetilK> q+ to ask about ProjectExpression as required
15:27:45 <SimonS> ... and need to think about order
15:28:06 <bijan> It looks good to me
15:28:18 <bijan> q+
15:28:29 <ivanh> :;-)
15:28:50 <SimonS> Kjetil: Should project expressions really be required?
15:29:04 <SimonS> SteveH: hardly possible to do aggregates and subqueires without.
15:29:11 <bijan> On queue!
15:29:15 <LeeF> q?
15:29:23 <KjetilK> ack me
15:29:24 <Zakim> KjetilK, you wanted to ask about ProjectExpression as required
15:29:28 <chimezie> We have a person on queue
15:29:36 <LeeF> ack bijan
15:30:17 <SimonS> bijan: What if we find out something is harder to do than expected?
15:30:23 <SimonS> ... do we have a strategy there?
15:30:43 <SimonS> LeeF: Use the usual W3C excuse... ;-)
15:31:05 <bijan> I love lead pipes!
15:31:24 <AndyS> We had the lead pipes at our house removed last month
15:31:49 <SimonS> LeeF: break.
15:36:38 <LeeF> 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.
15:46:17 <chimezie> AxelPolleres�:� will do
15:46:34 <chimezie> LeeF�:� np :)
16:33:48 <LeeF> chimezie, bijan, iv_an_ru we're starting back up
16:33:54 <LeeF> 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)
16:35:43 <kasei> scribenick: kasei
<LeeF> subtopic: Feature decision
<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
16:36:59 <kasei> LeeF: 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
16:38:27 <kasei> ... overlap of work for some features, not others (bgp entailment). makes sense to do some work in parallel.
16:39:08 <SteveH> +1
16:39:10 <AxelPolleres> +1
16:39:10 <KjetilK> +1
16:39:19 <kasei> ... 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
16:39:25 <SimonS>  +1
16:40:11 <kasei> AndyS: 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
16:42:09 <AxelPolleres> q+
16:42:14 <LeeF> ack AxelPolleres
16:42:56 <kasei> AxelPolleres: 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
16:43:54 <bglimm> q+
16:44:10 <LeeF> 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"
16:45:26 <kasei> bglimm: 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
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.
16:47:04 <kasei> ... open issues on required features shouldn't prevent discussion of time-permitting features
16:47:18 <bglimm> q+
16:47:53 <ericP> +1 to deathmarch
16:47:59 <SteveH> -1 to deathmarch
16:48:10 <LeeF> 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...
16:50:00 <kasei> ... 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.
16:50:45 <LeeF> 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
16:51:39 <kendall> as am I
16:52:07 <kasei> LeeF: 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
16:52:26 <kasei> ... 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
16:53:00 <LeeF> 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
16:53:22 <kendall> 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
16:55:44 <KjetilK> q+
16:55:48 <kasei> AndyS: 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
16:56:31 <kasei> ... (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
16:59:44 <kasei> ... relatively happy with current list
17:01:05 <kasei> pgearon: happy, but note we haven't discussed update yet.
17:01:12 <AndyS> +1 -- update is underdiscussed
17:02:05 <kasei> SteveH: 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.
17:03:18 <kasei> ... 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)
17:04:17 <KjetilK> Specify a simple, optional freetext query syntax and semantics.
17:04:18 <kendall> update being underdiscussed, particularly w/r/t security implications, worries me
17:04:29 <SteveH> +1 to kendall
17:04:42 <KjetilK> +1
17:04:44 <kasei> LeeF: poll on (possibly simple) full text feature
17:04:45 <pgearon> +1
17:04:48 <AlexPassant> 0
17:04:49 <LukeWM> 0
17:04:50 <kasei> 0
17:04:52 <SimonS> +1
17:04:53 <AxelPolleres> 0
17:04:53 <SteveH> -1 too complex
17:04:53 <bglimm> 0
17:04:58 <john-l> +1
17:04:58 <ericP> -1
17:05:01 <kendall> -1
17:05:07 <AndyS> +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
17:05:49 <LeeF> 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)
17:06:22 <kasei> ... 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
17:07:12 <pgearon> 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.
17:07:32 <kendall> but it doesn't have to be in the language
17:07:37 <kendall> it could be in the protocol
17:07:46 <kendall> or, as andy says, in something entirely separate
17:07:57 <kendall> (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?
17:09:09 <AndyS> 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.
17:09:45 <kasei> AndyS: member submission would be a good route
17:09:50 <AndyS> ack me
17:09:58 <LeeF> ack KjetilK
17:09:58 <KjetilK> ack me
17:10:42 <kasei> AlexP: 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.
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! :>
17:12:09 <kasei> bglimm: 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
17:12:53 <kasei> AxelPolleres: 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.
17:14:13 <kasei> AxelPolleres: should we scope to looking into only certain functions?
17:14:23 <kasei> AndyS: no
17:14:37 <LeeF> "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?
17:15:46 <AndyS> q+
17:15:52 <LeeF> 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
17:16:03 <kasei> ericP: 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)
17:17:26 <kasei> ... 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
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 .
17:18:47 <AxelPolleres> s/functions/function library/
17:18:48 <kasei> LeeF: punt on IP issues until writing charter
17:19:16 <LeeF> chimezie, are you around?
17:19:20 <LeeF> john-l, are you around?
17:19:31 <chimezie> 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 ?
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
17:21:13 <chimezie> It doesn't include BNode reference (which is important for us), but time-constraints , etc.. 
17:21:26 <SteveH> seconded
17:21:31 <AxelPolleres> +1
17:21:33 <chimezie> So, yes, looks good  :)
17:21:33 <ericP> +1
17:21:37 <KjetilK> threeonded
17:21:37 <LeeF> 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
17:22:05 <bijan> +1 (before going home)
17:22:13 <pgearon> +1
17:22:52 <bglimm> +1
17:23:03 <kasei> LeeF: does anyone abstain or object to propsal?
17:23:05 <AndyS> +1
17:23:09 <SimonS> +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
17:23:15 <LeeF> No abstentions or objections
<LeeF> topic: Features & Rationale document
<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
17:24:30 <AlexPassant> 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
17:25:28 <kasei> ... will use wiki for collab. environment. at some point will freeze page and put into a more formal document.
17:26:05 <AndyS> q+
17:26:17 <kasei> AlexP: for each feature: motivation, description, proposed syntax, discussion
17:26:42 <kasei> Steve: 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.
17:27:32 <kasei> KjetilK: 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
17:27:50 <kasei> AndyS: must be existing implementations, not just "examples".
17:28:12 <LeeF> ack AndyS
17:28:48 <kasei> ... 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.
17:31:00 <kasei> LeeF: next issue - naming.
17:31:29 <SimonS> SPARQL 2010
17:31:30 <kasei> ... "2.0" and "1.1". are there others?
17:31:54 <kasei> ... update may have another name, but what name for the core language?
17:32:09 <SteveH> also federated might have a different name...
17:32:55 <AxelPolleres> Axel: getting back to F+R Schedule
17:33:04 <kasei> ... would be great to have something in 4 weeks.
17:33:11 <AxelPolleres> LeeF: reasonable within 4 weeks?
17:33:31 <AxelPolleres> Kjetil&Alex agree.
17:33:45 <AlexPassant> +1 first week of june
17:34:11 <kasei> KjetilK: have one day a week. telecon + editing document.
17:34:40 <kasei> Alex: 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.
17:36:32 <kasei> AxelPolleres: don't have to write it all yourselves. ask for content, can discuss on telecon.
<LeeF> topic: Naming and Modularity
<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?
17:37:02 <kasei> ericP: 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!
17:37:27 <kasei> pgearon: if update is in it, 2.0, otherwise 1.1.
17:37:38 <kasei> kasei: 1.1, not strong preference.
17:37:38 <AlexPassant> +1 for pgearon 
17:38:06 <kasei> ericP: wondering about pgearon's opinion
17:38:19 <kasei> pgearon: update is a big feature. 2.0 signifies this.
17:38:27 <kasei> LeeF: 2.0
17:38:41 <kasei> LukeWM: don't care
17:39:06 <kasei> SteveH: 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?
17:39:31 <kasei> AndyS: 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!)
17:40:09 <kasei> ... 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
17:40:21 <kasei> KjetilK: 1.1. update as seperate. SPARQL/OWL seperate.
17:40:50 <kasei> AlexP: 2.0 with update, otherwise 1.1.
17:41:21 <kasei> SimonS: 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.)
17:42:22 <SteveH> q+
17:42:31 <LeeF> ack SteveH
17:42:43 <kasei> AxelPolleres: 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.
17:43:30 <kasei> LeeF: seems to be consensus on that. does anyone think otherwise?
17:43:50 <kendall> fwiw, i think "1.1" is a dumb name
17:43:57 <john-l> Leef, you prefer 2.0?
17:44:03 <LeeF> 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.
17:44:15 <LeeF> i'm happy with 2010 also fwiw :)
17:44:17 <LeeF> q+ yimin
17:44:20 <kasei> ericP: worries about what keeping update separate looks like.
17:44:26 <john-l> I prefer 2010.
17:44:47 <kendall> SPARQL 2010: The Sadistic Satyr
17:44:54 <kasei> ... 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?
17:45:37 <AndyS> Much laughter over  "The Speedy Squirrel"
17:45:47 <kasei> ... 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.
17:47:10 <kasei> SteveH: imagining two langs would share grammar. core sparql would error if you tried to use update.
17:48:05 <AndyS> 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.
17:48:44 <AndyS> ack me
17:48:46 <LeeF> ack yimin
17:49:15 <kasei> yimin:  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.
17:50:02 <kendall> (what users are these? i don't recognize 'yimin')
17:50:20 <kendall> AH
17:50:22 <pgearon> +q
17:50:22 <kendall> thanks, LeeF
17:50:30 <kasei> ericP: SQL has sublanguages, but users don't think of them.
17:50:39 <LeeF> ack pgearon
17:50:41 <kendall> I think that's a pretty awfula analogy
17:50:56 <ericP> 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.
17:51:35 <AndyS> 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.
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!)
17:53:15 <AxelPolleres> (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.
17:53:56 <kendall> Axel: no, they don't
17:54:04 <kendall> programmers don't even write that much SQL these days
17:54:33 <SteveH> I like Andy's proposal
17:54:41 <kasei> AxelPolleres: no particular preference.
17:55:13 <AndyS> (was not my proposal - I just liked it)
17:55:21 <kasei> SteveH: branding "SPARQL/Query", "SPARQL/Update", ...
17:55:29 <kendall> +1
17:55:32 <kasei> LeeF: do we need a specific name for the work this WG is doing?
17:55:51 <AxelPolleres> SteveH: SPARQL = SPARQL/Query SPARQL/Update
17:56:33 <AndyS> 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
17:56:49 <SteveH> 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
17:57:08 <ericP> +1 to megillah (SP?) proposal
17:57:12 <kendall> SPARQL/Inference (We can hope!!)
17:57:57 <SteveH> isn't this WG a megillah?
17:57:58 <AxelPolleres> rdf-sparql-query11/ , rdf-sparql-update/ rdf-sparql-entailments/, rdf-sparql-protocol11/
17:58:07 <AndyS> .g seems to agree on spelling
17:58:15 <SteveH> federated also
17:58:20 <KjetilK> +1
17:58:20 <AndyS> +1
17:58:23 <LeeF> 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
17:58:40 <AxelPolleres> +1
17:58:55 <bglimm> +1
17:59:10 <kasei> ericP: tempted not to number overall SPARQL.
17:59:11 <AndyS> Are we using Apache Ivy to import all the docs?
17:59:21 <kendall> +[1.1,2.0]
17:59:26 <kendall> hah
17:59:32 <kasei> LeeF: 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
18:00:00 <ericP> i second
18:00:02 <AndyS> +i
18:00:05 <KjetilK> +1
18:00:10 <kendall> why the 1.1 bit?
18:00:10 <pgearon> +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
18:00:30 <kendall> previous version "SPARQL", this version "SPARQL/Query"
18:00:34 <ericP> i second
18:00:35 <SteveH> 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
18:01:33 <ericP> i object
18:02:59 <kasei> ericP: 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<...>.
18:03:56 <kasei> ... no network requests from the endpoint.
18:03:59 <AndyS> q+
18:04:26 <kasei> ... 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?
18:05:23 <kasei> SteveH: ideally, yes. but there are many stores that don't GET on a FROM.
18:06:10 <LeeF> ack AndyS
18:06:10 <kasei> ... 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.
18:06:40 <kasei> ... "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?
18:08:36 <KjetilK> +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
18:09:51 <AndyS> 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.
18:10:45 <kasei> ... 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.
18:11:51 <SimonS> +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.
18:13:03 <kasei> ericP: suggest SteveH lobby for text that deals with safe operations, a "SPARQL/Safe" name.
18:13:32 <LeeF> SPARQL/DangerDangerDanger
18:13:58 <AxelPolleres> 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.
18:14:06 <KjetilK> +1 to not rule it out
18:14:14 <LeeF> 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
18:14:50 <AxelPolleres> ... 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.
18:15:41 <KjetilK> +1
18:15:49 <kasei> LeeF: any abstentions or objections?
18:15:49 <pgearon> +1
18:15:52 <AxelPolleres> +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
18:16:02 <SteveH> can we have an issue along the lines of what AndyS wrote
18:16:03 <KjetilK> 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?
18:16:06 <bglimm> +1
18:16:52 <kasei> KjetilK: what should title of features document be?
18:17:34 <kasei> ... "yeah, I'm happy"
18:18:45 <ericP> topic: response to rdf:text
<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
18:18:41 <kasei> ... tomorrow dive into features
18:19:09 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/rdf_text_LC_WG_comment
18:19:09 <ywang4> ywang4 has joined #sparql
18:19:30 <AxelPolleres> http://www.w3.org/TR/rdf-text/
18:19:37 <kasei> AxelPolleres: current response, based on comments by AndyS.
18:19:48 <kasei> ... interop problems with SPARQL.
18:20:45 <kasei> ... 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
18:22:10 <kasei> ... 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
18:23:19 <kasei> ... 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.
18:24:12 <kasei> ... rdf:text should affect D-entailment
18:24:22 <ericP> q+ to check a use case
18:24:50 <kasei> LeeF: 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
18:25:21 <ericP> q-
18:25:36 <kasei> AndyS: 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
18:25:54 <SteveH> q+ to ask meta-question
18:27:11 <kasei> ... literals have lang or dt, not both. code relies on this.
18:27:47 <kasei> AxelPolleres: 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
18:30:33 <kasei> AxelPolleres: if your data doesn't have rdf:text in it, you won't get it out of the functions.
18:30:55 <bglimm> q+
18:31:45 <kasei> AndyS: 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
18:32:56 <kasei> ... 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))
18:33:30 <LeeF> INSERT { <a> <b> "foo@en"^^rdf:text } ...
18:33:36 <kasei> ericP: 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.
18:34:55 <bglimm> q-
18:35:13 <LeeF> 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
18:35:28 <kasei> AndyS: need to give guidance for tools that generate this (data, queries?)
18:36:28 <kasei> ... it's legal and generates confusion.
18:36:43 <kasei> ... rdf:text doc doesn't make it clear what to do.
18:36:52 <kasei> ... suggestions is to have a section for sparql issues.
18:37:13 <kasei> ericP: shouldn't be a "sparql" section
18:38:32 <kasei> ... 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
18:40:08 <kasei> ericP: 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.
18:41:39 <kasei> ... not a sparql-specific issue.
18:42:12 <kasei> ... other than new issues, where are we on current text?
18:42:36 <kasei> AxelPolleres: would not require a new section
18:43:43 <kasei> AndyS: 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?
18:44:49 <kasei> ericP: 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
18:45:53 <kasei> ... allowing iri resources (kanji, arabic in urls, etc.)
18:46:10 <kasei> ... draw text from sparql spec
18:46:22 <AndyS> q?
18:46:35 <kasei> AxelPolleres: would like concrete suggestion
18:46:42 <ericP> http://www.w3.org/TR/rdf-sparql-query/#docTerminology
18:47:20 <ericP> \http://www.w3.org/TR/rdf-sparql-query/#QSynIRI
18:47:58 <ericP> scribenick: ericP 
18:48:03 <ericP> ack SteveH 
18:48:03 <Zakim> SteveH, you wanted to ask meta-question
18:48:38 <ericP> SteveH: 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
18:49:38 <ericP> AxelPolleres: 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
18:50:21 <ericP> OWL was doing something similar
18:50:31 <ericP> AxelPolleres, OWL was doing something similar
18:51:23 <ericP> SteveH: as it stands, rdf:text changes RDF
18:51:40 <ericP> ... which means that those hundreds of RDF impls are technically incorrect
18:52:14 <ericP> AxelPolleres: the alternative serialization is only present in RIF
18:52:51 <ericP> ... 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]
18:56:02 <SteveH> q-
18:56:11 <ericP> what's FILTER ("@"^^rdf:text == false) ?
18:56:19 <ericP> or FILTER (""^^rdf:text == false) ?
18:57:42 <AndyS> http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#FILTERs
18:58:36 <AxelPolleres> ""^^rdf:text
18:59:50 <AxelPolleres> ""^^xs:integer
19:00:05 <AndyS> FILTER(""^^xs:string)
19:00:10 <AndyS> FILTER("false"^^xs:string)
19:00:23 <AxelPolleres> FILTER(""^^xs:integer)
19:00:46 <AxelPolleres> FILTER ("@"^^rdf:text == false)
19:03:32 <AndyS> 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 ?
19:17:16 <AndyS> 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
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
19:31:56 <ericP> second
19:32:08 <AndyS> 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
19:44:24 <AxelPolleres> 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
19:55:38 <kasei> scribenick: kasei
19:55:55 <kasei> LeeF: 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.
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
20:01:10 <AndyS> 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
20:01:48 <AxelPolleres> +1
20:01:52 <bglimm> +1
20:01:57 <pgearon> +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
20:02:41 <kasei> LeeF: 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
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].
<LeeF> Adjourned for the day.
20:04:01 <Zakim> -MIT262
20:04:07 <Zakim> -Bristol
20:04:08 <Zakim> 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
20:05:28 <kasei> kasei has left #sparql
20:24:40 <LeeF> LeeF has joined #sparql
20:40:00 <LeeF__> LeeF__ has joined #sparql
21:26:28 <Zakim> Zakim has left #sparql
21:53:53 <pgearon> pgearon has joined #sparql
22:46:22 <bglimm> bglimm has joined #sparql
23:54:52 <LeeF> LeeF has joined #sparql
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00001415