W3C

CSV on the Web Working Group Teleconference

25 Mar 2015

See also: IRC log

Attendees

Present
gkellogg, ivan, jtandy, JeniT
Regrets
Chair
Jeni
Scribe
Jeremy Tandy

Contents


<trackbot> Date: 25 March 2015

I'll try another method

<ivan> http://bit.ly/19OJSLq

<scribe> scribe: Jeremy Tandy

<JeniT> https://github.com/w3c/csvw/issues/389

<scribe> scribenick: jtandy

JeniT: #389 - just a hangover - take out the relevant text

gkellogg: agreed

<JeniT> https://github.com/w3c/csvw/issues/391

ivan: [will do the necessary action]

JeniT: next - #391

gkellogg: we have some additional types of properties that [don't fit]
... there's the foreign key

ivan: that's a separate issue

gkellogg: true - but still "reference" isn't a defined as a particular property type
... #398 and #391 are overlapping
... [lists a few of the properties]

ivan: but they clearly are a given type of property - so it's just an editorial thing

gkellogg: "references" (from foreign key) should be an object property

ivan: [is checking what his diagram says]

JeniT: the diagram already shows it as an object property
... editor action; agree with gkellogg's characterisation

gkellogg: [...] @language and @base have always bothered me
... these are _really_ properties

JeniT: once merging is done, these have disappeared

ivan: and they don't appear in the diagram

gkellogg: how useful is the "top level properties" section
... could it go in the JSON-LD description?

<ivan> +1 to Jeni

JeniT: this needs to be here - some folks won't look at JSON-LD stuff

gkellogg: [...] probably ok as it is then
... lets treat them as atomic properties

ivan: should they be in the diagram?

JeniT: depends on how you're characterising the diagram

gkellogg: perhaps have @context ...
... with @language and @base as separate items

[...]

[discussion on how the diagram should look]

see http://w3c.github.io/csvw/metadata/index.html#metadata-format for the diagram

JeniT: I suggest putting a separate box labelled @context with properties @base and @language

ivan: I will do that

JeniT: [updates the issue]
... is @type an atomic property or link property

gkellogg: link properties resolve according the base - this is not the case for @type

<JeniT> https://github.com/w3c/csvw/issues/393

JeniT: ok
... next - #393

gkellogg: events catching up with us
... tableSchema takes on two different characteristics depending on usage
... suggest changing the usage in foreignKey to schemaReference
... [discussion based on text of issue]

JeniT: agreement all around

ivan: [updates the labels on the issue]

JeniT: schemaReference sounds correct

gkellogg: need to update the namespace doc and the metadata doc

<JeniT> https://github.com/w3c/csvw/issues/398

ivan: i will update the diagrma

s/diagrna/diagram/

JeniT: next #398

gkellogg: easiest thing is to add some text on the array property of "foreignKeys"
... describing how to normalise these values

JeniT: look at the definition of foreignKey
... [looking for ref]

<JeniT> http://w3c.github.io/csvw/metadata/#table-foreignKeys

gkellogg: this should be "schema foreignkeys"

JeniT: yep

gkellogg: I'll fix that
... need to tighten up the language here
... schemaReference [discussed earlier] will be a link property
... [... discussed the normalisation algorithm]

JeniT: I think for the normalisation that for objects you go into the objects and nornalise them
... otherwise you get stuck on schemas

gkellogg: yes - but the wording is not [clear] enough

JeniT: [updates the issue to reflect the recommended text]
... "Agreed on telcon: normalisation language needs to include normalising properties of objects, including properties of objects in arrays."

ivan: so - JeniT and gkellogg have some editor action, I must update the diagram
... then we reach equilibrium

JeniT: yes
... what are Ivan's publication constraints?

ivan: we publish on tue and thu
... we can't assume the web master can review on easter monday
... we can say that the docs are ready by Friday 27th for internal review

JeniT: yes

gkellogg: I can do all my updates today

ivan: how much time do we need to re-read the doc

gkellogg: many of my issues relate to reading through the doc
... still need the line by line review tho

JeniT: we need telcon signoff with quorum

ivan: can do by email

JeniT: shall we aim for publication on 14th april?

ivan: that would work

JeniT: 9th would be ok - but would that give enough time for making changes following editorial review

ivan: can we get jürgen and davide to read with their fresh eyes -
... we will not see the errors [because we read what we think it says]
... can we get all the docs through snapshot / respec by 9/10th
... and let the web master review

JeniT: we can confirm this at our meeting on 8april

ivan: would like a decision so that I can notify the web master that things are coming
... this is an internal milestone - but we need to show wide review
... can JeniT and danbri create a list of the groups in W3C who we need to review
... security, internationalisation

JeniT: also some TAG level issues - inclined to ask their review too

ivan: we're not at last call yet - this is good
... we can get the issues early

JeniT: how long before we can go to LC?

ivan: difficult to say; depends on the response
... sometime in Junish
... also depends on the implementations
... if we get into LC with 2 implementations then LC can be very quick
... we should reach out to those people who said they would implement
... make sure they are ready

JeniT: others too - adam retter , raphael

ivan: we should be noisy when we publish

gkellogg: they will need to provide the test suite

ivan: let's list the test suite in the blog communication

JeniT: lets tell people that we have the start of the test suite; please add more tests as you go
... please write additional tests and contribute as you go

gk

gkellogg: my main worry is that we'll have too many tests - there are many variations
... there's a reference to data package spec in the docs - is this still correct

JeniT: let's change this ref to say that it's "based on" rather than still close to
... also inclined to change Rufus to be an author rather than editor on this spec

ivan: shall we add anyone else

JeniT: what about ivan - credit for the diagram

ivan: i'll sleep better!
... what about danbri

JeniT: not really - you could list the entire WG for contribution

ivan: we should have the WG acknowledged for all 4 specs

gkellogg: i'll take care of that
... all - or active members?

ivan: active
... here's the list
... danbri
... davide

not phila

ivan: anatasia - yes
... she helped danbri
... paul downey - no
... alf eaton - yes

<ivan> Fukuno, Taisuke - no

<ivan> https://www.w3.org/2000/09/dbwg/details?group=68238

<ivan> Gutteridge, Christopher

<ivan> - yes

<ivan> Herman, Ivan

[laughter]

<ivan> - no :-)

<ivan> Hu, Chunming

[I propose YES for ivan]

<ivan> - no

<ivan> ngram, William ( - yes

<ivan> Kellogg, Gregg - yes

<ivan> Konstantopoulos, Stasinos - yes

<ivan> Mannens, Erik - no

<ivan> Mannens, Erik - yes

<ivan> Metcalf, Christopher

JeniT: Erik did turn up to the f2f - am inclined not to include

<ivan> - no

<ivan> Noriega, Alfonso

<ivan> -no

JeniT: don't include yet - but Christopher Metcalf could be an implementor

<ivan> Polleres, Axel - yes

<ivan> Pollock, Rufus -yes

<JeniT> I said Erik *should* be included because of coming to the F2F

<ivan> Retter, Adam - yes

<ivan> Seaborne, Andy - yes

<ivan> Simonis, Ingo

<ivan> - no

<ivan> Stephan, Eric ( - yes

<ivan> Tandy, Jeremy - yes

<ivan> Tennison, Jeni - maybe

<ivan> Thomas, Mathew

<ivan> no

<ivan> Troncy, Raphaël - no

<ivan> Umbrich, Jürgen - yes

<ivan> ZERGAOUI, Mohamed - no

<ivan> + Yakov - yes

<ivan> Tim Finin ?

JeniT: also go through the contributors in the UC doc

ivan: gkellogg - will you take care of this?

gkellogg: yes - but will pass to JeniT & ivan etc. for review

<Zakim> jtandy, you wanted to ask ivan about the outstanding PR and to

https://github.com/w3c/csvw/pull/395

ivan: will check for consistency

gkellogg: formally the "json" datatype is uppercase, with a lowercase alias

JeniT: lowercase is the term we use in the datatype property for consistency with others; xml, html
... capitalised version is used elsewhere

gkellogg: in the namespace I've defined them as uppercase with a lowercase alias

ivan: what to use in the doc?
... in the diagram?
... is the diagram ok as it?

[discussion about upper and lowercase datatype names]

JeniT: [this] is very confusing ... you're not supposed to have the uppercase versions in the metadata

ivan: think the metadata doc is ok as it

gkellogg: keep the namespace doc the same
... also need to move forward on the validation tests
... positive validation tests should have json and rdf output
... negative validation tests return errors

JeniT: one or more errors
... agreed

<Zakim> jtandy, you wanted to ask about email on list about linked-csv to rdf

JeniT: thanks! enjoy holidays ...
... I won't be around next week

<ivan> trackbot, end telcon

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/03/25 16:02:15 $