14:42:23 <RRSAgent> RRSAgent has joined #csvw
14:42:23 <RRSAgent> logging to http://www.w3.org/2015/02/04-csvw-irc
14:42:25 <trackbot> RRSAgent, make logs public
14:42:25 <Zakim> Zakim has joined #csvw
14:42:27 <trackbot> Zakim, this will be CSVW
14:42:27 <Zakim> ok, trackbot; I see DATA_CSVWG()10:00AM scheduled to start in 18 minutes
14:42:28 <trackbot> Meeting: CSV on the Web Working Group Teleconference
14:42:28 <trackbot> Date: 04 February 2015
14:59:30 <JeniT> JeniT has joined #csvw
14:59:45 <trackbot> RRSAgent, make logs public
14:59:47 <trackbot> Zakim, this will be CSVW
14:59:47 <Zakim> ok, trackbot; I see DATA_CSVWG()10:00AM scheduled to start in 1 minute
14:59:48 <trackbot> Meeting: CSV on the Web Working Group Teleconference
14:59:48 <trackbot> Date: 04 February 2015
14:59:54 <gkellogg> gkellogg has joined #csvw
15:00:15 <ivan> zakim, dial ivan-voip
15:00:15 <Zakim> ok, ivan; the call is being made
15:00:16 <Zakim> DATA_CSVWG()10:00AM has now started
15:00:19 <Zakim> +Ivan
15:00:51 <gkellogg> zakim, code?
15:00:51 <Zakim> the conference code is 2789 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), gkellogg
15:01:14 <Zakim> +[IPcaller]
15:01:48 <danbri> shall i scribe?
15:01:51 <jumbrich> jumbrich has joined #csvw
15:02:08 <Zakim> +??P8
15:02:12 <gkellogg> zakim, I am ??P8
15:02:12 <Zakim> +gkellogg; got it
15:02:31 <Zakim> + +44.207.346.aaaa
15:02:37 <Zakim> +??P16
15:02:46 <jumbrich> zakim, I am ??P16
15:02:46 <Zakim> +jumbrich; got it
15:02:56 <ivan> zakim, who is here?
15:02:57 <Zakim> On the phone I see Ivan, JeniT, gkellogg, danbri, jumbrich
15:02:58 <Zakim> On IRC I see jumbrich, gkellogg, JeniT, Zakim, RRSAgent, danbri, ivan, trackbot
15:03:06 <danbri> scribenick: danbri
15:03:20 <JeniT> Regrets: jtandy
15:03:47 <danbri> gregg's suggestions: https://lists.w3.org/Archives/Public/public-csv-wg/2015Feb/0004.html
15:03:57 <danbri> jenit: let's start w/ f2f and topics for that, next thu/fri
15:04:05 <danbri> +1
15:04:35 <danbri> jenit: i've been going through issues clustering them, … pulled out only 4 areas
15:04:42 <danbri> (I don't see in https://lists.w3.org/Archives/Public/public-csv-wg/2015Feb/ … you mean github notifications?)
15:04:52 <danbri> … there's a set around disconnect between CSV files and tables
15:05:11 <danbri> one set around primary key + refs between multiple files
15:05:26 <danbri> a couple around annotations and how annotations reference other things, how they are incorp'd in conversions
15:05:38 <danbri> and a few around language, and how lang is handled in mapping esp for common properties
15:05:45 <danbri> those are the areas where I found clusters of issues
15:06:05 <danbri> also we should spend a fairly high % of time looking at the conversions
15:06:12 <danbri> as they need more attention and have most issues
15:06:19 <danbri> any other thoughts on f2f priorities?
15:06:27 <danbri> (+1 from me on conversions getting attention -dan)
15:06:36 <danbri> ivan: we have currently 75 open issues, which is quite a number
15:06:48 <danbri> but there may be quite a lot of these which are really editorial things
15:07:04 <danbri> jenit: yes, quite a few are labelled as resolved, just require editor action but not needing more discussion
15:07:06 <danbri> https://github.com/w3c/csvw/issues
15:07:25 <danbri> https://github.com/w3c/csvw/issues?q=is%3Aopen+is%3Aissue+label%3AResolved shows 9 'resolved' but open.
15:07:38 <danbri> jenit: requires people to go through some other issues
15:07:54 <danbri> … if an issue is neither resolved or requires discussion/decision then it is in a limbo and needs looking at
15:08:07 <danbri> ivan: we have been a bit chaotic with issues. After f2f we have made over 100
15:08:11 <danbri> … but we'll find a way
15:08:15 <danbri> jenit: yes
15:08:28 <danbri> ivan: What is the goal we set ourselves for the f2f?
15:09:15 <danbri> ivan: My dream would be that after f2f, we have to make a bunch of editorial work, but after that round i.e. approx end march, we're in position to issue what would've once been called a Last Call.
15:09:26 <danbri> …. "maybe I'm a dreamer…"
15:09:32 <gkellogg> q+
15:09:37 <JeniT> ack gkellogg
15:10:03 <danbri> dan: we might not close all issues at f2f but can leave it with a clear owner on anything left open
15:10:07 <danbri> gregg: this should be achievable
15:10:14 <danbri> where i am with my impl it looks pretty solid
15:10:24 <danbri> i don't think we have normative text on extracting embedded metadata on CSVs
15:10:32 <danbri> perhaps we need reqs around what other formats need to find
15:10:39 <danbri> s/find/provide/
15:10:41 <danbri> e.g. TSVs are simple
15:10:45 <danbri> ivan: eh?
15:11:06 <danbri> gregg: we have some description on how to extract CSVs, illustrative text, gives a flavour for how other formats might be handled
15:11:13 <danbri> this should be normative
15:11:22 <ivan> q+
15:11:31 <danbri> if we're opening door for other formats, need to be clearer on this and use some hypothetical format at least to be testable
15:11:36 <JeniT> ack ivan
15:11:38 <danbri> re csv mappings and our existing examples they are pretty solid
15:11:58 <danbri> ivan: to other formats I think that we agreed at some point in time, that we have the conceptual thing which is our model
15:12:09 <danbri> … and we should not get into any other syntax variation on how these can be mapped on our model
15:12:13 <danbri> i don't think that we should go there
15:12:30 <danbri> i fully agree that the default metadata issue is still open and needs to be defined somewhere
15:12:45 <danbri> we agreed at some point… that if metadata is part of the orig csv file, we do not define the format of that
15:12:59 <danbri> in a sense the only thing that we will have somehow in our default metadata is when the 1st row are the col names
15:13:02 <danbri> that's a kind of metadata
15:13:15 <danbri> any other variation on metadata within the csv file we decided to be out of scope for now
15:13:24 <danbri> gregg: I thinkyou're right, not trying to solve that here
15:13:34 <danbri> … jsut that i think the results we have are [good]
15:14:09 <danbri> ivan: back to orig thing, i'm playing with an impl as well. Although there are many things I have not done, I have same feeling as you. Where we seem to be the weakest, … the usage of foreign keys and how diff tables are related to each other
15:14:15 <danbri> in our current docs that area is weakest
15:14:25 <danbri> can we spend time reviewing that?
15:14:39 <danbri> other issues are smaller details
15:14:45 <danbri> good as we have captured big picture
15:14:58 <danbri> to be less of a dreamer, it is realistic to expect "last call" sometime spring
15:15:08 <danbri> we aim for intermediate draft publication end of march
15:15:14 <danbri> may not be last call
15:15:21 <danbri> aim for lc by early june
15:15:25 <danbri> that is realistic
15:15:43 <danbri> jenit: maybe we can work it out at f2f, ...
15:15:51 <danbri> … may simply be useful for us to all sit in a room and type
15:15:58 <danbri> … actually get some stuff done or on a screen
15:16:01 <danbri> sharing in smaller groups
15:16:08 <danbri> actually do some work, not just discussion
15:16:20 <danbri> action: dan check beamer setup for non google staff
15:16:20 <trackbot> Created ACTION-62 - Check beamer setup for non google staff [on Dan Brickley - due 2015-02-11].
15:17:17 <danbri> jenit: Rufus may or may not come for some portion of the time
15:17:38 <danbri> ivan: same for phil archer
15:17:39 <Zakim> -jumbrich
15:17:44 <danbri> … they're not on list but  might come over
15:17:52 <danbri> for a day maybe
15:18:18 <DavideCeolin> DavideCeolin has joined #csvw
15:18:22 <Zakim> +??P16
15:18:29 <jumbrich> zakim ??P16 is me
15:18:46 <jumbrich> zakim, I am ??P16
15:18:46 <Zakim> +jumbrich; got it
15:18:48 <danbri> jenit: let's try to eat together somewhere around victoria, plenty of places
15:18:57 <danbri> ivan, can you paste the f2f url?
15:19:04 <JeniT> https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02
15:19:06 <ivan> https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02
15:19:09 <danbri> thx thx
15:20:02 <danbri> gregg: we're approaching time when counting implementations matters
15:20:14 <danbri> jenit: that's it for f2f
15:20:39 <Zakim> +[IPcaller]
15:20:51 <DavideCeolin> zakim, [IPcaller] is me
15:20:51 <Zakim> +DavideCeolin; got it
15:21:03 <danbri> hi Davide!
15:21:37 <danbri> davide: I may be able to attend f2f, will try
15:22:04 <JeniT> https://lists.w3.org/Archives/Public/public-csv-wg/2015Feb/0004.html
15:22:05 <danbri> topic: Gregg's Big List Of Issues
15:22:18 <danbri> Issue #96 (PR #187): Use of aboutUrl, propertyUrl and valueUrl. (should be able to close #101).
15:22:23 <JeniT> https://github.com/w3c/csvw/issues/96
15:22:24 <danbri> oops, bot clash
15:23:03 <danbri> gregg: #96 this was as discussed/resolved last week, change urlTemplate into aboutUrl, propertyUrl to be a uritemplate property, and add a value url and make them all inherited properties
15:23:13 <danbri> (don't take my spelling as canonical --scribe)
15:23:17 <JeniT> https://github.com/w3c/csvw/pull/187
15:23:18 <danbri> … see a PR in github
15:23:20 <danbri> tx
15:23:49 <danbri> … desc in metadata doc, … property can be an array i.e. repeatable, that is challenging w.r.t. spec text how to handle/define this.
15:23:52 <ivan> q+
15:23:54 <danbri> that's the primary thing I noticed
15:23:56 <JeniT> ack ivan
15:24:31 <danbri> ivan: there was another issue, whether the property uri can be an array, … q was whether the about uri if it inherited down to a column level, then the about uri can change from one col to another
15:24:33 <danbri> that's a question
15:24:42 <danbri> (did i capture that? is there an issue # for this?)
15:24:55 <danbri> gregg: that's implication and intention for making it inheritable
15:25:07 <danbri> point was to allow diff columns in rdf to be diff entities
15:25:14 <danbri> not clear what this means in javascript
15:25:27 <danbri> (javascript meaning json)
15:25:37 <danbri> gregg: json properties typically based on column name not the about url
15:25:47 <danbri> if you just used col names there would be nothing to distinguish from the single json object
15:25:58 <danbri> we'd need to decide how we'd reflect them
15:26:00 <danbri> [if at all]
15:26:05 <danbri> ivan: let's separate the 2 issues
15:26:10 <danbri> property names being an array vs about URLs
15:26:15 <danbri> diff numbers?
15:26:22 <JeniT> https://github.com/w3c/csvw/issues/186
15:26:27 <danbri> (+1 on allowing different entities for diff columns in the rdf)
15:26:52 <danbri> gregg: the other impl of proeprty uri being a template is that it could vary per row
15:27:03 <danbri> … some discussion on not including col metadata
15:27:10 <danbri> jenit: re #186 and multiple property names
15:27:12 <JeniT> https://github.com/w3c/csvw/issues/186#issuecomment-72842231
15:27:34 <danbri> my comment (see link) i found it useful when mapping data into rdf, you sometimes want dc:title AND rdfs:label
15:27:42 <danbri> but for simplicity sake let's have it be only a single value
15:27:46 <danbri> +1 for jeni's proposal
15:27:51 <danbri> q+
15:27:59 <JeniT> ack danbri
15:28:35 <JeniT> PROPOSED RESOLUTION: #186 propertyUrl only has one value
15:28:39 <JeniT> +1
15:28:39 <gkellogg> +1
15:28:40 <danbri> danbri: in rdfa/microdata multiple arcs to a value are graceful but horrible in json, support skipping
15:28:42 <danbri> +1
15:28:45 <ivan> +1
15:29:03 <jumbrich> 0
15:29:13 <DavideCeolin> 0
15:29:14 <danbri> jenit: jumbrich and davide -- if you don't feel you have enough info to vote you  can write 0
15:29:19 <ivan> RESOLUTION: #186 propertyUrl only has one value
15:29:25 <danbri> (i.e. it helps to indicate that you don't object)
15:29:33 <danbri> ivan: shall i close it directly?
15:29:42 <danbri> gregg: let's keep it open until text is updated and commited.
15:29:47 <danbri> ivan: i'll mark it as editorial
15:29:54 <danbri> (done)
15:30:04 <danbri> jenit: i suggest we don't go into full complexity of #187
15:30:24 <danbri> gregg: i thought if we could resolve this we'd be in a less compelx situation
15:30:32 <danbri> re pull requests, dependencies, ...
15:30:35 <danbri> jenit: ok
15:30:48 <danbri> ivan: #187 makes all 3 properties inheritable
15:30:57 <Zakim> -JeniT
15:31:04 <danbri> https://github.com/w3c/csvw/pull/187
15:31:18 <danbri> gregg: ivan if you're not comfortable with this let's wait til f2f
15:31:21 <danbri> ivan: I'm not comfortable
15:31:25 <danbri> gregg: let's just move on
15:31:36 <danbri> ivan: yes, f2f.
15:31:37 <Zakim> +[IPcaller]
15:31:42 <danbri> gregg: a couple of other pull requests
15:31:56 <danbri> ivan: [as above]
15:32:12 <danbri> … consequences of having all 3 properties inherited are … potentially complex
15:32:19 <danbri> not a prob with property uri, but with the about uri
15:32:24 <danbri> jenit: yes
15:32:30 <danbri> gregg: not a problem for rdf
15:32:39 <danbri> ivan: even in rdf, now we have a structure with the row property
15:32:50 <danbri> … what is , … how do i bind the triple to the rest of the structure, so to say?
15:32:56 <danbri> gregg: up to creative use of the metadata
15:33:05 <danbri> normally you'd […] for the row
15:33:17 <danbri> if someone assigns diff abouturi to diff rows, complex things become possible
15:33:21 <danbri> jenit: timeout
15:33:24 <Zakim> -jumbrich
15:33:30 <danbri> … we'll do better going through this at f2f with examples
15:33:34 <JeniT> https://github.com/w3c/csvw/pull/185
15:33:43 <Zakim> +??P6
15:33:47 <danbri> (re examples - reminder that https://github.com/w3c/csvw/tree/gh-pages/examples/tests/scenarios/chinook is a nice dataset with links and multiple entities)
15:33:50 <danbri> #185
15:33:51 <jumbrich> zakim, I am ??P6
15:33:51 <Zakim> +jumbrich; got it
15:33:57 <danbri> ivan: bunch of editorial things in pull req
15:34:17 <danbri> gregg: back to orig intention, you can have embedded csv without lang in it but matching title in asserted metadata that does have a language
15:34:39 <danbri> gregg: i had made a change some time ago, meaning that lang of metadata needed to be applied when you created the embedded metadata
15:34:50 <danbri> you'd end up with title having same lang as the embedded metadata and they'd match
15:35:04 <danbri> this change allows a title with no lang or lang=UND i.e. undefined to match a title in any other language
15:35:13 <danbri> meaning that we do not need to arbirarily apply a lang to embedded metadata
15:35:20 <danbri> and we can apply as intended to [missed]
15:35:23 <danbri> i tried!
15:36:14 <danbri> gregg: e.g. tree metadata
15:36:23 <danbri> … lang for metadata terms in the context is assreted as english
15:36:30 <danbri> the csv itself when you extract metadata from it
15:36:33 <danbri> default metadata
15:36:36 <danbri> something that's emplty
15:36:44 <danbri> creates meta without a default lang
15:36:50 <danbri> no name field only title assumed from col names
15:37:11 <danbri> in order to allow the title from the embedded metadata to match the title from the found metadata which is in english, we need to allow it to match
15:37:18 <danbri> ivan: i ran into this problem exactly
15:37:43 <danbri> gregg: there is a further conseq which is that if you were to merge these two metadata you would get descriptions the same except for language spec
15:37:51 <danbri> ivan: hence should be considered as the same
15:37:58 <danbri> gregg: yes, as being the one with the lang (defined)
15:38:03 <danbri> ivan: i agree
15:38:17 <danbri> jenit: i have a comment on it, but it is captured elsewhere, happy just merging
15:38:21 <danbri> gregg: great
15:38:31 <danbri> jenit: done
15:38:40 <danbri> that was #184
15:38:52 <danbri> skipping #64 as related to phantom col thing, which we need to work through.
15:38:54 <danbri> #170
15:39:02 <danbri> https://github.com/w3c/csvw/pull/170
15:39:02 <JeniT> https://github.com/w3c/csvw/issues/170
15:39:08 <danbri> gregg: relates to rdf/json mappings, 3 sections
15:39:14 <danbri> core table, table from metadata, table group
15:39:28 <danbri> as i went through it, to specify it to ignore metadata would seem to need processor action
15:39:38 <danbri> and wouldn't provide anything that you'd get from just using default extracted metadata
15:39:47 <ivan> q+
15:39:49 <danbri> i did not see a reasonable need to have a different processing form for core tabular data
15:39:50 <JeniT> ack ivan
15:39:56 <danbri> suggestion to remove those
15:39:59 <danbri> sections
15:40:11 <danbri> ivan: fundamentally agree. 2 areas where a simplification on the conv docs can be done -
15:40:25 <danbri> … by pushing some of the things into a common place, which is probably the metadata doc
15:40:29 <danbri> one is the one just said
15:40:36 <danbri> conversion doc works only with annotated table
15:40:47 <danbri> as one of the specs says what the default metadata is
15:40:58 <danbri> i think it makes a lot of sense to have default metadata specified somewhere anyway
15:41:26 <danbri> other thing related but diff, is that there are a lot of words in these docs on how the cell values should be converted and also how the inheritance of properties work, down to a cell level
15:41:37 <danbri> i think this is something that will eventually move to the metadata doc too as it is a general principle
15:41:42 <danbri> gregg: i believe most of it is already there
15:41:54 <danbri> ivan: that is great, means these 2 will make the conv docs very much simpler
15:42:00 <danbri> this is reflected in my impl experience
15:42:06 <danbri> most of the sweat is on the metadata
15:42:14 <danbri> once it is there, … generation is of rdf or json
15:42:18 <danbri> comparatively simple
15:42:19 <gkellogg> http://htmlpreview.github.io/?https://github.com/w3c/csvw/blob/gk-transformations/csv2rdf/index.html
15:42:31 <danbri> gregg: i did my own version of the rdf transofrm doc -^ url
15:42:38 <danbri> takes this approach, is more template like
15:42:44 <danbri> proscribes triples to generate
15:43:11 <danbri> ivan: q is whether making the core tabular data model dissapear is a major change
15:43:18 <danbri> jenit: bbiab
15:44:05 <danbri> gregg: doc has instead of SHALL specific triples given for output
15:44:13 <danbri> does include specific metadata eg on cols
15:44:19 <danbri> fundamentally it outputs triple info
15:44:28 <danbri> for each row, it uses all the lang from the metadata doc
15:44:39 <danbri> ivan: that's more or less what i do as well
15:44:57 <danbri> what i do, once all the metadata are merged, i create for every row on the fly, i make a cell level with all the transformations etc
15:45:04 <danbri> then use the structure to issue either rdf or json
15:45:17 <danbri> gregg: my version is extremely sparse
15:45:23 <danbri> simple describes what's emitted
15:45:50 <danbri> dan q re testing
15:45:55 <danbri> gregg: i created a no. of tests
15:46:03 <danbri> could make more, paused as we were changing things
15:46:12 <danbri> i think we have perhaps 30 or 40 tests for both rdf and json
15:46:52 <danbri> I asked about testing ivan's impl w.r.t. the tests gregg created
15:47:44 <danbri> jenit: we were going to get rid of the idea of the core tabular data model, there's no value add for it, ...
15:47:51 <danbri> i don't think there are any implications of that
15:47:55 <danbri> mark this as resolved
15:48:01 <danbri> ie. in #170
15:48:15 <JeniT> PROPOSED RESOLUTION: We remove ‘Core Tabular Data Model’ and define everything in terms of ‘Annotated Tabular Data Model’ #170
15:48:19 <danbri> +1
15:48:21 <JeniT> +1
15:48:29 <gkellogg> +1
15:48:36 <JeniT> we will spend time at F2F going through conversion documents
15:48:55 <JeniT> RESOLUTION: We remove ‘Core Tabular Data Model’ and define everything in terms of ‘Annotated Tabular Data Model’ #170
15:49:07 <Zakim> -jumbrich
15:49:15 <danbri> https://github.com/w3c/csvw/issues/175
15:49:22 <Zakim> +??P0
15:49:28 <jumbrich> zakim, I am ??P0
15:49:28 <Zakim> +jumbrich; got it
15:49:28 <danbri> gregg: this was basically "what is the default metadata ?"
15:49:35 <danbri> what's expected to be provided by it?
15:49:47 <danbri> gregg: primary diff from core metadata, … is that core does not assume that 1st row is header
15:49:58 <danbri> instead we had col=123 etc for headings
15:50:16 <danbri> my take is that typical way you expect to find a csv is that 1st row is a col titles
15:50:35 <danbri> … so using that you can get a reasonable mapping
15:50:46 <danbri> so table group with empty resources [scribe not capturing detail]
15:51:07 <danbri> gregg: some discussion on http content type param, header absent, ...
15:51:17 <danbri> to get back to orig appraoch of col=1 etc instead of an initial header
15:51:26 <danbri> jenit: I don't really understand this w.r.t. defaulting
15:51:39 <danbri> even with an indiv csv file you get the metadata you can guess at from that csv file
15:51:49 <danbri> gregg; you need a context from which to extrat the dialect info
15:51:53 <ivan> q+
15:51:59 <danbri> having simply an empty metadata estabs that context
15:52:05 <danbri> could be same as saying that there is none
15:52:20 <danbri> gregg: my processor looks at all the metadata, merges, uses that then re-merges everything
15:52:26 <JeniT> ack ivan
15:52:30 <danbri> some concept of having metadata when you extract embedded metadata is required
15:52:47 <danbri> ivan: there are 2 things, i still have to understand whether essentially saying,… forgetting table groups, i have only one table
15:53:04 <danbri> … if you have no metadata at all, all the processing we have on metadata will ultimately generate [whatever we need]
15:53:06 <danbri> not sure if this true
15:53:12 <danbri> gregg: it generates a reasonable output
15:53:36 <danbri> ivan: wait, no… not whether it generates reasonable output.  In the prev discussion, we do not need the core tabular model, because we have only got annotated tabular models now
15:54:03 <danbri> … we need to show clearly that if there is really nothing in the current terminology -core tab data - process of merging, defaulting etc, will give us a reasonable annotated model.
15:54:14 <danbri> gregg: to achieve this we could change defaults for skip rows and header
15:54:26 <danbri>  if you say header: false, you'd get to what is currently in the core metadata extraction
15:54:34 <danbri> jenit: feels like a real technicality
15:54:46 <danbri> … without examples that show diffs it is hard to decide
15:54:53 <danbri> ivan: agree, one of the issues for next week
15:54:59 <danbri> … another q for what gregg said
15:55:41 <danbri> ivan: I had this discussion with Ivan, … the dialect info that we introduced, if the processing model of the whole thing is such that the dialect is used to control the parsing, with prescriptive stuff, … or vs is it info i get after parser?
15:55:45 <danbri> you seem to go the 1st way, ...
15:56:07 <danbri> gregg: dialect tells you what the col separator is, e.g. ",". In order to parse the doc, you'd need to know that
15:56:38 <danbri> ivan: maybe worth putting into the doc somewhere, is some sort of an abstract processing model, if i have a conformant processor, what are the steps that it must take w.r.t. metadata, parsing, generation of the output
15:56:55 <danbri> gregg: syntax doc, … locating the metadata, …
15:56:56 <gkellogg> http://w3c.github.io/csvw/syntax/#parsing
15:57:09 <danbri> ivan: not only the parsing but the merging of the metadata etc
15:57:15 <danbri> … my impl right now does it the other way
15:57:44 <danbri> … it has to be restructured. I start with the CSV file. I extract everything from there. But essentially I should be doing it the other way around, get metadata 1st then do parsing afterwards.
15:57:51 <danbri> gregg: that was point of the default metadata yes
15:58:02 <danbri> … in doc for parsing it has informative language towards what you want
15:58:05 <danbri> jenit: t-2
15:58:14 <danbri> … taking parsing discussion to f2f
15:58:27 <danbri> … we have very strong direction originally that we couldn't talk about parsing, it was out of our remit
15:58:38 <danbri> AOB pre f2f?
15:58:54 <danbri> gregg: suggest people examine the test cases that are in there as they explore many of the things in there
15:58:58 <danbri> can go thru at f2f
15:59:08 <danbri> describe additional testcase needs
15:59:21 <danbri> jenit: i'll try to put a rough structure together for f2f but expect it to be fairly fluid
15:59:36 <danbri> … let's try to get to a place where editors are equiped to take fwd drafts end march
15:59:51 <Zakim> -Ivan
15:59:52 <Zakim> -danbri
15:59:53 <Zakim> -gkellogg
15:59:55 <Zakim> -JeniT
15:59:58 <Zakim> -DavideCeolin
16:00:00 <Zakim> DATA_CSVWG()10:00AM has ended
16:00:00 <Zakim> Attendees were Ivan, JeniT, gkellogg, +44.207.346.aaaa, danbri, jumbrich, DavideCeolin
16:00:15 <ivan> trackbot, end telcon
16:00:15 <trackbot> Zakim, list attendees
16:00:15 <Zakim> sorry, trackbot, I don't know what conference this is
16:00:23 <trackbot> RRSAgent, please draft minutes
16:00:23 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/04-csvw-minutes.html trackbot
16:00:24 <trackbot> RRSAgent, bye
16:00:24 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2015/02/04-csvw-actions.rdf :
16:00:24 <RRSAgent> ACTION: dan check beamer setup for non google staff [1]
16:00:24 <RRSAgent>   recorded in http://www.w3.org/2015/02/04-csvw-irc#T15-16-20