View source for SocopOor/RepositoryPrinciples

== Repositories and Foundries -Geospatial Ontology Principles based on the OBO experience  ==

The medical field has been working intensely on ontologies and the Open Biological and Biomedical Ontologies (OBO) is now a collection of freely available well-structured controlled vocabularies available on the BioPortal. Starting in 2006 OBO developed a series of 10 best practice principles (http://www.obofoundry.org/crit.shtml ) that can be leveraged of geospatial ontologies and its Open Ontology Repository which is based on Bio-Portal technology.  Note in the OBO work many potential ontologies are stored in the Bio-Portal Repository.  A selected group are them analyzed using the principles below and those that pass become select members of the OBO Foundry. The adaptation of the relevant OBO principles for moving candidates from our Geo-OOR to an eventual Geo Foundry might be expressed as follows: 

1.	The ontology must be open and 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 under the original name or with the same identifiers. 

The OBO ontologies are for sharing and are resources for the entire community. For this reason, they must be available to all without any constraint or license on their use or redistribution. That is the developers of the ontology should have no proprietary restrictions use such as arise with copyright and licensing. However, it is proper that their original source is always credited and that after any external alterations, they must never be redistributed under the same name or with the same identifiers. A license for open use such as developed by Creative Commons (http://creativecommons.org/licenses/by/2.00) may be useful. 

2.	The ontology is in, or can be expressed in, a common shared syntax. In the case of OBO this may be either the OBO syntax, extensions of this syntax, or OWL.  There are issues even for OBO since the OBO syntax OWL syntax do not the same level of expressivity and thus there are issue when converting between those. Thus it is difficult to define relation between two properties in OWL. For example, it is not possible to define that value of property Base-tree-height should be greater than the value of property Canopy-tree-height.  Another issue is property composition.  OWL does not allow property definitions where one property is combination of other two properties. These may be important parts of geosemantics. Thus for our geosemantic work even richer formalisms may be .  These may be supersets of OWL such as developed for the Common Logic standard. Converting down to less expressive formalisms like OWL are a matter of research such as discussed in:  A Practical Exploration of Ontology interoperability with Conceptual Graphs for added expressivity in the Semantic Web by Ashima Shah , Richard Hill and Simon Polovina (see http://research.shu.ac.uk/aces/spark/index.php/DC/article/viewFile/6/11).
The simple reason for a common level  to enable the same tools to be easily applied which in turn facilitates shared software implementations. Currently more advanced tools based on Common Logic are under development and may be available to time to aid this project. 

3.	The ontologies possesses a unique identifier space within an Open Ontology Repository.
The source of term (e.g. classes, relations) from any ontology should be immediately identifiable by a unique prefix of the identifier of each term. Thus SWEET terms may use SWEET as a prefix. The OBO team developed a detailed ID policy to ensure uniqueness and easy of use on the Web with URIs identifying metadata etc.  The current OOR documentation of ontologies represents a significant start on a SOCoP INTEROP ID policy.
4.	The ontology provider has procedures for identifying distinct successive ontology versions. 

This true for many of the ontologies, such as SWEET, that the community has been interested.  The OOR supports this by having a version tag as part of importation of ontologies. 

5.	The ontology has a clearly specified and clearly delineated content.
For the OBO Foundry an ontology must be orthogonal to other ontologies already lodged within the Foundry. This is not true for the exsiting [[GeopOOR]] since many overlapping ideas exist to begin with.  It remains a project to map between various ontologies and to produce orthogonality.  Even harder is community acceptance of a single ontology for one domain, rather than encouraging rivalry between domain ontologies.  It is not clear that domain can be defined cleanly enough to support this, but there are good reasons for the principle of orthogonality. It allows two different ontologies, for example geometry and geo-features, to be combined through new relationships that explicitly describe relations in a controlled fashion. 

6.	An ontologies should be well documented and  include textual definitions for all terms. 
Like biological and medical terms, geospatial and geoscience ones may be ambiguous.  What is a mountain? So terms should be defined so that their precise meaning within the context of a particular ontology is clear to a human reader. This should be done in a structured fashion such as identifying super and sub-classes, distinguishing properties etc. 

7.	The ontology uses relations which are unambiguously defined following the pattern of definitions.  
OBO provides a start on this with core relations defined at http://www.obofoundry.org/ro/ . Located_in, contained_in, and adjacent_to are all important geo-relations.  In addition the Geo-SPARQL work has developed some core relations. 

8.	The ontology has a plurality of independent users. 

Ordnance Survey, USGS and SWEET ontology work all has such independent candidate users. 

9.	The ontology will be developed collaboratively with other Repository-Foundry members.
Initial ontologies for the OOR may be independently developed, but once they are available to the wider community development on new versions and ontologies to support Use Cases will be collaborative.  This is analogous to the advancement for the Gene Ontology (GO) from its pre-OBO existence to a refinement during OBO work.  See http://www.geneontology.org/GO.ontology.relations.shtml for a discussion of  GO and OBO relations etc. 

[[Category:SOCoP]]