move pyiron_ontology to standalone table

[liamhuber]

Dependencies are all pinned properly with daily CI runs working fine; coverage is 95%; readthedocs is up and running.

The dependencies are only numpy, owlready2, pandas, and pint, so I think "standalone" make sense.

[jan-janssen]

I currently do not see that pyiron_ontology fits for:

there is a continuous release of spin-off packages which are used inside pyiron, but which can also be used as stand-alone packages

I would rather move it to the Stable Version section just like pyiron_contrib

[jan-janssen]

Thinking about this a bit more the Stable Version is most likely also not the right category. I guess my biggest issue is currently that I do not see how pyiron_ontology is currently used or how it is going to be used in future.

[liamhuber]

I currently do not see that pyiron_ontology fits for:

there is a continuous release of spin-off packages which are used inside pyiron, but which can also be used as stand-alone packages

If this objection is something beyond your second comment about where/how it is used, please expand; I don't see how pyiron_ontology fails to fit this description.

Thinking about this a bit more the Stable Version is most likely also not the right category.

I agree; those packages (ex.-base) are all domain specific, depend on pyiron_base (afaik), and have some corpus of data associated with them. Those criteria aren't explicitly listed in the header, but I agree pyiron_ontology does not fit in well.

I guess my biggest issue is currently that I do not see how pyiron_ontology is currently used or how it is going to be used in future.

The first clause is extremely straightforward: pyiron_ontology is already used in ironflow. In the example below (also demo'd on the ironflow landing page) it is leveraged to provide both the dynamic (i.e. use-based) typing that controls whether connections are allowed, and the node recommendation system, which is powered by the the same functionality as the "workflow tree" example in the pyiron_ontology docs:

As for future use, of course that's harder to nail down. @JNmpi has requested and I fully agree that pyiron_workflow should get extended with ontological typing (ala ironflow). In the course of doing that I would expect to make changes to pyiron_ontology -- possibly even significant ones -- but since it's already working and has demonstrated applicability to the problem, it's the logical place to start for that functionality.

[jan-janssen]

The first clause is extremely straightforward: pyiron_ontology is already used in ironflow.

But then I do not understand why you do not want to keep it in Next Generation Developments

[liamhuber]

Because it is a small, standalone tool that I can see being useful to other projects that want to exploit dynamic typing or workflow-tree constructions. I.e. I see it as a standalone tool, and not something that is intrinsically or exclusively for use with other pyiron modules

[jan-janssen]

From my perspective pyiron_ontology is a library for the packages in Next Generation Developments - mainly ironflow as you explained above. In contrast to this, the packages in Stand-alone Packages are libraries for the current stable version and the new developments. Therefore pyiron_ontology belongs to Next Generation Developments.

[liamhuber]

From my perspective pyiron_ontology is a library for the packages in Next Generation Developments - mainly ironflow as you explained above.

For me this is a bit of a chicken-and-egg issue; the library (afaik) is currently only leveraged by ironflow, but it is fully standalone and can be leveraged in non-pyiron projects just as well. Moving it to the Stand alone table makes this generic usability clear and raises visibility.

In contrast to this, the packages in Stand-alone Packages are libraries for the current stable version and the new developments. Therefore pyiron_ontology belongs to Next Generation Developments.

IMO this is an overly restrictive interpretation of "used in pyiron" that overrides the more important section-header description of "Stand alone".

If we do choose to apply this more restrictive interpretation, I suppose pyiron_lammps then also needs to be moved to another section.

[jan-janssen]

If we do choose to apply this more restrictive interpretation, I suppose pyiron_lammps then also needs to be moved to another section.

That's a good suggestion - I am happy to move pyiron_lammps to Next Generation Developments

[liamhuber]

If we do choose to apply this more restrictive interpretation, I suppose pyiron_lammps then also needs to be moved to another section.

That's a good suggestion - I am happy to move pyiron_lammps to Next Generation Developments

🤦‍♂️ while I appreciate the internal consistency, that wasn't my main point. IMO ironflow should be in Next Generation Developments because it is a proof-of-concept in scope and, importantly, not receiving active dependency updates; pyiron_workflow should be in Next Generation Developments because it is feature-incomplete (storage is not merged, database interactions are non-existent).

In contrast, pyiron_lammps and pyiron_ontology are both feature-complete, stable, and useable as-is. Stand alone is quite a sensible place for both.

(As an aside, pyiron_gui can probably be over in Stable as well, although it's possible @niklassiemer has some feature incompleteness concerns he wants to address first, similar to my feelings on pyiron_workflow).

[jan-janssen]

I guess we should discuss this topic in the next pyiron meeting, as I feel it is a more fundamental discussion how we want to define the categories on the GitHub overview page.

[jan-janssen]

As discussed in the pyiron meeting, we agreed to move pyiron_ontology to Stand-alone Packages and pyiron_gui to Stable Version, reducing the next generation developments to pyiron_workflow and ironflow.