Ontology for Change Management by enl52124

VIEWS: 5 PAGES: 34

More Info
									                         Software Engineering Fall 2005




                          Ontology Management System
                    Software Requirements Specification
                                                        Version <1.4>
                                                               2/16/2006




CS 4310 Fall 2005                   e495572b-3f30-4e32-ac13-68302f8f43ec.doc
   Ontology Management System




Document Control
Approval
   The Guidance Team and the customer will approve this document.


Document Change Control
                                         Initial Release:      December 20, 2005

                                        Current Release:       February 16, 2006
                    Indicator of Last Page in Document:        
                                   Date of Last Review:        TBD

                                   Date of Next Review:        TBD
                          Target Date for Next Update:         TBD


Distribution List
   This following list of people will receive a copy of this document every time a new version of this document
   becomes available:
                                Guidance Team Members:
                                                  Dr. Ann Gates
                                                  Dr. Thamar Solorio
                                                  Elsa Tai

                                Customer(s):      Dr. Randy Keller
                                                  Leonardo Salayandía
                                Software Teams:
                                                  EngineSoft
                                                  Eisen Corp
                                                  Mexsys Corporation
                                                  Hades Inc
                                                  Solution Developers Inc.
                                                  CompuGlobalHyperMegaNet
                                                  Intelligent Software Systems
                                                  Gemini Software Development

Change Summary
   The following table details changes made between versions of this document

          Version               Date           Modifier                               Description
            1.0            12/20/2005             E. Tai             Section 1 and 2: Combining information from
                                                                     teams‟ SRS
            1.1              1/26/06      Ann Gates and Leo          Section 2: Cleaning use case diagram, Section
                                             Salayandía              3: Cleaning and adding requirements.

    Ontology Management System             CS 4310 Fall 2005                  Version: 1.4 2/16/2006       Page ii
Ontology Management System




       Version               Date         Modifier                          Description
         1.2             1/31/06      Ann Gates and Leo   Section 2: UC Diagram, Browse and Query
                                         Salayandía       merged into Retrieve.

         1.3                 2/7/06   Ann Gates and Leo   Section 2: Completed
                                         Salayandía       Appendices A and B edited, diagrams are still
                                                          pending
                                                          Section 3: Cleaning and adding requirements.
         1.4             2/15/06      Ann Gates and Leo   Section 3.1.1.2: Completed
                                         Salayandía
                                                          Subsections for actors, use cases, and
                                                          scenarios
                                                          Corrected grammar and text in Section 1.




 Ontology Management System           CS 4310 Fall 2005             Version: 1.4 2/16/2006         Page iii
Ontology Management System



                                                             TABLE OF CONTENTS
DOCUMENT CONTROL ...........................................................................................................................II
  APPROVAL.................................................................................................................................................. II
  DOCUMENT CHANGE CONTROL................................................................................................................ II
  DISTRIBUTION LIST ................................................................................................................................... II
  CHANGE SUMMARY ................................................................................................................................... II
1. INTRODUCTION ................................................................................................................................. 1
  1.1. PURPOSE AND INTENDED AUDIENCE .............................................................................................. 1
  1.2. SCOPE OF PRODUCT ........................................................................................................................ 1
  1.3. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS.......................................................................... 1
     1.3.1.   Definitions ............................................................................................................................... 1
     1.3.2.   Acronyms ................................................................................................................................. 3
     1.3.3.   Abbreviations ........................................................................................................................... 4
  1.4. OVERVIEW ...................................................................................................................................... 4
  1.5. REFERENCES ................................................................................................................................... 4
2. GENERAL DESCRIPTION ................................................................................................................. 6
  2.1. PRODUCT PERSPECTIVE ................................................................................................................. 6
  2.2. PRODUCT FEATURES....................................................................................................................... 6
     2.2.1.   Actors ....................................................................................................................................... 7
     2.2.2.   Use Cases ................................................................................................................................ 7
     2.2.3.   Scenarios ................................................................................................................................. 7
  2.3. USER CHARACTERISTICS.............................................................................................................. 10
  2.4. GENERAL CONSTRAINTS .............................................................................................................. 10
  2.5. ASSUMPTIONS AND DEPENDENCIES.............................................................................................. 10
3. SPECIFIC REQUIREMENTS ........................................................................................................... 11
  3.1. EXTERNAL INTERFACE REQUIREMENTS ..................................................................................... 11
     3.1.1.   User Interfaces ...................................................................................................................... 11
     3.1.2.   Hardware Interfaces .............................................................................................................. 15
     3.1.3.   Software Interfaces ................................................................................................................ 15
     3.1.4.   Communications Interfaces ................................................................................................... 15
  3.2. BEHAVIORAL REQUIREMENTS ..................................................................................................... 15
     3.2.1.   Same Class of User ................................................................................................................ 15
     3.2.2.   Related Real-world Objects ................................................................................................... 17
     3.2.3.   Related Features .................................................................................................................... 20
     3.2.4.   Stimulus ................................................................................................................................. 21
     3.2.5.   Functional.............................................................................................................................. 23
  3.3. NON-BEHAVIORAL REQUIREMENTS ............................................................................................. 23
     3.3.1.   Performance Requirements ................................................................................................... 24
     3.3.2.   Qualitative Requirements ...................................................................................................... 24
     3.3.3.   Maintainability ...................................................................................................................... 24
     3.3.4.   Portability .............................................................................................................................. 24
     3.3.5.   Security .................................................................................................................................. 24
     3.3.6.   Design and Implementation Constraints ............................................................................... 24
  3.4. OTHER REQUIREMENTS ............................................................................................................... 24
APPENDIX A. DIAGRAMS ...................................................................................................................... 25
  A.1 ONTOLOGY OMT DIAGRAM ............................................................................................................. 25
  A.2 DATA FLOW DIAGRAMS..................................................................................................................... 26
     i. Scenario #1: Retrieve .................................................................................................................... 26
     ii.    Scenario #2: Contribute ............................................................................................................ 27
     iii.   Scenario #3: Validate ................................................................................................................ 27
  A.3 STATE CHARTS ................................................................................................................................... 27
     iv.    Scenario #3: Contribute ............................................................................................................ 27
     v. Scenario #4: Validate .................................................................................................................... 27
 Ontology Management System                               CS 4310 Fall 2005                             Version: 1.4 2/16/2006                     Page iv
Ontology Management System



APPENDIX B. OWL FORMAT ................................................................................................................ 28
 B.1 OWL BASE ONTOLOGY ..................................................................................................................... 28
 B.2 CONCEPT NAME TAG ......................................................................................................................... 28
 B.3 ANNOTATION TAG FOR RESOURCE URI ........................................................................................... 29




 Ontology Management System                          CS 4310 Fall 2005                          Version: 1.4 2/16/2006                 Page v
Software Requirements Specification




1.       Introduction
1.1.     Purpose and Intended Audience
The purpose of the Software Requirements Specification (SRS) is to give the customer a clear and precise
description of the functionality of the proposed Ontology Management System (OMS). The SRS divides the
system requirements into two parts, behavioral and non-behavioral requirements. The behavioral requirements
describe the interaction between the system and its environment. Non-behavioral requirements relate to the
definition of the attributes of the product as it performs its functions. This includes the level of security,
efficiency, reliability, maintainability, portability, capacity, and the standards of compliance of the product. The
intended audience of the SRS is the Geology Department at The University of Texas at El Paso (UTEP) and the
development team. This document serves as an agreement between both parties regarding the product to be
developed.


1.2.     Scope of Product
GEOsciences Network (GEON) is an NSF-funded IT research program to conduct fundamental research
towards developing a cyber-infrastructure for the earth science community. The goal of GEON is to provide
advanced information technologies that support intelligent searching, integration, visualization, analysis, and
modeling of datasets. In addition, GEON provides high performance computing platforms required to analyze
and model such datasets; thus, facilitating the interdisciplinary collaboration of earth science community efforts.
The University of Texas at El Paso Departments of Computer Science and Geology Department are
collaborating to develop a service-oriented Ontology Management System (OMS) that will maintain ontologies
about the resources available on the GEON Network. The OMS will be integrated into the GEON cyber-
infrastructure as a service such that other applications or services can use the OMS functionality. GEON
resources are broadly classified as data, methods, and products, and are distributed geographically and
organizationally across the GEON Network partner sites [3]. The purpose of the ontologies is to maintain
knowledge about the GEON resources in order to facilitate their discovery and integration. The OMS will
manage the ontologies and provide client applications with the following services:
        Retrieve that will allow users to navigate through the available ontologies in search of concepts and
         corresponding resources as well as search for concepts and corresponding resources based on keyword
         queries.
        Contribute that will allow contributors to create new ontologies and/or propose modifications to
         existing ontologies.
        Validate that will allow domain-experts to control the contribution process of ontologies by providing
         functionality to accept and reject new contributions.


1.3.     Definitions, Acronyms, and Abbreviations

1.3.1.         Definitions
The definitions in this section are given in the context of the product being developed. This intention is to assist
the user in their understanding of the requirements for the system.

          TERM                                                     DEFINITION
Check-Box                       A graphical user interface object that can be clicked to turn an option on or off.

 Software Requirements Specification         CS 4310 Fall 2005                     Version: 1.4 2/16/2006   Page
                                                                                                            1
Software Requirements Specification




           TERM                                                     DEFINITION
Clear-text                      Computer Security term used to refer to text that is not encrypted.

Client Application              A software application external to our system that a user will utilize to interact with
                                the OMS.
Command Button                  A graphical user interface object that can be clicked on to confirm or cancel the
                                option.
Concept                         It is represented as a class, a concept facilitates the description of a domain of
                                knowledge [9].
Contribution                    It refers to either a newly created ontology, or a modified existing ontology.

Data-grid field                 A graphical user interface object that allows data to be presented in a spread-sheet
                                style, i.e., the user is able to navigate through cells by rows and columns.

Dictionary                      Dictionary that maintains relationship name, synonym, description of the
                                relationship, and inverse relationship name.

Domain Concept                  For a relation R(x,y), the domain concept is signified by x.

Implied relationship            A relationship that is inherited from a parent concept; also referred to as a child
                                relationship.
List Box                        A graphical user interface object that can be used to display data vertically in an
                                ordered format.

Metadata                        Information that describes another set of data. For ontology, the metadata is the
                                information stored in the Metadata Table.
MySQL                           Open source relational database management system [13].

Network-addressable             A resource that can be referenced through a URI.
resource

OMS repository                  It refers to the repository that the OMS currently accessed at the moment of user
                                request.

Ontology                        It refers to the explicit description of concepts in a domain closure and relations
                                among them [9].
Plug-in                         A component that provides a certain type of functionality within the context of a
                                host application. The component is configured into the system at deployment time,
                                which implies that the plug-in component can be installed and un-installed on/from
                                the host application.

Portal                          It is a web site that provides a starting point or gateway to other resources on the
                                Internet or an intranet.
Portlet                         A reusable web component that displays relevant information to Portal users.

Protégé                         An open source ontology editor and knowledge-base framework developed at
                                Stanford university.
Radio Button                    A series of related and mutually exclusive circular buttons of which only one can
                                be clicked to select a specific option.
Range                           Allowed classes for slots of type instance are the range of a slot [9].
 Software Requirements Specification          CS 4310 Fall 2005                     Version: 1.4 2/16/2006    Page
                                                                                                              2
Software Requirements Specification




          TERM                                                     DEFINITION
Range Concept                   For a relation R(x,y), the range concept is signified by y.

Relational database             Data that is stored in a relational model and manipulated by relational algebra
                                operators that are typically in the form of SQL.
Repository                      A storage place where an ontology and dictionary are stored.

Resources                       Classification of concepts into data, methods, and products.


Taxonomical hierarchy           Hierarchy of classes (concepts) represented as superclasses and subclasses [9].

Text Box                        A graphical user interface object that allows text to be inputted through a keyboard.

User                            The superset of the following types of user: general, validator, and contributor.

Web Service                     Also called application services, they are services (usually including some
                                combination of programming and data, but possibly including human resources as
                                well) that are made available from a business's Web server for Web users or other
                                Web-connected programs.


1.3.2.         Acronyms

                             Acronym                             Description
                        DAML                  DARPA Agent Markup Language

                        DBMS                  Database Management System

                        DFD                   Data Flow Diagram

                        GEON                  Geosciences Network
                        HTML                  Hyper Text Mark-Up Language
                        HTTP                  Hyper Text Transfer Protocol

                        OIL                   Ontology Interchange Language

                        OMS                   Ontology Management System
                        OMT                   Object Modeling Technique
                        OWL                   Ontology Web Language
                        OWL-S                 OWL-based Web service ontology

                        RDF                   Resource Description Framework
                        SNOBASE               Semantic Network Ontology Base, [14]

                        SOA                   Service-Oriented Architecture
                        SOAP                  Simple Object Access Protocol
                        SQL                   Structured Query Language
                        SRS                   Software Requirements Specification
 Software Requirements Specification         CS 4310 Fall 2005                     Version: 1.4 2/16/2006   Page
                                                                                                            3
Software Requirements Specification




                             Acronym                           Description
                        TBD                To Be Determined
                        URI                Universal Resource Identifier

                        UTEP               The University of Texas at El Paso
                        XML                Extensible Markup Language
                        WSDL               Web Services Description Language


1.3.3.         Abbreviations

                                   ABBREVIATION                   MEANING

                             cf.                        Confer (or Compare)

                             e.g.                       For example

                             i.e.                       Such as

                             info.                      Information


1.4.     Overview
The SRS is divided into three major sections: Introduction (Section 1), General Description (Section 2), and
Specific Requirements (Section 3).
Section 1 includes five subsections. Section 1.1 provides the purpose and intended audience of the document.
Section 1.2 describes the scope of the product. Section 1.3 provides the definitions, acronyms and abbreviations.
Section 1.4 provides the organization of the document. Section 1.5 lists the references used in this document.
Section 2 includes five subsections. Section 2.1 contains a description of the product, its overall structure, and
its functionality. Section 2.2 summarizes the main features of the OMS. Section 2.3 identifies each type of
users of the system. This is accomplished through a summary of actors, use-cases and scenarios. Section 2.4
states existing general constraints. Section 2.5 gives the assumptions and dependencies of the OMS.
Section 3 includes four major subsections. Section 3.1 contains requirements that are related to the external
interface. Section 3.2 contains the functional requirements that are organized in the following categories: same
class of user, related real-world objects, stimulus, related features, and limits and default settings. Section 3.3
contains non-behavioral requirements consisting performance and qualitative requirements, as well as design
and implementation constraints. Section 3.4 outlines database, operations and site adaptation requirements.


1.5.     References
    [1] CompuGlobalHyperMegaNet, “Software Requirements Specification,” University of Texas at El Paso,
        December 2005
    [2] Eisen Corp, “Software Requirements Specification,” University of Texas at El Paso, December 2005
    [3] EngineSoft, “Ontology Management System, Interview Report,” version 2.1, Fall 2005.
    [4] EngineSoft, “Software Requirements Specification,” University of Texas at El Paso, December 2005
    [5] Gemini Software Development, “Software Requirements Specification,” University of Texas at El
        Paso, December 2005

 Software Requirements Specification       CS 4310 Fall 2005                    Version: 1.4 2/16/2006   Page
                                                                                                         4
Software Requirements Specification



    [6] Guidance Team, “Requirements Definition Document”, El Paso, University of Texas at El Paso,
        August 26, 2005.
    [7] Hades, “Software Requirements Specification,” University of Texas at El Paso, December 2005
    [8] Mexsys Corporation, “Software Requirements Specification,” University of Texas at El Paso,
        December 2005
    [9] N. Noy and D. McGuiness, “Ontology Development 101: A Guide to Creating Your First Ontology,”
        http://protege.stanford.edu/publications/ontology_development/ontology101.pdf.
    [10] S. Bechhofer, F. Harmelen, J. Hendler, I. Horrocks, D. McGuinness, P. Patel-Schneider, L. Stein,
         “OWL Web Ontology Language Reference”, January 16, 2006. http://www.w3.org/TR/owl-ref/.
    [11] Solution Developers, “Software Requirements Specification,” University of Texas at El Paso,
         December 2005
    [12] “WS-I Organization‟s Website,” January 16, 2006, http://www.ws-i.org.
    [13] “MySQL Website,” January 18, 2006, http://www.mysql.com.
    [14] “SNOBASE Website,” January 19, 2006, http://www.alphaworks.ibm.com/tech/snobase




 Software Requirements Specification   CS 4310 Fall 2005                  Version: 1.4 2/16/2006   Page
                                                                                                   5
Software Requirements Specification




2.       General Description
2.1.     Product Perspective
The system described in this document is called the Ontology Management System (OMS), and it is designed to
maintain ontologies about geoscience resources. The system will provide functionality to allow geoscientists to
manage concepts and related geoscience resources, and to allow other users and applications to browse and
query the ontologies to enhance resource discovery and integration.
IBM has developed a system called Semantic Network Ontology Base (SNOBASE) [14] that shares similarities
to the OMS. Like OMS, SNOBASE is a framework for creating, modifying, querying, and storing ontologies.
In contrast, the OMS provides additional functionality that supports concurrent ontology creation and
modification by including an ontology browsing mechanism and a validation process for edits. The OMS also
allows network-addressable resources to be linked to ontology concepts in order to facilitate resource discovery
and integration in cyber-infrastructure efforts like GEON. Finally, client interaction with the OMS does not
depend on platform-specific API‟s or connectors, but rather utilizes standardized service-oriented technologies
that allow client applications to use its functionality across different platforms.


2.2.     Product Features
Figure 1 presents a use case diagram that provides the representation of the OMS from a user‟s perspective. The
figure sticks represent the external actors that interact with the OMS, and the ovals represent the use cases
supported by the OMS; these components are described next.




                                                    Retrieve
                       General User




                                                   Contribute



                        Contributor                                       Editing and Data Store Tools
                                                                                      Visualization




                                                    Validate




                         Validator




                                       Figure 1.       Use Case diagram




 Software Requirements Specification      CS 4310 Fall 2005                    Version: 1.4 2/16/2006    Page
                                                                                                         6
Software Requirements Specification



2.2.1.         Actors

The OMS classifies actors into the following groups:
        General User: This actor represents a client application that performs “non-administrative tasks”. The
         General User actor provides the ability to its human user to search for concepts or resources of interest
         by browsing the ontology structure or by performing queries based on keywords and search types.
        Contributor: This actor represents a client application that provides its human user with the ability to
         propose new ontologies or modifications to existing ontologies. Through the Contributor actor, the
         human user has the ability to propose modifications to ontology structure by adding new concepts,
         relations, and setting links between concepts and network-addressable resources.
        Validator: This actor represents a client application that provides its human user with the ability to
         accept or reject proposed contributions. Through the Validator actor, the human user (typically a
         domain expert) has the ability to review new contributions, provide feedback to the contributor, and
         accept or reject the contributions proposed.
        Data Store: This actor represents the permanent storage of the OMS. The Data Store includes a
         DBMS and a file system. The DBMS maintains metadata, dictionary, and user access levels. The file
         system hosts ontology files represented in OWL.


2.2.2.         Use Cases

The OMS supports the following use cases:
        Retrieve: The OMS provides General User actors with the ability to request ontologies by browsing or
         by performing queries. The General User actors are responsible for providing a buffer space for the
         retrieved ontology and provide an adequate representation for its human user (e.g., graphical).
        Contribute: The OMS provides Contributor actors with the ability to enter new ontologies to be
         verified by an expert and propose modifications to existing ontologies. With respect to existing
         ontologies, this use case assumes that a Retrieve use case is used in order to identify the ontology
         portion of interest. New and modified ontologies are verified for appropriate OWL format, are flagged
         as pending validation, and are queued for validation. The OMS acknowledges the Contributor actor
         once the new or changed ontology has been processed.
        Validate: The OMS provides Validator actors with the ability to validate proposed and modified
         ontologies. The OMS provides a list of ontologies that are flagged as pending validation; the Validator
         actor submits a selection from the list; the OMS provides the original ontology, along with the
         proposed changes; the Validator actor presents both versions to the human user in appropriate format
         (e.g., a visual representation of the original ontology with the proposed changes highlighted); the
         Validator actor submits the results of the validation process; the ontology is flagged accordingly and
         the contributing author is notified of the outcome.


2.2.3.         Scenarios
Each user interacts with the OMS through some specialized client application that supports the operations that
are of interest to the class of user. The following scenarios describe the interaction between users, their client
applications, and the OMS.
Scenario for Retrieve Use Case
Description: The user retrieves an ontology from the OMS.
Actors: General User, Data Store
Precondition: A connection between the OMS and the client application has been established.
Trigger Condition: The user initializes the retrieve functionality of the client application.
    1. The client application supports the Browse retrieval option and the user selects it.
    2. The client application sends an initial request for Browse to the OMS.
 Software Requirements Specification      CS 4310 Fall 2005                   Version: 1.4 2/16/2006    Page
                                                                                                        7
Software Requirements Specification



    3.  The OMS receives the initial request for Browse and responds by sending the list of available
        ontologies (i.e., ontology unique ID, ontology name and ontology description).
    4. The client application displays the ontology list in appropriate format for user presentation (e.g.,
        HTML).
    5. The user selects a particular ontology from the list.
    6. The client application requests the selected ontology from the OMS by sending the ontology‟s unique
        ID.
    7. The OMS retrieves the selected ontology from the data store in OWL format and sends it to the client
        application.
    8. The client application transforms the OWL ontology into an appropriate format for presentation to the
        user (e.g., graphical).
    9. The user selects a particular concept from the ontology that is linked to a resource‟s URI.
    10. The user selects the resource‟s URI link and is redirected to it.
    11. End of use case.

Alt 1: Step1: The client application supports the Query retrieval option and the user selects it.
Step1.1: The user selects a search type (i.e., Data, Method, Product, or All).
Step1.2: The user enters concept names to query on and initiates the query action.
Step1.3: The client application sends the query request to the OMS.
Step1.4: The OMS receives the request for Query and responds by sending the list of ontologies that matched
         the search type and concept names specified.
Step1.5: The use case continues at Step 4.

Alt 2: Step9: The user does not find knowledge or resources of interest within this ontology. The user wants to
select another ontology.
Step9.1: The use case continues at step 1.


Scenario for Contribute Use Case
Description: The user submits a contribution (i.e., a new ontology, a change to an existing ontology, a new
relationship, a change to an existing relationship, a new synonym, or a change to an existing synonym) to the
OMS.
Actors: Contributor, Validator, Data Store
Precondition 1: The client application has access to the new contributions to be submitted or supports the
functionality for the user to input the contributions to be submitted.
Precondition 2: The client application is able to send contributions to the OMS in OWL format (i.e., the client
application is responsible for converting user input to OWL format if necessary).
Precondition 3: A connection between the OMS and the client application has been established.
Trigger Condition: The user initializes the functionality to submit a contribution in the client application.
     1. The client application displays a change request form to the user.
     2. The user fills the change request form, specifying that the contribution corresponds to a new ontology.
     3. The user references the contribution on the client application and initiates the submission.
     4. The client application sends the change request form and the contribution in OWL format to the OMS.
     5. The OMS receives the change request and inspects the new contribution for errors.
     6. The OMS acknowledges the successful process of the change request to the client application, locks
         the contribution to prevent any further changes, and stores the new contribution on the Data Store.
     7. The OMS notifies a validator user through email of the submission of a new contribution.
     8. End of use case.

Alt 1: Step1: The user fills the change request form, specifying another type of contribution.
Step1.1: The use case continues at Step 3.

Alt 2: Step6: The OMS finds that the contribution is not in valid OWL format.
Step6.1: The OMS sends a notification message to the client application about the incompatible format.
Step6.2: End of use case.
 Software Requirements Specification      CS 4310 Fall 2005                    Version: 1.4 2/16/2006   Page
                                                                                                        8
Software Requirements Specification




Alt 3: Step6: The OMS finds that the contribution received references relationship names that are not registered
in the Relationship Table.
Step6.1: The OMS sends a notification message to the client application containing a list of relationships that
         are not present in the Relationship Table and suggests that the user should either update the
         Relationships Table or the Synonyms Table accordingly before attempting the submission again.
Step6.2: End of use case.


Scenario for Validate Use Case
Description: The user analyzes the submitted ontology contribution and decides whether to accept, reject, or
request additional information from the contributor.
Actors: Contributor, Validator, Data Store
Precondition: A connection between the OMS and the client application has been established.
Trigger Condition: The user initiates the functionality to validate contributions in the client application.
    1. The client application sends an initial request to the OMS for the list of change requests.
    2. The OMS retrieves the list of change requests from the data store and sends it to the client application.
    3. The client application displays the list of change requests in appropriate format for the user.
    4. The user selects an item to validate from the list and initializes the validation process.
    5. The client application sends the user selection to the OMS.
    6. The selected change request corresponds to a new contribution (i.e., a new ontology, a new
         relationship or a new synonym entry); the OMS retrieves the change request and the corresponding
         contribution from the data store and sends it to the client application.
    7. The client application displays the change request form and the contribution in appropriate format for
         the user.
    8. The user inspects the contribution against the Change Request description and decides that the
         contribution is valid.
    9. The user updates the change request form to reflect the validation outcome and initiates the
         submission.
    10. The client application sends the updated submission form to the OMS.
    11. The OMS receives the submission form, notifies the contributor about the outcome, updates the
         metadata information of the contribution to indicate a validated entry, and unlocks the contribution.
    12. End of use case.

Alt1: Step6: The selected change request corresponds to the modification of an existing item (i.e., an ontology
change, a relationship change, or a synonym change).
Step6.1: The OMS retrieves the change request, the corresponding contribution, and the existing data that is
         being targeted by the change request.
Step6.2: The client application displays the change request form, the contribution, and the targeted data in
         appropriate format for the user.
Step6.2: The use case continues at Step 8.

Alt2: Step8: The user inspects the contribution against the Change Request description and decides that the
contribution is not valid.
Step8.1: The user updates the change request form to reflect the validation outcome, providing feedback to the
contributor, and initiates the submission.
Step8.2: The client application sends the updated submission form to the OMS.
Step8.3: The OMS receives the submission form, notifies the contributor about the outcome and sends him/her
the feedback from the validator, and discards the contribution from the data store.
Step8.3: End of use case.

Alt3: Step8: The user inspects the contribution against the Change Request description and decides that more
information is needed in order to make a decision.
Step8.1: The user updates the change request form to reflect the validation outcome, providing feedback to the
contributor, and initiates the submission.
 Software Requirements Specification     CS 4310 Fall 2005                   Version: 1.4 2/16/2006   Page
                                                                                                      9
Software Requirements Specification



Step8.2: The client application sends the updated submission form to the OMS.
Step8.3: The OMS receives the submission form, notifies the contributor about the outcome and sends him/her
the feedback from the validator.
Step8.3: End of use case.


2.3.       User Characteristics
There are three types of users that will interact with OMS via client applications. A description of the users
follows:
      1.   The General User class represents users interested in browsing or querying ontologies. The typical user
           of this class has basic computer usage skills and is knowledgeable in the Geosciences (not necessarily
           an expert).
      2.   The Contributor class represents users interested in contributing to the knowledge represented in the
           ontology repository. The typical user of this class has basic computer usage skills and is
           knowledgeable in the Geosciences, most probably having a niche of expertise.
      3.   The Validator class represents users that perform administrator tasks on the system and that serve as
           gatekeepers of the contribution process of the system. The typical user in this class is a computer
           power user (i.e., has computer usage skills beyond the basic level without necessarily being an expert
           user). Furthermore, this class of user is an expert geoscientist or has commanding knowledge to
           evaluate contributions from others.


2.4.       General Constraints
The general constraints on the development of the system are as follows:
          The system will be completed by the end of May 2006.
          The Ontology Management System will be implemented in C#.
          The DBMS will be implemented in MySQL 5.0


2.5.       Assumptions and Dependencies
The assumptions are as follows:
          The Access Table has been created for a relational database.
          For every entry in the Access Table, there is a corresponding entry (based on UserID) in a table that
           maintains information about the contributor, e.g., name, contact information, and associated
           organization.
          The maintenance of the Access Table is outside the scope of the project.
          All users have at least basic computer skills.
          The username and password for users will be encrypted.
          Management of synonyms for concept names will be added in a future version of the system.
          The Change Request mechanism will have extended functionality in a future version of the system.
          The development team will use this SRS to implement the system.




 Software Requirements Specification         CS 4310 Fall 2005                 Version: 1.4 2/16/2006   Page
                                                                                                        10
Software Requirements Specification




3.       Specific Requirements
3.1.     External Interface Requirements
This section contains the specification of requirements for interfaces among different components and their
external capabilities, including all its users, both human and other systems. Inter-dependencies or constraints
associated with interfaces are identified.


3.1.1. User Interfaces
This section describes a generic user (client) interface that utilizes the OMS. Given that the OMS is based on an
SOA, there can be numerous client interface implementations. Each implementation would only provide the
specific interactions that it requires to accomplish the goals of its context.


3.1.1.1.       General Interface

[SRSreq 01] The client interface shall allow the user to provide a user name and a password to the OMS either
            directly or through some centralized, single-sign on mechanism.

[SRSreq 02] The client interface shall not show the user password in clear-text format at any time.

[SRSreq 03] The client interface shall provide a notification mechanism that displays the following message
            when he or she has an incorrect user name or password: “Invalid user name or password.”

[SRSreq 04] The client interface shall provide a notification mechanism that displays the user‟s access privilege
            level when the user is signed on.

[SRSreq 05] The client interface shall be implemented using standard GUI components:

                        text-box fields to allow entering, editing, or displaying textual data;

                        command buttons to allow the user to confirm the initialization of interaction with the
                         OMS;

                        check-box fields to allow the user to set or unset a given Boolean option on the OMS;

                        radio-button fields to allow the user to choose a Boolean option among a group of options
                         on the OMS; and

                        list-box or combo-box fields to allow the user to choose a textual input from a list of
                         options on the OMS.

[SRSreq 06] The client interface shall use data-grid fields when entering, editing, or displaying table-like data.

[SRSreq 07] The client interface shall use XML-editor components when entering, editing, or displaying XML
            data.

[SRSreq 08] The client interface shall provide HTML search-result components to display retrieval results from
            the OMS (as described in Section 3.2), and to allow the user to follow links contained in the
            displayed results.




 Software Requirements Specification         CS 4310 Fall 2005                     Version: 1.4 2/16/2006   Page
                                                                                                            11
Software Requirements Specification



3.1.1.2.       Visualization Interface

[SRSreq 09] The client interface shall provide Ontology Visualization components to transform ontologies
            provided by the OMS in OWL format and display them in graphical representations, or to allow
            the user to input or modify ontologies in graphical representations, and transform them into OWL
            format for input into the OMS.

[SRSreq 10] The client interface shall provide two ways for begin visualizing an ontology: query or navigation.

              A query shall return all concepts in which the keyword given in the query appears; when the user
               clicks on a concept, the concept shall be displayed.

              The user shall be able to navigate an ontology by selecting a one of the following concepts, e.g.,
               data, product, or method.

[SRSreq 11] Each of the concepts associated with the categories of “Data,” “Method,” and “Product” shall have
           its own unique color: purple, blue, and green, respectively.

[SRSreq 12] The system shall display a Note shape next to each concept that has relationships associated with it
           as shown in Fig. 2.


                                             List of relationships for one concept

                            Relationships
                              1.   Bouguer Anomaly             derived from           Bouguer Correction          about
                              2.   Bouguer Anomaly             derived from             Drift Correction          about
                              3.   Bouguer Anomaly             derived from             Tidal Correction          about
                              4.   Bouguer Anomaly             derived from           Free Air Correction         about
                              5.   Bouguer Anomaly             derived from           Latitude Correction         about
                              6.   Bouguer Anomaly                 used for              Anomaly Map              about
                                   Child relationships ….
                                   6a. Bouguer Anomaly          used for          Bouguer Anomaly Map           about

                              7.   Bouguer Anomaly                  part of       Complete Bouguer Anomaly about
                              8.   Bouguer Anomaly                input into             Interpretation           about
                                   Child relationships ….
                                   8a. Bouguer Anomaly          input into        Forward Modeling              about
                                   8b.   Bouguer Anomaly        input into        Inverse Modeling              about




                                                                  Bouguer               about
                                                                  Anomaly

                                                            EndPt Ref: http://…




                                              Figure 2.               Relationships list.




 Software Requirements Specification                CS 4310 Fall 2005                                      Version: 1.4 2/16/2006   Page
                                                                                                                                    12
Software Requirements Specification



[SRSreq 13] When the user clicks on the Note shape of a concept, the system shall display all tuples,
           <DomainConceptName, relationshipName, RangeConceptName> that represent all direct and
           implied relationships, i.e., child relationships, in which the concept associated with the Note shape
           is the domain concept, as shown in Fig. 2.

[SRSreq 14] If the Range Concept is a “parent” concept, then the tuple in the list of relationship tuples shall be
           distinguished with a tag or marking to inform the user that the children of the Range Concept are
           also related to the Domain Concept, as depicted in Fig. 2.

[SRSreq 15] When the user selects a relationship, the visualization component shall show the relationship to the
           concept, as shown in Fig. 3.


               Corrected       about                                        Gravity       about
                                                   derivedFrom
               Gravity Data                                                 Correction




                                   Figure 3.        Example of a general relationship

[SRSreq 16] A user shall be able to navigate an ontology using indicator arrows, as shown in Fig. 4, that allow
           the user to expand the concept to view the parent(s) (up arrow), view the left sibling (left arrow),
           view the right sibling (right arrow), or view two children (down arrow).



                                                         Concept    about




                                    Figure 4.        Indicator arrows for a concept

[SRSreq 17] The following method shall be used to view a concept in an ontology, where the display is
           centered on the primary node n (see Fig. 5).
               Node 1.         n

               Node 2.         parent of n

               Node 3.         left sibling of n

               Node 4.         right sibling of n

               Node 5.         child 1 of n

               Node 6.         child 2 of n

[SRSreq 18] If a primary node has more than one parent, then the display shall show only one parent and an
           indicator arrow shall remain with the primary node, as depicted in Fig. 5.



 Software Requirements Specification           CS 4310 Fall 2005              Version: 1.4 2/16/2006   Page
                                                                                                       13
Software Requirements Specification



[SRSreq 19] If a primary node has more than two children, then the display shall show only two children and a
           left (right) indicator arrow shall appear on the first (second) child node that is displayed if the
           display can be expanded to show another child node.


                                                                                                                             ConceptP        about
                                                                                                                                                                 Up Indicator Arrow Remains




         ConceptN         about



                                                                                ConceptLS     about                        ConceptN        about                                  ConceptRS       about


                                                                        EndPt Ref: http://…                                                                                 EndPt Ref: http://…




                                                                                                        ConceptC1       about                     ConceptC2        about


                                                                                                  EndPt Ref: http://…                      EndPt Ref: http://…




                              Figure 5.                          Multiple Parents and selecting up indicator arrow

[SRSreq 20] When the user selects the “about” text in a concept, the visualization component shall display a
           textbox with the metadata associated with the concept as depicted in Fig. 6.

[SRSreq 21] When the user selects the “about” text associated with a relationship, the visualization component
           shall display the metadata, i.e., the description, associated with the relationship as depicted in Fig.
           6.

[SRSreq 22] When the user selects the URI of the concept, the resource pointed to by the URI shall be
           redirected to that resource.

                                                                                                                                            Metadata for a relationship
            Relationships
             1.     Bouguer Anomaly                     uses         Bouguer Correction          about
                                                                                                                          Bouguer Anomaly values are gridded and then used to create a
             2.     Bouguer Anomaly                     uses           Drift Correction          about
                                                                                                                          Bouguer Anomaly Maps and displayed in the form of a surface.
             3.     Bouguer Anomaly                     uses           Tidal Correction          about
             4.     Bouguer Anomaly                     uses         Free Air Correction         about
             5.     Bouguer Anomaly                     uses         Latitude Correction         about
             6.     Bouguer Anomaly                   used for          Anomaly Map              about
                    Child relationships ….
                                                                                                                                                Metadata for a concept
                    6a. Bouguer Anomaly             used for     Bouguer Anomaly Map           about

             7.     Bouguer Anomaly                   used for Complete Bouguer Anomaly about                              1. The value obtained after latitude correction, elevation correction
             8.     Bouguer Anomaly                   used for          Interpretation           about                    (including both free-air and Bouguer corrections), and (usually) terrain
                    Child relationships ….
                                                                                                                          correction have been applied to gravity data. The Bouguer gravity field
                    8a. Bouguer Anomaly                          Forward Modeling              about
                                                                                                                          is not the same as the field which would have been observed at the
                                                    used for
                          Bouguer Anomaly           used for     Inverse Modeling
                                                                                                                          datum elevation, because the shape of anomalies due to remaining
                    8b.                                                                        about
                                                                                                                          density irregularities still are appropriate to the elevation of
                                                                                                                          measurement rather than to those of the datum elevation. Also called
                                                                                                                          Bouguer gravity. 2. Sometimes, a departure from smoothness in the
                                                                                                                          contours on a map showing Bouguer values (i.e., a residual in more...




                                     Free Air            about                                         Bouguer          about                                           Complete    about
                                     Anomaly                                                           Anomaly                                                          Bouguer Anomaly

                              EndPt Ref: http://…                                               EndPt Ref: http://…                                              EndPt Ref: http://…




                      Figure 6.                            Metadata associated with a concept and a relationship

 Software Requirements Specification                                         CS 4310 Fall 2005                                                      Version: 1.4 2/16/2006                            Page
                                                                                                                                                                                                      14
Software Requirements Specification



3.1.2. Hardware Interfaces
There are no requirements for hardware interfaces.


3.1.3. Software Interfaces
This section describes the interfaces and formats of interaction between the different components of the OMS.

[SRSreq 23] The OMS shall use the OWL format to handle all ontology data interactions between the service
            and client applications, and between the service and the data store.

[SRSreq 24] The OMS shall use XML to handle all metadata interactions between the service and client
            applications.

[SRSreq 25] The data store component of the system shall provide two interfaces, a DBMS implemented as
            MySQL 5.0, and a file system implemented as NTFS.


3.1.4. Communications Interfaces
This section contains requirements that pertain to the communication interfaces between the OMS and the client
applications, and between the OMS and the data store.

[SRSreq 26] The OMS shall use the HTTP/SOAP messaging protocol between the service and the client
            applications, as prescribed by the Basic Profile 1.1 and the Attachments Profile 1.0 proposed by
            the Web Services Interoperability Organization [12].

[SRSreq 27] The interaction between the OMS and the DBMS component of the data store shall be carried out
            through the MySQL .Net Connector 1.0.7.

[SRSreq 28] The interaction between the OMS and the file system component of the data store shall be carried
            out by a dedicated, secured connection.


3.2.     Behavioral Requirements
This section contains behavioral requirements related to Same Class of User, Related Real-World Objects,
Related Features, Stimulus, and Functional.


3.2.1.         Same Class of User
This section presents the requirements associated with a particular class of user. For complete requirements
associated with the functionality given in Table 1, refer to Section 3.2.3.

[SRSreq 29] The OMS shall provide the following access levels, with user privileges summarized in Table 1:
                        General User
                        Contributor
                        Validator




 Software Requirements Specification     CS 4310 Fall 2005                   Version: 1.4 2/16/2006   Page
                                                                                                      15
Software Requirements Specification




                                          Table 1: Privileges by Access Level

                         PRIVILEGES                    GENERAL USER        CONTRIBUTOR              VALIDATOR

        Retrieve validated ontologies                             √                √                        √

        Navigate ontologies                                       √                √                        √

        Post an ontology                                                           √                        √

        Edit an ontology                                                           √                        √

        Retrieve ontologies pending validation                                                              √

        Validate an ontology                                                                                √


[SRSreq 30] Users shall not be subject to authentication by the OMS to access privileges at the “General User”
            access level.

[SRSreq 31] The OMS shall provide authentication mechanisms to allow users to log in to secure “Contributor”
            or “Validator” access levels.

[SRSreq 32] All operations of the OMS shall be subject to authorization mechanisms that verify that an
            operation is supported for the user initiating the operation, as per Table 1.

[SRSreq 33] The authentication and authorization mechanisms of the OMS shall be based on the Access Table
            Schema illustrated in Table 2.

[SRSreq 34] The authorization Access Table (cf. Table 2) shall be hosted on the DBMS component of the data
            store.
                                            Table 2: Access Table Schema

      Attribute               Type                      Constraint                      Comments/Description
                                          Must be “Contributor” or “Validator.”     Access level used to authorize
     accessLevel       VARCHAR(10)
                                          Default: “Contributor”                    user operations.
                                          Password must be at least 8 characters
                                          long, and must contain at least one       Password used to authenticate
       password        VARCHAR(16)        digit. The password cannot be the         a user‟s ID when logging into
                                          same as the userID, and is case           the system.
                                          sensitive.

                                          UserID must be 8-16 characters and/or
        userID                                                                      Identifier for a person logging
                       VARCHAR(16)        numbers, must be unique within the
         (PK)                                                                       into system.
                                          system, and is case sensitive.
.




    Software Requirements Specification       CS 4310 Fall 2005                    Version: 1.4 2/16/2006       Page
                                                                                                                16
Software Requirements Specification



3.2.2.         Related Real-world Objects
Real-world objects are entities with either physical or conceptual counterparts in the real world. The object
modeling diagram is given in the appendix. The syntax and semantics of OWL can be found in the OWL Web
Ontology Language Reference document [10].


3.2.2.1.       Ontology

[SRSreq 35] An ontology shall be maintained in OWL format and stored as XML files on the file system
            component of the data store.

[SRSreq 36] All ontology concepts in the OMS shall be descendants of one of the following root concepts:
            Data, Method, or Product.

[SRSreq 37] GEON resources represented in the ontology shall be attached as URI references to leaf concepts
            on the ontology through annotation OWL tags (cf. Appendix B).

[SRSreq 38] Ontologies shall support the addition of concept metadata through associated text in the OWL
            declaration of the ontology.

[SRSreq 39] The valid domain associated with an ontology shall be one of the following:
                    Gravity
                    Seismology
                    Satellite Imagery
                    Magnetic
                    Physical Properties


3.2.2.2.       Ontology Metadata

[SRSreq 40] The OMS shall maintain the metadata provided in Table 3 for all registered ontologies, and this
            metadata shall be stored in the DBMS component of the data store.

                                       Table 3: Ontology Metadata Table Schema
     Attribute                 Type                     Constraint                  Comments/Description

   OntoID (PK)           VARCHAR(9)                                            Unique identifier for the ontology

 Ontology Name          VARCHAR(20)                                            Ontology Name

                                             Valid entries: gravity,           The geoscience knowledge area
      Domain            VARCHAR(20)          seismology, magnetic, satellite   from which the ontology
                                             imagery, physical properties      knowledge is captured.

                                                                               Identification of validator (FK to
   Validator ID         VARCHAR(16)
                                                                               UserID in Access Table)

                                                                               True if ontology has been
     Validated             BOOLEAN           Default: False
                                                                               validated; false otherwise

                                                                               Description of ontology and
    Description         VARCHAR(100)
                                                                               community that contributes to it.


 Software Requirements Specification          CS 4310 Fall 2005                 Version: 1.4 2/16/2006      Page
                                                                                                            17
Software Requirements Specification




                                                                                Ref. to the OWL file on the file
      OntoRef           VARCHAR(30)                                             system component of the data
                                                                                store.




3.2.2.3.       Relationship Table

[SRSreq 41] The OMS shall maintain a dictionary as described in Table 4 for all relationships of all registered
            ontologies, and this dictionary shall be stored in the DBMS component of the data store.

                                         Table 4: Relationships Table Schema
           Attribute                    Type                       Constraint           Comments/Description
                                                                                      Identifies ontology to which
                                                                                      the dictionary is associated
            OntoID                 VARCHAR(9)
                                                                                      (FK-OntoID in Ontology
                                                                                      Metadata Table

                                                       Naming Convention: lower
                                                       case letter for the first
                                                       character of the name, no      Primary Key; name of the
     RelationshipName              VARCHAR(20)
                                                       spaces between words, and      relationship, e.g., isInputTo
                                                       the subsequent words begin
                                                       with a capital letter

                                                                                      Name of the inverse
 InverseRelationshipName           VARCHAR(20)
                                                                                      relationship, if any

                                                                                      Type of the relationship‟s
                                                                                      domain, where
                                                                                      D: Data
                                                                                      P: Product
                                                       Valid entries include: D, P,   M: Method
        DomainType                     CHAR(3)
                                                       M, DP, DM, PM, DPM
                                                                                      DP: Data or Product
                                                                                      DM: Data or Method
                                                                                      PM: Product or Method
                                                                                      DPM: Data, Product, or
                                                                                      Method
                                                       Valid entries include: D, P,   Type of the relationship‟s
         RangeType                     CHAR(3)
                                                       M, DP, DM, PM, DPM             range; see above

                                                                                      Description of the
         Description               VARCHAR(75)
                                                                                      relationship




 Software Requirements Specification           CS 4310 Fall 2005                 Version: 1.4 2/16/2006      Page
                                                                                                             18
Software Requirements Specification




[SRSreq 42] The OMS shall maintain a table of records as described in Table 5 for all synonyms associated
            with a relationship name.

                                         Table 5: Relationship Synonyms Table

       Attribute                  Type                       Constraint                 Comments/Description

  RelationshipName1         VARCHAR(20)                                              Foreign key, Relationship
                                                                                     table)
                                                                                     Relationship name of the
  RelationshipName2         VARCHAR(20)
                                                                                     synonym (Primary key)



[SRSreq 43] A relationship shall be displayed as a tuple, <DomainConceptName, RelationshipName,
            RangeConceptName>.

[SRSreq 44] A subclass of a concept shall inherit the relationships and properties of the parent concept.


3.2.2.4.       Change Requests

[SRSreq 45] The Change Request Table shall be used to manage changes to an ontology.

[SRSreq 46] The Change Request Table shall contain an entry for each type of change, i.e., ontology, concept,
           relation, and metadata.

[SRSreq 47] The Change Request Table shall contain the following fields:

               OntoID- identification number of the ontology, if not a new ontology

               Change- one of the following:

                 o       (“Ontology,” <”Add” >, <newOntologyName>, <OWLrepresentation>, <dictionary
                                Table>, <OntologyMetadata>)

                 o        (”Concept,” <”Add” | “Modify”>, <conceptName>, <text>, <metadata>)

                 o       (”Relation,” <“Add” | “Modify”>, <relationName>,                   <InverseRelationName>,
                                 <DomainType>, <RangeType>, <Description>)

                 o        (”Concept,” ”Delete”, <conceptName>)

                 o       (”Relation,” ”Delete”, <relationName>)

                 o       (”Relation,”      ”Delete”,              <relationName>,          <DomainConceptName>,
                                 <RangeConceptName>)

               Description: the description of the added ontology or changes.

               Status- Pending/Accept/Reject

[SRSreq 48] Entries by the contributor to the Change Request Table shall automatically be entered as
           “Pending” for Status.




 Software Requirements Specification          CS 4310 Fall 2005                  Version: 1.4 2/16/2006   Page
                                                                                                          19
Software Requirements Specification



3.2.3.         Related Features
This section describes requirements of related features and is divided into Browse, Query, Contribute, and
Validate.

[SRSreq 49] All service requests from client applications to the OMS shall include appropriate user credentials
            to carry out the authentication and authorization mechanisms as described in the Same Class of
            User requirements of Section 3.2.1.


3.2.3.1.       Retrieval

[SRSreq 50] The OMS shall be able to process a request to view a list of all available ontologies in the data
            store.

[SRSreq 51] The OMS shall be able to process a request to retrieve an ontology based on the ontology ID
            (OntoID).

[SRSreq 52] The OMS shall be able to process a request that retrieves a list of ontologies based on the concept
            name.


3.2.3.2.       Contribute

[SRSreq 53] Submissions of a new ontology shall include the following information: ontology name; domain;
           description; the OWL representation of the ontology; and the metadata associated with the
           ontology.

[SRSreq 54] An ontology that has changes submitted by a contributor shall be locked for further edits.

[SRSreq 55] If an ontology is locked for edits, then the dictionary associated with the ontology shall be locked
            for edits.

[SRSreq 56] If an ontology is unlocked, then the dictionary associated with the ontology shall be unlocked.

[SRSreq 57] The OMS shall assign a unique OntoID number to a new ontology that is submitted as follows:
            NNYYMMDDL, where NN are the first two characters of the corresponding domain name;
            YYMMDD is the year, month, and day of the submission; and L signifies a letter that is used to
            distinguish ontologies that may be submitted on the same date in the same domain, where the first
            submission is “A” and subsequent submissions follow the order of the alphabet.

[SRSreq 58] The OMS shall store the OWL file of a new ontology into the file system component of the data
            store by assigning it a file name that reflects the OntoID.


3.2.3.3.       Validate

[SRSreq 59] The OMS shall support a request that returns a list of ontology IDs and ontology names that are
            pending validation, i.e., that have their Validated field set to false in the Ontology Metadata Table
            (cf. Table 3), and an indication of whether it is a new ontology or a changed ontology.

[SRSreq 60] The OMS shall support a request that includes an ontology ID of a changed ontology that is
            pending validation and that returns the list of changes as described in Section 3.2.2.4.

[SRSreq 61] The OMS shall support a request from a Validator user to change the Status field of the Change
           Request Table to Accept or Reject.

 Software Requirements Specification      CS 4310 Fall 2005                   Version: 1.4 2/16/2006     Page
                                                                                                         20
Software Requirements Specification



[SRSreq 62] The OMS shall support a request from a Validator user to replace an existing ontology with the
            ontology that contains the approved changes.


3.2.4.         Stimulus
The following section describes the stimuli of the system depending on different operations offered by the
OMS.


3.2.4.1.       Retrieval

[SRSreq 63] When the OMS receives a retrieval request based on browsing, the OMS shall return OntoID,
            OntoName, and Description (cf. Table 3) for each ontology in the data store.

[SRSreq 64] When the OMS receives a request for retrieving a list of ontologies based on the substring
           provided for a concept name, the OMS shall examine each OWL class tag (cf. Appendix B.2) in
           each ontology in the data store and, for any ontology for which the substring matches a string given
           in the “concept name” field, the OMS shall include that ontology ID in the list of returned
           ontologies.

[SRSreq 65] When the OMS receives a request from a client application to retrieve an ontology, the OMS shall
           check the status of the ontology, create a copy of the requested ontology, and send an OWL
           representation of the ontology along with its corresponding dictionary to the client application that
           made the request.

[SRSreq 66] When the OMS receives a request from a client application to retrieve an ontology and the
           ontology is locked, the OMS shall display the following warning message: “The selected ontology
           is locked for editing and pending validation; it does not reflect pending updates.”

[SRSreq 67] When the client application requests an ontology, the OMS shall check the ontology‟s status and
           acknowledge the client application accordingly.


3.2.4.2.        Contribute

[SRSreq 68] When a new ontology is submitted for validation, the ontology shall be added as a file to the data
            store.

[SRSreq 69] When an ontology is submitted for validation, an entry in the Ontology Metadata table (cf. Table
            3) shall be created that stores the information from the Change Request into the table, that sets the
            “Validated” field to false and that enters a reference to the file stored in the data store.

[SRSreq 70] When a new or changed ontology is submitted for validation, the OMS shall check that all
            relationships in the ontology are entered in the Relationships Table (cf. Table 4) before accepting
            the submission.

[SRSreq 71] When a new ontology has been accepted for submission, OMS shall return the generated OntoID
            to the client application.

[SRSreq 72] If one or more relationships in a submitted ontology are missing from the Relationship Table, the
            OMS shall return the following error message: “The following relationships <<list of relationship
            names>> could not be found in the relationship table. Please add an entry, add a synonym, or
            check the spelling before resubmitting your ontology.”




 Software Requirements Specification      CS 4310 Fall 2005                   Version: 1.4 2/16/2006   Page
                                                                                                       21
Software Requirements Specification



[SRSreq 73] When a change request is made to delete or modify a concept and the concept name does not exist
            in the ontology, the OMS shall return the following error message: “Change request on invalid
            concept name.”

[SRSreq 74] When a change request is made to delete or modify a relation and the relation name does not exist
            in the ontology, the OMS shall return the following error message: “Change request on invalid
            relation name.”

[SRSreq 75] When a change request is made to delete a concept, the OMS shall return the following warning
            message: “Your change will impact the following relations: <<list of relationship names>>.”

[SRSreq 76] When a change request is made to delete a relation, the OMS shall return the following warning
            message: “Your change will impact the following concepts: <<list of concept names>>.”

[SRSreq 77] When a contribution has been successfully submitted for validation, the OMS shall send the
            following acknowledgement message via e-mail to the registered validator: “The following
            ontology has been submitted for validation: <ontoID>.”

[SRSreq 78] When the OMS responds to a submission with a warning message, the OMS shall wait for
            confirmation from the user before accepting the contribution.

[SRSreq 79] When the OMS accepts a contribution, the OMS shall return the following message: “Thank you
            for your submission. You will be notified when your submission has been validated.”

[SRSreq 80] When the OMS responds to a submission with an error message, the OMS shall cancel the
           submission request.


3.2.4.3.        Validate

[SRSreq 81] When a client application requests the validation service, the OMS shall return the ontoID,
           ontology name, and ontology description for all new and modified ontologies that have been
           submitted for validation.

[SRSreq 82] When the OMS receives a request for validation of a modified ontology, the OMS shall return the
           ontology, its corresponding dictionary, and send a list of the modified ontologies along with its
           corresponding dictionary to the client application.

[SRSreq 83] When a validator view-request is made to view a submission, the OMS shall return the original
           ontology and the changed ontology.

[SRSreq 84] Any part of the ontology that is not changed shall remain unchanged when the ontology is updated.

[SRSreq 85] When the OMS receives a request from the client application using the validation service to extract
           an ontology with status „pending for validation‟, the OMS shall extract and return the requested
           ontology, its corresponding dictionary, and a list of each modification to the ontology along with its
           justification.

[SRSreq 86] When the OMS receives a request from the validator application to accept a contribution, the OMS
           shall change the status of an ontology to „unlocked‟.

[SRSreq 87] After the ontology status has been changed to „unlocked‟, the OMS shall send an
           acknowledgement to the contributor stating that the „contribution was accepted‟.

[SRSreq 88] When the validator rejects a contribution to an existing ontology, the client application sends a
           request to the OMS to reject the ontology, and the “reject” request includes the ontoID and text to
           provide feedback to the contributor.

 Software Requirements Specification      CS 4310 Fall 2005                   Version: 1.4 2/16/2006   Page
                                                                                                       22
Software Requirements Specification



[SRSreq 89] When the OMS receives a request to “reject” ontology <ontoID>, the OMS shall unlock the
           ontology associated with <ontoId>, the OMS shall send a message to the contributor stating that
           “The contribution to ontology <ontoID> was rejected”, and the OMS shall send the feedback
           provided by the validator.

[SRSreq 90] When the OMS receives a “Delete”request from the validator client application to delete ontology
           <ontoID>, the OMS shall remove the OWL file associated with <ontoID> and all the entries
           associated with <ontoID> from the following tables: Metadata, Relationship, and Synonym.

[SRSreq 91] When the OMS receives a “Delete”request from the validator client application to delete a concept,
           the OMS shall remove the concept and all relations associated with the concept.

[SRSreq 92] When the OMS receives a “Delete”request from the validator client application to delete a relation
           that does not include <DomainConceptName> and <RangeConceptName>, the OMS shall remove
           all relations.

[SRSreq 93] When the OMS receives a “Delete”request from the validator client application to delete a relation
           that includes <DomainConceptName> and <RangeConceptName>, the OMS shall only remove the
           relation between <DomainConceptName> and <RangeConceptName> and nothing else.

[SRSreq 94] When the OMS receives an “Add” request from the validator client application to add a new
           concept, then the <text> and <metadata> parameters shall not be empty.

[SRSreq 95] When the OMS receives an “Modify” request from the validator client application to modify
           concept denoted by <conceptName>, the OMS shall modify on those parameters, i.e., <text> and
           <metadata>, that are not empty.

[SRSreq 96] When the OMS receives an “Add” request from the validator client application to add a new
           relation, then the <relationName>, <InverseRelationName>, <DomainType>, <RangeType>, and
           <Description> parameters shall not be empty.

[SRSreq 97] When the OMS receives an “Modify” request from the validator client application to modify the
           existing relation denoted by <relationName>, the OMS shall modify only those parameters, i.e.,
           <InverseRelationName>, <DomainType>, <RangeType>, and <Description>, that are not empty.


3.2.4.4.       Authentication and Authorization

[SRSreq 98] When the OMS cannot authenticate the user, the OMS shall return an error message stating
           „invalid user‟.

[SRSreq 99] When the OMS cannot authorize an operation for a given user, the OMS shall return an error
           message starting „invalid operation for current access level privileges.


3.2.5.         Functional
Functional requirements are specified in other sections.


3.3.     Non-behavioral Requirements
This section includes requirements relating to performance, qualitative requirements, maintainability,
portability, security, and design implementation and contraints.




 Software Requirements Specification      CS 4310 Fall 2005                 Version: 1.4 2/16/2006   Page
                                                                                                     23
Software Requirements Specification



3.3.1.         Performance Requirements

There are no performance requirements specified at this time.


3.3.2.         Qualitative Requirements
There are no qualitative requirements specified at this time.


3.3.3.         Maintainability

There are no maintainability requirements specified at this time.

3.3.4.         Portability

[SRSreq 100] There shall be no platform dependencies on the client applications of the OMS other than the
           platform requirements specified in the Communication Interfaces described in Section 3.1.4 and the
           Security requirements listed in Section 3.3.3.


3.3.5.         Security

[SRSreq 101] All user-credential data exchange between the OMS and client applications shall be encrypted
           and carried out over a secure connection.

[SRSreq 102] All data exchange between the OMS and client applications that result in the modification of the
           data store shall be carried out over a secure connection.


3.3.6.         Design and Implementation Constraints

There are no design and implementation requirements specified at this time.


3.4.     Other Requirements
This section includes requirements relating to database structures and operations, any special operations
required by the user, and any installation or software portability issues.
There are no other requirements specified at this time.




 Software Requirements Specification      CS 4310 Fall 2005                   Version: 1.4 2/16/2006   Page
                                                                                                       24
Software Requirements Specification




Appendix A. Diagrams
A.1 Ontology OMT Diagram
The ontology OMT diagram is given as reference to illustrate the different components of an ontology.




                                       Figure A-1: Ontology OMT Diagram




 Software Requirements Specification       CS 4310 Fall 2005                Version: 1.4 2/16/2006   Page
                                                                                                     25
Software Requirements Specification




A.2 Data Flow Diagrams

                                  i. Scenario #1: Retrieve



                                                                                                                                    Requested
                                                                                                                                     Ontology


      Ontology Query
                                                           1. Retrieve Ontology
                                                                                                                    Ontology List

            Browse Selection


                                                        Requested
                                                         Ontology
                                                                                  Ontology List

                                                                    Requested
                                                                                                                                OMS
                                                                     Ontology                                                 Repository




      Geoscientist
                               Resource Selection                                                                                    Display
                                                          2. Retrieve Resource




                                                                                                  Resource




                                                    Figure A- 2: Level 1 Retrieve DFD




 Software Requirements Specification                   CS 4310 Fall 2005                                 Version: 1.4 2/16/2006                 Page
                                                                                                                                                26
Software Requirements Specification



                                 ii. Scenario #2: Contribute


                                 iii. Scenario #3: Validate


A.3 State Charts

                                 iv. Scenario #3: Contribute
                     [!username.valid ||
                   !password.valid] / Error
                          Message
                                                                       Locked


                          Idle
               Entry: connect to OMS and
                  display login prompt                                Check complete [!Valid Result]
                                                                         /Send Error Message
               Do: Process username and                                                                             Edit Ontology
                       password

                                                                                                                                         submitForPosting(Ontology)
                                                                                                                                                [Post == true]
              [name.valid & password.valid]
                                                                                            Check complete
                                                                                        [! Post & Valid Result]     lookUpRelation(Relation)
                                                                                        / returnValid (relation)         [Post == false]
                                      selectOntology(Ontology)
                                          [!Ontology.locked]
                                            / lock(Ontology)                                                       Dictionary Check


                    Select Ontology
                                                                                                       Check complete [Post & Valid Result]
                                                                                                             / email (Domain Expert)

                                                                                                                    Post Ontology
     selectOntology(Ontology)
         [Ontology.locked]




                                                           Figure A- 3: Editing StateChart


                                 v. Scenario #4: Validate




 Software Requirements Specification                             CS 4310 Fall 2005                                        Version: 1.4 2/16/2006                Page
                                                                                                                                                                27
Software Requirements Specification




Appendix B. OWL format

B.1 OWL Base Ontology
The following OWL code is given as a reference for the heading name spaces that should be referenced in all
ontologies hosted in the OMS. The ontology describes the Data, Method and Product concepts that should be
imported into all ontologies.


        <?xml version="1.0"?>
        <rdf:RDF
                  xmlns="http://utepgeon01.utep.edu/oms/2006/01/oms.owl#"
                  xmlns:oms="http://utepgeon01.utep.edu/oms/2006/01/oms.owl#"
                  xml:base="http://utepgeon01.utep.edu/oms/2006/01/oms.owl#"
                  xmlns:owl="http://www.w3.org/2002/07/owl#"
                  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
                  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
                  xmlns:daml="http://www.daml.org/2001/03/daml+oil#">


         <owl:Ontology rdf:about="">
           <rdfs:comment>Base OWL ontology for the Ontology Management System</rdfs:comment>
           <rdfs:label>Data-Method-Product Ontology</rdfs:label>
         </owl:Ontology>


         <owl:Class rdf:ID="Product"/>
         <owl:Class rdf:ID="Data"/>
         <owl:Class rdf:ID="Method"/>
        </rdf:RDF>




B.2 Concept Name Tag
The following tag illustrates an example declaration of a concept within an OWL ontology.


                                       <owl:Class rdf:ID="<<concept name>>"/>




 Software Requirements Specification         CS 4310 Fall 2005                  Version: 1.4 2/16/2006   Page
                                                                                                         28
Software Requirements Specification




B.3 Annotation Tag for Resource URI
The following tag illustrates an example declaration of a resource‟s URI that is matched to a concept name.


                             <owl:AnnotationProperty rdf:about="<<resource URI>>" />









 Software Requirements Specification       CS 4310 Fall 2005                 Version: 1.4 2/16/2006   Page
                                                                                                      29

								
To top