Add SSSOM/CSV?

[nichtich]

SSSOM is primarly defined in form of SSSOM/TSV based on TSV and YAML. In theory/future there is SSSOM/JSON and SSSOM/RDF but there is no SSSOM/CSV although it is used in practice (just use replace TSV by CSV as defined in RFC 2048). This would be a minor addition to the specification. Alternatively people should be asked to not use CSV for SSSOM.

[gouttegd]

I admit that I am somewhat irritated by the fact that people have been creating “SSSOM/CSV” sets even though there has never been anything in the spec that could remotely suggest that this was a valid possibility. CSV is never mentioned, and I am pretty sure the word “comma” is never mentioned either.

I added SSSOM/CSV support in SSSOM-Java only after I realised that SSSOM-Py silently accepts SSSOM/CSV input and that there were SSSOM/CSV files in the wild, but I only did so reluctantly.

However, here we are:

(1) there are “SSSOM/CSV” sets in the wild, whether I like it or not;
(2) all major implementations of SSSOM (SSSOM-Py, SSSOM-Java, and SSSOM-JS) already support SSSOM/CSV (do correct me if I’m wrong about SSSOM-JS?);
(3) formally defining SSSOM/CSV as a valid format would indeed be a minor addition.

So, I don’t really see any strong reason to object. @matentzn , your opinion?

[nichtich]

I'm just adding optional support of CSV to SSSOM-JS to make more existing data usable. Still there are multiple CSV dialects around so better explicitly reference RFC 4180.

[matentzn]

(3) formally defining SSSOM/CSV as a valid format would indeed be a minor addition.

Is there a way to define the CSV format by referring to a standardised transformation from TSV to CSV rather than by adding CSV as a separate standard serialisation?

[matentzn]

I am not entirely certain about whether CSV support makes things better or worse. I trust your both judgment more than my own on this; if you think its a not bad idea, lets do it.