Name and location of the goal, gosl, tensor, plot "data science and visualization" framework

[rcoreilly]

After much work, the goal, gosl, tensor and plot packages are now relatively stable and working well for the emer neural network simulations. Now we need to decide how to package all of this stuff.

• Dependency-wise, all of these packages depend on each-other, and on lots of other things within core, but nothing else in core depends on them.

• From a basic semantics and categorization of software functionality perspective, it doesn't really make sense to have a "data science and visualization" system embedded within a GUI framework.

• The external visibility of the framework as a coherent entity unto itself is also enhanced by it being a separate entity.

• Also, logistically, do we really want people filing issues and having discussions about math and algorithms and all that stuff in the same space as low-level GUI stuff? No.

Therefore, it makes sense to move this stuff out of core, and into its own repository.

Although we could put it into the cogent monorepo, I think it is sufficiently complex and multi-faceted as to warrant its own separate repository under cogentcore.org. The cogent monorepo is more appropriate for self-contained apps, but not for something that is really a new toolkit and framework.

To make this all happen, we need an overall name for the thing.

In terms of the overall scope, this framework encompasses the functionality of Python's NumPy and associated packages like matplotlib, and the broader IPython ecosystem (Jupyter notebooks etc). A central focus is on visualization and interactive GUI elements that make the exploration and management of data easier, and a "capstone" package in the system is a core data <-> visualization API that integrates everything and makes it easy to generate any kind of visualization from any kind of data, and have that connection be bidirectional (and yet clean, simple, etc).

By leveraging the strengths of the Cogent Core GUI framework, we can potentially make the system "even better" than the current python offerings, and there is no doubt that they will be much cleaner at the code level (being in just one language instead of a mess of C++ and python) and automatically available on the web without requiring a backend server, etc.

These wikipedia pages provide lots of references for the overall scope and content: https://en.wikipedia.org/wiki/Data_and_information_visualization https://en.wikipedia.org/wiki/Category:Free_data_visualization_software https://en.wikipedia.org/wiki/Category:Data_visualization_software https://en.wikipedia.org/wiki/List_of_information_graphics_software

Also, here are our existing discussions for the design of the system, which ended up in the cogent repo:

• Numbers: Math mode design cogent#324
• Numbers: data fs filesystem cogent#348

Some broad considerations on naming:

• We will retain the "Cogent" prefix, and the cogent repo apps have established the "generic" theme where the mail program is just Mail (i.e., "Cogent Mail"), instead of trying to come up with some kind of unique name for the app itself (e.g., "thunderbird" or "outlook").
• OTOH, we didn't call "core" "Cogent GUI", in part because it is bigger than that, and the same consideration applies to this project, because it is an entire framework, not just an encapsulated well-defined app. This is the same reasoning for why it doesn't belong under the existing cogent monorepo.
• Strongly prefer single, short, "real" words, as contrasted with acronyms and contractions (bonus points for cool backronyms as in core = code once run everywhere, but it also has to stand on its own).

Here's an initial list of names:

• Numbers: this is what we originally came up with in the generic, self-contained app mode.
• Data: another appropriate generic name.

Neither of those capture the key visualization aspect of the framework, however. In my opinion, some connection to this term is essential to capture the essence of the project.

• Vision: this is my favorite, because it is the shortest coherent "real" word that is closely related to "Visualization", and it has clear connotations of "insight" and is used for things like a Vision Statement -- we want people to "have a vision" of their data -- not just to see it, but to really understand it deeply, and this term captures that "deep understanding" aspect.
• Insight: per above, but less cool than Vision IMO. OTOH, @kkoreilly thinks "vision" is too confusable with actual vision stuff like the Apple Vision Pro and some kind of other vision software, like an AI vision model or something. I'm not convinced that this is a problem.
• Sight: another shorter option along the same lines. "Cogent Sight" just doesn't quite roll off the tongue as nicely as "Cogent Vision" however.

Some other more jokey options:

• Ize: as in visualize, and it sounds like "eyes".
• Lize: statistics are just lies.. :)

[kkoreilly]

We just recently had a conversation in which you referenced https://github.com/emer/vision, and I had to clarify what you were talking about because of your confusing Cogent Vision idea. Cogent Insight makes more sense than Cogent Vision, but it seems strange; almost satirical.

Moreover, your point here indirectly raises a key issue that I have mentioned before:

Also, logistically, do we really want people filing issues and having discussions about math and algorithms and all that stuff in the same space as low-level GUI stuff? No.

If you take the approach of #1380 (some interrepo mirroring system), then people will randomly file issues in either one of the repositories, leading to a massive headache. If you disable issues on the smaller repo, then there is really no point in having it, and you get the exact same problem as golang.org/x, where people have to file issues on the main repo. It would be even worse than that since you wouldn't be able to have PRs in the smaller repo or else you would get massive synchronization problems. Your #1380 proposal is simply untenable, as it sacrifices a massive amount of clarity and usability in exchange for a minor improvement in discoverability.

As such, you need to clarify whether you are proposing taking a #1380-esque approach here. If so, that is not happening. If not, then I think it is a highly questionable choice to remove key functionality that strongly depends on core from the repo. We want an integrated documentation content wiki for this ecosystem, and as soon as you poke holes in the monorepo, you get a lot of problems.

[rcoreilly]

"Lab" is also a possible naming theme, in the overall science space -- like a little laboratory for running experiments with your data or something like that. Notebook is also a central concept / metaphor. Scope-wise however this overall repository is more of a full framework / toolkit and a Notebook would end up being one component of the larger space, which includes a browser and other components, which might include a spreadsheet like thing and who knows what else. Again at some point we probably need to get a bit more specific about what else we want to include so we at least have some kind of overall space and architecture in mind.

[kkoreilly]

I like Cogent Lab better than Cogent Vision and Cogent Science, but I am not sure yet if it is good enough.

[rcoreilly]

"Cogent Lab" is probably too similar to "CoLab"?

If you look at all the other names in this space, and you think about how it will look on github and as a directory, the individual name (without the cogent prefix) really needs to stand on its own as a "proper name". Just actually picture checking out a repository called data, and seeing that name on the list of repositories. It is just too generic. It is like calling your child child. It needs to be a proper name, at the top level.

Again, if it is one of many within a whole cluster of cogent apps, like Cogent Mail etc, then this consideration does not apply -- those are automatically "subordinate" within the cogent branding sphere. But this needs to be a "top level" name.

Furthermore, the "cogent" branding will often be dropped, so you want it to be able to stand on its own. Just saying "Data" is not going to cut it -- might as well just call it "software" or "framework".

The very fact that Vision is a metaphorical, non-literal term makes it a proper name. Indeed, it is the proper name of a Marvel character.

Compare what happens when you go to https://en.wikipedia.org and type in Vision vs. Data in their search bar. https://en.wikipedia.org/wiki/Vision has many uses as a proper name for all kinds of things. https://en.wikipedia.org/wiki/Data is just the actual page on data itself as a concept. Yes there are a few other uses of it as a proper name, including a Star Trek character most notably: https://en.wikipedia.org/wiki/Data_(disambiguation) but it is obvious which name is more generally compelling as a proper name.

[rcoreilly]

After further discussion, it seems like Lab is actually a good, increasingly widely used "generic" term for this category of software, and there are enough other instances that the similarity with CoLab should not be a problem.

So we'll go for Cogent Lab!

[kkoreilly]

(For example: MATLAB, JupyterLab, CoLab)