See also: IRC log
<trackbot> Date: 11 June 2014
4 june record http://lists.w3.org/Archives/Public/public-csv-wg/2014Jun/0029.html
resolved: fair record
AndyS: no progress
"with all requirements work, … maybe best to wait until that completes"
"some of the requirements are getting into design"
jeremy: "fair comment, have tried to remove/fix those"
'How to distinguish field (cell) references in JSON, and other questions about templates'
<- jeremy q
jeremy: having made some progress on UC + requirements, I took a look at the templates
… got to thinking how cell refs work in json, where curly braces are heavily used
AndyS: I don't think it would be a problem…
… Gregg was proposing some of this stuff, and he loves JSON, …
… we could pick diff delimiters for diff syntaxes
… curly brackets are fairly natural in RDF
… others elsewhere
jtandy: the whole brace enclosure could be a non-issue, look to see if the thing in the brace is a valid col ref, or cell ref
… probably in hindsight where Gregg's coming from
jtandy: am trying to apply this + metadata to the weather
danbri: i liked my turtle template experiment having files that count as real turtle
andys: maybe, but someone put it the other way around ,… being able to work lightweight and not need to parse as RDF
… you could use it as a big string
andys: tricky bits — suppose you're generating a predicate as a prefix'd name
<AndyS> namespace:{col}
<AndyS> subject namespace:{col} object .
andys: trying to come up with examples where the curly brackets aren't hidden in something that won't be touched
jtandy: json conversion falls out of the …
… of the conversion approach we're trying for json-ld
… seems to work for me. Not looking at XML myself.
jtandy: Eric, … where are we with UC review + feedback?
ericstephan: we have feedback from most of
the reviewers
... overnight, a few more questions have come out. At this point we've
given at least 2 calls asking for checks. I'd like to propose that if we
can catch up today/tomorrow, then we've given opportunity for feedback.
If we don't have feedback, then we've given fair notice, ...
dan: cut off end of this week?
jtandy: David Booth has got back to me, is hoping to pick up his review next week
dan: what further work needed?
jtandy: listed to discuss later
jtandy: rather than review open issues, just note that they are open in github
https://github.com/w3c/csvw/issues?labels=Use+Case+Document&page=1&state=open
PTAL
please take a look
:)
jtandy: I opened discussion recently about whether row by row processing is sufficient
… some examples have used a blank field to indicate a ditto
'same as cell above', or 'same as cell to left'
stasinos suggests that the missing value definitions could be enhanced to say 'take my value from somewhere else'
jtandy: if you can refer to another col in a row
that's easy
<stasinos> +q
if you're referring up or down in doc, it breaks our row-by-row processing model
<fresco> ideally, exporting merged cells would put the same value in each cell
andys: there has to be … somewhere, … deal with cycles, as spreadsheets deal with
<fresco> i.e. all references should be converted to their actual values on export
… if youre doing spreadsheety things, … why not make a spreadsheet. On the other hands, some kinds of references may be useful. I've not had time to dive into use cases.
…. do we have fwd ref to a row you've not encountered yet?
jtandy: personally I've only seen refs to earlier in the file
… rather than fwd refs to things I've not parsed yet
stasinos, this and summing regions, spreadsheet-esque things, ...
… you can do this specific thing by just remembering one row
… we need to remember a couple of rows, because of the header
stasinos: main point, … doesn't increase expressivity as we need headers anyway
danbri: consider hadoop-like parallel processing.
… also that preprocessing for grid-extracts, and regex exploded cols, v appealing.
jtandy: in this UC job classification, it's more than just remember the previous row
danbri: is there a simple pre-processing step that would make data more normalised
?
jtandy: sometimes blanks are blanks,
sometimes it means the last value above/left.
... sometimes it's even within the same col
… not a core use case for me
danbri: they should fix it themselves!
stasinos: mech for data provider telling us what to do when encountering a particular value
… for a particular column, dataset, … data provider would have to tell us what it means
…same applies for explaining what a blank means, and where
… consider case where same col has real blanks and dittos pathological, needs provider-fix
… the standard export format for major spreadsheet software of this is more legitimate
"consensus agreement on whether the UCR document is ready for republication as PWD"
jtandy: keen to get sense of if WG things it is ready to go
… who has read it through?
danbri: only the new jobs case
eric/davide?
eric: I've scanned it overall, it is shaping up nicely, one part that I didn't get to follow up on (maybe davide can comment), was categorization
… I noticed some categories were empty at this point
should those categories be eliminated? or more work needed there?
davide: can be deleted
eric: I'll go back and make sure the contributors line up with the doc
<scribe> ACTION: davide remove empty categories from UC doc [recorded in http://www.w3.org/2014/06/11-csvw-minutes.html#action01]
<trackbot> Created ACTION-23 - Remove empty categories from uc doc [on Davide Ceolin - due 2014-06-18].
davide: some CSV codes are quite large, in doc, goes beyond the yellow box (doc formatting)
… should we leave as is, … adjust?
jtandy: this is for example bits of csv in the doc, which are sometimes long
… we can't just add line-breaks
… I'm comfortable with those people who are really interested scrolling to the right
danbri: are the actual samples linkable too?
jtandy: in many cases yes, and linked already.
ericstephan: for future ref, this is where it could make sense from a printing perspective, to make a link off to the larger CSV, and put an image into the doc
… I know we want actual copies of the csv, but maybe image in doc makes it more tractable
davide: re categories, i can't now see any
empty categories
... or class of requirements
only 'accepted requirements'
regarding specifics, i don't see any that are now empty.
I remember deleting some time back
ericstephan: apologies, perhaps this was comment on a prev version
jtandy: in version I see, section 3.2.2 is empty, 3.2.3, 3.2.4
<jtandy> http://w3c.github.io/csvw/use-cases-and-requirements/index.html#can-req-annotation
3.2.2 Requirements relating to annotation of CSV
3.2.3 Requirements relating to metadata discovery
3.2.4 Requirements relating to applications
davide: ok, will fix!
danbri: more for today?
jtandy: for consensus agreement, let's make sure we get signoff next week
RESOLUTION: prepare for publication signoff on the UC+R doc in next week's call
i.e. everyone read/comment
danbri: possible cultural heritage use case looming
jtandy: I raised issue on list, … that metadata vocab missing some flags, referenced in the 'parsing tabular data' data model
jtandy flags the flags
<yakovsh> +q
<jtandy> http://lists.w3.org/Archives/Public/public-csv-wg/2014Jun/0070.html
yakovsh: regarding flags and encoding, … it is carried in the mimetype. If it can be carried in the (metadata) doc itself, we need to deal with conflicts
danbri: needed for cdroms, data sticks, ...
yakovsh: agree needed, we just need to say what to do in case of a conflict
see html, xml, … find least painful way of doing it.