Draft: start of document for certain implementation details about obofoundry.github.io

[nataled]

@cthoyt that was the first method considered and ultimately rejected. You're only seeing part of what this list will be, and some has nothing to do with issues. Also, we don't want to create a label for a one-time project.

[nataled]

From issue tracker (some of these are potential additions not necessarily proposed for a principle):
METADATA Term adoption #2330 (also #2324)
SOCIAL External axioms #1443 & #1991 | possible new "what to do with terms" principle (can be p14)
METADATA Versioning term identifiers #1347 /
METADATA Linking term to discussion on tracker #1097
METADATA Language tags #479 (also #325)
METADATA Synonym types #2450
METADATA Ontology root terms annotation #2149
COMMUNICATION (do we need STANDARDIZATION?) Short ontology descriptions #1968
COMMUNICATION Documentation for license #1840
METADATA Publications metadata #1671
METADATA Ontology merging #1548
COMMUNICATION Discourage BFO shadow classes #1539
METADATA Exemplar classes #899
CONTENT? Ignoring NCIT (no issue, but has come up that NCIT is not well-formed enough to be a concern re: things like overlap)
METADATA Ontology metadata requirements #1365
STANDARDIZATION? Standardized xref prefixes in ontologies #525
Proposals here: #482 (comment)
COMMUNICATION Ontology subsets documentation #466
COMMUNICATION Referring to taxa not in NCBITaxon #434
METADATA Standardizing how imported ontologies are noted #424
COMMUNICATION Document how to add logo #72
METADATA Modeling metaclasses #2454 (thanks @cthoyt, that's a good addition)

[cthoyt]

@nataled simplest way might be to create a new label for the issue tracker / PRs

[cthoyt]

Another one for this list: #2454

[nataled]

Bill H: Reviewed principles 1-8. No eligible text except for 'Term adoption' in P8.
Hande: Reviewed last 5. No eligible text.
EWG: Reviewed P9 & P10. No eligible text.

[nataled]

For guidance, we have the following categories for the principles themselves:

Social ():
P1) Open - The ontology MUST be openly available to be used by all without any constraint other than (a) its origin must be acknowledged and (b) it is not to be altered and subsequently redistributed in altered form under the original name or with the same identifiers.
P9) Documented Plurality of Users - The ontology developers should document that the ontology is used by multiple independent people or organizations.
P10) Commitment To Collaboration - OBO Foundry ontology development, in common with many other standards-oriented scientific activities, should be carried out in a collaborative fashion.
P11) Locus of Authority - There should be a person who is responsible for communications between the community and the ontology developers, for communicating with the Foundry on all Foundry-related matters, for mediating discussions involving maintenance in the light of scientific advance, and for ensuring that all user feedback is addressed.

Communication (between ontology developers and between developers and users):
P8) Documentation - The owners of the ontology should strive to provide as much documentation as possible.
P13) Notification of Changes - Ontologies SHOULD announce major changes to relevant stakeholders and collaborators ahead of release.
P20) Responsiveness - Ontology developers MUST offer channels for community participation and SHOULD be responsive to requests.

Content (pertains to what is in the ontology):
P5) Scope - The scope of an ontology is the extent of the domain or subject matter it intends to cover. The ontology must have a clearly specified scope and content that adheres to that scope.
P6) Textual Definitions - The ontology has textual definitions for the majority of its classes and for top level terms in particular.
P7) Relations - Relations should be reused from the Relations Ontology (RO).
P12) Naming Conventions - The names (primary labels) for elements (classes, properties, etc.) in an ontology must be intelligible to scientists and amenable to natural language processing. Primary labels should be unique among OBO Library ontologies.
P16) Maintenance - The ontology needs to reflect changes in scientific consensus to remain accurate over time.

Technical (formats):
P2) Common Format - The ontology is made available in a common formal language in an accepted concrete syntax.
P3) URI/Identifier Space - Each ontology MUST have a unique IRI in the form of an OBO Foundry permanent URL (PURL).
P4) Versioning - The ontology provider has documented procedures for versioning the ontology, and different versions of ontology are marked, stored, and officially released.