12:39:54 <RRSAgent> RRSAgent has joined #csvw
12:39:54 <RRSAgent> logging to http://www.w3.org/2015/04/08-csvw-irc
12:39:58 <Zakim> Zakim has joined #csvw
12:47:02 <ivan> ivan has joined #csvw
12:47:57 <danbri> zakim, this will be CSVW
12:47:57 <Zakim> I do not see a conference matching that name scheduled within the next hour, danbri
12:48:13 <danbri> meeting is in 1h 12m, right?
13:03:58 <ivan> trackbot, prepare telcon
13:04:00 <trackbot> RRSAgent, make logs public
13:04:02 <trackbot> Zakim, this will be CSVW
13:04:03 <trackbot> Meeting: CSV on the Web Working Group Teleconference
13:04:03 <trackbot> Date: 08 April 2015
13:04:03 <Zakim> ok, trackbot; I see DATA_CSVWG()10:00AM scheduled to start in 56 minutes
13:10:43 <danbri> :)
13:57:33 <danbri> danbri has joined #csvw
13:58:56 <gkellogg> gkellogg has joined #csvw
14:00:20 <jtandy> jtandy has joined #csvw
14:02:08 <danbri> zakim, who is on the phone?
14:02:08 <Zakim> DATA_CSVWG()10:00AM has not yet started, danbri
14:02:10 <Zakim> On IRC I see jtandy, gkellogg, danbri, ivan, Zakim, RRSAgent, trackbot
14:02:27 <gkellogg> zakim, code?
14:02:27 <Zakim> the conference code is 2789 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), gkellogg
14:02:32 <JeniT> JeniT has joined #csvw
14:02:36 <ivan> zakim, dial ivan-voip
14:02:36 <Zakim> ok, ivan; the call is being made
14:02:37 <Zakim> DATA_CSVWG()10:00AM has now started
14:02:39 <Zakim> +Ivan
14:02:52 <Zakim> +??P8
14:03:02 <jtandy> zakim, ??P8 is me
14:03:02 <Zakim> +jtandy; got it
14:03:33 <danbri> ditto
14:03:49 <Zakim> +[IPcaller]
14:04:43 <danbri> are all of us skype users? who is waiting for zakim
14:04:51 <Zakim> +??P13
14:04:55 <gkellogg> zakim, I am ??P13
14:04:57 <Zakim> +gkellogg; got it
14:04:59 <danbri> i got prompted for code, getting a long sulky silence now.  I guess it knows it is being decommissioned.
14:06:18 <Zakim> + +44.207.346.aaaa
14:07:05 <ivan> https://github.com/w3c/csvw/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3A%22For+LCCR%22
14:07:06 <JeniT> scribenick: JeniT
14:07:13 <JeniT> chair: danbri
14:07:19 <danbri> issues https://lists.w3.org/Archives/Public/public-csv-wg/2015Apr/0001.html
14:07:37 <danbri> https://github.com/w3c/csvw/issues?q=is%3Aopen+is%3Aissue+label%3A%22Requires+telcon+discussion%2Fdecision%22
14:08:09 <JeniT> https://github.com/w3c/csvw/issues/464
14:08:25 <danbri> Removing table group/table/column compatibility constraints for inherited properties #464
14:08:35 <danbri> jeni: should remove those constraints
14:08:50 <danbri> gkellogg: what was orig thinking?
14:09:00 <danbri> jenit: to prevent incompatibilities
14:09:09 <danbri> ivan: turn into editors action
14:09:18 <danbri> https://github.com/w3c/csvw/issues/463 property values
14:09:25 <danbri> jenit: looks like as long as gregg is happy, ...
14:09:33 <danbri> gkellogg: diff between annotation and property wasn't clear at the time
14:09:50 <danbri> … for most part when we ref a property value we can ref an anno value, specifically within model doc
14:10:02 <danbri> if there is logic involved derriving that, perhaps should be in model doc definition of that annotation
14:10:08 <danbri> ivan: small editor's action?
14:10:13 <danbri> remove other stuff
14:10:17 <danbri> yup
14:10:32 <danbri> https://github.com/w3c/csvw/issues/462 Errors in metadata documents
14:11:18 <danbri> discussion of required properties
14:11:26 <danbri> e.g. table groups, where 'resources' is required
14:11:31 <danbri> table groups have 'url' as required
14:12:06 <danbri> discussing diff between properties that are required vs those that are undefined
14:12:17 <danbri> gkellogg: unless it is a common property …
14:12:27 <danbri> "	•	including properties (aside from common properties) which are not defined in this specification"
14:13:14 <danbri> jenit, also w.r.t. "	•	having invalid values for a given property" there could be emerging practice
14:13:23 <danbri> jenit: these could/should be non fatal errors
14:13:28 <danbri> must ignore (something something)
14:13:33 <gkellogg> tackbot, pointer?
14:13:39 <danbri> values that are not valid for a given property, implementations should use default value
14:13:40 <jtandy> +1 ... these non-fatal errors should produce warnings & implementations should ignore
14:13:43 <danbri> trackbot, pointer?
14:13:43 <trackbot> Sorry, danbri, I don't understand 'trackbot, pointer?'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
14:13:50 <ivan> rrsagent, pointer?
14:13:50 <RRSAgent> See http://www.w3.org/2015/04/08-csvw-irc#T14-13-50
14:14:10 <JeniT> PROPOSAL: unrecognised properties are ignored (with warning), invalid values use default (with warning)
14:14:15 <jtandy> +1
14:14:18 <ivan> +1
14:14:18 <gkellogg> +1
14:14:39 <danbri> +0.9
14:14:49 <ivan> RESOLVED: unrecognised properties are ignored (with warning), invalid values use default (with warning)
14:15:10 <jumbrich> jumbrich has joined #csvw
14:16:20 <danbri> gkellogg: i would say 'should'
14:16:24 <danbri> +1 for should
14:16:26 <jumbrich> jumbrich has joined #csvw
14:17:11 <jtandy> (what about MAY)
14:17:35 <danbri> danbri: ok with SHOULD as 'ought to have an uptight mode, but ok if can be disabled'
14:18:24 <danbri> https://github.com/w3c/csvw/issues/461 Creating URLs based on the base URL of another CSV file
14:18:30 <danbri> skipping
14:18:37 <danbri> https://github.com/w3c/csvw/issues/460
14:18:44 <danbri> csvw:table predicate vs resources annotation vs resources property
14:18:55 <danbri> ivan: should go ahead and do that
14:18:59 <danbri> table
14:19:03 <danbri> tables
14:19:19 <danbri> gkellogg: we use table elsewhere,
14:19:27 <danbri> jenit: we have notes in the metadata spec
14:20:26 <danbri> jenit: if something takes a list use plural?
14:21:27 <danbri> gkellogg: w.r.t. plural consistency, title vs titles, source vs sources
14:21:36 <danbri> jenit: i am comfortable w/ plurals for annos in the metadata doc
14:21:47 <danbri> yet use singular term which is the rdf convention for properties in the rdf conversion
14:22:01 <danbri> gkellogg: so there is a json-ld term which is plural but it is equiv to the singular …?
14:22:13 <danbri> jenit: ye—es
14:22:33 <danbri> … in the json metadata, it flows better when they are plural, as in data package or tabular data format we're basing on
14:22:36 <jumbrich> sorry, somehow cannot dial in to the call ( i ll follow the scribbing )
14:22:51 <danbri> jumbrich - yeah we all had zakim trouble. If you keep trying it might work.
14:23:02 <jumbrich> ok
14:23:51 <danbri> jenit: we should as gkellogg says, have the two as being synonymous. Spec that have to use plural version in the metadata doc, and singular version when generating RDF in the conversion.
14:24:20 <danbri> gkellogg: my task would be to update the ns docs so the property defs are all in the singular form, and both a singular and a plural term defined, … and we use the plural version where that makes sense
14:24:47 <danbri> danbri: can we use a surface form in one plurality mapped to a common url?
14:24:54 <danbri> foo and foos -> http://example.org/foos
14:25:03 <danbri> jenit: e.g. plural term and singular property?
14:25:14 <danbri> plural like columns, property would be column
14:25:19 <danbri> are we ok with title?
14:25:32 <danbri> jenit: we should try to be consistent for our own set of terms
14:25:37 <danbri> so 'titles' -> 'title' property
14:25:55 <danbri> gkellogg: should we enumerate all the properties for which we want plurals in the metadata doc?
14:26:01 <danbri> jenit: the ones that are plural now are those, i think
14:26:03 <danbri> ...
14:26:10 <danbri> gkellogg: and title(s)?
14:26:16 <danbri> jenit: which is currently singular, ...
14:26:25 <danbri> jtandy: typically we only have one title
14:26:30 <danbri> but useful to know you have more than one
14:26:37 <danbri> gkellogg: so i'd say 'titles'
14:26:47 <jtandy> q+
14:26:50 <JeniT> PROPOSAL: we will use plural terms for things that can have more than one value, mapped to single properties
14:27:02 <danbri> ack jtandy
14:27:22 <danbri> jtandy: when we have a llist of the changes, can we take care to share those as it means editorial work e.g. in csv2* docs, ivan's diagram etc
14:27:40 <danbri> ivan: for time being, we have only resources->tables, title->titles. correct?
14:27:41 <danbri> yes.
14:27:45 <danbri> ivan updating issue
14:28:03 <danbri> gkellogg: csv2rdf doc should then use singular version of the properties?
14:28:13 <danbri> jtandy: except when talking about the metadata annotations themselves, not the output
14:28:20 <danbri> gkellogg: if you use csvw: prefix, then singular
14:28:21 <danbri> agreed.
14:28:24 <ivan> rrsagent, pointer?
14:28:24 <RRSAgent> See http://www.w3.org/2015/04/08-csvw-irc#T14-28-24
14:28:48 <danbri> jenit assigning this to gregg, who will include some commits for csvw*
14:28:54 <danbri> can't do diagram, ivan handling that.
14:29:24 <danbri> https://github.com/w3c/csvw/issues/459 	Generating `rdf:type` triples on rows
14:29:29 <danbri> handled already?
14:29:43 <danbri> jtandy: have made a pull req on the docs, but not test cases w.r..t standard mode output
14:29:51 <danbri> gkellogg: waiting for the dust to settle
14:29:59 <danbri> jtandy: #459 issue has a branch ready for merging
14:30:18 <JeniT> https://github.com/w3c/csvw/issues/449
14:30:25 <danbri> HTTP headers vs dialects
14:30:29 <danbri> ivan: agreed already?
14:30:46 <danbri> jenit: yes, commented for PR, … phil making sure that headers only overide dialect description if you use default dialect
14:30:50 <danbri> current pr?
14:30:57 <danbri> gkellogg: current overides a default in the dialect
14:31:00 <danbri> eg. setting header to false
14:31:05 <danbri> if not set in dialect descr
14:31:21 <danbri> but as jenit points out, if there is any dialect desc at all, would do that. so only in case with no defined dialect descr.
14:31:31 <danbri> also part of this, creating inherited property lang.
14:31:52 <danbri> jenit: happy with that
14:31:59 <danbri> https://github.com/w3c/csvw/issues/446
14:32:04 <danbri> "Inherited property annotations on columns"
14:32:14 <danbri> ivan: just a pull req to merge now
14:32:19 <danbri> jenit: so long as everyone happy
14:32:29 <danbri> editor action
14:33:02 <danbri> jenit: offers to [do something for gregg]
14:33:08 <danbri> https://github.com/w3c/csvw/issues/445 Row annotations in conversion specifications
14:33:35 <danbri> jenit: this is basically that the model doc on which all of these conversions should be based, ...
14:33:59 <danbri> … based on the model and what annotations are available in the model. And if you do that, in the model we have annotations of rows that would make sense copying onto row objects when converting to rdf.
14:34:26 <danbri> however we have currently no way of settting annotations on rows. we might get that in future. in that case, this would prevent us from going back to rewrite the conversion spec just because something became possible.
14:34:30 <danbri> make sense?
14:35:04 <danbri> ivan: ye-es. but to be honest if we change the metadata doc to include explicit ways to add row annotations, we'll need a new recommendation anyway. so if in same round we update the two CSV conversion docs it doesn't look to me as a big deal.
14:35:35 <danbri> jenit: but there could be e.g. a completely different spec created by someone else, e.g. taking about how data was embedded within a CSV file, that had row-level annotations and how they map into the tabular data model.
14:35:44 <jtandy> q+ to ask if we're only talking about common properties?
14:36:00 <danbri> jenit: there are core annotations ,...
14:36:41 <danbri> if you just concentrae w/ what you can do on the model it doesn't make much sense to ignore annos on rows
14:36:44 <ivan> q+
14:37:15 <danbri> ivan: i'd rather not make this change now
14:37:18 <danbri> ack jtandy
14:37:18 <Zakim> jtandy, you wanted to ask if we're only talking about common properties?
14:37:19 <jtandy> ack me
14:37:30 <danbri> ack ivan
14:38:06 <danbri> ivan: essentially as gregg said, if we go down that logic, then we should have yet another review of the 2 csv conv docs, as they rely on the terminology that also appears in the metadata doc. It refers to the metadata doc in terms of the property value etc.
14:38:10 <danbri> jenit: completely agree
14:38:30 <danbri> i thought we had agreed, and the examples seem to agree that these docs would be based on the model and not reading things from the metadata
14:38:35 <danbri> read this as an editorial change
14:38:39 <danbri>  everything comes from the model
14:38:53 <danbri> working on those editorial changes to make it point to the model not to the metadata doc
14:39:03 <danbri> ivan: at the moment we have property values that are defined in the metadata doc
14:39:11 <danbri> gkellogg: we have agreed to change it to annotation value
14:39:18 <danbri> ivan: means restructuring those 2 docs
14:39:27 <danbri> gkellogg: the annotations sort of by def refer to the model doc
14:39:46 <danbri> ivan: but the anno values that we refer to, let's say … what's value of the main property if it is not explicitly given, ...
14:40:01 <danbri> gkellogg: it's the name annotation and the ref is to column name in the model doc
14:40:20 <danbri> … result of applying the metadata doc with this csv to create the name annotation, title annotation, etc...
14:40:32 <danbri> those are fairly straightforward changes
14:40:46 <danbri> conceptually jeni points out that we shouldn't refer to the metadata directly but to the resulting model
14:41:03 <danbri> jtandy: i may have been sometimes consistently clumsy, saying 'property' instead of 'annotation'
14:41:15 <danbri> gkellogg: jeni has rightly clamped down on terminology
14:41:31 <danbri> ivan: i am fine with that, but this becomes a kind of nicety which is not properly and clearly described somewhere
14:41:44 <danbri> probably just a note or something, more confusing for our readers than helpful.
14:42:01 <danbri> somewhere/someplace, in conv doc(s) or several places, we have to make clear that e.g. if we make ...
14:42:14 <danbri> if conv uses row annotation, we have to make it clear that there is no spec for that overall
14:42:15 <danbri> q+
14:42:25 <JeniT> http://w3c.github.io/csvw/syntax/#converting-tables
14:42:31 <danbri> gkellogg: the non core annos are what get output, per jenit
14:43:11 <danbri> ivan: what jeni is saying, technically speaking she is right, somewhere in the rdf conv docs, in the algo, there is a line that says 'and if there are row level annotations, those are also added to the output in std mode'
14:43:22 <danbri> reading those lines, … someone will have no idea what we're talking about
14:43:24 <gkellogg> > In standard mode only, emit the triples generated by running the algorithm specified in section 5. JSON-LD to RDF over any notes and common properties specified for the table group, with node G as an initial subject, the notes or common property as property, and the value of the notes or common property as value.
14:43:32 <danbri> jenit: yes, agree, re a note explaining what is going on.
14:43:40 <danbri> gkellogg: yes, in metadata doc and in model doc, ...
14:43:45 <danbri> e.g. (reads above)
14:44:05 <danbri> gkellogg: agree it is a fairly big change
14:44:12 <danbri> it is too much to try to do to publish next week
14:44:18 <danbri> ivan: so yeah i tend to agree
14:44:23 <danbri> q is whether this is something we can postpone
14:44:34 <danbri> it does not fundamentally change our current docs technically speaking
14:44:42 <danbri> jenit: it does change them technically as well
14:45:02 <danbri> implies an impl needs the json
14:45:21 <danbri> jeni: i'd rather take another week and get it right.
14:45:28 <danbri> ivan: becomes a problem
14:45:38 <danbri> … if not published on 16th i may have problems w/ week of 20th
14:45:55 <danbri> maybe 21st is possible
14:46:38 <danbri> https://github.com/w3c/csvw/issues?q=is%3Aopen+is%3Aissue+label%3A%22Requires+telcon+discussion%2Fdecision%22 is down to 3.
14:47:05 <jtandy> q+ to ask about specific actions for everyone
14:47:20 <danbri> jenit: i've gone thru rdf conv and highlighted in pen my copy, … will try to bring that in next week if we have time
14:47:28 <danbri> doc could be ready by beginning of next week
14:47:41 <danbri> q?
14:48:10 <gkellogg> ack danbri
14:48:16 <danbri> ack jtandy
14:48:16 <Zakim> jtandy, you wanted to ask about specific actions for everyone
14:48:52 <danbri> jenit: i will go ahead and make what i view as editorial changes
14:49:03 <danbri> … and will add in a piece on adding in non-core annotations
14:49:08 <danbri> no specific action for jtandy
14:49:21 <ivan> rrsagent, pointer?
14:49:21 <RRSAgent> See http://www.w3.org/2015/04/08-csvw-irc#T14-49-21
14:49:37 <danbri> https://github.com/w3c/csvw/issues/444
14:49:41 <danbri> Should tables have a schema annotation?
14:49:59 <danbri> jenit: general agreement yes they should
14:50:18 <danbri> gkellogg: in case table schema was in form of an url, or included an ID, then that would be used as the table schema
14:50:30 <danbri> ivan's suggestion was that there are other link properties that perhaps should possibly be considered
14:50:40 <danbri> jenit: dialect doesn't apply as not relevant for a model
14:50:43 <danbri> arguably
14:50:47 <danbri> ivan: I agree with that
14:50:52 <danbri> another one …
14:50:58 <danbri> url as a link property?
14:51:08 <danbri> gkellogg: resource is embedded within foreign keys
14:51:11 <danbri> object property?
14:51:13 <danbri> [..]
14:51:56 <danbri> jenit: the only object properties that we have are tableschema and dialect and reference which is in foreignkeys and has special handling
14:51:59 <danbri> ivan: confirmed from diagram
14:52:05 <danbri> ivan: so my comment is answered.
14:52:07 <danbri> jenit: ok
14:52:13 <danbri> so editorial?
14:52:36 <danbri> leaving to assign as we go through
14:52:50 <danbri> https://github.com/w3c/csvw/issues/461
14:52:56 <danbri> Creating URLs based on the base URL of another CSV file
14:53:13 <danbri> jtandy: ivan suggested 'keep it as-is for now'
14:53:26 <danbri> anyone who wants to use relative links should think about their data carefully. it is difficult.
14:53:40 <danbri> you have a centrally published resource. but 100+ publishers, … ...
14:54:11 <danbri> jenit: happy with pursuing that as a course of action if jtandy can update the example to include the organization as a column and show then how to generate a value url consistently across files
14:54:18 <danbri> gkellogg: we'll have to update tests also
14:54:27 <danbri> ivan: do we want to highlight it as something we want feedback on?
14:54:39 <danbri> jtandy: suggest not
14:54:48 <danbri> gkellogg: could be a note, so a non-normative change
14:55:06 <danbri> jenit: could add a note in one of the relevant examples? but i wouldn't draw huge attention to it
14:55:18 <danbri> ivan: so does not req telecon discussion. actions?
14:55:29 <danbri> jtandy: i have an action to update the multi-file example to include org
14:55:42 <danbri> we'll re-use this issue for that.
14:55:47 <ivan> rrsagent, pointer?
14:55:47 <RRSAgent> See http://www.w3.org/2015/04/08-csvw-irc#T14-55-47
14:55:56 <danbri> jenit: this is the 2nd of my suggestions, i.e. assumption that we generate absolute urls.
14:56:13 <danbri> jtandy: you want full name of the org? or some abbreviation?
14:56:27 <danbri> jenit: use an abbrev
14:56:38 <danbri> even use a funky abbreviation
14:56:48 <danbri> t-4
14:56:56 <danbri> jtandy: will add another table using HFCE
14:57:01 <danbri> ivan: we have no more red actions!
14:57:15 <danbri> expecting more ?
14:57:18 <danbri> jenit: i've listed all mine
14:57:23 <danbri> rest are editorial
14:57:43 <danbri> (no other issues from people on call)
14:57:47 <danbri> ivan: w.r.t. publishing...
14:57:53 <danbri> i've created folders on repo for the draft thing
14:57:57 <danbri> so you don't need to worry about tha
14:57:58 <danbri> t
14:58:07 <danbri> if you have made changes on csv files in the folders, you should make the changes there
14:58:11 <danbri> true for me for the diagrams
14:58:23 <danbri> how confident are you that once docs are ready, you'll do it publication ready?
14:58:27 <danbri> last time was suspiciously easy.
14:58:41 <danbri> 2 mins.
14:58:45 <danbri> jenit: reasonably confident.
14:58:51 <danbri> bound to be some html issues.
14:58:55 <danbri> ivan: last time was v smooth!
14:59:10 <danbri> jtandy: i don't think many external refs
14:59:18 <danbri> maybe mistaken refs into the metadata and syntax docs
14:59:22 <danbri> ivan: otherwise we're good.
14:59:31 <danbri> (i have a script …)
14:59:38 <danbri> gkellogg: i'll do some final checks too.
14:59:57 <danbri> ivan will make some checks, jtandy will update example per #461 via a branch
15:01:27 <danbri> when should pubreq be sent? monday.
15:01:31 <danbri> gives time for thurs
15:01:40 <danbri> pub itself has to be available tues evening boston time.
15:01:47 <danbri> for webmaster jeremie
15:01:54 <danbri> checks would happen weds
15:02:37 <JeniT> PROPOSAL: Provided pending editorial changes are solved, we will publish new versions of the documents on the 16th
15:02:39 <danbri> +1
15:02:40 <JeniT> +1
15:02:40 <jtandy> +1 (pending smooth review of changes)
15:02:44 <gkellogg> +1
15:03:10 <ivan> +1
15:03:11 <danbri> RESOLVED
15:03:22 <Zakim> -JeniT
15:03:23 <Zakim> -jtandy
15:03:28 <ivan> RESOLVED:  Provided pending editorial changes are solved, we will publish new versions of the documents on the 16th
15:03:31 <Zakim> -Ivan
15:04:46 <Zakim> -gkellogg
15:04:46 <Zakim> -danbri
15:04:48 <Zakim> DATA_CSVWG()10:00AM has ended
15:04:48 <Zakim> Attendees were Ivan, jtandy, JeniT, gkellogg, +44.207.346.aaaa, danbri
15:04:50 <danbri> rrsagent, please draft minutes
15:04:50 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/08-csvw-minutes.html danbri
15:04:56 <danbri> rrsagent, please make minutes public
15:04:56 <RRSAgent> I'm logging. I don't understand 'please make minutes public', danbri.  Try /msg RRSAgent help
15:05:04 <danbri> rrsagent, please make logs public
15:07:00 <jtandy> jtandy has joined #csvw
16:58:27 <Zakim> Zakim has left #csvw
18:39:45 <danbri> danbri has joined #csvw
19:36:07 <JeniT> JeniT has joined #csvw