IRC log of sparql on 2010-11-23

Timestamps are in UTC.

14:54:47 [RRSAgent]
RRSAgent has joined #sparql
14:54:47 [RRSAgent]
logging to
14:54:53 [Zakim]
Zakim has joined #sparql
14:55:03 [AxelPolleres]
trackbot, start meeting
14:55:05 [trackbot]
RRSAgent, make logs world
14:55:07 [trackbot]
Zakim, this will be 77277
14:55:07 [Zakim]
ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 5 minutes
14:55:08 [trackbot]
Meeting: SPARQL Working Group Teleconference
14:55:08 [trackbot]
Date: 23 November 2010
14:55:36 [AxelPolleres]
14:55:45 [AxelPolleres]
chair: Axel Polleres
14:55:54 [LeeF]
zakim, this will be SPARQL
14:55:54 [Zakim]
ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 5 minutes
14:55:55 [AxelPolleres]
regrets: Chime, MattPerry, NickH, OlivierCorby
14:57:50 [Zakim]
SW_(SPARQL)10:00AM has now started
14:57:57 [Zakim]
14:58:10 [cbuilara]
Zakim, +?P9 is me
14:58:10 [Zakim]
sorry, cbuilara, I do not recognize a party named '+?P9'
14:58:20 [cbuilara]
Zakim, +??P9 is me
14:58:20 [Zakim]
sorry, cbuilara, I do not recognize a party named '+??P9'
14:58:33 [cbuilara]
Zakim, +P9 is me
14:58:33 [Zakim]
sorry, cbuilara, I do not recognize a party named '+P9'
14:58:44 [Zakim]
14:58:46 [Zakim]
14:58:51 [cbuilara]
14:58:58 [SteveH_]
SteveH_ has joined #sparql
14:59:07 [AndyS]
zakim, ??P12 is me
14:59:07 [Zakim]
+AndyS; got it
14:59:15 [AxelPolleres]
cbuilara is carlos
14:59:16 [pgearon]
pgearon has joined #sparql
14:59:25 [cbuilara]
zakim, ??P9 is me
14:59:25 [Zakim]
+cbuilara; got it
14:59:36 [Zakim]
15:00:05 [Zakim]
+ +3539149aaaa
15:00:14 [Zakim]
15:00:15 [AlexPassant]
Zakim, +3539149aaaa is me
15:00:15 [Zakim]
+AlexPassant; got it
15:00:26 [Zakim]
15:00:28 [AxelPolleres]
Zakim, who is on the phone?
15:00:28 [Zakim]
On the phone I see cbuilara, AxelPolleres, AndyS, kasei, AlexPassant, pgearon, SteveH
15:01:21 [Zakim]
15:01:29 [LeeF]
zakim, Lee_Feigenbaum is me
15:01:31 [Zakim]
+LeeF; got it
15:01:44 [Zakim]
15:02:10 [AxelPolleres]
15:02:39 [AxelPolleres]
scribe: leeF
15:02:53 [AxelPolleres]
topic: admin
15:02:58 [LeeF]
# PROPOSED: Approve minutes at
15:03:01 [LeeF]
PROPOSED: Approve minutes at
15:03:03 [cbuilara]
I can hear you
15:03:05 [AndyS]
can hear you
15:03:18 [AxelPolleres]
RESOLVED: Approve minutes at
15:03:51 [AxelPolleres] comments summary
15:03:56 [LeeF]
AxelPolleres: comments page has been updated as above ^^^
15:04:10 [LeeF]
... still a few questions about whether responses are needed to some comments
15:04:32 [LeeF]
... one thread from Richard C about protocol faults
15:04:39 [LeeF]
... another from ???
15:04:45 [LeeF]
... do we need to reply officially?
15:05:46 [LeeF]
LeeF: we do need to reply to Richard, once we handle protocol issues
15:06:56 [LeeF]
... other was from Ross H, which we've replied to
15:07:29 [AxelPolleres]
* BINDINGS in SPARQL Query 2010-10-14 Dave Beckett ... answered by Peter Ansell
15:07:30 [AxelPolleres]
* typo in SPARQL 1.1 Query Language WD: invalid property "rdf:next" Michael Schneider ... answered by Andy
15:07:30 [AxelPolleres]
* Permit LOAD from a SPARQL CONSTRUCT endpoint David Booth ... answered by Alex
15:07:30 [AxelPolleres]
15:07:36 [AndyS]
15:07:38 [AlexPassant]
15:07:43 [LeeF]
ack AndyS
15:07:52 [AndyS]
On emment -
15:07:56 [AndyS]
One moment ....
15:08:02 [LeeF]
q+ AndyS
15:08:05 [LeeF]
ack AlexPassant
15:08:22 [NicoM]
NicoM has joined #Sparql
15:09:27 [AxelPolleres]
ACTION: ask Davidf booth for confirmation of reply and add row to comments table
15:09:27 [trackbot]
Sorry, couldn't find user - ask
15:09:40 [LeeF]
ACTION: Alex to ask Davidf booth for confirmation of reply and add row to comments table
15:09:41 [trackbot]
Created ACTION-334 - Ask Davidf booth for confirmation of reply and add row to comments table [on Alexandre Passant - due 2010-11-30].
15:09:57 [LeeF]
AndyS: editorial matters, checked with Lee and went ahead and replied
15:10:36 [LeeF]
ack AndyS
15:10:47 [LeeF]
AxelPolleres: comment on BINDINGS does not need our action
15:10:54 [LeeF]
AxelPolleres: Please check comments list and see if you can move any forwards
15:11:19 [LeeF]
... in particular, there is one on property paths that we haven't addressed yet - has anyone looked at that?
15:11:43 [LeeF]
AndyS: yes, it's a very good summary of everything we've talked about, but i don't think changes our position - we have been cognizant of the points raised when we made our decisions
15:11:56 [SteveH]
15:12:08 [LeeF]
... raises issue of equivalence between triple patterns and path pattern, and also about considering future extensions to include length of paths
15:12:32 [SteveH]
15:13:06 [LeeF]
AndyS: Good points, but no new information. Will draft a response
15:13:09 [LeeF]
+1 AndyS
15:13:19 [LeeF]
s/+1 AndyS/LeeF: +1 AndyS
15:14:05 [LeeF]
Next regular meeting: 2010-11-30 @ 15:00 UK / 10:00 EST (scribe: Carlos Buil)
15:14:23 [LeeF]
topic: Publication schedule
15:15:44 [AxelPolleres]
ACTION: alex to address MS-1 comment
15:15:45 [trackbot]
Created ACTION-335 - Address MS-1 comment [on Alexandre Passant - due 2010-11-30].
15:15:51 [LeeF]
(DIsucssion around comment MS-1, which Alex agrees to own)
15:16:14 [LeeF]
AxelPolleres: In October we discussed our schedule and trying to get to Last Call
15:16:14 [AxelPolleres]
15:16:45 [AlexPassant]
LeeF: you can close ACTION-334 : I've updated table and asked David (off-list) to acknowledge (on-list)
15:16:49 [LeeF]
AxelPolleres: per our schedule, we should be reviewing docs for Last Call now
15:16:57 [LeeF]
trackbot, close ACTION-334
15:16:57 [trackbot]
ACTION-334 Ask Davidf booth for confirmation of reply and add row to comments table closed
15:17:09 [LeeF]
AxelPolleres: what can we do / do we need to do to get to Last Call?
15:17:56 [AxelPolleres]
15:18:16 [LeeF]
AndyS: Everything is marked in the document with @@ as to what needs to be done from my point-of-videw
15:18:20 [LeeF]
15:18:25 [LeeF]
AndyS: There is a lot of editing to be done
15:18:31 [LeeF]
AndyS: I've done BIND
15:18:48 [LeeF]
AndyS: Doing GROUP BY ... AS ...
15:19:05 [LeeF]
AndyS: There are consistency things that need to be done, such as aligning grammar fragments throughout the document - will do once grammar is stable
15:19:11 [LeeF]
AndyS: And a lot of general editing to do
15:19:24 [LeeF]
AxelPolleres: what's missing for the grammar?
15:19:30 [LeeF]
AndyS: decision on verbs for update
15:20:19 [LeeF]
LeeF: what needs a group decision if anything?
15:20:45 [LeeF]
AndyS: don't think anything, there was a discussion around prefixed names which would radically change things, but don't htink there's anything right now where WG action is blocking progress
15:21:01 [LeeF]
AxelPolleres: any time frame estimate?
15:21:03 [LeeF]
AndyS: about a month
15:21:14 [AndyS]
... very rough estimate
15:21:15 [LeeF]
AxelPolleres: Steve?
15:21:30 [LeeF]
SteveH: have two pages of notes on things that want to change - probably about 3 days of editing effort, hoping to find 3 days of time before the end of December
15:21:53 [LeeF]
AndyS: (to Steve) we need to link up on formal semantics of aggregation
15:21:59 [LeeF]
SteveH: hoping first to fix information gap in how things line up
15:22:06 [LeeF]
SteveH: and then check if you (AndyS) believe it
15:23:08 [LeeF]
AxelPolleres: ready before christmas?
15:23:15 [LeeF]
SteveH: no, ready before end of December
15:24:00 [LeeF]
LeeF: if documents are ready at the end of December, probably not publishing LC before the end of January
15:24:03 [LeeF]
AxelPolleres: update?
15:24:08 [LeeF]
pgearon: one issue is shortcuts
15:24:18 [LeeF]
AlexPassant: comments on formal model that have not been addressed
15:24:30 [LeeF]
AlexPassant: also comments on bnodes and other things from previous reviews that need to be incorporated
15:24:42 [LeeF]
AlexPassant: shortcuts, formal model, comments from previous reviews
15:27:28 [LeeF]
AxelPolleres: Sandro?
15:27:32 [LeeF]
sandro: I can work on that any time.
15:27:43 [LeeF]
AxelPolleres: We'll find a common time to discuss.
15:28:04 [LeeF]
AxelPolleres: ... issues about embedding RIF in RDF
15:28:26 [AxelPolleres]
ACTION: axel to check back with Birte/chime on entailment regimes schedule
15:28:26 [trackbot]
Created ACTION-336 - Check back with Birte/chime on entailment regimes schedule [on Axel Polleres - due 2010-11-30].
15:29:25 [AxelPolleres]
15:29:43 [LeeF]
AndyS: base URI matter and handling of default graphs still to be addressed in HTTP protocol document
15:29:49 [AxelPolleres]
LeeF: I got back to chime to inform us about status
15:30:17 [AxelPolleres]
service description?
15:30:19 [LeeF]
AxelPolleres: service desc?
15:30:22 [LeeF]
kasei: two issues
15:30:29 [LeeF]
kasei: add feature URI for basic federated queries
15:30:42 [LeeF]
kasei: have some links and text that need to align with a protocol document whenever that is dealt with
15:31:16 [AxelPolleres]
no objections to kasei address the first item.
15:31:26 [AxelPolleres]
15:31:59 [AxelPolleres]
LeeF: dedicated TC would probably help
15:32:50 [AxelPolleres]
protocol doc a bit laging, no dedicated editor at the moment.
15:33:26 [LeeF]
Who would be willing to participate in working sessions around protocol?
15:33:31 [SteveH]
telecon, yes. editing, no
15:33:45 [kasei]
I'd be willing to help.
15:33:59 [LeeF]
Lee would be willing to help
15:34:00 [AndyS]
As SteveH
15:34:30 [AxelPolleres]
ACTION: LeeF to sned out a doodle poll on protocol TC
15:34:30 [trackbot]
Created ACTION-337 - Sned out a doodle poll on protocol TC [on Lee Feigenbaum - due 2010-11-30].
15:35:24 [AxelPolleres]
Axel: outcome needed of that dedicated TC is a schedule (Andy: and who's doing the writing)
15:36:01 [ivan]
ivan has joined #sparql
15:36:03 [AndyS]
AndyS: schedule requires writing effort
15:36:15 [ivan]
zakim, dial ivan-voip
15:36:15 [Zakim]
ok, ivan; the call is being made
15:36:17 [Zakim]
15:36:18 [AxelPolleres]
federated query extension?
15:36:42 [AxelPolleres]
carlos: want to have everything ready by 21 dec
15:36:44 [AndyS]
15:37:19 [AxelPolleres]
carlos: would appreciate feedback.
15:37:23 [LeeF]
AndyS: are there any syntax changes?
15:37:27 [LeeF]
carlos: no
15:37:28 [AxelPolleres]
andy: any syntax changes in mind?
15:38:37 [AxelPolleres]
15:38:40 [AxelPolleres]
15:39:40 [LeeF]
AxelPolleres: some changes with examples, list everyone contributing as participants
15:39:49 [AxelPolleres]
update by mid of december.
15:40:27 [ivan]
15:40:45 [LeeF]
AxelPolleres: ivan is leaving us as staff contact, thanks to ivan for all of his help
15:40:46 [AndyS]
15:41:03 [LeeF]
ivan: restructuring in light of new groups and w3c resources
15:41:10 [LeeF]
... will be picking up rdb2rdf staff contact
15:41:16 [LeeF]
... also new rdf group coming up
15:41:22 [LeeF]
... will stay on SPARQL mailing list
15:41:53 [LeeF]
ack AndyS
15:42:04 [LeeF]
AndyS: what's the status of the function library document?
15:43:11 [AxelPolleres]
topic: shortcuts
15:43:13 [AndyS]
zakim, who is on the phone?
15:43:13 [Zakim]
On the phone I see cbuilara, AxelPolleres, AndyS, kasei, AlexPassant, pgearon, SteveH, LeeF, Sandro, Ivan
15:44:12 [AxelPolleres]
PROPOSED1: Add update shortcuts in LC marked explicitly "AT RISK" and asking for feedback, explicitly about potentially complicating the language, and implementation experience.
15:44:21 [AxelPolleres]
PROPOSED2: postpone ISSUE-59
15:44:33 [SteveH]
15:44:44 [AlexPassant]
+1 for a strawpoll
15:44:45 [SteveH]
15:44:51 [ivan]
15:45:22 [LeeF]
SteveH: how about one strawpoll?
15:45:38 [LeeF]
sandro: is the reason not to do this because it slows down the schedule?
15:46:01 [AlexPassant]
It wont slow down schedule imo
15:46:08 [AndyS]
15:46:10 [AlexPassant]
not from an editing pov at least
15:46:13 [SteveH]
15:46:23 [LeeF]
LeeF: expresesd concerns relate to not wanting to add shortcuts into the language yet
15:46:39 [AndyS]
15:47:23 [LeeF]
AxelPolleres: +1 is for adding shortcuts, -1 is for postponing work on shortcuts
15:47:44 [AndyS]
Small point: we already have a "shortcut" -- CLEAR
15:48:07 [AxelPolleres]
+1 is for adding shortcuts, -1 is for postponing work on shortcuts
15:48:08 [kasei]
15:48:09 [SteveH]
15:48:10 [AlexPassant]
15:48:12 [LeeF]
sandro: +1
15:48:15 [AndyS]
15:48:19 [Zakim]
15:48:34 [LeeF]
15:48:37 [cbuilara]
15:48:42 [pgearon]
15:48:53 [ivan]
zakim, dial ivan-voip
15:48:53 [Zakim]
ok, ivan; the call is being made
15:48:55 [Zakim]
15:49:12 [ivan]
15:49:31 [AxelPolleres]
15:49:52 [AxelPolleres]
15:50:05 [AxelPolleres]
ROPOSED: Add update shortcuts in LC marked explicitly "AT RISK" and asking for feedback, explicitly about potentially complicating the language, and implementation experience.
15:50:09 [LeeF]
15:50:10 [SteveH]
15:50:27 [AndyS]
15:50:31 [kasei]
15:50:47 [LeeF]
RESOLVED: Add update shortcuts in LC marked explicitly "AT RISK" and asking for feedback, explicitly about potentially complicating the language, and implementation experience, SteveH, LeeF, kasei abstaining
15:51:26 [LeeF]
15:51:26 [trackbot]
ISSUE-59 -- Shall we add shortcuts for update as proposed in -- open
15:51:26 [trackbot]
15:51:35 [LeeF]
ISSUE-59: RESOLVED: Add update shortcuts in LC marked explicitly "AT RISK" and asking for feedback, explicitly about potentially complicating the language, and implementation experience, SteveH, LeeF, kasei abstaining
15:51:35 [trackbot]
ISSUE-59 Shall we add shortcuts for update as proposed in notes added
15:51:40 [LeeF]
trackbot, close ISSUE-59
15:51:40 [AxelPolleres]
topic: function library
15:51:40 [trackbot]
ISSUE-59 Shall we add shortcuts for update as proposed in closed
15:51:55 [AxelPolleres]
15:54:02 [AxelPolleres]
15:54:26 [SteveH]
15:54:32 [AndyS]
Simple literals.
15:54:34 [kasei]
simple literals, please
15:54:58 [LeeF]
Simple literals, can always be casted with xsd:string(...)
15:55:08 [AxelPolleres]
seems that we need "own versions" for all
15:55:11 [AxelPolleres]
7.3.2 fn:compare
15:55:12 [AxelPolleres]
7.4.1 fn:concat
15:55:12 [AxelPolleres]
7.4.3 fn:substring
15:55:12 [AxelPolleres]
7.4.4 fn:string-length
15:55:13 [AxelPolleres]
7.4.7 fn:upper-case
15:55:13 [AxelPolleres]
7.4.8 fn:lower-case
15:55:14 [AxelPolleres]
7.4.10 fn:encode-for-uri
15:55:16 [AxelPolleres]
7.5.1 fn:contains (collation form optional)
15:55:18 [AxelPolleres]
7.5.2 fn:starts-with
15:55:20 [AxelPolleres]
7.5.3 fn:ends-with
15:55:52 [SteveH]
CONCAT(...) == STR(fn:concat(...))
15:56:03 [LeeF]
LeeF: Would like to be able to freely compose these functions that deal in strings
15:57:37 [SteveH]
"Atomic datatypes are those having values which are regarded by this specification as being indivisible."
15:57:50 [AndyS]
"Atomic datatypes are those having values which are regarded by this specification as being indivisible. "
16:00:02 [Zakim]
16:00:40 [LeeF]
adjourned, officially
16:00:57 [SteveH]
sorry, got kicked, missed the end of AndyS's diatribe
16:01:18 [Zakim]
16:02:10 [ivan]
zakim, drop me
16:02:10 [Zakim]
Ivan is being disconnected
16:02:11 [Zakim]
16:02:42 [Zakim]
16:02:43 [Zakim]
16:02:44 [Zakim]
16:02:49 [Zakim]
16:02:53 [Zakim]
16:03:15 [AxelPolleres]
Axel: Andy, would there for the string related functions speak anything against defining our own that treat strings and simple literals the same and return simple lieterals instead of strings?
16:03:21 [AxelPolleres]
Any: that sounds doable
16:03:31 [AxelPolleres]
16:03:46 [AxelPolleres]
adjourned for real now... thanks all!
16:03:48 [Zakim]
16:03:49 [Zakim]
16:03:51 [Zakim]
SW_(SPARQL)10:00AM has ended
16:03:53 [Zakim]
Attendees were AxelPolleres, AndyS, cbuilara, kasei, pgearon, AlexPassant, SteveH, LeeF, Sandro, Ivan
16:03:57 [AxelPolleres]
rrsagent, make records public
16:05:43 [AndyS]
Re: keyword CONCAT
16:06:05 [AndyS]
Is it proposed to add that to SPARQL?
16:07:22 [SteveH]
it was in the summary note from Axel, so I hope so
16:08:55 [AxelPolleres]
CONCAT ... I understood yes... it is one of the string functions in question
16:09:16 [kasei]
but not all of the functions are getting keywords, right?
16:09:29 [AxelPolleres]
16:09:36 [AndyS]
My Q exactly.
16:11:26 [kasei]
yeah, i was confused by that. if they aren't all getting keywords, then we can't use steve's syntactic equivalent proposal using STR().
16:13:55 [AndyS]
A complete proposal would be good then telecon time can be quite short (?)
16:15:53 [kasei]
this scares me (from Axel's email): "i.e. makes fnsparql: functions usable without the prefix"
16:19:35 [sandro]
AxelPolleres, sorry, I forgot and hung up without talking to you about RIF-in-RDF
16:25:41 [AndyS]
kasei: agree strongly. Whole grammar is fixed keyword based. A function called SELECT?!!
16:26:25 [AndyS]
Would need (1) context sensitive tokenizing or (2) emerate all keywords in the function rule+general keyword catcher. Yuk to both.
16:27:02 [kasei]
does anyone have any idea how I might add RDFa to an xmlspec document?
16:27:18 [kasei]
I haven't the faintest idea where to start.
16:28:15 [SteveH]
yeah, I want keywords in the grammar
16:28:30 [SteveH]
kasei, cargo cult it?
16:28:39 [kasei]
are there existing examples?
16:28:41 [AndyS]
No idea - I have found the XSLT tends to either pass through or remove stuff it does not know in different ways in different places. eg.. <p class=""> seems to loose class=
16:28:46 [SteveH]
there are some good examples if you google for them
16:29:14 [SteveH]
kasei, ah, I see
16:29:15 [kasei]
ha! first result for "xmlspec rdfa" is the service description document.
16:29:19 [SteveH]
yeah, that sounds optomistic
16:32:00 [AndyS]
Like a command line parser I wrote many years ago. After a while, went looking for a better one (not a hack) and only found my old code.
16:35:34 [kasei]
this may be hopeless.
16:36:02 [kasei]
just changing the doctype seems like a challenge.
16:38:03 [AxelPolleres]
"this scares me (from Axel's email): "i.e. makes fnsparql: functions usable without the prefix"
16:38:13 [AxelPolleres]
hmmm, in what sense?
16:38:52 [kasei]
a magic namespace prefix? in what way shouldn't that scare me? :)
16:39:08 [kasei]
too much like virtuoso's bif: namespace.
16:39:35 [kasei]
they should either be actual keywords or proper functions.
16:39:57 [AxelPolleres]
well, we have already functions that don't need a prefix (bound, str ...)
16:40:42 [kasei]
those are actual keywords, though. the way you phrased the email suggested having a default namespace for functions that would make this work without them being keywords.
16:40:47 [kasei]
at least that's how I understood it.
16:41:03 [AxelPolleres]
All I meant to suggest was that all the functions we agree to be within the interoperable set of functions for SPARQL1.1, ie those within the fnsparql: namespace, be usable without an explicit prefix.
16:41:09 [AndyS]
I read it as open ended set of keywords. Tricky. Also, talks about profiles.
16:41:40 [AxelPolleres]
didn't mean open ended, but only those rubber-stamped by the SPARQL1.1 spec.
16:41:58 [AxelPolleres]
ie. those we expect all SPARQL1.1 compliant engines to support.
16:42:26 [AxelPolleres]
I would find it awkward if we need - for those - prefixes for some and not for others.
16:43:30 [AxelPolleres]
profiles will probably not work for us, true, because we don't have that mechanism (only exists for RDFa, right?) and we don't have time left to define it.
16:43:51 [AxelPolleres]
so why not just give all the functions we want "in" an fnsparql: URI?
16:45:17 [AndyS]
?? you're arguing for keywords as well as fnsparql: URIs?
16:46:06 [AxelPolleres]
what I have in mind is like in XQuery... the fn: functions don't need to be prefixed in XQuery, ie concat("a","b") is a perfectly fine XQuery.
16:48:14 [kasei]
so a keyword and a uri for every function?
16:48:24 [AxelPolleres]
ie. any function func(...) without a prefix is understood as fnsparql:func(...) whereas if you want other functions you need to give a full URI.
16:49:52 [AndyS]
Because xquery uses the base URI?
16:50:26 [AndyS]
<concat>("a", "b") would work in SPARQL is base is as fn: is.
16:50:54 [AxelPolleres]
16:51:36 [AxelPolleres]
Do you assume bound(), str() etc. to have no corresponding URIs?
16:51:54 [kasei]
i don't like the idea of relying on BASE, though, because application-defined bases are useful.
16:52:10 [kasei]
they might, but not necessarily.
16:52:35 [AxelPolleres]
16:54:36 [kasei]
i'm guessing that the uri in that section is a suggested uri for the operator?
16:54:49 [kasei]
hadn't seen that before.
16:55:36 [AxelPolleres]
so, I thought all operators have a URI, and that for all fnsparql: operators there is likewise an operator/keyword in the language.
16:55:50 [AxelPolleres]
16:56:28 [kasei]
they didn't all have iris in 1.0
16:56:51 [kasei]
and i'm not sure i want the whole function library ending up as keywords
16:57:37 [kasei]
too many obscure things that don't need to be keywords
16:57:45 [AxelPolleres]
? for instance?
16:57:45 [kasei]
like fn:seconds-from-dateTime
16:58:06 [SteveH]
that's really useful!
16:58:13 [SteveH]
use the SQL equivalent all the time
16:58:18 [kasei]
but I don't want it as a keyword! :)
16:58:29 [SteveH]
16:58:39 [SteveH]
I do, but not right now
16:58:41 [AxelPolleres]
the problem i see is in teaching sparql ... how do I convey to people: this is thes set of functions sparql supports... some of them have prefixes, some don't... why?
16:59:05 [SteveH]
AxelPolleres, what do you mean by prefixes? they're QNames, or Keywords
16:59:08 [kasei]
SteveH: do you want all of the dateTime functions as keywords? timezone-from-dateTime?
16:59:11 [SteveH]
...or URIs
16:59:41 [SteveH]
kasei, not right now, but compared to implementing, say, property patch a few dozen DT functions is a walk in the park
16:59:49 [AxelPolleres]
I think it's fair that the limited set of functions we expect to be intereoperable between all implementations usable as keywords without prefix, yes.
16:59:52 [SteveH]
SPARQL 1.2 can have more in it :)
17:00:00 [SteveH]
AxelPolleres, agreed
17:00:24 [kasei]
agreed it's not hard to implement. I just think it clutters the language. it doesn't seem fundamental enough to deserve a keyword to me.
17:00:40 [AxelPolleres]
if we think that some of the proposed fn: functions are too "obscure" then let's not include them...
17:01:32 [AxelPolleres]
I think prefixes for some functions and no prefixes for others (among the standard function library) clutters the language... at least, for users.
17:01:59 [AndyS]
I am not clear what you are proposing : why not just add keywords as necessary. keywords and URI are documented together but it's not an alternative calling mechanism. And some of the builtins don't obey XSD eval rules.
17:02:02 [AndyS]
17:03:04 [AndyS]
and keywords with "-" in would a style change. (COBOL!)
17:03:20 [AxelPolleres]
I was proposing something like
17:03:42 [AxelPolleres]
[61'] FunctionCall ::= (IRIref |Qname) ArgList
17:03:48 [AxelPolleres]
17:04:51 [AxelPolleres]
[61'] FunctionCall ::= (IRIref |PN_LOCAL) ArgList
17:05:24 [AxelPolleres]
where a "PN_Local" would be interpreted as "fnsparql:PN_Local"
17:05:28 [AxelPolleres]
wouldn't that work?
17:05:30 [AndyS]
PN_LOCAL is not a token visible to the grammar.
17:06:06 [AxelPolleres]
what do you mean by "visible
17:06:09 [AxelPolleres]
17:06:12 [AndyS]
PN_LOCAL only occurs inside a prefixed name --> must have a :
17:06:14 [SteveH]
AndyS, doesn't lisp also allow - in function names (that's two strikes ;)
17:06:21 [AxelPolleres]
17:06:32 [AxelPolleres]
[152] PN_LOCAL ::= ( PN_CHARS_U | [0-9] ) ((PN_CHARS|'.')* PN_CHARS)?
17:06:33 [AndyS]
"Lisp"? Not one lisp but yes.
17:07:09 [AndyS]
How do you think "xyz:select" parses?
17:07:39 [AxelPolleres]
Why can't I reuse PN_LOCAL at another place in the grammar?
17:07:43 [AndyS]
It's' one token (greedy rule) including the ":"
17:07:55 [AndyS]
Try it and see.
17:07:58 [AxelPolleres]
I don't understand.
17:08:17 [AndyS]
"SELECT *" is what exactly?
17:08:28 [AxelPolleres]
PNAME_NS has the ":"
17:08:35 [AndyS]
a function call? a SELECT clause?
17:08:39 [AxelPolleres]
PN_LOCAL doesn't
17:10:25 [AxelPolleres]
what you are referrring to is that there would be conflicts if other keywords were used as function names??!?
17:10:34 [AndyS]
And where is PN_LOCAL used? only via PNAME_LN, BLANK_NODE_LABEL
17:11:03 [AndyS]
longer tokens that involve a mandator :
17:11:03 [AxelPolleres]
and why can't it be used along ArgList ?
17:12:00 [AndyS]
Parsing works by generating tokens then deciding what to do. (true for LL or LALR or indeed LR)
17:12:20 [AndyS]
tokens are content-insensitive.
17:12:24 [AndyS]
tokens are context-insensitive.
17:13:08 [AndyS]
The token set does not change during parsing (can do that in javacc - it's outside LL)
17:13:40 [AxelPolleres]
sure, I am trying to understand why "PN_LOCAL Arglist" would raise an ambiguity.
17:13:45 [AndyS]
The grammar (lowercase and mnixed case rules) see PNAME_LN, BLANK_NODE_LABEL
17:14:50 [AndyS]
Because the tokenizer never generates PN_LOCAL - it's always part of a larger token that is known to be that token before PN_LOCAL reached. Example: ...
17:15:15 [AndyS]
Suppose the tokenizer sees the letters S E L E C T
17:15:25 [AndyS]
what token does it emit?
17:19:53 [AxelPolleres]
hmmm, and the only other alternative is to put each and every built-in call which we want accessible as a keyword in the grammar, as inf rule [106] yes?
17:20:29 [AxelPolleres]
and you don't want to put all functions of the SPARQL1.1 function library there... yes? or would that be an alternative?
17:20:55 [AxelPolleres]
(sorry need to run for another meeting :-( )
17:21:04 [AxelPolleres]
take this to email?
17:21:39 [AxelPolleres]
would adding all our function library to rule [106] be an alternative?
17:21:47 [AxelPolleres]
need to really run, sorry
17:21:48 [AxelPolleres]
AxelPolleres has left #sparql
17:22:02 [AxelPolleres]
AxelPolleres has joined #sparql
17:22:03 [AxelPolleres]
AxelPolleres has left #sparql
18:16:23 [Zakim]
Zakim has left #sparql
18:19:01 [kasei]
fn:compare is intended to respect the xpath defn. w.r.t. all-string arguments?
18:19:40 [kasei]
(modulo the xsd:string vs. simple literal issue)
18:28:34 [AndyS]
Given the time available, tempting to define our own string ops (and keywords for them as often (?) used), own URI namespace. Shortest path to LC.
18:34:41 [kasei]
19:10:53 [cbuilara]
cbuilara has left #sparql
20:16:38 [LeeF]
I'd be happy (enough) with that
20:16:49 [LeeF]
In glitter, all my keyword functions are also invokable via URI
20:16:59 [LeeF]
i'm starting to move more and more to just invoking all functions as URI
20:17:03 [LeeF]
well, except operators
20:35:02 [karl]
karl has joined #sparql
21:18:57 [AndyS]
AndyS has joined #sparql