IRC log of sparql on 2009-05-06

Timestamps are in UTC.

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
10:53:22 [Zakim]
+MIT262
10:53:25 [Zakim]
+??P0
10:53:35 [AxelPolleres]
thanks.
10:53:36 [Zakim]
-MIT262
10:53:39 [SteveH]
AxelPolleres, RRSAgent is case sensitive
10:53:40 [AndyS]
zakim, ??P0 is Bristol
10:53:40 [Zakim]
+Bristol; got it
10:53:40 [ericP]
Zakim, please dial MIT262b
10:53:41 [Zakim]
ok, ericP; the call is being made
10:53:42 [Zakim]
+MIT262b
10:53:49 [ericP]
weak!
10:54:09 [ericP]
Zakim, please disconnect MIT262b
10:54:09 [Zakim]
MIT262b is being disconnected
10:54:11 [Zakim]
-MIT262b
10:54:11 [AndyS]
zakim, Bristol has SimonS, SteveH, Kjetil_, LukeWM
10:54:11 [Zakim]
+SimonS, SteveH, Kjetil_, LukeWM; got it
10:54:18 [AndyS]
zakim, Bristol has AndyS
10:54:18 [Zakim]
+AndyS; got it
10:54:39 [AndyS]
zakim, Bristol has AlexPassant, AxelPolleres
10:54:39 [Zakim]
+AlexPassant, AxelPolleres; got it
10:54:44 [Zakim]
+MIT262
10:54:50 [AndyS]
zakim, who is on the phone?
10:54:50 [Zakim]
On the phone I see Bristol, MIT262
10:54:51 [Zakim]
Bristol has AlexPassant, AxelPolleres
10:55:21 [AndyS]
zakim, Bristol has SimonS, SteveH, Kjetil_, LukeWM, AlexPassant, AxelPolleres,AndyS
10:55:21 [Zakim]
AlexPassant was already listed in Bristol, AndyS
10:55:22 [Zakim]
AxelPolleres was already listed in Bristol, AndyS
10:55:23 [Zakim]
+SimonS, SteveH, Kjetil_, LukeWM, AndyS; got it
10:56:07 [Zakim]
-MIT262
10:56:33 [ericP]
do you see us?
10:56:37 [AndyS]
Eric, mute your end
10:56:38 [Kjetil_]
yep
10:56:40 [AndyS]
we can see you
10:56:56 [AxelPolleres]
can you hear us?
10:57:00 [Kjetil_]
ericP: don't hang yourself
10:57:00 [ericP]
nope
10:58:46 [AxelPolleres]
we should be on the phone
10:59:05 [AxelPolleres]
phone is cpompletely separate from video-link's audio
10:59:24 [AxelPolleres]
iv_an_ru can you hear us?
10:59:27 [AxelPolleres]
iv_an_ru can you hear eric?
10:59:39 [ivan]
zakim, call ivan-voip
10:59:39 [Zakim]
ok, ivan; the call is being made
10:59:41 [Zakim]
+Ivan
10:59:43 [AxelPolleres]
Zakim, who is on the phone?
10:59:43 [Zakim]
On the phone I see Bristol, Ivan (muted)
10:59:44 [Zakim]
Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS
10:59:52 [Zakim]
+MIT262
11:00:00 [ivan]
I hear you guys
11:00:03 [bijan]
bijan has joined #sparql
11:02:32 [AndyS_]
AndyS_ has joined #sparql
11:04:44 [AndyS_]
zakim, who is on the phone?
11:04:44 [Zakim]
On the phone I see Bristol, Ivan, MIT262
11:04:45 [Zakim]
Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS
11:05:49 [AxelPolleres]
Zakim, who is on the phone?
11:05:49 [Zakim]
On the phone I see Bristol, Ivan, MIT262
11:05:50 [Zakim]
Bristol has SimonS, SteveH, Kjetil_, LukeWM, AndyS
11:06:24 [AndyS]
bijan - ack - we have zakim for audio
11:06:35 [Zakim]
+ +01212803aaaa
11:06:47 [AndyS]
And the video works. Lee has just arrived. Eric+Lee+Greg in Boston
11:06:50 [iv_an_ru]
zakim, +0121 is me
11:06:50 [Zakim]
+iv_an_ru; got it
11:07:19 [AndyS]
We have Ivan/NL and Ivan/RU on the phone
11:07:49 [bijan]
Thanks AndyS
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, Ivan, 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, ivan, 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:13:38 [AxelPolleres]
Paul is missing from http://www.w3.org/2009/sparql/wiki/Scribe_List, I see! :-)
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:27 [LeeF]
zakim, choose a scribe
11:16:27 [Zakim]
Not knowing who is chairing or who scribed recently, I propose iv_an_ru
11:16:31 [LeeF]
zakim, choose a scribe
11:16:31 [Zakim]
Not knowing who is chairing or who scribed recently, I propose SimonS
11:16:48 [LeeF]
day 1, slot 2- Simon
11:16:50 [LeeF]
zakim, choose a scribe
11:16:50 [Zakim]
Not knowing who is chairing or who scribed recently, I propose kasei
11:17:01 [LeeF]
day 1, slot 3 - kasei
11:17:03 [LeeF]
zakim, choose a scribe
11:17:03 [Zakim]
Not knowing who is chairing or who scribed recently, I propose ericP
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:19:15 [ericP]
topic: introductions
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_Lap]
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_Lap
11:22:47 [ericP]
... ... will have everything they need
11:24:22 [AxelPolleres]
http://www.w3.org/2002/09/wbs/35463/features/results
11:24:33 [ericP]
topic: survey 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 consorcet results]
11:28:28 [SteveH]
q+
11:28:33 [ivan]
zakim, mute me
11:28:33 [Zakim]
Ivan 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:18 [AndyS]
zakim, ack
11:41:18 [Zakim]
I don't understand 'ack', AndyS
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 [ivan]
zakim, unmute me
11:46:35 [Zakim]
Ivan 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, Ivan, 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]
topic: Axel's Questions:
11:48:52 [KjetilK_Lap]
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_Lap]
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 [ivan]
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_Lap]
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:27 [LeeF]
q+ ericP to ask if anyone is opposed to standardizing the mechanism mainly/only
11:59:35 [LeeF]
ack ivan
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]
ivan: i don't disagree with AndyS and SteveH, but we should flush out features we enable
12:00:29 [LeeF]
ack KjetilK_Lap
12:00:43 [ericP]
KjetilK_Lap: 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_Lap]
0
12:04:55 [AlexPassant]
+1
12:05:22 [ericP]
bijan: [gargled "hi"]
12:05:38 [Zakim]
-iv_an_ru
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_Lap: 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 an scoring
12:08:55 [LeeF]
s/an scoring/and scoring
12:09:18 [ericP]
KjetilK_Lap: 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_Lap: 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_Lap]
iv_an_ru: what kind of solution have you built?
12:15:16 [KjetilK_Lap]
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:15:28 [SteveH]
kjetil, , not :
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 expressions 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:06 [AxelPolleres]
s/expressions/custom functions/
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_Lap: couldn't you just spec a syntax?
12:24:00 [ericP]
LeeF: you have a cost porting between LARC 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:24:48 [AndyS]
s/LARC/LARQ/
12:25:57 [ericP]
KjetilK_Lap: 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:18 [LeeF]
s/SteveH:/SteveH,
12:26:41 [AndyS]
There are regex indexing schema
12:26:50 [ericP]
q+ to propose a "use xpath when possible" directive
12:26:57 [AndyS]
s/schema/schemes/
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 [ivan]
+1
12:29:15 [ericP]
... i don't think standards help beyond there
12:29:38 [ericP]
KjetilK_Lap: 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_Lap: 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 regext 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:27 [KjetilK_Lap]
s/regext/regexps/
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 [ivan]
+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:36:22 [ericP]
q+
12:36:24 [ericP]
q-
12:37:26 [ericP]
ivan: 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, Ivan, 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_Lap]
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_Lap]
Zakim, unmute iv_an_ru
12:38:38 [Zakim]
iv_an_ru was not muted, KjetilK_Lap
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_Lap]
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_Lap
12:42:15 [ericP]
KjetilK_Lap: 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:41 [LeeF]
s/Bijan:/Bijan,
12:42:59 [ericP]
... and then say "if you want stemming et al, use xpath"
12:43:00 [bijan]
s/SteveH:/SteveH,
12:43:01 [ivan]
+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_Lap: 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, so 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:47:58 [SteveH]
s/so/but/
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]
[ivan would add questions on property paths]
12:50:27 [ericP]
topic: property paths
12:50:54 [ericP]
ivan: 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 [ivan]
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 insure a coherent list
12:55:12 [LeeF]
s/insure/ensure
12:55:40 [bijan]
It's not really all that encouraged
12:55:47 [LeeF]
q?
12:56:50 [LeeF]
ack ivan
12:57:13 [LeeF]
ivan: 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 Ivan for the list access need in SPARQL point
12:58:46 [ericP]
ivan: 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 Ivan 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_Lap]
+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 ivan'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]
-Ivan
13:04:01 [Zakim]
-iv_an_ru
13:35:07 [LeeF]
we're re-starting
13:35:34 [LeeF]
scribenick: SimonS
13:35:52 [SimonS]
AxelPolleres: continue discussion of questions
13:35:52 [ivan]
zakim, dial ivan-voip
13:35:52 [Zakim]
ok, ivan; the call is being made
13:35:54 [Zakim]
+Ivan
13:36:03 [ivan]
zakim, mute me
13:36:03 [Zakim]
Ivan 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, Ivan (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 look like assignment, but logically it can't be.
13:47:23 [SimonS]
s/look/looks/
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_Lap]
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_Lap]
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, Ivan (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_Lap]
Zakim, Bristol has SimonS, SteveH, KjetilK_Lap, LukeWM, AndyS, AxelPolleres, AlexPassant, bglimm
13:52:38 [Zakim]
SimonS was already listed in Bristol, KjetilK_Lap
13:52:39 [Zakim]
SteveH was already listed in Bristol, KjetilK_Lap
13:52:40 [Zakim]
LukeWM was already listed in Bristol, KjetilK_Lap
13:52:41 [Zakim]
AndyS was already listed in Bristol, KjetilK_Lap
13:52:42 [Zakim]
+KjetilK_Lap, 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:56:51 [kendall]
(doh; good reminder LeeF)
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 pwerful subqueries
13:58:44 [SimonS]
s/pwerful/powerful
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]
ivan: 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 [ivan]
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 [ivan]
+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 (not present): maybe
14:10:50 [kendall]
if they do, then we wouldn't
14:11:10 [SimonS]
s/Kendall (not present)/kendall/
14:11:17 [kendall]
thanks, Simon! :)
14:11:27 [kendall]
NP
14:11:42 [SimonS]
AxelPolleres: LimitPerResource
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:11:58 [SimonS]
...still OK to drop it, if subsumed by subselects?
14:12:06 [kendall]
well, i mean, assuming that I find the email convincing :>
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 butare 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_Lap]
+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: cou can reject andy 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:20:42 [AndyS]
s/andy query/any 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.
14:22:14 [SimonS]
Axelpolleres: LimitByResource
14:22:29 [SimonS]
s/Axelpolleres/AxelPolleres/
14:23:05 [SimonS]
Kjetil: Without LimitByResource, working on multiple datasources becomes more difficult.
14:23:16 [KjetilK_Lap]
- LimitClause ::= 'LIMIT' INTEGER
14:23:16 [KjetilK_Lap]
+ 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 thatn in the wiki.
14:29:00 [SimonS]
Kjetil: Really need aggregate plus limit.
14:29:06 [SimonS]
s/thatn/than/
14:29:34 [SimonS]
SteveH: also want thinks 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_Lap]
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:45 [LeeF]
s/FYI:/ FYI:
14:45:55 [KjetilK_Lap]
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.
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_Lap]
q-
14:51:54 [Zakim]
+Chimezie_Ogbuji
14:51:54 [KjetilK_Lap]
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_Lap]
ack me
14:53:05 [Zakim]
KjetilK_Lap, you wanted to say something negative
14:53:10 [Zakim]
-Bristol
14:53:24 [KjetilK_Lap]
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_Lap]
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 [ivan]
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 ivan
15:06:08 [bijan]
OWL Profiles: http://www.w3.org/TR/owl2-profiles/
15:06:29 [SimonS]
ivan: 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; skoping?
15:08:37 [SimonS]
s/skoping/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
15:11:04 [AndyS]
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 [ivan]
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 ivan
15:15:39 [SimonS]
ivan: 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]
ivan: 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 [ivan]
q?
15:17:04 [ivan]
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]
ivan: 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 ivan
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]
ivan: does not include encoding RIF rules in RDF.
15:22:24 [chimezie]
By reference to a RIF ruleset, Ivan
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 [ivan]
chimezie, I would not talk about SPARQL-DL but SPARQL-OWL
15:25:33 [bijan]
q-
15:25:37 [LeeF]
q?
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_Lap]
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 [ivan]
:;-)
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_Lap]
ack me
15:29:24 [Zakim]
KjetilK_Lap, 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:38 [Zakim]
-Chimezie_Ogbuji
15:31:44 [Zakim]
-Ivan
15:31:46 [Zakim]
-bijan
15:31:49 [SimonS]
LeeF: break.
15:32:03 [Zakim]
-MIT262
15:32:17 [Zakim]
-Bristol
15:32:18 [Zakim]
SW_(SPRQL-F2F)6:30AM has ended
15:32:19 [Zakim]
Attendees were MIT262b, SimonS, SteveH, Kjetil_, LukeWM, AndyS, AlexPassant, AxelPolleres, Ivan, +01212803aaaa, iv_an_ru, kasei, LeeF, ericP, pgearon, bijan, KjetilK_Lap, bglimm,
15:32:23 [Zakim]
... Chimezie_Ogbuji, Bristol
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:31:33 [SteveH]
KjetilK_Lap: http://foaf.qdos.com/verify-demo the foaf:knows prximity stuff
16:31:41 [Zakim]
SW_(SPRQL-F2F)6:30AM has now started
16:31:42 [Zakim]
+MIT262
16:32:02 [LeeF]
zakim, MIT262 has kasei, ericP, LeeF, pgearon, yimin
16:32:02 [Zakim]
+kasei, ericP, LeeF, pgearon, yimin; got it
16:32:40 [Zakim]
+??P6
16:32:42 [Zakim]
-??P6
16:32:42 [Zakim]
+??P6
16:32:51 [AndyS]
zakim, ??P6 is Bristol
16:32:51 [Zakim]
+Bristol; got it
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:33:55 [AndyS]
zakim, Bristol has KjetilK_Lap, AlexPassant, AndyS, AxelPolleres, SimonS, bglimm, LukeWM
16:33:55 [Zakim]
+KjetilK_Lap, AlexPassant, AndyS, AxelPolleres, SimonS, bglimm, LukeWM; got it
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:33 [kasei]
scribenick kasei
16:35:43 [kasei]
scribenick: kasei
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_Lap]
+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 would support it being a feature
16:52:52 [SteveH]
*wouldn't
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_Lap]
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_Lap]
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_Lap]
+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_Lap
17:09:58 [KjetilK_Lap]
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_Lap: 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_Lap]
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]
AxelPolleres: if we leave it unscoped, would that be problematic for the charter?
17:15:46 [AndyS]
q+
17:15:48 [LeeF]
s/AxelPolleres/Kjetil
17:15:52 [LeeF]
ack KjetilK_Lap
17:15:52 [Zakim]
KjetilK_Lap, 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 [LeeF]
zakim, who's on the phone?
17:18:48 [Zakim]
On the phone I see MIT262, Bristol
17:18:48 [kasei]
LeeF: punt on IP issues until writing charter
17:18:49 [Zakim]
Bristol has KjetilK_Lap, AlexPassant, AndyS, AxelPolleres, SimonS, bglimm, LukeWM
17:18:50 [Zakim]
MIT262 has kasei, ericP, LeeF, pgearon, yimin
17:19:04 [AndyS]
zakim, who is on IRC?
17:19:04 [Zakim]
I don't understand your question, AndyS.
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_Lap]
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
17:24:05 [kasei]
... 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.
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_Lap]
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_Lap]
+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_Lap]
+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_Lap]
+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_Lap]
+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_Lap]
+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_Lap]
ack me
18:16:03 [Zakim]
KjetilK_Lap, 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:30 [kasei]
LeeF: next up, response to rdf:text
18:18:41 [kasei]
... tomorrow dive into features
18:18:45 [ericP]
topic: response to rdf:text
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].
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_Lap, 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