Topics

#correspondencetables header format #correspondencetables

Miguel Fernández Astudillo
 

Yes, that makes a lot of sense

-----Original Message-----
From: hackathon2019@bonsai.groups.io <hackathon2019@bonsai.groups.io> On Behalf Of Chris Mutel
Sent: 26 March 2019 11:57
To: hackathon2019@bonsai.groups.io
Subject: Re: [hackathon2019] #correspondencetables header format

Please consider https://frictionlessdata.io/specs/csv-dialect/. We don't want to invent our own CSV dialect!

On Tue, 26 Mar 2019 at 11:35, <miguel.astudillo@...> wrote:

Dear all



For consistency I think we should specify a bit more the format of the
final tables



Separator: I’d propose “,”

null values: An empty value seems reasonable to me, but I do not have a strong preference.

Header: just one row, the first one



That should help the parser later on. What do you think?



Miguel



From: hackathon2019@bonsai.groups.io <hackathon2019@bonsai.groups.io>
On Behalf Of @MicDr
Sent: 25 March 2019 18:21
To: hackathon2019@bonsai.groups.io
Subject: Re: [hackathon2019] #correspondencetables header format



Agree. Isn t this also the current format of the tables?



--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################

 

Please consider https://frictionlessdata.io/specs/csv-dialect/. We
don't want to invent our own CSV dialect!

On Tue, 26 Mar 2019 at 11:35, <miguel.astudillo@...> wrote:

Dear all



For consistency I think we should specify a bit more the format of the final tables



Separator: I’d propose “,”

null values: An empty value seems reasonable to me, but I do not have a strong preference.

Header: just one row, the first one



That should help the parser later on. What do you think?



Miguel



From: hackathon2019@bonsai.groups.io <hackathon2019@bonsai.groups.io> On Behalf Of @MicDr
Sent: 25 March 2019 18:21
To: hackathon2019@bonsai.groups.io
Subject: Re: [hackathon2019] #correspondencetables header format



Agree. Isn t this also the current format of the tables?

--
############################
Chris Mutel
Technology Assessment Group, LEA
Paul Scherrer Institut
OHSA D22
5232 Villigen PSI
Switzerland
http://chris.mutel.org
Telefon: +41 56 310 5787
############################

Massimo Pizzol
 

When I tried to create metadata yesterday for one of the tables (isic4 to Nace2 I think) that table was in the format you describe. The problem was that some columns had mixed data types (e.g. strings and numbers) and the infer function got it wrong so I had to manually fix this. So I would suggest to keep data types homogeneous within the same column – if possible!

 

Not sure how to deal with missing values but I don’t think using e.g. zero is a good option so I would also go for empty value. OK for separator and header.

 


Massimo

 

From: <hackathon2019@bonsai.groups.io> on behalf of "miguel.astudillo via Groups.Io" <miguel.astudillo@...>
Reply-To: "hackathon2019@bonsai.groups.io" <hackathon2019@bonsai.groups.io>
Date: Tuesday, 26 March 2019 at 11.35
To: "hackathon2019@bonsai.groups.io" <hackathon2019@bonsai.groups.io>
Subject: Re: [hackathon2019] #correspondencetables header format

 

Dear all

 

For consistency I think we should specify a bit more the format of the final tables

 

Separator: I’d propose “,”

null values: An empty value seems reasonable to me, but I do not have a strong preference.

Header: just one row, the first one

 

That should help the parser later on. What do you think?

 

Miguel

 

From: hackathon2019@bonsai.groups.io <hackathon2019@bonsai.groups.io> On Behalf Of michele.derosa@...
Sent: 25 March 2019 18:21
To: hackathon2019@bonsai.groups.io
Subject: Re: [hackathon2019] #correspondencetables header format

 

Agree. Isn t this also the current format of the tables?

Miguel Fernández Astudillo
 

Dear all

 

For consistency I think we should specify a bit more the format of the final tables

 

Separator: I’d propose “,”

null values: An empty value seems reasonable to me, but I do not have a strong preference.

Header: just one row, the first one

 

That should help the parser later on. What do you think?

 

Miguel

 

From: hackathon2019@bonsai.groups.io <hackathon2019@bonsai.groups.io> On Behalf Of michele.derosa@...
Sent: 25 March 2019 18:21
To: hackathon2019@bonsai.groups.io
Subject: Re: [hackathon2019] #correspondencetables header format

 

Agree. Isn t this also the current format of the tables?

Bo Weidema
 

I still do not understand why we do not use RDF for this? In RDF every one of the relations would be separate.

Bo

Den 2019-03-25 kl. 18.03 skrev miguel.astudillo@...:

Hello all

should the correspondence table have only two columns?



For example, the exiobase to nace codes: to classify exiobase activities to nace codes the names (descriptions) are not needed. For me it would make more sense to have nace code to nace name in a different table. What do you think?

Miguel
--

Michele De Rosa
 

Agree. Isn t this also the current format of the tables?

Miguel Fernández Astudillo
 

Hello all

should the correspondence table have only two columns?



For example, the exiobase to nace codes: to classify exiobase activities to nace codes the names (descriptions) are not needed. For me it would make more sense to have nace code to nace name in a different table. What do you think?

Miguel