14:29:41 RRSAgent has joined #csvw 14:29:41 logging to http://www.w3.org/2015/01/07-csvw-irc 14:29:43 RRSAgent, make logs public 14:29:43 Zakim has joined #csvw 14:29:45 Zakim, this will be CSVW 14:29:45 ok, trackbot; I see DATA_CSVWG()10:00AM scheduled to start in 31 minutes 14:29:46 Meeting: CSV on the Web Working Group Teleconference 14:29:46 Date: 07 January 2015 14:30:05 Chair: Jeni 14:30:44 Agenda: https://www.w3.org/2013/csvw/wiki/Meeting_Agenda_2015-01-07 14:30:44 ivan has changed the topic to: Agenda: https://www.w3.org/2013/csvw/wiki/Meeting_Agenda_2015-01-07 14:49:35 bill-ingram has joined #csvw 14:49:50 bill-ingram has left #csvw 14:50:36 bill has joined #csvw 14:55:17 gkellogg has joined #csvw 15:00:29 zakim, dial ivan-voip 15:00:29 ok, ivan; the call is being made 15:00:30 DATA_CSVWG()10:00AM has now started 15:00:31 +Ivan 15:01:15 +??P21 15:01:19 zakim, I am ??P21 15:01:21 +gkellogg; got it 15:02:06 + +1.217.333.aaaa 15:02:27 zakim, aaaa bill 15:02:27 zakim, caller is me 15:02:27 I don't understand 'aaaa bill', ivan 15:02:28 sorry, bill, I do not recognize a party named 'caller' 15:02:42 zakim, aaaa is bill 15:02:42 +bill; got it 15:03:45 sorry, just trying to dial 15:04:22 +[IPcaller] 15:07:04 JeniT: lots of issues needing discussions — what should be focus on? 15:08:22 ivan: would like to see an example where metadata comes from different places 15:08:45 JeniT: examples don't [currently] represent that situation 15:09:21 …propose discussing examples then import/metadata issues 15:09:37 ivan: prefer to look at merge and import stuff first 15:09:45 http://w3c.github.io/csvw/syntax/#examples 15:10:11 gkellogg: trying to understand the merge order 15:10:42 …how to use data from meta file, e.g., skip columns, before ever seeing the csv itself 15:11:34 https://github.com/w3c/csvw/issues/145 is ivan’s point 15:11:44 ie how to merge metadata 15:12:37 … let's do combination first 15:12:53 https://github.com/w3c/csvw/issues/145#issuecomment-68766764 15:14:20 JeniT: point is to separate when we're talking about merged metadata document used to annotate tabular data model 15:15:09 …issues raised around how the metadata file is created from multiple metadata files — using imports 15:15:24 …why did we think we needed imports in the first place? 15:15:43 http://www.w3.org/2014/10/27-csvw-minutes.html#item09 15:16:11 “RESOLUTION: We use an ‘import’ property in the first metadata document found through the precedence hierarchy described in section 3 (but with inclusion of user-defined metadata); the merge is a depth first recursive inclusion” 15:16:30 …search for this text ^ 15:17:46 ivan: I remember JeniT's comment that you have do a bunch of GETs in any case 15:18:25 gkellogg: you don't want to repeat yourself; import mechanism solves that 15:18:34 …but seems relatively advanced to start with 15:18:52 …first need to figure out how to deal with multiple sources of metadata 15:19:31 ivan: we had a slightly different situation: the unnecessary GETs were just one of the issues 15:20:17 …also have the possibility to talk about several files, i.e., directory-level metadata 15:20:52 JeniT: stiff have to repeat for each table common stuff 15:21:00 s/stiff/still 15:22:08 ivan: much more complicated in (e.g.) javascript because of async nature 15:22:20 …question is whether it is really worth it 15:22:40 gkellogg: complication is when promises are chained together 15:22:50 …if you encounter an import in there 15:23:12 ivan: right, you end up with recursive calls to promises — it's ugly 15:23:33 JeniT: let's move away from implementation in favor of focus on use cases 15:24:00 q+ 15:24:17 …do we need to merge metadata files at all — is that useful 15:25:00 ivan: wondering whether we can have a structure within the metadata file instead of relying on import 15:25:22 ack gkellogg 15:25:24 …some sort of a global structure that is conceptually copied into each 15:25:56 gkellogg: certainly the ability to have common table-level metadata is complicated by the fact that @id is required by table 15:26:18 …one way around that is to require @id *after* all processing is finished 15:26:47 JeniT: in that case schema is used in a slightly different way 15:27:01 gkellogg: schema is property of table group 15:27:35 JeniT: sounds like suggesting that some kind of table group property contains all these *global* properties 15:28:54 JeniT: propose we scrap imports in lieu of table group metadata 15:29:14 ivan: looking back at the structure from before the f2f 15:29:47 …you have few ways to get the metadata; also can do more than one, in which case you'd have to merge 15:29:57 it says “Processors must attempt to locate a metadata document based on each of these locations in order, and use first metadata document that is successfully located in this way.” 15:30:00 gkellogg: suggest you take the first one and then stop 15:30:33 …merge issues still exists in cases of user-supplied metadata, etc 15:30:52 http://w3c.github.io/csvw/syntax/#using-overriding-metadata 15:31:08 JeniT: example 2 (?) handles user-supplied metadata ^ 15:32:37 gkellogg: whatever user metadata is provided, process is to coerce it into consistent metadata 15:33:26 …consistent == if title is in one it must be the same as in the other 15:33:45 ivan: several titles are put into an array 15:34:05 …the beauty and complication of import mechanism is that is defines a semantic merge 15:34:39 …we have to know which has higher precedence 15:35:33 …my personal view is that we take everything and step by step merge them using import algorithm 15:35:59 gkellogg: would like to differ that until we've addressed merging in general 15:37:10 ivan: two things: 1.) import property, necessary or not 2.) import as an algorithm for merging 15:39:12 JeniT: to move forward, propose we take the language from the syntax document about merging, and from the metadata document about where to find metadata files and how to merge them 15:39:33 …we have an example there for dealing with that 15:39:54 …regarding the import statement itself, more discussion is needed 15:39:59 …leave it in for now 15:40:21 ivan: can we formally propose it and discuss it over e-mail and see where it goes 15:41:03 gkellogg: don't want to belabor but once we have the merge order rules, the import directive will be more better understood 15:41:41 …proposed in my description a way in which it might work 15:42:44 …if we just think about title, and have several sources of title information 15:43:50 s/name/title 15:44:17 ivan: current merge algorithm handles this already 15:44:44 JeniT: name and title are handled very differently 15:46:01 gkellogg: i think name is set from title unless it is otherwise stated 15:46:43 ivan: titles can pile up in an array, but name must be the same 15:47:04 JeniT: name is a required property on column desc 15:47:52 ivan: i need to have a name, else I cannot convert to RDF 15:49:29 …according to the current algorithm, titles may be different, but if (at the first step) if i don't have the name, i don't have a column desc for the final metadata 15:49:35 …need to start somewhere 15:50:02 gkellogg: postpone validation until after merge has taken place 15:50:26 …what's the difference between an annotation and a property? 15:50:42 …title will always exist, name may not, so extract name from title 15:51:01 …allows space for other metadata to specify name 15:51:27 ivan: what i claim is that this does not work with the current merging algorithm 15:52:05 …if i have two metadata files with two arrays of column descriptions, if i can find common 15:52:11 …values, I can merge 15:52:20 …otherwise there is no way to find the merge 15:53:01 JeniT: reason is that current algorithm as described assumes every column will have a name 15:53:25 …since the creation of the metadata documents, we've introduced this issues 15:54:17 gkellogg: sounds like JeniT has a concept, which we'll need to work out 15:54:26 JeniT: I do have concept for how this works 15:55:06 …specified either by the implementation or the specification, it's only when you get to the metadata documents where that merge might happen 15:55:48 …in other words, there's work to do in terms of describing that in terms of metadata documents 15:58:00 gkellogg: it might just be useful to walk through an example to see what the process would be 15:58:40 http://w3c.github.io/csvw/syntax/#annotated-tabular-data-model 16:00:05 JeniT: will try to make examples for further discussion 16:00:30 ScribeNick: JeniT 16:00:35 ivan: the current schema is complicated as two merged schemas may have a different structure. 16:00:36 :) bye 16:00:44 ScribeNick: gkellogg 16:00:47 -bill 16:00:58 … If we make use of the order and number of column descriptions, then it’s easied by knowing they have the same number of columns. 16:01:20 -gkellogg 16:01:22 -Ivan 16:01:24 -JeniT 16:01:24 DATA_CSVWG()10:00AM has ended 16:01:24 Attendees were Ivan, gkellogg, +1.217.333.aaaa, bill, JeniT 16:01:40 rrsagent, draft minutes 16:01:40 I have made the request to generate http://www.w3.org/2015/01/07-csvw-minutes.html ivan 17:29:01 Zakim has left #csvw