14:01:07 <RRSAgent> RRSAgent has joined #csvw
14:01:07 <RRSAgent> logging to http://www.w3.org/2015/05/20-csvw-irc
14:01:09 <Zakim> Zakim has joined #csvw
14:01:51 <danbri> I don't have my mobile (and therefore the app
14:02:08 <JeniT> JeniT has joined #csvw
14:03:19 <danbri> "you are the 1st person to join the meeting, please stand by"
14:03:28 <JeniT> coming, sorry
14:03:40 <danbri> I phoned in via https://lists.w3.org/Archives/Public/public-csv-wg/2015Apr/0078.html  dialing in: +1-617-324-0000, Access code:649 989 326
14:04:39 <JeniT> https://mit.webex.com/mit/j.php?MTID=mc56af7b6c21f64a3bccd65c2290affe9
14:04:44 <danbri> ok
14:06:12 <danbri> jenit: I'd like to understand the issue around ID and datatypes
14:06:27 <danbri> gkellogg: discussed somewhat last week. @id bothered me from the json-ld perspective
14:06:32 <danbri> because datatype can accept a string
14:06:40 <danbri> which is then read as the base of an object it is expanded to
14:06:53 <danbri> … e..g if you say '@datatype': 'string'
14:07:03 <danbri> … it means that there's a base entry whose value is string
14:07:10 <danbri> [details mangled, probably]
14:07:25 <danbri> jenit: it should be handled as other object refs, i.e. whose object is id is string
14:07:32 <danbri> gkellogg; that's why i was uncomfortable
14:07:41 <danbri> … consulting spec, …
14:08:24 <danbri> … inherited property
14:08:38 <danbri> reads from "atom property contains either a single string, …"
14:08:41 <danbri> (url?)
14:09:43 <danbri> jenit: discrepancy is how I'd think about it
14:10:08 <danbri> gkellogg: we could have said, that if it is a string, … (most json-ld -ish way) … then expanded into a string whose @id is the URI expansion of that string
14:10:13 <danbri> jenit: yup
14:10:29 <danbri> … then in the model, when describing datatypes, as well as a base annotation you'd have an identifier annotation
14:10:51 <danbri> ?? would be an url, e.g. xml schema, base would always be a known url
14:11:08 <danbri> gkellogg: [impl details
14:11:10 <danbri> ]
14:12:43 <danbri> nearbyish in the Web: http://www.w3.org/TR/swbp-xsch-datatypes/
14:13:16 <danbri> …
14:13:27 <danbri> gkellogg: base is the orig datatype  from which it is restricted, typically 'string'
14:13:39 <danbri> if you're referencing an external dt it is possible they'll ref something else, sure.
14:13:53 <danbri> there are 2 ways in which the values are being constrained. One is through the facets we'll describe on that dt
14:14:05 <danbri> other is on dictates of the referenced external dt description
14:15:21 <danbri> jenit: considering story in which datatype is an object property rather than atomic property, and where we have an @id on datatype which is used to populate a new identifier annotation in the model
14:15:28 <danbri> we'd retain base, populated from the base property
14:15:47 <danbri> and then use @id to identify datatypes when we are creating new datatypes by restricting existing datatypes
14:16:05 <danbri> make sense?
14:16:57 <danbri> gkellogg: main src of my consternation was that it appeared we had 2 ways of looking at this; one in which string value of a dt would be nominally expanded into its ID; but also used for base.
14:17:32 <danbri> jenit: can see why you might be concerned there. I think fix is to not introduce a new property but to [add an annotation]
14:18:00 <danbri> …
14:20:30 <danbri> gkellogg, did you drop off?
14:20:32 <gkellogg> can you guys hear me?
14:20:34 <danbri> no
14:20:37 <gkellogg> I can hear you.
14:20:42 <danbri> unless you aren't saying anything, in which case yes.
14:23:47 <danbri> jenit: i"ll write up what I think is a consistent approach in the issue to discuss again next week.
14:24:07 <danbri> gkellogg: discuss our conventions for locating metadata?
14:24:20 <danbri> jenit: Discussed on list. I'll go on TAG call next thurs to talk about it.
14:24:42 <danbri> gkellogg: I started this off, … I was initially fairly horrified by the url munging we were doing.
14:25:08 <danbri> I even wonder how important it is, given purpose is finding the metadata doc, given that for all practical purposes we'll typically be starting at it.
14:25:14 <danbri> Have been making tests around this.
14:25:33 <danbri> Almost seems like, really you should start with the metadata document originally
14:26:06 <danbri> jenit: don't we say … when we retrieve metadata docs automatically. If the doc doesn't explicitly include a ref to the requested tabular data file, then it must be ignored
14:26:11 <JeniT> http://w3c.github.io/csvw/syntax/#link-header
14:26:15 <danbri> q+
14:27:01 <danbri> danbri: URI equivalence rules, e.g. case or :80 in url?
14:27:07 <danbri> gkellogg: string comparisions, effectively
14:27:34 <danbri> rrsagent, pointer?
14:27:34 <RRSAgent> See http://www.w3.org/2015/05/20-csvw-irc#T14-27-34
14:28:30 <danbri> https://github.com/w3c/csvw/issues/562
14:28:53 <danbri> jenit: I expect ppl will continue to reference CSV files directly until browsers etc evolve smarter handling of the json
14:29:09 <danbri> … no right minded publisher would point to json metadata
14:29:32 <danbri> gkellogg: dialogue with mark
14:29:40 <danbri> … suggestions around url template were interesting
14:30:10 <danbri> jenit: you'd need to look up the wellknown file, locate the mapping, use that to generate the urls, … then locate the metadata from that
14:30:21 <danbri> more processing, more complicated for publishers, …
14:32:29 <danbri> jenit: if you want higher data quality on Web things need to be easier for publishers, even with less purity
14:33:33 <danbri> …
14:35:42 <danbri> danbrI: how about packaging the json-ld inside html via <script>?
14:35:54 <danbri> jenit: I've been thinking about packaging options
14:36:51 <danbri> … eg a known link relation within the page ,pointing to the metadata file, rather than embedding it to a script
14:37:02 <danbri> only link rel we use now is describedBy / describes
14:37:27 <danbri> jenit: you could have an html file that talked about the metadata
14:37:35 <danbri> gkellogg: the link rel is a bit more of a stretch there
14:37:51 <danbri> (maybe for <table> …?)
14:38:59 <danbri> http://danbri.github.io/csvw-template/example2-csv.html
14:39:16 <danbri> jenit: my concern is to say 'any csv on the Web processor needs to be able to interpret html'
14:40:23 <danbri> gkellogg: is this the main format, or a handy possible option?
14:40:42 <danbri> (discussion about not wanting a dependency on html)
14:41:17 <danbri> jenit: prior to discussion next Thurs, would be useful to have more discussion in that thread, in email or github
14:45:12 <danbri> ….
14:45:13 <danbri> ---
14:45:15 <danbri> case insensitivty
14:45:25 <JeniT> https://github.com/w3c/csvw/issues/551
14:45:27 <danbri> jenit: I am leaning towards that we shouldn't have any of this case insensitive matching
14:45:30 <danbri> as an impl burden
14:46:19 <danbri> gkellogg: [tears madly at hair, bangs face on keyboard, slightly] people think about these IDs as being tokens, … a colloqialism about using lowercase, case insensitive matching is pretty common, regexes etc.
14:47:00 <danbri> regexes might have to adapt if case insensitivty goes away in general
14:47:47 <danbri> jenit: i lean more the other way. as you start putting in things that are basically … 'oh you got it a bit wrong, don't worry, we'll fix it up…' that actually leads to more confusion
14:47:48 <danbri> danbri: +1
14:48:00 <danbri> gkellogg: should title be a req'd property of a col?
14:48:09 <danbri> and not do matching on names, which have restricted syntax
14:48:33 <danbri> real world, a title anno is really needed to hook that up
14:48:54 <JeniT> http://w3c.github.io/csvw/metadata/#schema-compatibility
14:50:46 <danbri> (/me commented in #555 https://github.com/w3c/csvw/issues/555#issuecomment-103913709 )
14:53:57 <JeniT> PROPOSAL: In 5.5.1 Schema Compatibility, when not validating, columns simply match on index without consideration of name or titles
14:54:36 <danbri> +1
14:54:42 <gkellogg> +1
14:55:10 <gkellogg> https://github.com/w3c/csvw/issues/551
15:05:37 <danbri> rrsagent, please make minutes public
15:05:37 <RRSAgent> I'm logging. I don't understand 'please make minutes public', danbri.  Try /msg RRSAgent help
15:06:01 <danbri> "The logs do not appear to be created yet, danbri" doh
15:13:22 <gkellogg> rrsagent, make logs public
16:28:14 <Zakim> Zakim has left #csvw