ARTICLE IN PRESS

Contents lists available at ScienceDirect

Computers & Geosciences

Computers & Geosciences 34 (2008) 1022– 1033

0098-30

doi:10.1

� Cor

E-m

geohab@

journal homepage: www.elsevier.com/locate/cageo

Developing a modular hydrogeology ontology by extending theSWEET upper-level ontologies

Ajay Tripathi, Hassan A. Babaie �

Department of Geosciences, Georgia State University, Atlanta, GA 30302-4105, USA

a r t i c l e i n f o

Article history:

Received 22 December 2005

Received in revised form

6 July 2007

Accepted 29 August 2007

Keywords:

SWEET ontologies

Upper-level ontology

Hydrogeology

Modular domain ontologies

04/$ - see front matter & 2008 Elsevier Ltd

016/j.cageo.2007.08.009

responding author. Tel.: +1404 463 9559; fa

ail addresses: atripathi1@gsu.edu (A. Tripath

langate.gsu.edu, hbabaie@gsu.edu (H.A. Ba

a b s t r a c t

Upper-level ontologies comprise general concepts and properties which need to be

extended to include more diverse and specific domain vocabularies. We present the

extension of NASA’s Semantic Web for Earth and Environmental Terminology (SWEET)

ontologies to include part of the hydrogeology domain. We describe a methodology that

can be followed by other allied domain experts who intend to adopt the SWEET ontologies

in their own discipline. We have maintained the modular design of the SWEET ontologies

for maximum extensibility and reusability of our ontology in other fields, to ensure inter-

disciplinary knowledge reuse, management, and discovery.

The extension of the SWEET ontologies involved identification of the general SWEET

concepts (classes) to serve as the super-class of the domain concepts. This was followed

by establishing the special inter-relationships between domain concepts (e.g., equivalence

for vadose zone and unsaturated zone), and identifying the dependent concepts such as

physical properties and units, and their relationship to external concepts. Ontology

editing tools such as SWOOP and Protege were used to analyze and visualize the structure

of the existing OWL files. Domain concepts were introduced either as standalone new

classes or as subclasses of existing SWEET ontologies. This involved changing the

relationships (properties) and/or adding new relationships based on domain theories. In

places, in the Owl files, the entire structure of the existing concepts needed to be changed

to represent the domain concept more meaningfully. Throughout this process, the

orthogonal structure of SWEET ontologies was maintained and the consistency of the

concepts was tested using the Racer reasoner. Individuals were added to the new concepts

to test the modified ontologies. Our work shows that SWEET ontologies can successfully

be extended and reused in any field without losing their modular or reference structure,

or disrupting their URI links.

& 2008 Elsevier Ltd. All rights reserved.

1. Introduction

Ontologies are developed for formal depiction ofreality through explicit definition of concepts (terms),representing real (individual) domain entities, relationsbetween these entities, and rules and constraints forcombining and relating the terms (e.g., Neches et al.,

. All rights reserved.

x: +1404 6511376.

i),

baie).

1991). Although ontology has been defined as ‘‘a formal,explicit specification of a shared conceptualization’’(Gruber, 1993), it is used to encode the reality rather thanour conceptualization of it. Guarino (1998) categorizedontologies, based on their level of dependence, point ofview, or task, into four types: top-level, domain, task, andapplication. We are concerned with the first two types inthis paper. Top- or upper-level ontologies define verygeneral, meta, or abstract types (e.g., layer, surface, bodyof water) to unify a wide range of domain concepts(http://ontology.teknowledge.com).

ARTICLE IN PRESS

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–1033 1023

Upper-level ontology must be general enough to covera broad range of vocabularies (i.e., concepts and theirrelations) and theories of related domains (fields). Theseupper-level concepts are meant to be used to constructdomain ontologies of variable scope, purpose, nature, andsize, and define domain-specific concepts, such as vadosezone, bedding, and lake, through mechanisms such as sub-classing (i.e., specialization) (Gomez-Perez et al., 2004).Domain ontologies are engineered for specific fields suchas petrology and hydrogeology. These ontologies areformal specifications of the shared concepts, theories,and principles within each field. Given the inter-disciplinary nature of many sciences, ontology reuse is amajor activity in ontological engineering (Gomez-Perezand Rojas-Amya, 1999). Full or partial reuse of existingontologies allows domain experts to apply related con-cepts from other fields for intra- and inter-domaininformation interchange and management.

NASA’s Semantic Web for Earth and EnvironmentalTerminology (SWEET; Raskin and Pen, 2005) is a groupof top-level ontologies which are designed to beextended by domain experts such as planetary geologists,hydrogeologists, stratigraphers, and geophysicists. In theknowledge-driven world the need to develop ontologiesfor knowledge representation of an environmental sciencesuch as hydrogeology is not being questioned any more.The challenge today is to design modular domainontologies to prevent data redundancy, and at the sametime enable optimum reusability of information. Theontologies must have a modular design so that theycan be shared across applications, and be readily extendedor modified according to the requirements of a particulardomain (Rector, 2003). SWEET ontologies represent anexcellent example of a modular design. This meansthat the components of the ontologies (e.g., classesand properties) are defined at the global level in asingle OWL file, or in imported, reusable files. Themodular architecture ensures extensibility and reusability,which are facilitated through XML’s namespace andimport/include mechanisms (http://www.w3.org/TR/xmlschema-1/).

SWEET ontologies are evolving with time and requirecommunity contribution for future development. This isthe reason why we will continue to see version changes inthe future. It is expected that subject matter experts willbe able to identify the shortcomings and gaps in SWEETand suggest future modifications at the time of modelingtheir specific scenarios. The scope of this paper is topropose a methodology which could involve significantchanges in the existing structure and design of the top-level SWEET ontologies, without disturbing their overallcoherence.

Modifying complex upper-level ontologies such asSWEET can be overwhelming unless a structured approachis followed. These ontologies use complex concepts (i.e.,classes) which are sometimes inter-dependent eitherwithin or across the ontologies. When considering reusingor extending SWEET, the domain specialists need toanalyze the gaps in the existing upper-level design. It issometimes necessary to do complex structural modifica-tions (i.e., modifying class hierarchies), redefinitions of

classes, and cross-ontology modifications. While makingthese modifications, it is important to maintain thescope and modular structure of the ontologies forfurther extensibility and restructuring by other domainexperts.

Due to their modular architecture, SWEET ontologiesare being extended in several fields in the Earth Sciencessuch as structural geology (Babaie et al., 2006; Zhonget al., 2005), hydrogeology (Piasecki and Beran, 2005), andatmosphere (Ramachandran and Movva, 2005). In thispaper, we describe the methodology for extending theupper-level SWEET ontologies, and define the stepsinvolved in the reengineering process (Kalyanpur et al.,2004a). The methodology can be applied by other domainexperts who intend to modify and adopt the SWEETontologies for their own fields. There are several ontologyanalysis and design tools, such as Protege (Knublauchet al., 2004), SWOOP (Kalyanpur et al., 2004b), SMORE,and Altova SemanticWorks (http://www.altova.com/products_semanticworks.html), which can be used towork with the SWEET ontologies. In this paper we presentan approach towards reengineering the SWEET ontologiesto make them useful for a small part of the hydrogeologydomain without affecting their reusability, structuralintegrity, and stewardship.

2. Sweet ontologies

The SWEET is an upper-level ontology for Earth systemscience (http://sweet.jpl.nasa.gov/ontology/). There areseveral different ontologies within SWEET which includethousands of top-level concepts related to the Earth system(Raskin and Pan, 2005). Since the SWEET ontologies area large collection of concepts (terms), they are dividedinto orthogonal dimensions or facets (http://sweet.jpl.nasa.gov/guide.doc). Orthogonal or faceted design is atechnique which enables us to use combinations of termsacross ontologies in order to make compound terms. Forexample, if there is a term air in one of the ontologies(substance.owl) and another term temperature inthe same or other ontology (property.owl), we cancombine the two terms to make a compound term air

temperature. This way we eliminate the need to create anew air temperature term by itself. However, sometimes, itis a better idea to have meaningful, standalone compoundconcepts such as Hydraulic Gradient which need to beexplicitly defined rather than constructed by combiningtwo terms.

Orthogonal or faceted ontologies also help in quickretrieval of knowledge, and are therefore more efficient.Orthogonal dimensions or facets ensure reusability as wellas reductionism. Fig. 1 (http://sweet.jpl.nasa.gov/guide.doc) shows the SWEET ontologies represented by rectan-gular boxes. Fig. 1 also has two dotted rectangular boxescontaining a set of ontologies. The big box represents thefaceted ontologies whereas the small box representsintegrative ontologies. Integrative ontologies are unifyingontologies which do not contain mutually orthogonalterms. They contain holistic terms which use elementsfrom the faceted ontologies.

ARTICLE IN PRESS

SWEET Ontologies and Their Interrelationships

NaturalPhenomena

LivingSubstances

Human Activities

Data

Space Time

Numerics

Units

PhysicalProperties

Earth Realm

PhysicalProcesses

Non-LivingSubstances

Faceted Ontologies

Integrative Ontologies

Fig. 1. Architecture of SWEET ontologies (See text for explanation).

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–10331024

The lines in Fig. 1 represent properties which linkontologies. For example, the Earth Realm ontologyincludes the Aquifer concept (class) and the PhysicalProperties ontology. In the process of modifyingthe Earth Realm ontology, we identified the need toadd a new object property hasPermeability to theAquifer class. The hasPermeability property wasadded to the Physical Properties ontology to con-nect the Aquifer concept to the Permeability con-cept. In this case, the Aquifer and Permeability arethe domain and range of the hasPermeabilityproperty, respectively.

SWEET is a complex set of ontologies, where someof the base ontologies may not be fully orthogonal. Asan example, ontologies such as Units are just a scalefactor for the values in Physical Properties. On theother hand, the ontologies like Living Substance,Non-LivingSubstance, PhysicalProcessesand Earth Realm act as categorical qualifiers forPhysical Properties and appear as the first-orderontologies.

The OWL files of the SWEET ontologies, available fromhttp://sweet.jpl.nasa.gov/sweet, are scalable, i.e., they aredesigned to be extended and adopted for specializedlower-level domains such as hydrogeology. SWEET ontol-ogies are also application-independent, and can be usedacross multiple platforms.

3. Using SWEET ontologies for hydrogeology

Hydrogeology is a discipline of science which dealswith the occurrence, characteristics, and movement ofwater below the Earth’s surface. The hydrogeology sub-domain being modeled here pays particular attention tothe environmental conservation and natural resourcemanagement, and is closely related to other Earth systemconcepts like regional properties, physical properties,atmosphere, and space.

As described earlier, SWEET ontologies represent theupper-level concepts of the Earth system science, whichcan be extended and reengineered by adding newconcepts, properties, or individuals (instances), or byrearranging pre-existing owl classes, properties, andindividuals. The new, modified design (Tripathi, 2005)presented in this paper, makes SWEET more meaningful toa domain expert such as a hydrogeologist, withoutdisturbing the consistency of SWEET for use by otherdomains. The SWEET ontologies (i.e., OWL files) which wehave re-engineered, in order to accommodate some of thefundamental concepts of hydrogeology, are as follows:

�

earthrealm.owl—The earthrealm.owl on-tology constitutes the realms of the earth (as opposed tothe Sunrealm.owl). These realms include the atmo-sphere, ocean, and solid earth, and associated sub-realms

ARTICLE IN PRESS

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–1033 1025

such as BodyofWater and Hydrosphere-Layer.

� process.owl—This ontology includes physical pro-

cesses that affect living and non-living substances, suchas diffusion, evaporation, and inter-flow.

� property.owl—This ontology contains concepts

of Physical Properties such as temperature,pressure, and height, and could apply to other SWEETontologies like process.owl. These properties arethe measured physical quantities with units.

� phenomena.owl—This ontology is used to define

transient events such as hurricane, earthquake, El Nino,and volcanic eruption. This ontology also includesspecific instances of phenomena which comprise about50 events which have occurred over the past twodecades.

� substance.owl—This ontology includes the liv-

ing and non-living substances. The living substancesinclude plant and animal species. The non-livingsubstances include: particles, electromagnetic radia-tion, and chemical compounds.

� units.owl—This ontology includes conversion

factors between various units and consists of Unidata’sUDUnits. Prefixed units such as km and cm are definedas special cases of m with appropriate conversionfactor.

� human_activities.owl—This ontology takes

into account the impact of human activities onprocesses and phenomena. Some of these activitiesare commerce, fisheries, and farming.

Fig. 2. Ontology Repository Manager in Protege-OWL (http

�

material_thing.owl—This ontology includesphysical objects, structures, and equipments.

4. Steps involved in extending sweet

The modular reengineering of the SWEET ontologies,to adopt it for a small part of the hydrogeologydomain, involves the following steps (Tripathi, 2005).These steps can be taken by other domain experts whointend to extend the SWEET ontologies in their owndomains.

Step 1—importing and local storing of the ontologies:The ontology editing tools such as Protege-OWL, allowus to directly import the OWL files and edit the ontologies,thus enabling an import and extend option. TheSWEET ontologies were downloaded from (http://sweet.jpl.nasa.gov/ontology), and saved in a folder on our localmachine. Using The Ontology Repository Manager inProtege-OWL, we then created a project repository andselected the folder, where we had saved the local copy ofOWL files as our ‘‘Local folder’’ (Fig. 2). We could thus editthe local ‘‘cached’’ copy of the ontologies, and make all thenecessary changes to it until we were ready to propose thechanges for publication in the future version of the SWEETontologies.

Step 2—identifying domain concepts and properties:The next step is to identify and collect key concepts,

://protege.stanford.edu/doc/owl/owl-imports.html).

ARTICLE IN PRESS

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–10331026

definitions and information about the domain whichneed to be mapped. In our case, the hydrogeologi-cal terms were compiled together. Domain knowledgecan be gathered in several different ways such asbuilding scenarios and asking competency questions(Babaie et al., 2006), looking through existing glossaryof terms, or by interviewing domain experts (Gomez-Perez et al., 2004). All the available terms are thenidentified as classes, properties, or individuals. In theOWL language, concepts that represent entities in thedomain are depicted by classes. In some cases, classes arerelated to each other through subsumption, and need tobe arranged hierarchically, thus making some of theclasses, subclass of higher class(s) in the taxonomichierarchy. The subclasses, which inherit properties fromtheir super-class, can define their own properties. Forexample, the class Aquifer, which has the Unconfi-nedAquifer as a subclass, has properties such ashasName and hasLocation. These properties willbe inherited by the UnconfinedAquifer subclass.Individuals are instances of the concepts with filled valuesfor data type and relational properties. In this example,the hasName property could have the Floridan-Aquifer value. The OWL language enables powerfulreasoning capabilities which can help us query the domainmodels in order to manipulate data (Tripathi, 2005).

It is sometimes difficult to distinguish between classand property. Here is a simple example by which wecan understand the difference between a class, individual(i.e., instance), and property: ‘‘An aquifer whose nameis ‘X’ has hydraulic conductivity of 9�10�7 m s�1’’. Inthis example Aquifer is a class, X is an individual(e.g., X could be the ‘‘Floridan aquifer’’), and hasHy-draulicConductivity is a property. The 9�10�7

ms�1 is the value of the hydraulic conductivity for thisindividual. Property can either be a data type property oran object property. Datatype property has individuals orinstances related to a data type. For example, thedateOfAquiferTest property may have an XMLSchema xsd:date (http://www.w3.org/XML/Schema)datatype (e.g., 2005-10-03). An object (relational) prop-erty is one in which two individuals of a class are related.For example, all instances of the Aquifer class have aproperty called hasHydraulicConductivity,which relates instances of the domain class (i.e., Aqui-fer), to the instances of the range class (i.e., Hydraulic-Property).

Step 3—setting properties: Establish the inter-relation-ships between all existing and new concepts through theclass relationships such as owl: sub-ClassOf (e.g.,ConfinedAquifer sub-ClassOf Aquifer),owl:disjointWith (e.g., ConfinedAquiferdisjointWith Unconfined Aquifer), andowl:equivalentClass (e.g., vadose zone ¼unsaturated zone ¼ zone of aeration; pumping test ¼aquifer test).

Step 4—inter-relating concepts: Identify the dependentconcepts, such as physical properties (qualities) and units,and determine their relationships to external concepts,e.g., Water has Temperature 25. Temperature has UnitCelsius).

Step 5—extending upper-level concepts: Once theterms relevant to the domain are available, toolslike SWOOP or Altova Semantic Works can be used todo an advanced concept search across all theSWEET ontologies being used. Based on the result ofthe search the domain experts decide how to modelnew terms under existing terms in the SWEETontologies, or remodel the existing terms to makethe concepts more meaningful. The classes, sub-classes, properties, and individuals of relevant sectionsof the ontology are examined and the gaps are identi-fied. In order to see the relationships betweenterms, visualization tools like Altova SemanticWorks,OntoViz (http://protege.stanford.edu/plugins/ontoviz/ontoviz.html), or OwlViz (www.co-ode.org/downloads/owlviz/) can be used. These tools are very helpful whenwe are working with large and multiple ontologies such asSWEET.

Step 6—fine-editing the modified ontologies: After thedomain experts have identified the necessary changes tobe made, the ontologies can be edited using OWL editorslike Protege (Horridge et al., 2004) or Altova SemanticWorks. The OWL classes, properties, and individuals canthen be added or edited. During this step, new domainconcepts are added as new classes in the OWL files, or assubclasses of already existing classes in the SWEETontologies. Synonymous terms, commonly used in thedomain (e.g., hydrogeology), are also added at this stage.Once the new classes are added and the existing classesare modified, the relationships between concepts aremaintained. The existing relationships (properties) areredefined and new relationships are added within therequired domain. Conditional and restrictional logicalexpressions can also be checked or added in this step. Itis a better idea to add individuals (e.g., FloridanAquifer) after the classes and properties have beensatisfactorily modeled.

Step 7—checking for orthogonality: After acquiring theterms and identifying their relationships, we are readywith the raw version of an extended ontology; in our case,the hydrogeology sub-ontology. The new ontology re-quires some fine tuning to maintain the orthogonalstructure of SWEET ontologies. If any new concept isdisturbing the overall SWEET design, it needs to be re-adjusted. The conventions used in SWEET for namingclasses, properties, and individuals, must be maintainedwhen adding new classes, properties, and individuals.While adding new terms, reusability of the term by otherdomains must be considered. We thus design a sub-ontology which is scalable and has a scope for furtherextension or reuse.

Step 8—testing the ontology: The final step is to test theontology for syntax and semantics. This can be done usingOWL validators, or by checking the consistency of conceptsusing appropriate tools such as Protege, which uses theRacer reasoner, to check consistency of concepts. AltovaSemantic Works allows continuous check for syntax andsemantics while building the ontology. After the consistencycheck is done we can add individuals for specific require-ments. Once the individuals are added, we can write queriessuch as RDQL (a query language for RDF: http://

ARTICLE IN PRESS

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–1033 1027

www.w3.org/Submission/2004/SUBM-RDQL-20040109/), orOWL-QL (Fikes et al., 2003; http://ksl.stanford.edu/projects/owl-ql/) to get answers for our competency questions whichwe had used while modeling the knowledge base. Theontology is working correctly if we get correct answers tothose questions.

Step 9—publishing the ontology: Once the ontology hasbeen extended and carefully tested, it is ready to bepublished. Because we worked with a ‘‘cached’’ local copyof the ontology, we need to ask the SWEET webadministrator/curator to update the ontology with appro-priate version changes.

5. The hydrogeology ontology

We have applied the above steps and extended theSWEET top-level ontologies to make them compatiblewith a small part of the hydrogeology domain. Thereengineering involved several changes in design, andaddition of several new concepts to the originalSWEET taxonomies. We made several changes toSWEET’s earthrealm.owl ontology to accommo-date the new hydrogeology concepts. This includedconceptual changes to existing hierarchies and addingnew concepts to other SWEET ontologies like proper-ty.owl, units.owl, process.owl, and phe-nomena.owl. Here, we will illustrate and explain thechanges made to earthrealm.owl as an example of thereengineering process.

The figures in this section, representing the OWLclass hierarchies, have been created using the OntoViztab in Protege to illustrate the remodeling of theontologies. The properties of classes establish connectivitybetween concepts across ontologies. In the followingfigures, the boxes represent classes and the arrowsrepresent properties. The box having the head ofthe arrow is the super-class (parent class), and thebox which has the tail of the arrow is its subclass (childclass). Subclasses specialize their super-classes. If thearrows show a cyclic relationship, (i.e., the arrows pointin either directions between two boxes) the classes areequivalent and there is a recursive relationship. We alsoobserve the feature of multiple inheritance in thesefigures where multiple arrows from a subclass point todifferent super-classes. This indicates that one subclasscan inherit the behaviors and features from more than onesuper-class.

The earthrealm.owl file contains the mainconcepts related to groundwater. The property.owlcontains the object properties. The following importantchanges have been made to the earthrealm.owland property.owl ontologies to accommodate thehydrogeology domain:

5.1. Conceptual error corrected

In the original earth realm owl SWEET ontology,GroundWater is placed under owl: thing,and VadozeZone is placed under GroundWater.VadozeZone is the unsaturated zone and technicallydoes not relate to GroundWater by definition. Vado-zeZone is now separated from GroundWater, and ismade the equivalent class of UnsaturatedZone. Thenew ZoneOfAeration class is introduced and madeequivalent of the VadozeZone and Unsaturated-Zone (Fig. 3). This concept is therefore reconstructed inour modified earthrealm.owl ontology. Ground-Water is now part-of UndergroundWater.The region occupied by UndergroundWater islocated-in both the UnsaturatedZone(VadoseZone) and SaturatedZone, and theregion occupied by GroundWater is located-inthe SaturatedZone (Fig. 3).

5.2. Object properties added to groundwater

The following new object properties were defined for theGroundWater class: hasRecharge was added to theproperty.owl ontology, hasDischarge wasadded to the property.owl ontology, and hasLo-cation was added to the space.owl ontology.

5.3. Object properties added to unsaturatedzone

A new hasHydraulicConductivity propertywas defined for the SaturatedZone class, and wasadded to the property.owl ontology.

5.4. Concept of aquifer and its subclasses and properties are

added

A new SaturatedZone class was added as apart-of the Aquifer class, i.e., Aquifer has-part SaturatedZone (Fig. 3). The Ground-Water calss is located in SaturatedZone.Multiple sub-classes ArtesianAquifer, Confi-nedquifer, PerchedAquifer, and Water-TableAquifer are added and placed under Aquifer.ArtesianAquifer and ConfinedAquifer aremade equivalent. UnconfinedAquifer and Water-TableAquifer are made equivalent. Some of theseclasses and relations are shown in the well-formed code inListing 1, and in Figs. 3 and 5. The first few lines in the listingshow the XML namespace and import statements. Com-ments are given as: /!–This is a comment –S in the listing.Code is given as nested indentations for clarity.

Listing 1. Well-formed owl code showing some of thechanges to the sweet ontologies discussed in the text

ARTICLE IN PRESS

numerics:Numerical Entity

numerics:Geometrical Object

space:Spatial Object

? primary substance substance:water ?space:is Part Of Hydrosphere space:Body Earth Realm

Planetary RealmPlanetary StructureBody of Water-Ocean

subsurface Water ? space:inside Land Surface Layer Land Water Object

part-ofUnderground Water

located-in

Vadoze Zone

Unsaturated Zone

Zone Of Aeration Capillary Fringe

externally-connected-to

Saturated Zone

has-part

Aquifer

located-in

Ground Water

located-in

Fig. 3. Class diagram showing modified class hierarchy of earthrealm.owl ontology.

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–10331028

ARTICLE IN PRESS

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–1033 1029

/?xml version ¼ ‘‘1.0’’?S/rdf:RDF xml:base ¼ ‘‘http://sweet.jpl.nasa.gov/ontology/earthrealm.owl ’’xmlns ¼ ‘‘http://sweet.jpl.nasa.gov/ontology/earthrealm.owl# ’’xmlns:daml ¼ ‘‘http://www.daml.org/2001/03/daml+oil# ’’xmlns:dc ¼ http://purl.org/dc/elements/1.1/xmlns:numerics ¼ ‘‘http://sweet.jpl.nasa.gov/ontology/numerics.owl# ’’xmlns:owl ¼ ‘‘http://www.w3.org/2002/07/owl# ’’xmlns:property ¼ ‘‘http://sweet.jpl.nasa.gov/ontology/property.owl# ’’xmlns:rdf ¼ ‘‘http://www.w3.org/1999/02/22-rdf-syntax-ns# ’’xmlns:rdfs ¼ ‘‘http://www.w3.org/2000/01/rdf-schema# ’’xmlns:space ¼ ‘‘http://sweet.jpl.nasa.gov/ontology/space.owl# ’’xmlns:substance ¼ ‘‘http://sweet.jpl.nasa.gov/substance.owl# ’’xmlns:xsd ¼ ‘‘http://www.w3.org/2001/XMLSchema# ’’S/owl:Ontology rdf:about ¼ ‘‘http://sweet.jpl.nasa.gov/earthrealm.owl ’’S/owl:versionInfo rdf:datatype ¼ ‘‘http://www.w3.org/2001/XMLSchema#string ’’S.0//owl:versionInfoS/owl:imports rdf:resource ¼ ‘‘http://sweet.jpl.nasa.gov/numerics.owl ’’/S/owl:imports rdf:resource ¼ ‘‘http://sweet.jpl.nasa.gov/substance.owl ’’/S/owl:imports rdf:resource ¼ ‘‘http://sweet.jpl.nasa.gov/space.owl ’’/S/owl:imports rdf:resource ¼ ‘‘http://sweet.jpl.nasa.gov/property.owl ’’/S//owl:OntologyS/!—Only few domain classes are given below for brevity--S

/owl:Class rdf:about ¼ ‘‘http://sweet.jpl.nasa.gov/earthrealm.owl#UndergroundWater ’’S/owl:equivalentClassrdf:resource ¼ ‘‘http://sweet.jpl.nasa.gov/earthrealm.owl#SubsurfaceWater’’/S

/rdfs:subClassOfS/owl:RestrictionS

/owl:onPropertyS/owl:ObjectProperty rdf:about ¼ ‘‘

http://sweet.jpl.nasa.gov/space.owl#inside ’’/S//owl:onPropertyS/owl:allValuesFromSrdf:resource ¼ ‘‘

http://sweet.jpl.nasa.gov/earthrealm.owl#LandSurfaceLayer ’’/S//owl:RestrictionS

//rdfs:subClassOfS/rdfs:subClassOf rdf:resource ¼ ‘‘

http://sweet.jpl.nasa.gov/earthrealm.owl#LandWaterObject ’’/S//owl:ClassS

/owl:Class rdf:about ¼ ‘‘http://sweet.jpl.nasa.gov/earthrealm.owl#ConfinedAquifer ’’S/rdfs:subClassOf rdf:resource ¼ ‘‘http://sweet.jpl.nasa.gov/earthrealm.owl#Aquifer ’’/S

/owl:equivalentClassrdf:resource ¼ ‘‘/http://sweet.jpl.nasa.gov/earthrealm.owl#ArtesianAquifer ’’/S

//owl:ClassS/owl:ObjectProperty rdf:ID ¼ ‘‘hasPermeability’’S

/rdfs:domainS/owl:ClassS

/owl:unionOf rdf:parseType ¼ ‘‘Collection’’S/owl:Class rdf:about ¼ ‘‘http://sweet.jpl.nasa.gov/earthrealm.owl#Aquifer ’’/S/owl:Class rdf:about ¼ ‘‘

http://sweet.jpl.nasa.gov/earthrealm.owl#ConfiningLayer ’’/S/rdf:Description rdf:about ¼ ‘‘

http://sweet.jpl.nasa.gov/property.owl#Permeability ’’/S//owl:unionOfS

//owl:ClassS//rdfs:domainS/rdfs:range rdf:resource ¼ ‘‘http://sweet.jpl.nasa.gov/property.owl#Permeability ’’/S

//owl:ObjectPropertyS

/owl:ObjectProperty rdf:ID ¼ ‘‘hasHydraulicGradient’’S/rdfs:domainS

/owl:ClassS/owl:unionOf rdf:parseType ¼ ‘‘Collection’’S

/owl:Class rdf:about ¼ ‘‘http://sweet.jpl.nasa.gov/earthrealm.owl#Aquifer ’’/S/rdf:Description rdf:about ¼ ‘‘

http://sweet.jpl.nasa.gov/property.owl#HydraulicGradient ’’/S/owl:Class rdf:about ¼ ‘‘http://sweet.jpl.nasa.gov/earthrealm.owl#Well ’’/S

//owl:unionOfS//owl:ClassS

//rdfs:domainS

ARTICLE IN PRESS

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–10331030

/rdfs:range rdf:resource ¼ ‘‘http://sweet.jpl.nasa.gov/property.owl#HydraulicGradient ’’/S//owl:ObjectPropertyS

/owl:Class rdf:ID ¼ ‘‘UnconfinedAquifer’’S/owl:equivalentClassS

/owl:Class rdf:ID ¼ ‘‘WaterTableAquifer’’/S//owl:equivalentClassS/rdfs:subClassOfS

/owl:Class rdf:ID ¼ ‘‘Aquifer’’/S//rdfs:subClassOfS

//owl:ClassS

/owl:Class rdf:ID ¼ ‘‘VadozeZone’’S/owl:equivalentClassS

/owl:Class rdf:ID ¼ ‘‘UnsaturatedZone’’/S//owl:equivalentClassS

//owl:ClassS

/!—An instance of the Aquifer class--S/Aquifer rdf:ID ¼ ‘‘UpperFloridanAquifer’’S

/hasHydraulicHeadrdf:datatype ¼ ‘‘http://www.w3.org/2001/XMLSchema#int ’’S32//hasHydraulicHeadS/hasLocation rdf:resource ¼ ‘‘http://sweet.jpl.nasa.gov/space.owl#Lat31deg10min9sec_Long84deg49min55sec ’’/S/hasLowerBoundaryHeightrdf:datatype ¼ ‘‘http://www.w3.org/2001/XMLSchema#int ’’S/200/hasLowerBoundaryHeightS/hasDischargerdf:datatype ¼ ‘‘http://www.w3.org/2001/XMLSchema#float ’’S300.25//hasDischargeS

//AquiferS

/!--Other classes omitted for brevity--S//rdf:RDFS

numerics:Numerical Entity

numerics:Geometrical Object

space:Spatial Object

? space:is Part Of Geosphere ? primary Substance substance:Ground_subs...Earth Realm space:Body

Planetary Realm Planetary Structure Body Of Ground

Land Fill

Fig. 4. Super-classes of new LandFill class.

ARTICLE IN PRESS

numerics:Numerical Entity

numerics:Geometrical Object

numerics:Boundary

space:Body Boundary space:Edge Earth Realm

Planetary RealmPlanetary StructureGround Water Object Boundary

Water TableRecharge BoundaryBarrier Boundary

Unconfined Aquifer Water Table Aquifer

Fig. 5. Sub-classes of GroundWaterObjectBoundary.

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–1033 1031

5.5. New object properties added to aquifer

The following new object properties were definedin the property.owl ontology for the Aquifer class:hasPorosity, hasHydraulicGradient, has-HydraulicHead, hasTransmissibility, andhasPermeability.

5.6. New object properties added to saturatedzone

A new property hasHydraulicConductiv-ity was defined for the SaturatedZone class.This property was added to the property.owlontology.

5.7. Class capillary fringe is added

The CapillaryFringe class is externally-connected-tothe SaturatedZone (Fig. 3).

5.8. Class well is added along with its subclass and properties

The Well class is added to the hierarchy, with theConfinedWell, MonitoringWell, Piezo-meter, PumpingWell, UnconfinedWell, andRechargeWell subclasses. ArtesianWell wasadded as a new subclass of ConfinedWell.

5.9. Following object properties were added to well

The following new object properties were defined forthe Well class, and added to the property.owlontology: hasPotentiometricSurface, has-HydraulicGradient, hasSeepageVelocity,hasHydraulicHead, and hasDrawdown.

5.10. Changes made to BodyOfGround

The class BodyOfGround is a subclass of Earth-Realm. In the original ontology, BodyOfGround had

ARTICLE IN PRESS

numerics:Numerical Entity

numerics:Geometrical Object numerics:has Dimensions ?

space:Spatial Object numerics:Geometrical Object_3D

? space:Is Part Of Geosphere ? primary Substancesubstance:Ground_Subs space:Body Earth Realm space:layer ? space:Is Part Of Hydrosphere ? primary Substance

substance:Water

Body Of Ground Planetary Structure Planetary Realm Hydrosphere Layer

? Primary Substance substance:Rock Medium ? primary Substance substance:Sediment Confining Layer

Leaky Confining LayerAquitardAquifugeAquiclude

Rock Body Sedimentary Structure

Fig. 6. Super-classes of RockBody, super-classes and sub-classes of ConfiningLayer.

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–10331032

a sub-class Rock_Body which is changed to Rock-Body in order to maintain consistency of class namingconvention followed throughout SWEET ontologies. An-other sub-class Landfill is added under BodyOf-Ground (Fig. 4).

5.11. Changes made to GroundWaterObjectBoundary

The sub-classes BarrierBoundary and Re-chargeBoundary are added to GroundWater-ObjectBoundary (Fig. 5). WaterTable class is

made a necessary class for WaterTableAquifer(Fig. 5).

5.12. Changes made to HydrosphereLayer

Subclasses ConfiningLayer and Medium areadded to the HydrosphereLayer class. TheAquifuge, Aquiclude, Aquitard, and Leaky-ConfiningLayer are made subclasses of the Con-finingLayer class. Aquiclude is made equivalentto Aquifuge, and Aquitard is made equivalent

ARTICLE IN PRESS

A. Tripathi, H.A. Babaie / Computers & Geosciences 34 (2008) 1022–1033 1033

to LeakyConfiningLayer. The Medium classsubsumes RockBody, which is a subclass of the Body-OfGround class (Fig. 6).

5.13. New object properties added to ConfiningLayer

The following new properties were defined for theConfiningLayer class in the property.owlontology: hasPorosity, hasHydraulicCon-ductivity, hasTransmissivity, and has-Permeability.

7. Summary and future directions

The top-level SWEET ontologies are evolving rapidly,and as domain experts continue to explore the capabilitiesof SWEET, they will require changes and enhancements inthe ontologies to make them useful in their own field. Wehave modified and extended SWEET ontologies to accom-modate a domain-specific hydrogeology ontology. Thechanges include the introduction of new concepts andmodification of the hierarchical structure of some of theexisting classes without altering the main architectureand reference structure of these ontologies.

We demonstrated, through a nine-step approach, howa high-level set of ontologies such as SWEET can beextended to include lower-level domain concepts.Although our set of concepts has a limited number ofelements, the step by step, structured procedure describedin this paper demonstrates how to extend a top-levelontology for domain purposes. Hydrogeology domainexperts can add more classes and properties to the modeldesigned by us to suit their requirements and to furtherexpand these ontologies. For their convenience most ofthe concepts have been added as classes in ontologieslike property.owl, units.owl, process.owl or phenomena.owl. These classes can be linkedto the earthrealm.owl by adding appropriateproperties wherever they may be required.

The SWEET ontologies are application and databaseindependent. Different applications such as web agentscan be developed based on these ontologies. A similarmethodology as explained in the example scenario herecan be adopted to make these ontologies useful in otherdomains.

Acknowledgments

We thank Simon Cox, Rob Raskin, and an anonymousreviewer for improving the earlier version of the manu-script through their critical review. We would like tothank the domain specialists who have contributed theirideas and suggestions during the development of theontology.

References

Babaie, H.A., Oldow, J.S., Babaei, A., Ave Lallemant, H.G., Watkinson, A.J.,2006. Designing a modular architecture for the structural geologyontology. In: Sinha, A.K. (Ed.), Geoinformatics: Data to Knowledge.Geological Society of America Special Paper 397, pp. 269–282, doi:10.1130/2006.2397(21).

Fikes, R., Hayes, P., Horrocks, I., 2003. OWL-DL—a language fordeductive query answering on the semantic web. KSL TechnicalReport 03-12, Knowledge Systems Laboratory, Stanford University,Stanford, CA, 10pp. /http://www-ksl.stanford.edu/KSL_Abstracts/KSL-03-14.htmlS.

Gomez-Perez, A., Rojas-Amya, D., 1999. Ontological reengineering forreuse. In: Proceedings of the 11th European Workshop on KnowledgeAcquisition, Modeling and Management Lecture Notes in ComputerScience, vol. 1621, pp. 139–156.

Gomez-Perez, A., Fernandez-Lopez, M., Corcho, O., 2004. OntologicalEngineering, with Examples From the Areas of Knowledge Manage-ment, 3-Commerce and the Semantic Web. Springer, London, p. 403.

Gruber, T.R., 1993. Toward principles for the design of ontologies used forknowledge sharing. International Journal of Human–ComputerStudies 43, 907–948.

Guarino, N., 1998. Some ontological principles for designing upper levellexical resources, In: Proceedings of the First International Con-ference on Language Resources and Evaluation, Granada, Spain, 8pp./http://www.loa-cnr.it/Papers/LREC98.pdfS.

Horridge, M., Knublauch, H., Rector, A., Stevens, R., Wroe, C., 2004. APractical Guide To Building Owl Ontologies Using the Potege-OWLPlugin and CO-ODE Tools, first ed. The University of Manchester,p. 118.

Kalyanpur, A., Hashemi, N., Golbeck, J., Parsia, B., 2004a. Lifecycle of acasual web ontology development process. In: Proceedings of theWWW2004 Workshop on Application Design, Development andImplementation Issues in the Semantic Web, Manhattan, NY, USA,p. 8 /http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS//Vol-105/WWW04_COD3.pdfS.

Kalyanpur, A., Sirin, E., Parsia, B., Hendler, J., 2004b. Hypermedia inspiredontology engineering environment: Swoop. In: Proceedings of theThird International Semantic Web Conference (ISWC-2004), Japan,Poster.

Knublauch, H., Musen, M.A., Rector, A.L., 2004. Editing description logicontologies with the protege owl plugin. In: Proceedings, A technicaldiscussion for logicians—International Workshop on DescriptionLogics—DL2004, Whistler, BC, Canada, 9pp. /http://protege.stanford.edu/plugins/owl/publications/DL2004-protege-owl.pdfS.

Neches, R., Fikes, R.E., Finin, T., Gruber, T.R., Senator, T., Swartout, W.R.,1991. Enabling technology for knowledge sharing. AI Magazine 12,36–56.

Piasecki, M., Beran, B., 2005. Developing a domain ontology for thehydrologic community. In: Proceedings of the American GeophysicalUnion, 86(52), Fall Meeting 2005, San Francisco, CA, Abstract#IN43A-0321

Ramachandran, R., Movva, S., 2005. An ontology service for LinkedEnvironments for Atmospheric Discovery (LEAD). In: Proceedings ofthe American Geophysical Union, 86(52), Fall Meeting 2005, SanFrancisco, CA, Abstract #IN43A-0330

Raskin, R., Pan, M.J., 2005. Knowledge representation in the semanticweb for Earth and environmental terminology (SWEET). In: Babaie,H.A., Ramachandran, R. (Eds.), Special Issue Applications of XML inGeosciences, Computers & Geosciences 31, 1119–1125.

Rector, R., 2003. Modularization of domain ontologies implemented indescription logics and related formalisms including owl. In:Proceedings of the Second International Conference on KnowledgeCapture, Sanibel Island, FL, USA, pp. 121–128.

Tripathi, A., 2005. Developing a modular hydrogeology ontologyextending the SWEET ontologies. MS Thesis, Georgia State University,Atlanta, Georgia, 361pp. /http://etd.gsu.edu/theses/available/etd-07212005-180752/S.

Zhong, J., McGuinness, D.L., Antonellini, M., Aydin, A., 2005. Ontology forstructural geology. In: Proceedings of the American GeophysicalUnion, 86(52), Fall Meeting 2005, San Francisco, CA, Abstract#IN43A-0323.