Define and implement strategy for giving incubated datamodels their own homes

OAK follows a pluralistic approach, supporting a number of different datamodels (see slides [31 onwards in OAK tutorial](https://docs.google.com/presentation/d/1nSThZK1C1DOn0n5ItcvtI5Wve_O4MTGxnNhMEF3dv8Y/edit#slide=id.g133b9ecbfa3_0_679))

The datamodels we use are documented here:

- https://incatools.github.io/ontology-access-kit/datamodels/index.html

(some of the autogenerated documentation could be improved but that should be a separate issue)

The underlying source is here:

- https://github.com/INCATools/ontology-access-kit/tree/main/src/oaklib/datamodels
- note in the majority of cases the yaml is the SoT, and the Python is derived

In many cases we bootstrapped/seeded many datamodels for which there was a need but no community coalescence - the aim is not to claim territory but instead to incubate.

Some datamodels are for fairly specialized use cases, for example [cross-ontology diffs](https://incatools.github.io/ontology-access-kit/datamodels/cross-ontology-diff/index.html) (#172). Others are used more ubiquitously - for example, OWL (via funowl) or [OBOGraph](https://incatools.github.io/ontology-access-kit/datamodels/obograph/index.html).

Some datamodels are specified in LinkML, with python dataclasses derived. Others like FunOWL have their SoT in Python

Some datamodels are imported, others currently incubated in OAK

An example of an imported datamodel is [SSSOM](https://github.com/mapping-commons/sssom). Both the LinkML and the python dataclasses are upstream and are imported through standard PyPI mechanisms.

A goal is for each datamodel to live upstream of OAK, with its own governance, versioning, issue tracker, group of people who care passionately about the modeling. This is lower priority for some than others. Note that this migration should be largely invisible to OAK users.

* [ ] SSSOM **DONE**
- http://w3id.org/sssom - a datamodel for representing mappings between objects together with provenance
- this is a standard well understood datamodel, we have a dependency in pyproject.toml
- used by [mapping provider interface](https://incatools.github.io/ontology-access-kit/interfaces/mapping-provider.html)
- [datamodels/sssom](https://incatools.github.io/ontology-access-kit/datamodels/sssom/index.html)
* [ ] OboGraph **PARTIALLY DONE**
- a datamodel for representing ontologies in a graph-like form
- used by [obograph interface](https://incatools.github.io/ontology-access-kit/interfaces/obograph.html)
- docs: [datamodels/obograph](https://incatools.github.io/ontology-access-kit/datamodels/obograph/index.html)
- Note that this datamodel has existed since 2016. It was originally specified loosely with exemplar json, and there have been java bindings for some time. The goal is to move the schema from OAK back to here: https://github.com/biodatamodels/obograph and to derive everything from this.
* [ ] TextAnnotator
- A way of representing the output of an ontology annotator - i.e. text span, concept recognized
- used by [annotator interface](https://incatools.github.io/ontology-access-kit/interfaces/text-annotator.html)
- [datamodels/text-annotator](https://incatools.github.io/ontology-access-kit/datamodels/text-annotator/index.html)
- This reuses SSSOM where appropriate, but most are out of scope for SSSOM
- https://github.com/mapping-commons/sssom/issues/155
* [ ] KGCL **DONE**
- represent changes on ontologies at a high level. KGCL is specified in LinkML and has python, yaml, json, rdf serializations, and it's own curator-friendly DSL
- this already has its own separate repo and pypi package we import, so no work needs done here
- https://github.com/INCATools/kgcl
- used by diff and patcher interfaces
* [ ] FunOWL **DONE**
- funowl is a Python library for working with OWL, including parser (functional syntax) and python datamodel
- https://github.com/hsolbrig/funowl/
* [ ] Cross-Ontology Diffs
- #172
- represents diffs between two ontologies related by mappings
- currently just represents structural diffs but could be used to represent how two ontologies differ in eg text definitions
- This *could* be seen as the composition `SSSOM o KGCL`, but it's more nuanced deserving of its own datamodel
- While incredibly useful this is still a niche use case and there is likely no major rush to get this into its own repo
* [ ] Summary Statistics
- a datamodel for representing summary statistics e.g. number of classes for an ontology or set of ontologies
- #68
* [ ] Validation
- a datamodel for representing the results of ontology validation
- [datamodels/validation](https://incatools.github.io/ontology-access-kit/datamodels/validation/index.html)
- used by [validation interface](https://incatools.github.io/ontology-access-kit/interfaces/validator.html)
- currently we are using the LinkML validation datamodel which is general enough for any schema-like validation use case (this DM is itself based on the SHACL validation datamodel)
- TBD: should we have one validation model that combines syntax/structure/schema with semantics ie reasoning? This feels like overloading
* [ ] Search
- let's hold off on discussing this one for now, will likely undergo a mini-refactor
* [ ] Ontology Metadata
- this is a schema for representing which properties may or may not be used for ontology elements (e.g. terms *should* have definitions, *must not* have >1 definition)
- used as input in [validation interface](https://incatools.github.io/ontology-access-kit/interfaces/validator.html)
- obviously the best long term home is here: https://github.com/information-artifact-ontology/ontology-metadata/, but this is dependent on:
- https://github.com/information-artifact-ontology/ontology-metadata/issues/62
- getting cross-obo consensus on both *what mechanism* to use to specify metadata schema *and what that schema would be* will be hard. For now the strategy is to keep incubating a schema that is very useful for validating OBO ontologies, work towards some profiling mechanism
- [datamodels/ontology-metadata](https://incatools.github.io/ontology-access-kit/datamodels/ontology-metadata/index.html)

Start by reviewing src/oaklib/datamodels and the linked datamodel documentation, noting which models are generated from YAML, defined in Python, imported, or already hosted upstream. Compare the listed migration candidates and their upstream repositories or dependencies, including pyproject.toml. Done means the project has an agreed strategy and prioritized plan for giving incubated datamodels independent homes.

Written by the indexing model from the issue text.