OntologyMetadata

jie zheng edited this page Mar 15, 2017 · 2 revisions

Availability

Content

The ontology metadata file contains all the information required to use the IAO style of annotation properties.

  • editor preferred term: The concise, meaningful, and human-friendly name for a class or property preferred by the ontology developers. (US-English)

    1. Cardinality: each class must have a single editor preferred term
    2. Implementation: annotation property specified as a functional property named "preferred term".
  • definition: The official definition, explaining the meaning of a class or property. Shall be Aristotelian, formalized and normalized. Can be augmented with colloquial definitions.

    1. Cardinality: each class must have a single definition
  • definition editor: Name of editor entering the definition in the file. The definition editor is a point of contact for information regarding the term. The definition editor may be, but is not always, the author of the definition, which may have been worked upon by several people.

    1. Cardinality: each class can have many definition editors
  • definition source: formal citation, e.g. identifier in external database to indicate / attribute source(s) for the definition. Free text indicate / attribute source(s) for the definition. EXAMPLE: Author Name, URI, MeSH Term C04, PUBMED ID, Wiki uri on 31.01.2007

    1. Cardinality: each class can have one or more definition sources
    2. Implementation: annotation property named "definition source". See guidelines for providing sources for term definitions.
  • curation status specification:

    1. Each class has a single curation status
    2. The curation status of a class or property. The allowed values must come from this enumerated list of predefined terms:
      1. placeholder: This isn't a class that the ontology will keep - it's a placeholder for edits that are underway. The class name should start with an underscore
      2. uncurated: Nothing done yet beyond assigning a unique class ID and proposing a preferred term
      3. metadata incomplete: Class is being worked on; however, the metadata (including definition) are not complete or sufficiently clear to the editors.
      4. metadata complete: Class has all its metadata, but is either not guaranteed to be in its final location in the asserted IS_A hierarchy or refers to another class that is not complete.
      5. pending final vetting: All definitions, placement in the asserted IS_A hierarchy and required minimal metadata are complete. The class is awaiting a final review by someone other than the definition editor.
      6. ready for release: Class has undergone final review, is ready for use, and will be included in the next release. Any class lacking "ready_for_release" should be considered likely to change place in hierarchy, have its definition refined, or be obsoleted in the next release. Those classes deemed "ready_for_release" will also derived from a chain of ancestor classes that are also "ready_for_release."
    3. Cardinality: 1..1
    4. Implementation: enumerated value
  • example of usage: A phrase describing how a class name should be used. May also include other kinds of examples that facilitate immediate understanding of a class semantics, such as widely known prototypical subclasses or instances of the class. Although essential for high level terms, examples for low level terms (e.g., Affymetrix HU133 array) are not

    1. Cardinality: each class can have none, one, or more examples of usage
  • alternative term: An alternative name for a class or property which means the same thing as the preferred name (semantically equivalent)

    1. Cardinality: Each class can have many alternative terms
    2. Implementation: annotation property
  • editor note: A note containing points under consideration for further term development that may be included in released versions of the ontology. It should contain nothing embarrassing and something potentially useful for end users to understand the ontology. Editor notes should include the date of edit (YYYY/MM/DD) and the author.

    1. Cardinality: Each class can have one, or many editor notes
    2. Implementation: annotation property
  • curator note: An administrative note intended for the curator of the ontology. It will not be included in the released versions of the ontology, so it should contain nothing necessary for end users to understand the ontology. Curator notes should include the date of edit (YYYY/MM/DD) and the author.

    1. Cardinality: Each class can have one, or many curator notes
    2. Implementation: annotation property
  • obsolescence reason specification:

    1. Each deprecated class has a single obsolescence reason
    2. The obsolescence reason of a class or property. The allowed values must come from this enumerated list of predefined terms:
    3. failed exploratory term: The term was used used in an attempt to structure part of the ontology but in retrospect failed to do a good job
    4. terms merged: An editor note should explain what were the merged terms and the reason for the merge.
    5. term split: This is to be used when a term has been split in two or more new terms. An editor note should indicate the reason for the split and indicate the URIs of the new terms created.
    6. placeholder removed: This is to be used when the original term has been replaced by a term imported from an other ontology. An editor note should indicate what is the URI of the new term to use.
    7. term imported: This is to be used when the original term has been replaced by a term imported from an other ontology. An editor note should indicate what is the URI of the new term to use.
  • OBO foundry unique label: An alternative name for a class or property which is unique across the OBO Foundry.

    1. Implementation: The intended usage of that property is as follow: OBO foundry unique labels are automatically generated based on regular expressions provided by each ontology, so that SO could specify unique label = 'sequence ' + label, etc. , MA could specify 'mouse + label' etc. Upon importing terms, ontology developers can choose to use the 'OBO foundry unique label' for an imported term or not. The same applies to tools.

Discussion

See

https://github.com/information-artifact-ontology/IAO/issues/38 (closed)

obo2owl conversion:

https://github.com/information-artifact-ontology/IAO/issues/90

https://github.com/information-artifact-ontology/IAO/issues/91

https://github.com/information-artifact-ontology/IAO/issues/92

https://github.com/information-artifact-ontology/IAO/issues/93

https://github.com/information-artifact-ontology/IAO/issues/94

https://github.com/information-artifact-ontology/IAO/issues/95

https://github.com/information-artifact-ontology/IAO/issues/96

https://github.com/information-artifact-ontology/IAO/issues/97

https://github.com/information-artifact-ontology/IAO/issues/98

https://github.com/information-artifact-ontology/IAO/issues/99

https://github.com/information-artifact-ontology/IAO/issues/100

https://github.com/information-artifact-ontology/IAO/issues/103

Activate label display in Protege 3

Most of the time, you will want to display the labels of the annotation properties within the Protege 3 editor, i.e. display "definition" instead of for example IAO_0000115.

If this is the case, you need to follow the following steps:

  1. add the declaration of the protege defaultLanguage in your ontology
  2. add the declaration of the corresponding annotation property

Your file should be similar to:

[...]
  <owl:Ontology rdf:about="">
    <owl:imports rdf:resource="http://purl.obolibrary.org/obo/iao.owl"/>
    <protege:defaultLanguage rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
    >en</protege:defaultLanguage>
  </owl:Ontology>
  <owl:AnnotationProperty rdf:about="http://protege.stanford.edu/plugins/owl/protege#defaultLanguage"/>
</rdf:RDF>

You then need to follow the traditional steps to activate the label display within Protege:

  1. In Protege, in the menu OWL, choose preferences. This will open a new window.
  2. In this window, choose the Visibility tab. The section at the top left corner of that tab is called Metaclasses. Check the box "All" in this section, which should automatically check all the other boxes of the section for you. Do the same for the section RDF Properties and Annotation Properties.
  3. You can now close that window.
  4. In the Protege main window, you should see 5 tabs: Metadata (protege opens by default on that window), OWL Classes, Properties, Individuals and Forms. Choose the Forms tab.
  5. In the Forms tab, the left part is the Form browser. Select owl:Thing in the Form Browser.
  6. The right part of the tab, the Form editor, has a display slot at the top. In this display slot, scroll to select rdfs:label instead of :NAME
  7. Expand the sub tree rdfs:class by clicking the small grey triangle in front of it. Select owl:Class. As in 6., change the display slot to rdfs:label instead of :NAME
  8. In the form browser (left part of the window), select rdf:Property, and as in 6., change the display slot to rdfs:label instead of :NAME
  9. You can now choose the OWL Classes tab, and you should have the labels displayed instead of the numerical identifiers.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.