CogPO's Wiki Policies

The whole point of having a Wiki is to allow concepts to be identified and fleshed out collaboratively before becoming "official." A concept is entered into the official CogPO Protege/OWL files when it's been hammered out a bit on the Wiki and shows no sign of going away. Definitions and other properties can change once the concept is entered into CogPO, of course. But the general ideas are as follows:

1. Any member of the research community can create new concepts or edit concepts. Create a log in and start making suggestions. All edits are reviewed by CogPO curators, who reserve the right to undo them if it is not in keeping with best practices or ontological clarity.

1. While suggesting a new concept is as simple as making a new Wiki page, a new concept MUST include the required properties noted below before it will be considered for inclusion in CogPO. Optional properties are also listed in the Annotation Properties file.

1. Please use the Search box before you make a new concept to identify if the term or a related term has already been given a wiki page. We also recommend searching NeuroLex, CogAtlas, and the NCBO Bioportal for related terms so you can see what concepts other experts have created that might be what you need.

1. You can also suggest new relationships. The guidelines for defining relationships are coming soon.

Defining a concept in CogPO: required properties

In keeping with best practices from NeuroLex, the Neural ElectroMagnetic Ontology (NEMO), and others, concepts in CogPO must have the following annotation properties defined:

• COGPO_annotation_properties:definition – A natural language definition that adheres to Aristotelian constraints (A is a B that C's). Equivalent to core:definition. Example: The auditory modality is a sensory modality that involves the auditory nervous system.
• COGPO_annotation_properties:preferredlabel -- An underscore-delimited, human-readable label for a concept. Equivalent to rdfs:label and core:prefLabel. this is the most common way for humans to refer to the concept. Example: The preferred label for the concept "Auditory Modality" is "Auditory_Modality".
• COGPO_annotation_properties:hasURI -- This property defines the CogPO URI for a concept. The URI is a non-human-readable label that also provides a stable web address for accessing the concept. For an imported term, the URI should be the source ontology URI (if possible?). MIREOT recommends that the source term URI be included specifically. This only is filled in when the concept is curated.
• COGPO_annotation_properties:createdDate -- [YYYY-MM-DD] The date when the current concept was created. Equivalent to the same term in NeuroLex.
• COGPO_annotation_properties:curator -- This property defines the CogPO ontology curators who've contributed to the definition of a class. In the case of multiple curators, the individual curator name may also be associated with the definition, if that person was primarily responsible for it.
• COGPO_annotation_properties:hasCurationStatus -- This provides specific info on the level of curation a given class has received, and is specifically designed to promote automated reporting on the status of classes in an ontology. It is a type of skos_editorial_note. For a full listing of the possible values for Curation Status, see the full COGPO Annotation Properties Media:CogPOAnnotationPropertiesOct2009.pdf‎.

Also required are:

1. the direct superclass concept, either from within CogPO or from another ontology. Example: The superclass for Auditory_Modality is Stimulus_Modality.
2. the most granular concept from BFO that is applicable. Everything is either a continuant or an occurrent, but it would be better to suggest a branch a little lower in the BFO tree than that top level. The curators will also do their best to fill this term in.