CSV on the Web Working Group Teleconference

<danbri> issues https://lists.w3.org/Archives/Public/public-csv-wg/2015Apr/0001.html

<danbri> https://github.com/w3c/csvw/issues?q=is%3Aopen+is%3Aissue+label%3A%22Requires+telcon+discussion%2Fdecision%22

https://github.com/w3c/csvw/issues/464

<danbri> Removing table group/table/column compatibility constraints for inherited properties #464

<danbri> jeni: should remove those constraints

<danbri> gkellogg: what was orig thinking?

<danbri> jenit: to prevent incompatibilities

<danbri> ivan: turn into editors action

<danbri> https://github.com/w3c/csvw/issues/463 property values

<danbri> jenit: looks like as long as gregg is happy, ...

<danbri> gkellogg: diff between annotation and property wasn't clear at the time

<danbri> … for most part when we ref a property value we can ref an anno value, specifically within model doc

<danbri> if there is logic involved derriving that, perhaps should be in model doc definition of that annotation

<danbri> ivan: small editor's action?

<danbri> remove other stuff

<danbri> yup

<danbri> https://github.com/w3c/csvw/issues/462 Errors in metadata documents

<danbri> discussion of required properties

<danbri> e.g. table groups, where 'resources' is required

<danbri> table groups have 'url' as required

<danbri> discussing diff between properties that are required vs those that are undefined

<danbri> gkellogg: unless it is a common property …

<danbri> " • including properties (aside from common properties) which are not defined in this specification"

<danbri> jenit, also w.r.t. " • having invalid values for a given property" there could be emerging practice

<danbri> jenit: these could/should be non fatal errors

<danbri> must ignore (something something)

<gkellogg> tackbot, pointer?

<danbri> values that are not valid for a given property, implementations should use default value

<jtandy> +1 ... these non-fatal errors should produce warnings & implementations should ignore

<danbri> trackbot, pointer?

<trackbot> Sorry, danbri, I don't understand 'trackbot, pointer?'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

PROPOSAL: unrecognised properties are ignored (with warning), invalid values use default (with warning)

<jtandy> +1

<ivan> +1

<gkellogg> +1

<danbri> +0.9

<ivan> RESOLVED: unrecognised properties are ignored (with warning), invalid values use default (with warning)

<danbri> gkellogg: i would say 'should'

<danbri> +1 for should

<jtandy> (what about MAY)

<danbri> danbri: ok with SHOULD as 'ought to have an uptight mode, but ok if can be disabled'

<danbri> https://github.com/w3c/csvw/issues/461 Creating URLs based on the base URL of another CSV file

<danbri> skipping

<danbri> https://github.com/w3c/csvw/issues/460

<danbri> csvw:table predicate vs resources annotation vs resources property

<danbri> ivan: should go ahead and do that

<danbri> table

<danbri> tables

<danbri> gkellogg: we use table elsewhere,

<danbri> jenit: we have notes in the metadata spec

<danbri> jenit: if something takes a list use plural?

<danbri> gkellogg: w.r.t. plural consistency, title vs titles, source vs sources

<danbri> jenit: i am comfortable w/ plurals for annos in the metadata doc

<danbri> yet use singular term which is the rdf convention for properties in the rdf conversion

<danbri> gkellogg: so there is a json-ld term which is plural but it is equiv to the singular …?

<danbri> jenit: ye—es

<danbri> … in the json metadata, it flows better when they are plural, as in data package or tabular data format we're basing on

<jumbrich> sorry, somehow cannot dial in to the call ( i ll follow the scribbing )

<danbri> jumbrich - yeah we all had zakim trouble. If you keep trying it might work.

<jumbrich> ok

<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.

<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

<danbri> danbri: can we use a surface form in one plurality mapped to a common url?

<danbri> foo and foos -> http://example.org/foos

<danbri> jenit: e.g. plural term and singular property?

<danbri> plural like columns, property would be column

<danbri> are we ok with title?

<danbri> jenit: we should try to be consistent for our own set of terms

<danbri> so 'titles' -> 'title' property

<danbri> gkellogg: should we enumerate all the properties for which we want plurals in the metadata doc?

<danbri> jenit: the ones that are plural now are those, i think

<danbri> ...

<danbri> gkellogg: and title(s)?

<danbri> jenit: which is currently singular, ...

<danbri> jtandy: typically we only have one title

<danbri> but useful to know you have more than one

<danbri> gkellogg: so i'd say 'titles'

PROPOSAL: we will use plural terms for things that can have more than one value, mapped to single properties

<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

<danbri> ivan: for time being, we have only resources->tables, title->titles. correct?

<danbri> yes.

<danbri> ivan updating issue

<danbri> gkellogg: csv2rdf doc should then use singular version of the properties?

<danbri> jtandy: except when talking about the metadata annotations themselves, not the output

<danbri> gkellogg: if you use csvw: prefix, then singular

<danbri> agreed.

<danbri> jenit assigning this to gregg, who will include some commits for csvw*

<danbri> can't do diagram, ivan handling that.

<danbri> https://github.com/w3c/csvw/issues/459 Generating `rdf:type` triples on rows

<danbri> handled already?

<danbri> jtandy: have made a pull req on the docs, but not test cases w.r..t standard mode output

<danbri> gkellogg: waiting for the dust to settle

<danbri> jtandy: #459 issue has a branch ready for merging

https://github.com/w3c/csvw/issues/449

<danbri> HTTP headers vs dialects

<danbri> ivan: agreed already?

<danbri> jenit: yes, commented for PR, … phil making sure that headers only overide dialect description if you use default dialect

<danbri> current pr?

<danbri> gkellogg: current overides a default in the dialect

<danbri> eg. setting header to false

<danbri> if not set in dialect descr

<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.

<danbri> also part of this, creating inherited property lang.

<danbri> jenit: happy with that

<danbri> https://github.com/w3c/csvw/issues/446

<danbri> "Inherited property annotations on columns"

<danbri> ivan: just a pull req to merge now

<danbri> jenit: so long as everyone happy

<danbri> editor action

<danbri> jenit: offers to [do something for gregg]

<danbri> https://github.com/w3c/csvw/issues/445 Row annotations in conversion specifications

<danbri> jenit: this is basically that the model doc on which all of these conversions should be based, ...

<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.

<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.

<danbri> make sense?

<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.

<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.

<danbri> jenit: there are core annotations ,...

<danbri> if you just concentrae w/ what you can do on the model it doesn't make much sense to ignore annos on rows

<danbri> ivan: i'd rather not make this change now

<Zakim> jtandy, you wanted to ask if we're only talking about common properties?

<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.

<danbri> jenit: completely agree

<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

<danbri> read this as an editorial change

<danbri> everything comes from the model

<danbri> working on those editorial changes to make it point to the model not to the metadata doc

<danbri> ivan: at the moment we have property values that are defined in the metadata doc

<danbri> gkellogg: we have agreed to change it to annotation value

<danbri> ivan: means restructuring those 2 docs

<danbri> gkellogg: the annotations sort of by def refer to the model doc

<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, ...

<danbri> gkellogg: it's the name annotation and the ref is to column name in the model doc

<danbri> … result of applying the metadata doc with this csv to create the name annotation, title annotation, etc...

<danbri> those are fairly straightforward changes

<danbri> conceptually jeni points out that we shouldn't refer to the metadata directly but to the resulting model

<danbri> jtandy: i may have been sometimes consistently clumsy, saying 'property' instead of 'annotation'

<danbri> gkellogg: jeni has rightly clamped down on terminology

<danbri> ivan: i am fine with that, but this becomes a kind of nicety which is not properly and clearly described somewhere

<danbri> probably just a note or something, more confusing for our readers than helpful.

<danbri> somewhere/someplace, in conv doc(s) or several places, we have to make clear that e.g. if we make ...

<danbri> if conv uses row annotation, we have to make it clear that there is no spec for that overall

http://w3c.github.io/csvw/syntax/#converting-tables

<danbri> gkellogg: the non core annos are what get output, per jenit

<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'

<danbri> reading those lines, … someone will have no idea what we're talking about

<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.

<danbri> jenit: yes, agree, re a note explaining what is going on.

<danbri> gkellogg: yes, in metadata doc and in model doc, ...

<danbri> e.g. (reads above)

<danbri> gkellogg: agree it is a fairly big change

<danbri> it is too much to try to do to publish next week

<danbri> ivan: so yeah i tend to agree

<danbri> q is whether this is something we can postpone

<danbri> it does not fundamentally change our current docs technically speaking

<danbri> jenit: it does change them technically as well

<danbri> implies an impl needs the json

<danbri> jeni: i'd rather take another week and get it right.

<danbri> ivan: becomes a problem

<danbri> … if not published on 16th i may have problems w/ week of 20th

<danbri> maybe 21st is possible

<danbri> https://github.com/w3c/csvw/issues?q=is%3Aopen+is%3Aissue+label%3A%22Requires+telcon+discussion%2Fdecision%22 is down to 3.

<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

<danbri> doc could be ready by beginning of next week

<Zakim> jtandy, you wanted to ask about specific actions for everyone

<danbri> jenit: i will go ahead and make what i view as editorial changes

<danbri> … and will add in a piece on adding in non-core annotations

<danbri> no specific action for jtandy

<danbri> https://github.com/w3c/csvw/issues/444

<danbri> Should tables have a schema annotation?

<danbri> jenit: general agreement yes they should

<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

<danbri> ivan's suggestion was that there are other link properties that perhaps should possibly be considered

<danbri> jenit: dialect doesn't apply as not relevant for a model

<danbri> arguably

<danbri> ivan: I agree with that

<danbri> another one …

<danbri> url as a link property?

<danbri> gkellogg: resource is embedded within foreign keys

<danbri> object property?

<danbri> [..]

<danbri> jenit: the only object properties that we have are tableschema and dialect and reference which is in foreignkeys and has special handling

<danbri> ivan: confirmed from diagram

<danbri> ivan: so my comment is answered.

<danbri> jenit: ok

<danbri> so editorial?

<danbri> leaving to assign as we go through

<danbri> https://github.com/w3c/csvw/issues/461

<danbri> Creating URLs based on the base URL of another CSV file

<danbri> jtandy: ivan suggested 'keep it as-is for now'

<danbri> anyone who wants to use relative links should think about their data carefully. it is difficult.

<danbri> you have a centrally published resource. but 100+ publishers, … ...

<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

<danbri> gkellogg: we'll have to update tests also

<danbri> ivan: do we want to highlight it as something we want feedback on?

<danbri> jtandy: suggest not

<danbri> gkellogg: could be a note, so a non-normative change

<danbri> jenit: could add a note in one of the relevant examples? but i wouldn't draw huge attention to it

<danbri> ivan: so does not req telecon discussion. actions?

<danbri> jtandy: i have an action to update the multi-file example to include org

<danbri> we'll re-use this issue for that.

<danbri> jenit: this is the 2nd of my suggestions, i.e. assumption that we generate absolute urls.

<danbri> jtandy: you want full name of the org? or some abbreviation?

<danbri> jenit: use an abbrev

<danbri> even use a funky abbreviation

<danbri> t-4

<danbri> jtandy: will add another table using HFCE

<danbri> ivan: we have no more red actions!

<danbri> expecting more ?

<danbri> jenit: i've listed all mine

<danbri> rest are editorial

<danbri> (no other issues from people on call)

<danbri> ivan: w.r.t. publishing...

<danbri> i've created folders on repo for the draft thing

<danbri> so you don't need to worry about tha

<danbri> t

<danbri> if you have made changes on csv files in the folders, you should make the changes there

<danbri> true for me for the diagrams

<danbri> how confident are you that once docs are ready, you'll do it publication ready?

<danbri> last time was suspiciously easy.

<danbri> 2 mins.

<danbri> jenit: reasonably confident.

<danbri> bound to be some html issues.

<danbri> ivan: last time was v smooth!

<danbri> jtandy: i don't think many external refs

<danbri> maybe mistaken refs into the metadata and syntax docs

<danbri> ivan: otherwise we're good.

<danbri> (i have a script …)

<danbri> gkellogg: i'll do some final checks too.

<danbri> ivan will make some checks, jtandy will update example per #461 via a branch

<danbri> when should pubreq be sent? monday.

<danbri> gives time for thurs

<danbri> pub itself has to be available tues evening boston time.

<danbri> for webmaster jeremie

<danbri> checks would happen weds

PROPOSAL: Provided pending editorial changes are solved, we will publish new versions of the documents on the 16th

<danbri> +1

+1

<jtandy> +1 (pending smooth review of changes)

<gkellogg> +1

<ivan> +1

<danbri> RESOLVED

<ivan> RESOLVED: Provided pending editorial changes are solved, we will publish new versions of the documents on the 16th