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