See also: IRC log
<danbri> last week's meeting record: http://lists.w3.org/Archives/Public/public-csv-wg/2014Apr/0123.html
<danbri> 30th april minutes: http://lists.w3.org/Archives/Public/public-csv-wg/2014Apr/0123.html
Previous week's minutes are at http://www.w3.org/2014/04/23-csvw-minutes.html
i.e. it was on the 23rd, not the 24th
<AndyS> +1 to both
PROPOSED: Accept previous two week's minutes
RESOLUTION: Accept previous two week's minutes http://lists.w3.org/Archives/Public/public-csv-wg/2014Apr/0123.html and http://www.w3.org/2014/04/23-csvw-minutes.html
<scribe> chair: danbri
<scribe> scribe: phila
<scribe> scribeNick: phila
danbri: Introduces agenda
danbri: Where are we?
<ivan> UCR Editors' draft
ericstephan: Folks have been pretty swamped
but we've managed to add a few more use cases
... one came from Tim Robinson this morning
... and one to come from Phil
phila: (I added it this morning too)
ericstephan: We have to firm up the categorisation
<jtandy> do we need to flesh out the requirements themselves?
danbri: So do you have what you need for a next publication?
ericstephan: It depends on the time all of
us have this week
... I'm going to be fairly busy but I can spend some time on it
jtandy: I've not been able to pay much attention so far this week but I should be able to support Eric this week
DavideCeolin: There are a few things to
discuss. I sent an e-mail about that
... I have tried to classify the requirements following the last meeting. I don't know if the classification is OK or not
... also I was doubtful about the annotation req. Some reqs could be sub-reqs of that
phila: I added my use case. I'm now checking with the people it talks about that it is accurate
ivan: I think the new use cases lack
... Publishing in 2 weeks is not sacrosanct
... I'd rather that the requirement table and put it in the doc. If that takes > 2 weeks, so be it
... what's on the wiki is a significant step forwards
ericstephan: I would prefer moving without doing what Ivan just suggested
<jtandy> +1 to taking more time to get the requirements correct
<jtandy> ... and taking more time as necesssary
ericstephan: I think we can try to get things done... I'd prefer if we had a bit more time (Scribe correct, i.e. Eric agreed with Ivan)
<danbri> [ah, 'moving out' was wrt to timescale, not location of text]
ivan: There is no requirement to publish on 2 - 3 weeks
JeniT: I think this doc is really good, the
classification is excellent the reqs (section 4) ...
... section 4.2... I suggest putting all the reqs into accepted for what we want to publish next
... The 2 - 3 weeks deadline was arbitrary because I think deadlines help to motivate people
... if it takes longer, then OK
... but it's also good to publish heartbeat docs so people can track even small changes
... Re the issue of annotation and supplementary info reqs...
... There were lots of sub reqs and it's not clear whether we need some of the high level reqs
JeniT: I think we're looking at human-readable annotations
^^ That's the specific req under discussion
JeniT: There are lots of reqs, sub reqs around that
<jtandy> I agree that the "annotation and supplementary info" requirement should not overlap with the scope of the other requirements - therefore focus on the human readable annotation
danbri: This will be a FPWD of the RDF Mapping?
AndyS: Only if you want a very rough and
... There's a lot to be thought through to align the docs
danbri: How would an extra week help?
AndyS: I don't think it will make a stunning difference
danbri: Any particular reason for publishing everything in coordinated waves?
ivan: No, we can do what we like in that
... What bothers me about publishing this doc now... we had a discussion a few weeks ago on the general principles of conversation of CSV
... I think what the doc has is more or less in line with that. But I would like those discussions documented and published somewhere
... just for the public view of things
JeniT: Which doc would that fit in best?
ivan: I was thinking the same thing but don't have an answer
JeniT: There might need to be a general conversion doc?
ivan: Might it fit in the structure of the model doc?
JeniT: I can look
ivan: I don't mind. I just think the principles should be included somewhere
AndyS: Could you take a go at writing a couple of paras in an e-mail then it can at least go in the RDF doc. It might get moved later
ivan: It's a possibility, but if we do a JSON doc at some point then we'll have to sync those texts
AndyS: That might be the triggerto get it
out of the RDf doc
... Let's get the text out now and worry about where it ends up later
danbri: Jeni just circulated a draft
<danbri> ACTION: danbri supply a json-ld sentence for csv2rdf doc [recorded in http://www.w3.org/2014/05/07-csvw-minutes.html#action01]
<trackbot> Created ACTION-14 - Supply a json-ld sentence for csv2rdf doc [on Dan Brickley - due 2014-05-14].
AndyS: I thought Jeni's message is about an RDF form of the metadata doc
danbri: The idea was to take Jeni's sentiment and add it to the doc
JeniT: Not sure how that's relevant?
danbri: I'm just thinking about someone coming in to this and seeing RDF in 2 places
ivan: There is the issue of how the three docs work together
<AndyS> The CSV2RDF doc will refer to metadat doc and (eventually) align.
ivan: When I first saw the metadata doc I was a bit confused about the relationships. It needs clarity, that's all
danbri: Any more to say on RDF generation?
AndyS: If you can send the mail, Ivan, I'll add it to the doc
<scribe> ACTION: Ivan to send 2 paras on format conversion in an e-mail that Andy will incorporate in the mapping Doc [recorded in http://www.w3.org/2014/05/07-csvw-minutes.html#action02]
<trackbot> Created ACTION-15 - Send 2 paras on format conversion in an e-mail that andy will incorporate in the mapping doc [on Ivan Herman - due 2014-05-14].
ivan: We haven't got any use cases for the XML conversion?
JeniT: No, but we did just have a use case with XML metadata
ivan: It would be good to track that
JeniT: I agree
... I have taken CSV files and converted them to XML but there was more to it than that
danbri: You had a proposal, Jeni that everyone agreed with
<ivan> editor's copy
JeniT: Yes, the proposal was to not worry
about embedding any metadata in the CSV other than the column headings
... lots of +1s to that
danbri: So we're saying nothing, not that you can't do it?
JeniT: We're saying for our WG that, at least for now, we're focussing on CSV with no extra header lines with reserved character starts
danbri: Yes but people *are* putting extra headers in
JeniT: Yes, lots of examples of that - random ways - we need to scope that out for now I think
danbri: But we still need to point to the metadata file
... We have resolved to defer any consideration of embedding metadata in CSV docs with the exception of column headings
RESOLUTION: See above
JeniT: There are a few other issues... but I'm generally happy for them to stay in the file and for us just to have a heartbeat publication, prob in line with otehr docs
danbri: Any more on this doc?
ivan: I want to make sure that this is
reflectied - the RtL issue? We have the use case
... that's a new req that should be documented that may have an effect on the parsing algorithm
JeniT: I'm happy to add something about that
... prob in the parsing bit which is informative
ivan: I tried to get some feedback from CN
and JP folks to see if vertical writing might be relevant too
... it seems that no, they tend to work in rows (LtR)
<jtandy> re JP and CN - that's good to hear
ivan: but Arabic and Hebrew def go RtL
danbri: Do you have all you need?
JeniT: Last week we had a rough version. This week's is slightly less rough
<danbri> "Validation and conversion of tabular data on the web requires additional metadata that describes how the data should be interpreted. This document defines a vocabulary for metadata that annotates tabular data. This can be used to provide metadata at various levels, from collections of data from CSV documents and how they relate to each other down to individual cells within a table."
JeniT: I have discussed with Rufus how to
... One was whether to take it vocab first and then to JSON or from format to vocab - Rufus said the latter
... the other things was orienting it around using JSON-LD to map the data format
... also decided to scope the simplest possible case which is a single CSV file described by a single metadata file
... that leaves out packages of CSV files
... and several CSV fails that share the same schema
... what I've done today is to see those divisions in the format of the doc
JeniT: looking at aligning that with
existing RDF vocabs using JSON-LD
... using @ to point to the CSV file
... we can probably guess a rough version together over the next couple of weeks or a more formed version in 4 weeks
... So I'd welcome any comments on approach and direction. It means that we depart quite a bit from teh original data package format
ivan: So do we want at some point to go through the various issues before publication?
JeniT: I think it's OK to have some issues
in teh doc but it would be good to go through them
... anything up to section 2,2 basically
ivan: I think it would be good if this doc
included a reference/example to the RDF conversion doc
... AIUI if we use some sort of template for the RDF conversion then it should be clear where it goes in this metadata doc
<jtandy> agreed - it's not clear how the RDF conversion templates fit into the metadata doc
ivan: but it's not clear to me yet
... The format is very much taken from the data packages spec which doesn't include anything about conversion. I think that's a feature of the doc being young
danbri: Does it have any relationship to the UCR (explicitly)
JeniT: Not explicitly. Reqs are quite high level. e.g. 'Validation' - meaning what kind of validation?
jtandy: I just wanted to say... following on from the weather obs example I put on github, I'll try and apply the metadata doc and if broken will feed back
JeniT: That would be v helpful - but give it a week first
<danbri> (phil/ivan, where are we w.r.t. idea of rdf validation wg at w3c?)
<Zakim> phila, you wanted to talk about validation
discussion of poss usefulness of proposed RDF validation
JeniT: validation of the JSON might be useful for people wanting to use a JSON schema
<danbri> ack me?
danbri: The RDF validation might take some
pressure off us but we can't get wawy without any validation
... Anymore on the metadata vocab doc jeni?
danbri: Any upcoming events?
<JeniT> http://csvconf.com/ !!!!!
<DavideCeolin> possibly, but not 100% sure I'll be at ESWC
ericstephan: I'll be at hte data Reproducabilty workhop in Seattle tomorrow. Focused on the biomedical community. Very spreadsheet-centric. Lots of discussion there on tools and standards
<danbri> ESWC? seems not.
JeniT: There's a CSV Conf!
... the first international CSV conference in Berlin
phila: notes "A conference for data makers. Part of the week long OKFestival"
<danbri> part of http://2014.okfestival.org/ (so Rufus might know more)
ivan: Is it important for us to be there and for them to know about our work
<danbri> jeni planning to go
JeniT: I'm planning on going and hoping to give a presentation
danbri: I'd like to go if I can
<ericstephan> Thats our slogan CSV is relaxing
<yakovsh> there is going to be an ietf meeting in canada in july but its probably not relevant for our work : http://www.ietf.org/meeting/90/index.html