consider moving the mapping code to `pysen`

[LinguList]

I started drafting the mapping code, by establishing a new evaluation of similarities with respect to concepticon mappings in pysen. They are not perfect, but automated mapping has already been ported and 100% test coverage.

The principle is similar to what we decided to do in linse: in order to have access to part of the data in clts, we make a dump in zipped for, that can be included in the libraries and it is stated in RELEASING.md that the most recent dump needs to be made then.

The dump command is now available from pyconcepticon as well, and pysen also uses the dumped data for mapping.

[xrotwang]

I'm looking into this right now. So you'd propose to replacce concepticon.glosses with functinality in pysen?

[LinguList]

Yes. The idea is, similar to linse and orthography profiles (which is still not completely completed) to have dump-access to the major data from concepticon without relying on the concepticon-data.

pysen has already implemented the to_concepticon function, but no command line access (see here).

[LinguList]

So the concepticon command map_concepts I think could be best replaced by pysen map, so we'd have to add command line code to pysen.

The alternative, if we say: pysen is just the Python library, would be to say we include this into lexitools.

I am not sure now, to be honest, also with linse.

1. we need a central place to have command line code for orthography profile creation and concepticon concept mapping
2. we need to have the major internal code tested and want light-weight access to the code from within libraries that do not require to install all the data as well.

So I see two possibilities: the concept-mapping could be provided in a package like lexitools, which offers all services needed to manipulate datasets of all kinds, and already has a commandline functionality. We could leave it in concepticon, but make pysen a dependency, so we can develop the code in pysen in a more specific environment. Or we add it to pysen, as I originally thought would be the best idea (we should move pysen at some point to cldf or concepticon organization, I guess, as it seems ill-placed in lingpy). I think I am relatively open, provided we agree that it is useful to have a separate place to work on the algorithms of semantic manipulations in a light-weight package?