13:39:46 <RRSAgent> RRSAgent has joined #csvw
13:39:46 <RRSAgent> logging to http://www.w3.org/2015/04/22-csvw-irc
13:39:48 <trackbot> RRSAgent, make logs public
13:39:48 <Zakim> Zakim has joined #csvw
13:39:50 <trackbot> Zakim, this will be CSVW
13:39:50 <Zakim> ok, trackbot; I see DATA_CSVWG()10:00AM scheduled to start in 21 minutes
13:39:51 <trackbot> Meeting: CSV on the Web Working Group Teleconference
13:39:51 <trackbot> Date: 22 April 2015
13:59:34 <gkellogg> gkellogg has joined #csvw
14:00:03 <Zakim> DATA_CSVWG()10:00AM has now started
14:00:10 <Zakim> +??P0
14:00:17 <jtandy> zakim, ??P0 is me
14:00:17 <Zakim> +jtandy; got it
14:00:21 <jtandy> zakim, mute me
14:00:21 <Zakim> sorry, jtandy, muting is not permitted when only one person is present
14:00:42 <gkellogg> zakim, code?
14:00:42 <Zakim> the conference code is 2789 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), gkellogg
14:00:49 <ivan> zakim, dial ivan-voip
14:00:49 <Zakim> ok, ivan; the call is being made
14:00:50 <Zakim> +Ivan
14:00:53 <Zakim> +??P1
14:01:01 <gkellogg> zakim, I am ??P1
14:01:01 <Zakim> +gkellogg; got it
14:01:10 <JeniT> JeniT has joined #csvw
14:01:37 <jtandy> zakim, mute me
14:01:37 <Zakim> jtandy should now be muted
14:01:40 <Zakim> +[IPcaller]
14:01:47 <Zakim> +[IPcaller]
14:01:53 <danbri1> zakim, [IPcaller] is me
14:01:54 <Zakim> +danbri1; got it
14:02:22 <jtandy> zakim, unmute me
14:02:22 <Zakim> jtandy should no longer be muted
14:02:59 <danbri1> =Structuring issue handing
14:03:14 <danbri1> ivan: issues so far came in via email lists, am moving them towards github
14:03:47 <danbri1> … have to be careful all issues that come up should have a clear reference when things are done and we get a hopefully positive reply from orig commentator
14:03:52 <danbri1> q+ re github accounts
14:04:12 <danbri1> ivan: you all might have other tricks esp re github
14:04:24 <danbri1> … isssues relating to our oblig horizontal reviews eg i18n
14:04:35 <danbri1> q+ i18n asked about schedule
14:04:46 <danbri1> q+ to note i18n asked about schedule
14:04:57 <danbri1> ivan: we might want dedicated labels for these
14:05:07 <danbri1> also 2 things require something from us
14:05:11 <danbri1> eg. yakov ietf
14:05:23 <danbri1> ack me
14:05:23 <Zakim> danbri, you wanted to discuss github accounts and to note i18n asked about schedule
14:06:31 <danbri1> ivan: re schedule, what we said we'll try to do is move to CR in June so that's probably our answer
14:06:55 <danbri1> 'therefore comments towards end of may would be great'
14:07:38 <danbri1> jenit: can someone take resp for putting all issues into github, otherwise it is likely to [bad things]
14:07:45 <danbri1> ivan: i have been doing that past few days
14:07:53 <danbri1> q+ to suggest a weekly duty rosta
14:08:04 <danbri1> ivan: everything so far ought to be in github
14:08:07 <danbri1> but what details?
14:08:10 <ivan> https://github.com/w3c/csvw/issues/507
14:08:18 <danbri1> consider for example #507 clipboard stuff
14:09:12 <danbri1> ivan: if i'm not around someone else could cover
14:09:21 <danbri1> orig mail should be put into, copied, into issue, with a link
14:09:48 <danbri1> if a thread on list, … we ought to take a look at both, … when we answer to the mailing list maybe we should also link/copy in github
14:10:02 <danbri1> jeni: great if you can take responsibility
14:10:08 <danbri1> agree we don't need to copy them all
14:10:16 <danbri1> ref to 1st + summary text is great
14:10:33 <danbri1> responding to mail saying thank you, … point to github, may help direct relevant conversation into github
14:10:44 <danbri1> we should try to keep our discussion in the github issue as much as poss
14:11:00 <danbri1> and when we reach a conclusion after github discussion, reply in orig thread
14:11:01 <jtandy> +1 to JeniT 's suggestion about discussion in github and pasting conclusion into email thread
14:11:07 <danbri1> q+ to suggest changing thread titles
14:11:29 <danbri1> ivan: at end of may i'll be out in florence, then to nyc, …
14:11:49 <danbri1> q?
14:11:53 <danbri1> ack me
14:11:53 <Zakim> danbri, you wanted to suggest a weekly duty rosta and to suggest changing thread titles
14:12:31 <ivan> https://github.com/w3c/csvw/issues
14:13:55 <danbri1> there is also the "Milestone" mechanism
14:14:05 <danbri1> we could have "PreCR horiz review" there
14:15:07 <jtandy> I can swap labels for milestones
14:15:20 <jtandy> (if we agree that would be useful)
14:15:30 <ivan> csvw
14:17:13 <danbri1> jtandy: … still #205 to rework requirements
14:17:24 <danbri1> that issue is currently assigned to davide
14:18:04 <danbri1> jtandy: at tail end of f2f, he volunteered
14:18:09 <danbri1> jenit pinging in github
14:18:29 <danbri1> jenit, let's go thru issues
14:18:36 <danbri1> clipboard formats… https://github.com/w3c/csvw/issues/507
14:18:38 <JeniT> https://github.com/w3c/csvw/issues/507
14:18:54 <danbri1> clear that this is not relevant as we are not doing clipboard formats for csv files
14:19:03 <danbri1> jenit: propose that i respond to list making that point
14:19:11 <danbri1> q?
14:19:22 <ivan> https://github.com/w3c/csvw/issues/507#issuecomment-94857565
14:19:27 <danbri1> ivan: after i asked it, … one more comment i put here, … he did reply to my mail saying 'yes indeed'
14:19:28 <gkellogg> q+
14:20:25 <danbri1> gkellogg: does relate somewhat to an issue Ivan and I discussed, w.r.t. transformations if there is no source. In which case it nominally uses the annotated model. However there is no official API for that model to use.
14:20:33 <danbri1> But perhaps there is a way to serialize the data model back
14:20:54 <danbri1> … in which case a clipboard format for that annotated data model would be relevant
14:21:00 <danbri1> danbri: exciting work for v2!
14:21:02 <danbri1> jenit: +1
14:21:15 <danbri1> ...
14:21:25 <danbri1> jenit: for me, all of those transformations is completely impl defined
14:21:30 <danbri1> e.g. how any json is passed in
14:21:38 <danbri1> or rdf etc, stdin, params or whatever
14:21:41 <danbri1> we say nothing currently
14:22:05 <danbri1> also applies to what happens when someone specifies a transform with some format that we have not defined any kind of handling for
14:22:49 <danbri1> …
14:23:09 <danbri1> gkellogg: we haven't defined any way to access that abstract model
14:23:11 <ivan> q+
14:23:19 <ivan> ack gkellogg
14:23:22 <danbri1> jenit: i think we can't, it is outside our scope and we don't know yet what will be wanted/useful
14:23:26 <danbri1> … let's look in a year's time
14:23:41 <danbri1> can stdardize later
14:23:49 <jtandy> +1 to JeniT ... once there are implementations in place, we could construct (at least) a Note to describe
14:24:28 <ivan> q-
14:24:33 <danbri1> q?
14:24:59 <danbri1> back re #507
14:25:19 <danbri1> ivan: let's suggest we don't need to do anything, hopefully response is fine, then we can close the issue
14:25:22 <danbri1> rrsagent, pointer?
14:25:22 <RRSAgent> See http://www.w3.org/2015/04/22-csvw-irc#T14-25-22
14:25:31 <danbri1> rrsagent, please make logs public
14:25:44 <danbri1> https://github.com/w3c/csvw/issues/506 Relationships to RDB tables
14:25:57 <danbri1> ivan: not sure how closely Ashok is following our group/charter etc.
14:26:36 <danbri1> ivan: this is where the issue arose that gregg raises - the only thing that I think may make sense. In case of the transformation, there would be a way for the external process to get hold of the merged metadata.
14:26:44 <danbri1> … merged metadata has a clear syntax as we define it
14:26:48 <JeniT> hmph, Skype died
14:26:51 <Zakim> -JeniT
14:27:02 <danbri1> … if a way to get hold of that, i could imagine a way for processors to use it w.r.t. a relational database
14:27:30 <danbri1> ivan: it would be possible to create a processor that takes merged metadata and provides a relational database schema
14:27:36 <danbri1> and then from that point on, that's all we can do.
14:27:43 <Zakim> +[IPcaller]
14:27:48 <danbri1> what it would require, in spec of the metadata doc, …
14:28:14 <danbri1> ivan: the only thing it would req in the metadata doc is one more flag to transform to say that it takes merged metadata as its imput
14:28:20 <danbri1> jenit: how does that help?
14:29:02 <danbri1> ivan: only thing i was wondering about … just idea … i may imagine a processor that takes the metadata doc, the way we define it, and can turn the metadata doc into a relational schema. Could provide a hook in transformation, ...
14:29:16 <danbri1> jenit: if i was doing an import i'd want the data not just the schema
14:29:24 <jtandy> [so, for example, the metadata defined foreign keys that would materialise in a relational schema]
14:29:47 <danbri1> q+ to say i expected import/export tooling not schema gen
14:30:08 <danbri1> ack me
14:30:08 <Zakim> danbri, you wanted to say i expected import/export tooling not schema gen
14:31:05 <gkellogg> q+
14:31:17 <JeniT> ack gkellogg
14:31:34 <danbri1> gkellogg: other thing still open re rdb relationship, was bit about not being able to export cols that are from a reference
14:32:14 <danbri1> ivan: it would add a relatively complex thing to a slightly secondary feature
14:32:28 <danbri1> … adding a ref into spec to a wiki page that you can create is fine
14:32:44 <danbri1> gkellogg: do we need to document that we dont fully match rdb model in that regard
14:32:58 <danbri1> jenit: couldn't we have an appendix on the rdb mapping?
14:33:07 <danbri1> (in cvs2rdf presumably?)
14:33:15 <danbri1> ivan: we can turn wiki page into an appendix
14:33:15 <jtandy> (think so)
14:33:30 <danbri1> … i would not think that adding additional sparql engine etc is needed there
14:34:02 <danbri1> jenit: can we put an action on jtandy or gregg to add some appendix to the rdf doc?
14:34:12 <danbri1> ivan: let me do that, i wrote the wiki page. i'll make a 1st run.
14:34:16 <danbri1> turn it into appendix
14:34:22 <danbri1> rrsagent, pointer?
14:34:22 <RRSAgent> See http://www.w3.org/2015/04/22-csvw-irc#T14-34-22
14:34:35 <danbri1> (jenit makes a dedicated issue)
14:34:50 <jtandy> (lots of fast typing noises!)
14:35:25 <danbri1> ivan: doing anything more we consider beyond our charter, but we'll integrate that wiki page into final rdf doc.
14:35:34 <danbri1> dan to respond to ashok on this
14:35:46 <danbri1> ivan: should we cc tag list
14:36:20 <danbri1> back to https://github.com/w3c/csvw/issues
14:36:25 <ivan> https://github.com/w3c/csvw/issues/505
14:36:36 <danbri1> #505 minor, ivan's editorial that gregg/jeni could handle
14:36:50 <ivan> https://github.com/w3c/csvw/issues/509
14:36:58 <jtandy> q+
14:37:01 <danbri1> Relationship to Data Cube #509
14:37:07 <danbri1> q+ to suggest virtual cols help
14:37:10 <danbri1> q?
14:37:14 <danbri1> ack jtandy
14:37:38 <danbri1> jtandy: i have a reasonably well worked out example with real data, if i publish that into wiki i can refer to it
14:37:43 <danbri1> q?
14:37:58 <danbri1> ack me
14:37:58 <Zakim> danbri, you wanted to suggest virtual cols help
14:39:07 <ivan> https://github.com/w3c/csvw/issues/179
14:39:18 <danbri1> danbri: v useful having a datacube-based example on the value of virtual cols
14:39:54 <danbri1> ivan: my #179 issue i asked if we needed virtual columns. Doing the rdbrdf text i found i needed virtual columns. So we need it by charter.
14:39:58 <jtandy> [virtual columns are necessary for mapping CSV to RDF Data Cube]
14:40:03 <gkellogg> q+ Do we even need metadata merge?
14:40:14 <danbri1> so i am ok closing that issue
14:40:28 <danbri1> jenit: can you ivan make that comment within the issue?
14:40:33 <danbri1> so we can close it within that issue
14:40:39 <danbri1> ivan: ok, will do today
14:41:29 <ivan> https://github.com/w3c/csvw/issues/508
14:41:58 <gkellogg> q?
14:42:08 <danbri1> Comments on registration template for "appplication/csvm+json" #508
14:42:14 <gkellogg> q+, Do we even need metadata merge?
14:42:24 <danbri1> ivan: [missed]
14:42:28 <danbri1> will start things moving
14:42:38 <danbri1> ivan: process says this should be done before candidate rec
14:42:45 <danbri1> new process doesn't say much else
14:42:48 <danbri1> we should do it
14:43:18 <danbri1> gkellogg: it became apparent in my blog post writing, that metadata merge is a big issue for implementors. Complexity ....
14:43:27 <danbri1> only reason for it right now is to pull in titles from CSVs
14:43:48 <danbri1> it is possible that some embedded metadata could be defined, but as-is now, it only really exists for adding titles. Only there for verification purposes.
14:44:12 <danbri1> should we be rethinking notion of metadata merge, replace it with validation phase, checking CSV's cols to those described in metadata.
14:44:20 <danbri1> jenit: what of issue of user-provided metadata?
14:44:28 <jtandy> q+ to comment about 3rd party usage of CSV files
14:44:28 <danbri1> gkellogg: yes it might merge with some other metadata ...
14:44:52 <danbri1> … if what the user is providing is on the minor nature, e.g. a tab-separated values option, then sure some need to modify
14:44:57 <danbri1> but otherwise it is pretty minor
14:45:03 <danbri1> e.g. dialect description
14:45:12 <ivan> q+
14:45:15 <JeniT> ack jtandy
14:45:15 <Zakim> jtandy, you wanted to comment about 3rd party usage of CSV files
14:45:50 <JeniT> ack ivan
14:46:00 <danbri1> jtandy: (missed detail, sorry)
14:46:11 <danbri1> ivan: there is user metadata that jeni mentioned
14:46:25 <danbri1> we do not have evidence right now that gregg's point is true
14:46:29 <danbri1> [(or false :)]
14:46:46 <danbri1> there is option that the csv might carry metadata
14:46:51 <danbri1> which would also be merged with whatever is out there
14:47:01 <danbri1> any metadata that is part of the doc is only on trivial matters
14:47:26 <jtandy> [detail: for people re-using CSV files published by third parties, we can override any metadata defined at source because we can always start the CSV "import" by pointing to _my_ local metadata file]
14:47:32 <danbri1> q+ to ask re Spreadsheets support (excel, drive)
14:48:19 <JeniT> ack danbri1
14:48:56 <danbri1> q?
14:48:58 <danbri1> ack me
14:48:58 <Zakim> danbri, you wanted to ask re Spreadsheets support (excel, drive)
14:49:07 <ivan> q+ admin issue
14:49:28 <ivan> q+
14:49:33 <ivan> ack admin
14:49:36 <ivan> ack issue
14:49:46 <danbri1> jenit: Rufus has mentioned that (alongside virtual cols) the merge could be a barrier for implementors
14:49:53 <danbri1> we have had evidence that it is putting people off
14:50:04 <danbri1> I'm in favour of people defining formats with embedded metadata within them
14:50:36 <danbri1> we could say: it is down to them to say how that embedded metadata is converted to other, … we provide vocabulary, but not necssarily the exact processing rules
14:51:01 <danbri1> jenit: we have simplified around saying 'you use the 1st metadata file you find', even when that is user supplied, that reduces the times when we need merge
14:51:08 <danbri1> it is really now only focussed on titles from CSV files
14:51:13 <danbri1> and the user supplied options
14:51:18 <danbri1> and for them it will be impl defined
14:51:31 <danbri1> so because we're not defining what options, apis, commandlines etc , …
14:51:41 <jtandy> q+ to ask if there were any requirements demanding metadata merge
14:51:42 <danbri1> with all of that evidence i am also in favour of removing the need for merge
14:51:54 <JeniT> ack ivan
14:51:57 <danbri1> and instead have specialized step for checking titles supplied within CSV
14:52:09 <jtandy> +1 from me (the metadata merge discussions confused me)
14:52:12 <danbri1> ivan: 1st of all, admin issue. FOr all our processing, it would be good if this went into issue list.
14:52:12 <danbri1> +1
14:52:32 <danbri1> ivan: this seems a significant change, we should open/close it in github.
14:52:36 <danbri1> gkellogg: I will do that
14:52:46 <danbri1> would we need another pre-lccr pub?
14:52:57 <danbri1> [thoughtful silence]
14:53:05 <danbri1> ivan: let me come back to that
14:53:14 <danbri1> there is another related admin issue.
14:53:20 <danbri1> list of changes...
14:53:43 <danbri1> ivan: we do not have an *obligation* to issue another doc, since this is not formally a LC
14:53:49 <danbri1> since we are not in LC
14:54:12 <danbri1> i think that what we can do, … we make the change, and if it is documented on the issue list, we can send around an email on our own lists, we can draw attention to it
14:54:19 <danbri1> maybe contact implementors that we know about directly
14:54:25 <danbri1> q+
14:54:32 <danbri1> ack jtandy
14:54:32 <Zakim> jtandy, you wanted to ask if there were any requirements demanding metadata merge
14:54:34 <ivan> ack JeniT
14:54:55 <danbri1> jtandy: checking reqs to see if anything demanded a merge, … didn't find on a quick skim
14:55:07 <danbri1> ack danbri
14:55:18 <danbri1> danbri: test case that passes now and will fail or v-versa?
14:55:48 <danbri1> gkellogg: multiple relevant tests. will have to see which are affected. over 100 distinct tests…
14:56:26 <danbri1> gkellogg: as part of my extended action i'll investigate via my implementation
14:56:47 <jtandy> [a quick skim through the requirements indicates nothing demanding metadata merge]
14:57:21 <Zakim> -gkellogg
14:57:23 <Zakim> -jtandy
14:57:24 <Zakim> -Ivan
14:57:25 <Zakim> -JeniT
15:04:43 <ivan> rrsagent, draft minutes
15:04:43 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/22-csvw-minutes.html ivan
15:05:00 <Zakim> disconnecting the lone participant, danbri1, in DATA_CSVWG()10:00AM
15:05:03 <Zakim> DATA_CSVWG()10:00AM has ended
15:05:03 <Zakim> Attendees were jtandy, Ivan, gkellogg, JeniT, danbri1