Warning:
This wiki has been archived and is now read-only.
Chatlog 2010-12-07
From SPARQL Working Group
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 http://www.w3.org/2010/12/07-sparql-irc 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 http://www.w3.org/2005/06/tracker/irc 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: http://www.w3.org/2009/sparql/wiki/Agenda-2010-12-07 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 http://www.w3.org/2009/sparql/meeting/2010-11-30 15:05:07 <AxelPolleres> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-11-30 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> ://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0361.html 15:09:07 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0361.html 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> 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 <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? http://www.w3.org/mid/1291424556.4437.26.camel@waldron 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? http://www.w3.org/mid/AANLkTinb5WngJ6CKyKbL1K40j7Gv80zDUrFsYUL40TOa@mail.gmail.com 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> http://en.wikipedia.org/wiki/SHA-2 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> http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf 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 # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000285