See also: IRC log
<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