Chatlog 2010-12-07

From SPARQL Working Group
Jump to: navigation, search

See original RRSAgent log and preview nicely formatted version.

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

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> Agenda:
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> +AxelPolleres
14:58:16 <Zakim> +LeeF
14:59:02 <Zakim> +SteveH
14:59:24 <Zakim> +kasei
14:59:54 <Zakim> +Sandro
14:59:58 <MattPerry> MattPerry has joined #sparql
15:00:05 <chimezie> chimezie has joined #sparql
15:00:31 <Zakim> +Chimezie_Ogbuji
15:00:42 <Zakim> +MattPerry
15:01:12 <AndyS> Booting up ...
15:01:20 <AxelPolleres> alright...
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: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
15:03:23 <Zakim> +??P25
15:03:42 <AxelPolleres> Zakim, ??P25 is Souri
15:03:42 <Zakim> +Souri; got it
15:03:48 <Zakim> +??P21
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> topic: admin
15:04:37 <AxelPolleres> PROPOSED: Approve minutes at
15:05:07 <AxelPolleres> RESOLVED: Approve minutes at
15:05:14 <Zakim> +pgearon
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> +1 to s/LENGTH/STRLEN/g
15:08:20 <chimezie> AxelPolleres: Andy proposed to renam LEN to STRLEN (hope no objections)
15:08:23 <sandro> +1
15:08:24 <Souri> +1
15:08:25 <LeeF> yup
15:08:42 <chimezie> s/piped/typed
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> s/AncyS/AndyS/
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> q+
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> q?
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> +q
15:21:24 <AxelPolleres> q?
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> q+
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> q+
15:28:50 <SteveH> q-
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> q-
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") =?= "abc"@en
15:32:33 <AxelPolleres> concat (  "b"^^string, "c")
15:32:42 <AxelPolleres> "bc"^^xs:string
15:32:52 <chimezie> AndyS: I'm proposing this
15:32:53 <AxelPolleres> (andy)
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> 2
15:36:08 <Souri> q+
15:36:11 <kasei> 1 (very mild preference)
15:36:18 <MattPerry> 1
15:36:21 <SteveH> 1
15:36:29 <SteveH> (but not stong pref)
15:36:29 <AxelPolleres> 1 (mildly)
15:36:34 <kasei> q-
15:36:42 <AndyS> 2
15:36:46 <Souri> 1 (mildly)
15:36:58 <AxelPolleres> q?
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> q+
15:38:20 <Souri> q-
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> +1
15:44:42 <AndyS> abstain
15:44:57 <sandro> +1
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> subtopic: inclusion of SHA*/MD5 functions 
15:47:20 <SteveH> q+
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> SHA1(....)
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> 1
15:55:32 <chimezie> 2
15:55:43 <kasei> 0
15:55:49 <sandro> 2
15:55:52 <AndyS> 1
15:55:52 <AxelPolleres> 0
15:55:55 <MattPerry> 2
15:56:07 <pgearon> 1
15:56:12 <Souri> 2
15:56:15 <LeeF> 0
15:56:31 <SteveH> q+
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> ok
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> -LeeF
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> MD5?
16:00:57 <pgearon> +1
16:01:08 <AndyS> +MD5
16:01:15 <Zakim> -MattPerry
16:01:19 <sandro> PROPOSED: SPARQL function library will include MD5(), SHA1() , SHA224(), SHA256(), SHA384(), SHA512()
16:01:24 <SteveH> +1
16:01:26 <pgearon> +1
16:01:27 <sandro> +1
16:01:27 <chimezie> 0
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> bye
16:02:31 <Zakim> -Chimezie_Ogbuji
16:02:35 <Zakim> -Souri
16:02:36 <AxelPolleres> adjourned
16:02:38 <SteveH> bye all
16:02:39 <Zakim> -SteveH
16:02:51 <Zakim> -kasei
16:02:58 <Zakim> -AndyS
16:02:59 <AxelPolleres> rrsagent. make records public
16:03:01 <Zakim> -Sandro
16:03:06 <Zakim> -pgearon
16:03:22 <AxelPolleres> rrsagent, make records public
16:03:29 <Zakim> -AxelPolleres
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