CommunityPracticesInOntologyMetadata

Old wiki site for this page

 * This page is properly formattted to display this info.
 * https://wiki.cbil.upenn.edu/obiwiki.old/index.php/CommunityPracticesInOntologyMetadata

Requirements
The following requirements have been identified by the members of the BIRN Ontology Task Force in the course of the curation we've been doing on the BIRNLex ontology framework. Though what follows brings no implied warranty from NCBO or the OBO Foundry, in the course of this work, we've been advised extensively by several members of NCBO including Barry Smith and Daniel Rubin. We are working toward submitting BIRNLex to the OBO Foundry, have been guided by the OBO Foundry best practices, and have invested considerably investigating practices also in use by long standing biomedical knowledge representation efforts such as the NIH NLM Unified Medical Language System (UMLS) and the Gene Ontology.

Since the overall goal according to the OBO Foundry best practices is to maximally re-use of relevant community ontologies to promote semantic integration of data sets/observations described with any and all of the OBO Foundry ontologies, it appears to the BIRN OTF these annotation properties really ought to be included in the foundational levels of the shared ontologies - preferably at the foundational level (e.g., the Basic Formal Ontology (BFO) and OBO Relation Ontology (RO)), so as to guarantee software systems designed to algorithmically support conformance with the OBO Foundry principles can be extended to all participating ontologies. As mentioned by Liju Fan, we really would be unwise to invent our own languages for such properties.

The other aspect of providing the shared, foundational properties in an artifact we all share (e.g., BFO) is by importing that foundation, we also import those properties AND can sub-class from them as required. For instance, should BIRN need to add additional requirements for class definitions over-and-above the OBO Foundry requirements of lack of circularity and Aristotelean format, the BIRN OTF could sub-class the bfo:definition and add a definition that includes to needed additions. As a sub-class of bfo:definition, software designed to process such a property would still work on this property. If bfo:definition is sub-classed from skos:definition, software capable of processing that property would work on all these classes. Of course, since these are sub-sumptive graphs, sub-classing would only be allowed if ALL properties of skos:definition are true of the other two definitions as well.

(BB : more to come this evening. These are just to provide examples for all to peruse)

Background
The following represent the result of seeking to map the needs described above using annotation, editorial, and general metadata properties available in various standards

Current Practice
The following represent the current Annotation Properties in use within the BIRNLex OWL file.

(BB : more to come this evening. These are just to provide examples for all to peruse)

Though the overwhelming majority of |Dublin Core Metadata Terms || ] are much more targeted to librarian curation requirements, these also include several date properties derived from 'dc:date' of obvious use to us - e.g., modified, created, dateAccepted, etc.; however, these are not available in the dc-dl.owl file used by Protege, probably because subclassing Annotation Properties is not allowed in OWL-DL. There are also other DC Terms that would be useful - e.g., conforms to (a child of the DC Element relation). With this in mind - until we can work out a better solution - when I refer to a Source class above, I mean this is the class the specific Annotation Property would derive from were it possible to subclass Annotation Properties in OWL-DL. In the interim, this subclassing is simply indicated by flattening out the superclass - subclass relation in the specific Annotation Property name - e.g., birn:skosDefinitionoboDefinition_

� Of course, with the proliferation of such class properties, there are signficant issues that arise regarding their use: Though these would all be standard features in an RDBMS front-end user entry system, to the best of my current knowledge (2006-09-19), only number 2 (default property values) and 3 (enumerated lists) are directly supported in Protege-OWL. Without these conveniences, the curation process is unecessarily slower and error-prone.
 * Is there a way to create classes so they automatically possess the required properties.
 * Can default values be set for standard properties where defaults are appropriate - e.g., birn:creationDate should be automatically added to a new class with today's date.
 * Some properties should include an enumerated list of expected values, which can be expanded as necessary - e.g., 'birn:definitionSource', 'birn:curationStatus', etc.
 * Is there a means to easily associated one Annotation Property with another - e.g., associating the 'birn:definitionSource' MeSH with the 'birn:externalDefinition' shown above.
 * Can some of these properties be assigned as collections or as a bit map of enumeration values - e.g., for 'birn:curationStatus', there are classes where we'd want to specify both obo definition incomplete & graph position temporary.

Metatdata to Include About a Term
Minimum Information * current marked as defprov in OBI
 * Preferred Term Name (rdfs:label, SKOS:prefLabel)
 * Synonym(s) - See examples posted at ...
 * Unique Identifier (rdf:ID or dc:identifier)
 * Definition (rdfs:comment, SKOS:definition, dc:coverage)
 * Example of how to use the term (SKOS:example)
 * Source of Definition (dc:source, dc:contributor)

Additional Information
 * Term curation status - location in graph and format of definition (refer to above for how the BIRN project is using this; skos:editorialNote -> birn:curationStatus)
 * scopeNote (from SKOS, clarifies the meaning of the a concept)
 * changeNote (SKOS) - A note about a modification to a concept.
 * editorialNote (SKOS) - A note for an editor, translator or maintainer of the vocabulary.
 * historyNote (SKOS) - A note about the past state/use/meaning of a concept.
 * Reference to source of term/definition? (dc:relation, dc:bibliographicCitation)
 * hiddenLabel (SKOS)? -  A lexical label for a resource that should be hidden when generating visual displays of the resource, but should still be accessible to free text search operations.
 * set xml:lang attribute=en -> Check if this is needed using the new version of Protege

Metadata to Include About the Ontology

 * Title of Ontology (dc:title)
 * Subject (dc:subject)
 * Release Date (dc:date, dc:created, dc:issued)
 * Description of Ontology (dc:description)
 * Authors of the Ontology (dc:creator or dc:contributor)
 * Entity responsible for making the resource available? (dc:publisher)
 * Version of the ontology (owl:versionInfo, dc:hasVersion, dc:isVersionOf)
 * protege:defaultLanguage, value=en. This is needed to hide the numneric identifiers used in the rdf:ID field with the string label.

The current needs (Spring, 2007) for metadata information is listed on the OBI Minimal metadata page along with it's implementation in the OBI.owl file
====Note: The above is a minimal set of descriptors. Find a full recommendation and detailed information such as examples and cardinalities for the annotation tags in the Metadata Annotation document, Chapter 7.2.5.1 Metadata for representational units (RUs):==== http://msi-ontology.sourceforge.net/recommendations/MetaAnnotv2.doc

This document was compiled in a way to also fulfill the general domain iondependent needs of the NCIT and BIRN requirements (mentioned above).
An implementation of the full metadata set as owl annotation properties (ready to use by owl:imports statements) is available from:

https://svn.sourceforge.net/svnroot/msi-workgroups/ontology/RU_metadata.owl

For more details look at the [[OntologyMetadataAnnotation|Ontology Metadata Annotation |]] pages or the specification document.

This is a first draft and discussion version. Please have a look and send comments to the obi devel list
Dublin Core Metadata StandardDublin Core Metadata StandardDublin Core Metadata StandardDublin Core Metadata Standard