The original policy on ontology governance page is [ here ]. Now, that the Cluster has evolved into a Committee, and in light of recent 2016 Winter meeting discussions, we would like to revisit the ontology governance issue.
Notes for the Ontology Governance session at the 2016 Winter meeting can be found [here].
As we develop a governance policy we should interact with external groups to ensure reuse where applicable and broad adoption. Some groups that are relevant to the discussion:
- RDA: There is a metadata interest group that has spun out. No dedicated semantics group because semantics is everywhere in RDA
- Force11 - they are counting ontology as software using code to manage terms.
- GCMD - how do we impact the GCMD keywords, and how they manage them?
- EarthCube Semantics Working Group
A Possible Solution
- The ESIP Semantic Technologies Committee will commit to providing a dedicated server and ontology portal to the community. This will be funded out of the committee's yearly budget
- This portal will provide both registry and repository functions. Thus, it can host ontologies when needed as well as reference externally hosted ontologies
- The portal will require a minimum set of metadata to make the ontology useful. What this minimum set entails is open for discussion.
- The persistence of the server will allow for permanent and stable URIs.
- The ESIP Ontology Portal provides the notion of "authority". Each registered ontology is labeled with an authority.
- The authority dictates which entity/organization controls the ontology as well as the corresponding governance policy.
- ESIP would develop an ESIP-core authority - analogous to Dublin Core in the library sciences, Darwin Core in ecology, and Descartes Core in geography - to maintain a set of ontologies and vocabularies that are deemed central to ESIP and semantic interoperability
- It is important to note that ESIP-core is NOT a set of top-level (also called foundational or upper) ontologies. Rather, ESIP-core is a set of high-quality, often reused, ontologies and mappings that lower the initial entry hurdle to data access and integration
- Any ontology or mapping in the ESIP-core is subject to the ESIP Ontology Governance Policy
- Ideally, ESIP-core evolves into the first place people look and the gold-standard
- Additional ontologies - even those with semantics that conflict with ESIP-core semantics - can be registered and maintained under different (non-ESIP) authorities. Such ontologies may even have more uptake and use than ESIP-core ontologies - potentially leading to new discussions and revisions of ESIP-core ontologies.
- Ontologies restrict interpretations. They do not fix meaning.
- We encourage people to disagree with what terms mean and how they are modeling. Heterogeneity is a feature, not a bug.
- Thus, we should invest in ontology alignment and look for places where consistent, re-used, meaning emerges. This set becomes the core.
- Such a policy is inline with the Semantic Web vision that anyone can say anything about anything.
- What ends up in ESIP-core and how?
- I believe we need a system in which people can actively rate and comment on ontologies and offer forks. The core will converge and become stable by community buy-in and reuse
- Although, exactly what constitutes "enough" buy-in and reuse to be promoted to ESIP-core is an open question.
- Process for commenting, forking, and requesting changes
- The ESIP Ontology Portal does not have any of these features
- GitHub offers a decent way of doing this
- We create a GitHub repo under the ESIP organization containing the ontology governance policy once it is finalized
- What is a good method for ontology forking?
- For OWL ontologies we could create a new ontology and utilize the OWL constructs owl:priorVersion and owl:backwardCompatibleWith to provide credit back to the original ontology and also to allow software to track derivative ontologies in the repository.
- I would try to avoid taking ontologies already in the portal and duplicating them in GitHub for forking purposes. Maybe derived (forked) ontologies could go in GitHub and the ontology from which it was derived could have its portal metadata updated to reflect alternative copies in GitHub?
- GitHub issue tracking can be used to request changes and discuss ontologies in the ESIP-core
- ESIP-core Governance
- Continue the policy created by Peter Fox - a small committee comprised of the chair and two members at large review incoming change requests
- Minor changes/extensions are implemented immediately by the committee
- Large changes/extensions are sent out to the ESIP Semantic Technologies committee for debate and discussion
- Is there a clear dividing line between what is a minor change vs. a large change?