Open stefandesu opened 4 years ago
I'd not aim at functionality but simplicity and round-tripping with JSKOS convert from jskos-cli.
Hmm, I didn't know that jskos-cli has a completely separate set of conversion methods. We should definitely bring them together (I guess that's what you mean by "round-tripping with JSKOS convert from jskos-cli"?)
The thing is that almost all these features I listed above are, in my opinion, necessary for the conversion methods to make sense. Especially the first three points are things I stumbled upon when fixing the CSV conversion in jskos-server. For example, because jskos-server is streaming mappings that are converted to CSV, we don't have information about the maximum number of target concepts. Because the current method to generate the headers requires access to ALL mappings though, we can't used it and have to manually specific the header row. Also, jskos-server would currently fail to output mapping creator names if creator.en
is empty (that might be currently hardcoded into Cocoda, but it actually shouldn't be expected) because the conversion method doesn't deal with that.
Actually, it would probably be best to completely rewrite it all, making it more flexible (i.e. can be used not only for mappings, but also for other JSKOS entities), and replacing both jskos-tools' and jskos-cli's conversion methods with the new ones.
The method was improve in the past (#6), but there are still many more things that can improved:
fromCount
andtoCount
for example)prefLabel
method has a fallback for the language tag)type
creator
@nichtich Any further ideas?