The ontology release criteria are a compilation of the rules and artifacts that constitute the release of an ontology ( or versioned ontology module? tbd), and are key considerations in the planning, verifying, testing and release of an ontology. The criteria are a static view of the requirements for a release than about the what an ontology developer or agent might do with them releasing an ontology and less about what an ontology author and the ontology working group does during the various stages of developing an ontology – activities that to satisfy them. The latter activities are described separately in this portal under the processes areas mentionedunder Ontology Development Policies & Procedures. Furthermore, a clear distinction is made in the wording describing a criterion as to whether it is required element (“must”) or desired (“should”).
NOTE: For now, the release criteria are imported in An initial set of proposed release criteria was submitted to the release with comments are attached to this Wiki page here. These served as a Microsoft Word document with redlining and comment tracking activated. To add comments or make revisions, please download and edit directly in the Word document on your desktop (click on the “Quick Tutorial for Editing a MS Word Document in Atlassian” link below if you don’t know how to do this yet). Once the release criteria are stable and we have adopted an initial version of them, we’ll update this page and copy the actual content into the page.
| Attachments |
|---|
...
an input to compiling the target set of release criteria appearing below. And please note that this “target” set is a work-in-progress at the present time. If you wish to make comments or raise concerns, please log them in the Jira task for this here: https://oagiscore.atlassian.net/browse/DRMP-14
The list of criteria is as follows:
Freedom from IP encumbrances – the intellectual property (IP) terms called forth in the ontology file(s) are compliant with the IOF IP policy (mostly implicit through membership for future IOF generated content and through a check of license and copyright annotations against IOF required forms by hygiene tests and/or human inspection but may require member or broader patent checks even then, and any outside materials referenced, reused, or on which the IOF content is otherwise dependent. Any ontologies with content predating the OAGi transition will require convincing relevant OMG membership that the IP is unencumbered, typically through signing the release form, but other means may be used.)
Machine readable form (conformant with rdf/xml and OWL)
IRI structure and format (web ontology forms conform to IOF rules for IRI Structure and Format. Tested with hygiene tests or SPARQL queries)(see Confluence - Industrial Ontologies Foundry, Pages > Ontology Development Policies & Procedures > Procedures > Ontology Development > IRI Structure and Format)
Quality (with respect to naming and annotation rules, tested with hygiene tests and possibly human inspection)
Conformance to BFO (minimally, every class in a classified BFO version of the OWL ontology has a BFO class in its supertype hierarchy. Tested with a combination of reasoning and queries on the results)
Composability with Core (tested through a combination of automation and human inspection)
Composability with other IOF content (to already released content and, where applicable, the other components of the next release of which this content will be a part)[note that such a requirement may not apply to all IOF content] (tested through a combination of automation and human inspection)
Availability of additional artifacts in the proper form and repository location(s)
Required:
Documentation of any other ontologies, taxonomies, vocabularies, or other works used in or by the ontology, if any.
This should include information on the version used, the canonical source for these materials that is intended to be used going forward, information on the license, conditions of use, and any IP encumbrances associated with these resources.
(for Domain Ontologies) Use cases and competency questions, which may be in the same artifact if the Use Case Template was used.
Desirable (some of these may be required for domain independent ontologies, and/or their presence may represent a higher level of content maturity):
Getting started and overview document
Documentation of examples of element uses, edge cases, counter examples and known issues
More comprehensive guide of how to use all the elements, which may be combined with the above desirable content
RDF instance data providing examples of the elements in the ontology module(s) for both testing and explication of the ontology
Supplemental content for reused materials corresponding to what would be required for native IOF content (e.g. required IOF annotations for reused ontology elements)
Additional Considerations (as We Evolve These Criteria):
For each criteria:
describe the requirements
how they will be evaluated (automation, review)
evidence required (if applicable)
possible additional process, automation, or additional IOF decisions needed
notes/comments