See also: IRC log
JeniT: Won't approve last week's minutes as there are so few of us here
JeniT: Are you, Eric, standing in for the editors
ericstephan: I'll give a bit of
background on what we did last week
... before taking it back to the e-mail list
ericstephan: Last week we were
asked to evaluate the requirements
... Jeremy has been very busy so it was David who took the lead and starting working through the requirements
... I took a second pass. trying to work out which ones are more broadly accepted.
<JeniT> CSV ftw ;)
ericstephan: I made a table
... Jeremy also made some comments - all of these are in the table
... Tim made some last minute changes/additions as well
... also in the e-mail exchange there were further considerations
... I was looking for ones that we blanket accept and which ones may not be so universally accepted
... david was looking for requires that can be merged. Jeremy did the same
... Ivan brought some interesting comments. Should we be looking for blanket acceptance or should we try and categorise the ones we have
<jumbrich> JeniT, behind jumbrich is Jürgen Umbrich from WU Vienna
ericstephan: then we began talking about whether res should be mandatory or optional
<JeniT> http://lists.w3.org/Archives/Public/public-csv-wg/2014Apr/0110.html and thread
ericstephan: Then, Jeni said that
mandatory reqs mean that any implementation would need to do
all of them
... JeniT said these are just reqs from the use cases and we should keep it at that level
... I think we can iterate on these questions
... how do we vote on the reqs? By groups? By individual reqs in a telecon or e-mail?
JeniT: In terms of process, I'd
like to operate by consensus. Votes are only useful to
highlight those that need furtehr discussion
... I suggest if we have a list of those that are in and these are out - then people can raise objections
... we just then worry about ones that people think are in the wrong bucket
... I managed to go through them before the call. Would it be better for me to give feedback here or on the list
ericstephan: Might better on the list so we get more people involved
JeniT: OK, I'll do that. There
are a few where I have ideas
... some look like reqs for the tabular data model - maybe that's a category
... I think it's good to have reqs for each of the docs.
... I'll try and write an e-mail about all that
... really good work. Thank you Eric and the other editors
ericstephan: So do we let this
roll for another week?
... and then see if we can come to consensus?
JeniT: I suggests that we come
back next week with the reqs organised in buckets in the doc
and ask for approavl of that
... and if we need discussion then we can do it after that. We;re hoping for another publicatiin in about 3 weeks' time
PhilA: I'm half way through
wriitng my use case
... going from metadata to data
... I'll have it on the wiki this week
ericstephan: I did add some new use cases to our git, the one from Yakov. So we have two or three more UCs beyond Phil's that need to be added
JeniT: And Eric, you're going to add HL7 as well - I know there are more to add
ericstephan: I expect to have them all added this week.
JeniT: Anythign else from anyone?
AndyS: The 3 of us met - me, Ivan
... I think we got a clear picture of what we want to do.
... there will be an explicit phase around cleaning data so it more accurately conforms to the tab data model
... then basic mapping like this col is an integer
... then a template-driven transformation which may be purely string to string
... thought we'd add more content around that
... good focus for the work for the foreseeable future
JeniT: On the cleaning data
... I thinkwe tackled that a little in the model development
JeniT: there's a section of
parsing files into the tab data model
... that's not an RDF thing
... it's needed for any kind of understanding for tab data
... we also had some push back on that section/work
... at W3C level as it's not part of our charter to define parsing of tab data so I'd focus on the latetr portions of what you're talking about
AndyS: We're not planning on
writing anything about cleaning, just that you need to know the
... getting your character set right etc. is not part of this - we'll start after that
... what we need is a formal def of the Tabular Data Model
... is that in this doc or somewhere else/
JeniT: In what way is the def of the Core Tab Data model and annotated def not clear?
AndyS: I'd like it to say that a
table is a sequence of rows etc. More precise definition
... think we need a more textual description. at the moment it says 'data is held in a table' but doesn't say what a table is
JeniT: Would you be prepared to add yourself as an editor and then add any formal defs that are needed
AndyS: I think that's the best place for that def. I thinkw e could write the def and then worry about which doc it goes in
JeniT: I think it would be good if you could include that in the model doc for now - and we can think about audience etc. afterwards
AndyS: Might be better to split some of the more discursive stuff from the formal
JeniT: Are you willing to do that?
AndyS: Yes, if I can find the time
JeniT: I'm happy to put in the work, but I don't see a prob with the informality - clearly you do so can you fix it pls?
AndyS: One other thing... Gregg is travelling a lot in the coming weeks which will slow us down a little
JeniT: After last week I was
asked to write a bit more about...
... (see mail)
... My feeling was that most of us are on the same page in terms of how we want to pitch things
... but AndyS may hve more to say?
AndyS: There's nothing in there I
felt was wrong
... the devil is in the detail - what's a 2 or a 3
... different ecosystems put diff spin on things
... in publishing, assumption is that XSLT is available. Not so much in JSON- centric
... we'll see how far we get with the templating approach
... I suspect that's where the bulk of the work will be
... we should be able to make valuable input for JSON and XML
... some things like stops and starts don't apply to RDF etc.
JeniT: Anything else to raise on RDF mapping?
JeniT: I've not made the progress
I was hoping to make on whether we support embedding of
... I'm not sure that any of the UCs highlight that as a req and it may add complexity where it isn't necessary
... so I'm thinking of writing to the WG to get agreement that, apart from col heading, all metadata is in a separate file
... Again, my aim is to have a new version of the model doc in 3 weeks' time
JeniT: This morning I published
an Editor's Draft...
... it takes the JSON package and JSCON schema from OKF et al and turning it into W3C style but without really editing the content
... there's a little bit of motiviation in the intro
JeniT: showing the kind of thing
we're aiming for, why metadata is important
... I've got some issues I want to take to Rufus anad have proper discussion here next week
... one thing it highlights is the need for a separate data definition
... and annotations at individual cell and row level - this isn't handled at all in data Pacakaging
... so there is some progress on this
... Any questions/issues?
<ericstephan> Thank you!
OK, we'll call it a day there