IRC log of sparql on 2010-12-07

Timestamps are in UTC.

14:51:22 [RRSAgent]
RRSAgent has joined #sparql
14:51:22 [RRSAgent]
logging to
14:51:31 [AxelPolleres]
trackbot, this will be sparql
14:51:31 [trackbot]
Sorry, AxelPolleres, I don't understand 'trackbot, this will be sparql'. Please refer to for help
14:51:42 [Zakim]
Zakim has joined #sparql
14:51:51 [AxelPolleres]
zakim, this will be SPARQL
14:51:51 [Zakim]
ok, AxelPolleres; I see SW_(SPARQL)10:00AM scheduled to start in 9 minutes
14:52:01 [AxelPolleres]
14:52:45 [AxelPolleres]
(don't get schocked by the agenda updates, top list of topics remained the same, just tried to add links to latest mails for reference)
14:57:46 [LeeF]
trackbot, start meeting
14:57:48 [trackbot]
RRSAgent, make logs world
14:57:50 [trackbot]
Zakim, this will be 77277
14:57:50 [Zakim]
ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 3 minutes
14:57:51 [trackbot]
Meeting: SPARQL Working Group Teleconference
14:57:51 [trackbot]
Date: 07 December 2010
14:57:54 [LeeF]
zakim, this will be SPARQL
14:57:54 [Zakim]
ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 3 minutes
14:58:02 [Zakim]
SW_(SPARQL)10:00AM has now started
14:58:10 [Zakim]
14:58:16 [Zakim]
14:59:02 [Zakim]
14:59:24 [Zakim]
14:59:54 [Zakim]
14:59:58 [MattPerry]
MattPerry has joined #sparql
15:00:05 [chimezie]
chimezie has joined #sparql
15:00:31 [Zakim]
15:00:42 [Zakim]
15:01:12 [AndyS]
Booting up ...
15:01:20 [AxelPolleres]
15:01:58 [AxelPolleres]
Zakim, who is on the phone?
15:01:59 [Zakim]
On the phone I see AxelPolleres, LeeF, SteveH, kasei, Sandro, Chimezie_Ogbuji, MattPerry
15:02:20 [Zakim]
15:02:40 [AndyS]
zakim, get a move on
15:02:40 [Zakim]
I don't understand 'get a move on', AndyS
15:02:56 [Souri]
Souri has joined #sparql
15:03:01 [AxelPolleres]
scribe: Chime
15:03:14 [AndyS]
zakim, who is on the phone?
15:03:14 [Zakim]
On the phone I see AxelPolleres, LeeF, SteveH, kasei, Sandro, Chimezie_Ogbuji, MattPerry, Simon
15:03:19 [AxelPolleres]
Zakim, Simon is actually AndyS
15:03:19 [Zakim]
I don't understand 'Simon is actually AndyS', AxelPolleres
15:03:22 [Zakim]
15:03:23 [Zakim]
15:03:42 [AxelPolleres]
Zakim, ??P25 is Souri
15:03:42 [Zakim]
+Souri; got it
15:03:48 [Zakim]
15:03:54 [AndyS]
zakim, ??P21 is me
15:03:54 [Zakim]
+AndyS; got it
15:04:18 [chimezie]
LeeF: want to finish functional libraries discussion
15:04:24 [AxelPolleres]
tpoic: admin
15:04:37 [AxelPolleres]
PROPOSED: Approve minutes at
15:05:07 [AxelPolleres]
RESOLVED: Approve minutes at
15:05:14 [Zakim]
15:05:17 [chimezie]
Zakim, mute me
15:05:17 [Zakim]
Chimezie_Ogbuji should now be muted
15:05:49 [chimezie]
AxelPolleres: New comment from David Beckett
15:05:58 [chimezie]
... Carlos volunteered to draft reply
15:05:59 [SteveH]
I can reply to dave
15:06:03 [SteveH]
it's mostly about my stuff
15:06:34 [AxelPolleres]
ACTION: SteveH draft reply to Dave Beckett's comment
15:06:34 [trackbot]
Created ACTION-340 - Draft reply to Dave Beckett's comment [on Steve Harris - due 2010-12-14].
15:07:16 [AxelPolleres]
topic: function library
15:07:58 [chimezie]
AxelPolleres: piped literals v.s. plain literals for arguments in return types
15:08:18 [SteveH]
15:08:20 [chimezie]
AxelPolleres: Andy proposed to renam LEN to STRLEN (hope no objections)
15:08:23 [sandro]
15:08:24 [Souri]
15:08:25 [LeeF]
15:08:42 [chimezie]
15:08:51 [AxelPolleres]
15:09:07 [AxelPolleres]
15:09:43 [chimezie]
Andy: put aside CONCAT
15:09:56 [chimezie]
... for all others, work on one string (mostly)
15:10:27 [chimezie]
AndyS: language tags coming in, go out (same with xsd:string datatype)
15:10:41 [chimezie]
... arguments are treated as characters (exactly the same lang tag) can be compared
15:11:10 [chimezie]
... implying something stronger will not work
15:11:17 [chimezie]
.. either false or errors
15:11:39 [chimezie]
... problematic to assume language tags have a hierarchy - gets tricky
15:12:44 [chimezie]
Sandro: common case is @en. Will this prevent use of this?
15:12:49 [AxelPolleres]
sandro: en vs en-US vs. en-UK
15:12:53 [AxelPolleres]
15:13:12 [Souri]
STARTS("abc"@en, "a"@en-UK) can be replaced with STARTS(ENCODES(?str1),ENCODES(?str2)), right?
15:13:20 [chimezie]
AndyS: STR can be used to remove language tag
15:13:40 [pgearon]
AncyS, so are you saying that startsWith("foobar"@en, "foo") will not work?
15:13:54 [pgearon]
15:13:55 [AndyS]
pgearon - will work.
15:14:11 [chimezie]
AndyS: second argument doesn't have language tag, so example will work
15:14:24 [kasei]
I think sandro's use case if important. STARTS("foo"@en-UK, "f"@en) -- match all english literals regardless of UK, US, etc.
15:14:32 [SteveH]
startsWith("foobar"@en-GB, "foo"@en-US) is what won't work, right?
15:14:46 [chimezie]
AxelPolleres: worry about derived datatypes?
15:15:29 [chimezie]
AndyS: don't know how to make Steve's example work without analyzing the language tags
15:15:57 [AxelPolleres] derived types? e.g. xs:NCName vs xs:string do we need to worry?
15:16:01 [kasei]
I think the language comparison should be grounded in langMatches()
15:17:02 [chimezie]
AndyS: derived types get naturally handled by super type
15:17:15 [chimezie]
AxelPolleres: in any combination?
15:17:49 [chimezie]
AndyS: not required to support those types currently in SPARQL
15:17:49 [SteveH]
kasei, interesting idea
15:18:29 [AxelPolleres]
starts( "abc"^^xs:string, "a"^^xsd:NCName)
15:19:07 [kasei]
15:19:18 [kasei]
(sorry. i keep posting things in irc)
15:19:51 [chimezie]
Greg: for these operations (comparison on languages) it should be based on langMatches function
15:20:02 [LeeF]
ack karl
15:20:04 [LeeF]
ack kasei
15:20:17 [chimezie]
... want to query across variations of english for *all* languages, using langMatches will support this
15:20:22 [chimezie]
Zakim, who is on the phone?
15:20:22 [Zakim]
On the phone I see AxelPolleres, LeeF, SteveH, kasei, Sandro, Chimezie_Ogbuji (muted), MattPerry, Souri, AndyS, pgearon
15:20:27 [AxelPolleres]
15:20:33 [kasei]
STARTS("foo"@en-UK, "f"@en)
15:21:03 [chimezie]
AndyS: don't know how to make that work in all possible cases
15:21:18 [pgearon]
15:21:24 [AxelPolleres]
15:21:38 [chimezie]
... not sure if langMatches covers everything
15:22:01 [SteveH]
LANGMATCHES("en-UK", "en") is true, LANGMATCHES("en", "en-UK") is false
15:22:08 [AxelPolleres]
calling STR + langmatches explicitly seems to cover kasei's use case?
15:22:14 [chimezie]
Paul: sounds like big task for small usecase. don't want to mandate implementations in this way
15:22:21 [chimezie]
... too detailed to specify
15:22:27 [kasei]
pgearon, we already mandate langMatches support, though, right?
15:23:00 [SteveH]
15:23:05 [chimezie]
Paul: My typical usecase is a single language
15:23:34 [chimezie]
SteveH: (support for lang tags). Use two types of english in my RDF store
15:23:46 [SteveH]
+ german, french and italian
15:24:14 [chimezie]
AxelPolleres: haven't heard concrete alternative proposal
15:24:18 [SteveH]
but, I'm OK with what Andy suggests
15:24:20 [chimezie]
... move forward or think about it?
15:24:47 [chimezie]
AndyS: german / austrian - same word , different characters
15:25:15 [AxelPolleres]
"Januar"@de-DE = "Jänner"@de-AT (January)
15:25:18 [chimezie]
... an element of not saying lang matches are in terms of content and not character manipulation
15:25:44 [chimezie]
SteveH: STR is a decent fallback
15:26:09 [SteveH]
...bu I don't think users would expect STARTS() to care about lang tag
15:26:12 [chimezie]
AxelPolleres: objections to moving forward with this?
15:26:34 [chimezie]
AndyS: if mismatches is an error, then it is an extension point
15:26:37 [SteveH]
-1 to it being an error
15:27:09 [chimezie]
SteveH: rather false. If expecting an error can strip out w/ STR
15:27:23 [chimezie]
... 99% of usecases, starts is called with pair of literals where language tags are not of concern
15:28:28 [kasei]
15:28:50 [SteveH]
15:28:54 [chimezie]
AxelPolleres: didn't discuss concatenation - anything missing regarding this?
15:29:06 [chimezie]
AndyS: took that out of equation (complicated)
15:29:40 [pgearon]
15:30:15 [chimezie]
... cases here are regarding mixture of language tags (what happens) or mixture of simple and xsd;string
15:30:30 [chimezie]
... for former, return simple strings (after attempt to resolve language tags)
15:31:47 [AxelPolleres]
concat ( "a"@en, "b"^^string, "c")
15:31:48 [AxelPolleres]
15:32:28 [AxelPolleres]
= "abc"@en
15:32:33 [AxelPolleres]
concat ( "b"^^string, "c")
15:32:42 [AxelPolleres]
15:32:52 [chimezie]
AndyS: I'm proposing this
15:32:53 [AxelPolleres]
15:33:00 [chimezie]
SteveH: prefer return simple literal
15:33:00 [AxelPolleres]
"bc" (steve)
15:33:39 [chimezie]
AndyS: people often use xsd:string by mistake (tools do their own thing)
15:34:11 [chimezie]
... want to avoid forcing into a datatype that wasn't in data
15:34:33 [AndyS]
CONCAT("a"^^xsd:string, "") -> "a" or "a"^^xsd:string
15:34:42 [chimezie]
SteveH: result would be suprising if I get xsd;string back
15:34:53 [chimezie]
... also question of consistency
15:35:45 [AxelPolleres]
strawpoll CONCAT("a"^^xsd:string, "") -> "a" (vote 1) or "a"^^xsd:string (vote 2)
15:35:50 [SteveH]
AndyS, or, a more real world example CONCAT(?var, "")
15:35:53 [chimezie]
if STR can be used to forcibly strip out lang tags, then it would seem preffered to maintain them
15:36:05 [chimezie]
15:36:08 [Souri]
15:36:11 [kasei]
1 (very mild preference)
15:36:18 [MattPerry]
15:36:21 [SteveH]
15:36:29 [SteveH]
(but not stong pref)
15:36:29 [AxelPolleres]
1 (mildly)
15:36:34 [kasei]
15:36:42 [AndyS]
15:36:46 [Souri]
1 (mildly)
15:36:58 [AxelPolleres]
15:37:24 [LeeF]
I'm pretty happy with always returning simple or always returning xsd:string. Using xsd:string(...) or STR(...) just isn't a big deal to me.
15:37:28 [chimezie]
Souri: difference betwen "a" and "a"^^xsd:string (should be equivalent). one is just longer representation of same thing
15:37:33 [LeeF]
Also happy with anything in between.
15:37:53 [kasei]
LeeF, me too, except not anything in between! :)
15:37:56 [AndyS]
15:38:20 [Souri]
15:38:30 [AxelPolleres]
ack AndyS
15:38:41 [chimezie]
AndyS: in RDF MT they are the same value but not same term
15:39:05 [AxelPolleres]
but aren't they only the same value in D entailment?
15:39:05 [chimezie]
Souri: two lexical forms of same canonical value
15:39:46 [chimezie]
my preference isn't strong
15:41:06 [chimezie]
SteveH: advice to editor is fine
15:41:21 [AxelPolleres]
advice to the editors is to go ahead with returning plain literals only, in case of miced input
15:41:26 [AndyS]
zakim, who is on the phone?
15:41:26 [Zakim]
On the phone I see AxelPolleres, LeeF, SteveH, kasei, Sandro, Chimezie_Ogbuji (muted), MattPerry, Souri, AndyS, pgearon
15:41:57 [chimezie]
Sandro: record as resolved since we have consensus
15:42:50 [AxelPolleres]
PROPOSED: CONCAT returns plain literals in case of mixed input (plain, typed) literals and inherits language tags if not ambiguous.
15:43:42 [chimezie]
AndyS: doesn't capture discussion
15:44:25 [AxelPolleres]
PROPOSED: CONCAT returns simple literals in case of mixed input (simple, typed) literals
15:44:40 [SteveH]
15:44:42 [AndyS]
15:44:57 [sandro]
15:45:11 [AxelPolleres]
RESOLVED: CONCAT returns simple literals in case of mixed input (simple, typed) literals
15:45:47 [AxelPolleres]
RESOLVED: CONCAT returns simple literals in case of mixed input (simple, typed) literals (one abstention)
15:46:39 [AxelPolleres]
topic: inclusion of SHA*/MD5 functions
15:47:20 [SteveH]
15:47:22 [chimezie]
AxelPolleres: SHA-1 and/or SHA-2
15:47:26 [AxelPolleres]
SHA1 vs. SHA-2?
15:47:31 [chimezie]
is there implementation burden to do both?
15:47:52 [chimezie]
SteveH: should have both
15:48:30 [chimezie]
AxelPolleres: issue with key length?
15:48:41 [AxelPolleres]
keylength? argument or in the function name?
15:48:45 [chimezie]
Sandro: SHA-2 has variable key length
15:49:00 [chimezie]
... do we allow key length to be a parameter to function?
15:49:01 [AndyS]
SHA-224, SHA-256, SHA-384, SHA-512
15:49:04 [SteveH]
there's 4 keys lengs
15:49:05 [chimezie]
... no preference
15:49:18 [SteveH]
256 and 512 are more common, in my experience
15:49:19 [AndyS]
are the 4 kinds
15:49:21 [MattPerry]
FYI: Oracle Database supports MD4, MD5 and SHA-1
15:50:00 [sandro]
15:50:07 [chimezie]
AndyS: same procedure, seeded differently
15:50:09 [AxelPolleres]
so we talk about 5 functions here: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 ?
15:50:23 [chimezie]
or 2 (where the latter is parameterized)?
15:50:57 [chimezie]
Sandro: agree to be compliant with standard branding (re-use their common names)
15:51:10 [chimezie]
... might shift however. SHA-3 for instance
15:51:51 [AxelPolleres]
SHA1 SHA224, SHA256, etc?
15:52:02 [chimezie]
AndyS: those are names of algorithms (happen to be key lengths w/ SHA-2)
15:52:02 [AxelPolleres]
... as function names?
15:54:17 [AndyS]
15:54:33 [sandro]
15:54:38 [AndyS]
is the standard (latest revision)
15:54:42 [AxelPolleres]
SHA1(x), SHA224(x), SHA256(x), ... vs. SHA1(x), SHA2(x, 224), SHA2(x , 256), ...
15:55:26 [AxelPolleres]
strawpoll: SHA1(x), SHA224(x), SHA256(x), ... - vote 1 vs. SHA1(x), SHA2(x, 224), SHA2(x , 256), ... - vote 2
15:55:31 [SteveH]
15:55:32 [chimezie]
15:55:43 [kasei]
15:55:49 [sandro]
15:55:52 [AndyS]
15:55:52 [AxelPolleres]
15:55:55 [MattPerry]
15:56:07 [pgearon]
15:56:12 [Souri]
15:56:15 [LeeF]
15:56:31 [SteveH]
15:56:58 [chimezie]
SteveH: some are actually different algorithms
15:57:09 [MattPerry]
changing my vote to 1
15:57:10 [chimezie]
... 4 key lengths and 2 algorithms
15:57:11 [Souri]
Would we *require* support for *all* these functions in an implementation for conformance?
15:57:31 [chimezie]
Zakim, unmute me
15:57:31 [Zakim]
Chimezie_Ogbuji should no longer be muted
15:57:38 [Souri]
changing to 1
15:58:27 [chimezie]
implementations tend to rely on existing libraries for this kind of thing
15:58:36 [chimezie]
if not available in (say Java or Python) could be problematic
15:58:38 [chimezie]
for full compliance
15:58:41 [SteveH]
kasei, I think this is just about naming
15:59:27 [SteveH]
chimezie, there are implementations in java and python
15:59:38 [kasei]
SteveH, yeah ok. still, though. feels like we keep taking on functions.
15:59:43 [chimezie]
15:59:52 [chimezie]
Zakim, mute me
15:59:52 [Zakim]
Chimezie_Ogbuji should now be muted
15:59:58 [kasei]
I'm happy leaving it to the editors.
16:00:01 [MattPerry]
I would rather leave out sha-2 but I won't object
16:00:32 [Zakim]
16:00:41 [AndyS]
"Federal agencies should stop using SHA-1 for.. after 2010" - NIST
16:00:46 [sandro]
PROPOSED: SPARQL function library will include SHA1() , SHA224(), SHA256(), SHA384(), SHA512()
16:00:55 [SteveH]
16:00:57 [pgearon]
16:01:08 [AndyS]
16:01:15 [Zakim]
16:01:19 [sandro]
PROPOSED: SPARQL function library will include MD5(), SHA1() , SHA224(), SHA256(), SHA384(), SHA512()
16:01:24 [SteveH]
16:01:26 [pgearon]
16:01:27 [sandro]
16:01:27 [chimezie]
16:01:34 [Souri]
+1 to MD5
16:01:41 [chimezie]
Zakim, unmute me
16:01:42 [Zakim]
Chimezie_Ogbuji should no longer be muted
16:02:17 [AxelPolleres]
RESOLVED: SPARQL function library will include MD5(), SHA1() , SHA224(), SHA256(), SHA384(), SHA512()
16:02:28 [chimezie]
16:02:31 [Zakim]
16:02:35 [Zakim]
16:02:36 [AxelPolleres]
16:02:38 [SteveH]
bye all
16:02:39 [Zakim]
16:02:51 [Zakim]
16:02:58 [Zakim]
16:02:59 [AxelPolleres]
rrsagent. make records public
16:03:01 [Zakim]
16:03:06 [Zakim]
16:03:22 [AxelPolleres]
rrsagent, make records public
16:03:29 [Zakim]
16:03:30 [Zakim]
SW_(SPARQL)10:00AM has ended
16:03:31 [Zakim]
Attendees were AxelPolleres, LeeF, SteveH, kasei, Sandro, Chimezie_Ogbuji, MattPerry, Simon, Souri, AndyS, pgearon
16:22:32 [SteveH]
SteveH has joined #sparql
17:46:02 [AxelPolleres]
AxelPolleres has left #sparql
18:15:56 [Zakim]
Zakim has left #sparql