Official repository for Semantic Web for Earth and Environmental Terminology (SWEET) Ontologies. For more information, see https://sweet.jpl.nasa.gov.
SWEET ontologies are written in the OWL ontology language and are publicly available. SWEET version 2.3 is highly modular with 6000 concepts in 200 separate ontologies. You can view the entire concept space from an OWL tool such as Protege by reading in sweetAll.owl. Alternatively, these ontologies can be viewed individually.
SWEET 2.3 consists of nine top-level concepts/ontologies. SWEET is a middle-level ontology; most users add a domain-specific ontology using the components defined here to satisfy end user needs.
SWEET is governed by the ESIP Semantic Technologies [Committee] (http://wiki.esipfed.org/index.php/Semantic_Technologies) (STC) meaning that all proposed changes are evaluated by a number of subject matter experts. If you would like to learn more about SWEET, or are interested in joining the community, please join our community mailing list.
The development process for SWEET follows the Review-then-Commit software development process. For more information, see the Subsection below
The following is the SWEET Github development workflow:
- create a local copy of the ESIPFed sweet repo
git clone https://github.com/esipfed/sweet.git - configure remotes on local - specify the ESIPfed sweet repo remote as 'upstream':
git remote add upstream https://github.com/esipfed/sweet.git - fetch the branches and their respective commits from the upstream repository:
git fetch upstream - as with many projects,
masteris our main branch, so if you are proposing to change the codebase, skip to 5 below - log an issue in the sweet issue tracker. Please use labels to classify your issue. If you need a new label to be created then please state this in your issue description.
- create a branch in your local repo which tracks master in upstream. The branch name should reflect the issue number you created above e.g. SWEET-1
git checkout -b SWEET-1 upstream/master - make the changes in your branch & commit - with commit message please! e.g.
git commit -m "SWEET-1 Test Issue for SWEET" - synchronise your changes with upstream:
git push upstream SWEET-1 - within GitHub, create a Pull Request from SWEET-1 into master ... at this point, you might assign the Pull Request to someone else (preferabbly a subject matter expert) to check before merging
- EDITORS ONLY: Once a review has been undertaken and consensus exists that it is OK, within GitHub, merge the changes into master
- bring all those changes back into your local repo:
git fetch upstream - rebase (don't 'pull' - because this creates another commit) changes on your branch:
git rebase upstream/master
Additionally, if you wish to discuss SWEET issues with the STC, please contact us via the WG email list.
SWEET is licensed permissively under the Apache License v2.0 a copy of which ships with this source code.