Software Engineering Fall 2005

walkingceilInternet and Web Development

Oct 22, 2013 (4 years and 17 days ago)

147 views



Software Engineering Fall 2005















CS 4310 Fall 2005

walkingceil_2be8de00
-
4709
-
4579
-
ac1d
-
790d68582317.doc


Ontology Management System

Software Requirements Specification


Version <1
.4
>

2
/
16
/200
6

Ontology Management System

Ontology Management System



CS 4310 Fall 2005

Version:
1
.4

2
/
16
/200
6

Page
ii





Document Control

Approval

The Guidance Team and the customer will approve this document.

Document Change Control

Initial Release:

December 2
0, 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 e
very 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

Solu
tion 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

Secti
on 1 and 2: Combin
ing information from
teams’ SRS

N.N



⼰S

䅮n 䝡瑥s and i敯
卡污yand
í
a

卥捴楯n O㨠䍬敡ning us攠捡s攠d楡iramI
卥p瑩tn
P㨠䍬敡ning 慮d 慤d楮g r敱u楲em敮瑳.

Ontology Management System

Ontology Management System



CS 4310 Fall 2005

Version:
1
.4

2
/
16
/200
6

Page
iii






Version


Date

Modifier

Description

1.2

1/31/06

Ann Gates and Leo
Salayandía

Section 2: UC Diagram, Browse and Query

merged into Retrieve.

1.3

2/7/06

Ann Gates and Leo
Salayandía

Section 2: Completed

Appendices A and B edited, diagrams are still
pending

Section 3: Cleaning and adding requirements.

1.4

2/15/06

Ann Gates and Leo
Salayandía

Section 3.1.1.2: Completed

Su
bsections for actors, use cases, and
scenarios

Corrected grammar and text in Section 1.


Ontology Management System

Ontology Management System



CS 4310 Fall 2005

Version:
1
.4

2
/
16
/200
6

Page
iv





T
ABLE OF
C
ONTENTS

DOCUMENT CONTROL

................................
................................
................................
...........................

II

A
PPROVAL

................................
................................
................................
................................
..................

II

D
OCUMENT
C
HANGE
C
ONTROL

................................
................................
................................
................

II

D
ISTRIBUTION
L
IST

................................
................................
................................
................................
...

II

C
HANGE
S
UMMA
RY

................................
................................
................................
................................
...

II

1.

INTRODUCTION

................................
................................
................................
................................
.

1

1.1.

P
URPOSE AND
I
NTENDED
A
UDIENCE

................................
................................
..............................

1

1.2
.

S
COPE OF
P
RODUCT

................................
................................
................................
........................

1

1.3.

D
EFINITIONS
,

A
CRONYMS
,

AND
A
BBREVIATIONS

................................
................................
..........

1

1.3.1.

Definitions

................................
................................
................................
...............................

1

1.3.2.

Acronyms

................................
................................
................................
................................
.

3

1.3.3.

Abbreviations

................................
................................
................................
...........................

4

1.4.

O
VERVIEW

................................
................................
................................
................................
......

4

1.5.

R
EFERENCES

................................
................................
................................
................................
...

4

2.

GENERAL DESCRIPTION

................................
................................
................................
.................

6

2.1.

P
RODUCT
P
ERSPECTIVE

................................
................................
................................
.................

6

2.2.

P
RODUCT
F
EATURES

................................
................................
................................
.......................

6

2.2.1.

Actors

................................
................................
................................
................................
.......

7

2.2.2.

Use Cases

................................
................................
................................
................................

7

2.2.3.

Scenarios

................................
................................
................................
................................
.

7

2.3.

U
SER
C
HARACTERISTICS

................................
................................
................................
..............

10

2.4.

G
ENERAL
C
ONSTRAINTS

................................
................................
................................
..............

10

2.5.

A
SSUMPTIONS AND
D
EPENDENCIES
................................
................................
..............................

10

3.

SPECIFIC REQUIREMENT
S

................................
................................
................................
...........

11

3.1.

E
XTERNAL
I
NTERFACE
R
EQUIRE
MENTS

................................
................................
.....................

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.

B
EHAVIORAL
R
EQUIREMENTS

................................
................................
................................
.....

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.

N
ON
-
BEHAVIORAL
R
EQU
IREMENTS

................................
................................
.............................

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.

O
THER
R
EQUIREMENTS

................................
................................
................................
...............

24

APPENDIX A. DIAGRAMS

................................
................................
................................
......................

25

A.1

O
NTOLOGY
OMT

D
IAGRAM

................................
................................
................................
.............

25

A.2

D
ATA
F
LOW
D
IAGRAMS

................................
................................
................................
.....................

26

i.

Scenario #1: Re
trieve

................................
................................
................................
....................

26

ii.

Scenario #2: Contribute

................................
................................
................................
............

27

iii.

Scenario #3: Validate

................................
................................
................................
................

27

A.3

S
TATE
C
HARTS

................................
................................
................................
................................
...

27

iv.

Scenario #3: Contribute

................................
................................
................................
............

27

v.

Scenario #4: Validate

................................
................................
................................
....................

27

Ontology Management System

Ontology Management System



CS 4310 Fall 2005

Version:
1
.4

2
/
16
/200
6

Page
v





APPENDIX B. OWL FORM
AT

................................
................................
................................
................

28

B.1

OWL

B
ASE
O
NTOLOGY

................................
................................
................................
.....................

28

B.2

C
ONCEPT
N
AME
T
AG

................................
................................
................................
.........................

28

B.3

A
NNOTATION
T
AG FOR
R
ESOURCE
URI

................................
................................
...........................

29

Software Requirements

Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

1


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
des
cription 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 tha
t 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 collabora
tion of
e
arth 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

res
ources

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
, a
nd are
distributed geographically and
organizat
ionally 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
integr
ation.

The OMS will
manage the ontologies

and provide client applications with the following services:



Retrieve

that

will allow

user
s

to navigate through the available ontologies in search of concepts

and
corresponding resources

as well as
search for conce
pts
and corresponding resources
based on keyword
queries.



Contribute

that

will allow
contributors

to create new ontologies and/or propose modific
ations to
existing ontologies.



Validat
e

that

will allow
domain
-
experts
to control the contribution process of o
ntologies 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

2


TERM

DEFINITION

Clear
-
t
ext

Computer Security term used to refer to t
ext that is not encrypted.

Clie
nt 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 clas
s, 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 obj
ect 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 t
he
information stored in the Metadata Table.

MySQL

Open source relational database management system

[13]
.

N
etwork
-
addressable
resource

A resource that can be referenced through a URI.

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 compone
nt that displays relevant information to Portal users.

Protég
é

A
n
open source
o
ntology edit
or 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

3


TERM

DEFINITION

Range Concept

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

R
elational

databas
e

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, met
hods, 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 k
eyboard.

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 reso
urces 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 N
etwork

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 D
escription 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

4


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. Se
ction 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
inte
rface. 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 requi
rements 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 Specifica
tion,” 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

5


[6]

Guidance Team, “Requirements Definition Document”, El Paso, Univers
ity 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. Mc
Guiness, “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,
“O
WL 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 Organizatio
n’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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

6


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

geosci
ence

resources. The system will provide
functionality

to
allow geoscientists to
manage con
cepts and related
geoscience
resources
, and to allow other users and applications to browse and
query the ontologies to enhance resource discovery and integration
.


I
BM 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 functio
nality 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 re
source 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

Fig
ure

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 wit
h the OMS
,
and the ovals represent the use cases
supported by the OMS
; these components are described next
.


Figure 1.

Use Case diagram


Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

7


2.2.1.

Actors

The
OMS classifies actors into
the following

groups:



General User:
This actor represents a cl
ient application t
hat 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 searc
h 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, t
he
human user has the ability to
propose
modif
ications 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 repres
ents 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.
Th
e 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 r
equest 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 repr
esentation 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
.

W
ith

respect to existing
ontologies, t
hi
s use case assumes that a
Retrieve

use case is
used

in order
to identify the ontology
po
rtion of interest
.
New
and modified ontologies

are
verified for appropriate OWL format, are flagged

as pending validation
,

and are queued for validation. The OMS acknow
ledges 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
provide
s

a list of ontologies
that are flagged as
pending v
alid
ation
;

the V
alidator

actor submits a
select
ion from
the list
;

t
he OMS provide
s

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 C
ase

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
o
f

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 Brows
e

to the OMS.

Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

8


3.

The OMS receives the initial request for Brows
e

and responds by sending t
he 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 transform
s 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.

Step
9
.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

Pr
econdition

1
:

The client application
has access to the ne
w contributions to be submitted

or
supports the

functionality
f
or the user to input
the contributions to be submitted
.

Precondition 2:

The client application is able to

send contributions to the

OM
S 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 f
unctionality to submit a contribution in the client application.

1.

The client application displays a
c
hange
r
equest 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.

T
he 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 sub
mission 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

9



Alt

3
:

Step
6
:
The OMS finds that the contribution received references relationship names th
at are not registered
i
n the Relationship Table
.

Step
6
.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 t
he Synonyms Table accordingly before attempting the submission again.

Step
6
.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 additiona
l 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 t
he 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 c
hange 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 valida
tion 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 indica
te a validated entry
, and unlocks the contribution
.

12.

End of use case.


Alt1:

Step
6
:
The selected change request corresponds to the modification of an existing item (i.e., an ontology
change, a relationship change, or a synonym change)
.

Step
6
.1:
The OMS retr
ieves 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 fo
r the user.


Step6
.2: The use case continues
at

Step 8
.


Alt2:

Step
8
: 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
.

Step
8
.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 outcom
e and sends him/her
the feedback from the validator, and discards the contribution from the data store.


Step
8.3: End

of use case.


Alt3:

Step8: The user inspects the contribution against the Change Request description and decides that more
information i
s 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

10


Step8.2: The client application sends the updated submission for
m 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 Geosci
ences (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 Geosci
ences, 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
pow
er 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 implemen
ted
in MySQL 5.0

2.5.

Assumptions and Dependencies

The a
ssumptions 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 i
nform
ation, 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

11


3.

Specific Requirements

3.1.

External Interface Requ
irements

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
speci
fic interactions that it requires to accomplish the goals of its context.

3.1.1.1.

General Interface

[SRSreq 01]

Th
e client interface s
hall 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]

Th
e client interface shall not show the user password
in clear
-
text format at a
ny 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

enterin
g, editing, or displaying

textual
data
;



command buttons to allow the user to confirm the initialization of interac
tion 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 field
s

when

entering, editing, or
disp
lay
ing 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 compon
ents to display
retrieval
results from
the OMS

(as described
in Sect
ion

3.2
)
, an
d to allow the user to follow links
contained

in the
displayed results.

Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

12


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 gra
phical 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 navi
gation.



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
.


Figure 2.

Relationships list.





Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

13


[SRSreq 13]

When the user clicks on the Note shape of a concept, the system shall display all tuples,
<DomainConceptName, relationshipName, RangeConceptName> th
at 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 relations
hip 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 th
e relationship to the
concept, as shown in Fig. 3.



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 t
he parent(s) (up arrow), view the left sibling (left arrow),
view the right sibling (right arrow), or view two children (down arrow).


Figure 4.

Indicator arrows for a concept

[SRSreq 17]

The following method shall be used to view a concept in an

on
tology, 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
a
n
indicat
or arrow
shall
remain

with the primary node, as depicted in Fig.
5
.


Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

14


[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 displa
yed if the
display can be expanded to show another child node.


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
.


Figure 6.

Metadata associated with a concept and a relationship

Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

15


3.1.2.

Hardware Interfaces

There are no requirem
ents 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 al
l
ontology data
interaction
s

between the service
an
d 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 implemente
d 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 s
hall
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, secu
red 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 associate
d with a parti
cular class of user.
For complete requirements
associated with
the
functionality

given in Table
1, r
efer to Section
3.2.3
.

[SRSreq 29]

The
OMS shall
provide the following access levels, with user privileges summarize
d in
Tabl
e 1
:




General User



Contributor



Validator










Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

16






Table 1: Privileges by
Access Level

P
RIVILEGES

G
ENERAL
U
SER

C
ONTRIBUTOR

V
ALIDATOR

Retrieve validated ontologies







乡v楧at攠o湴n汯g楥i







Post an ontology






b摩琠a渠n湴n汯gy






剥o物敶攠o湴n汯g楥i

灥湤楮i va汩lat楯n





噡汩lat攠a渠n湴n汯gy






[SRSreq 30]

U
ser
s

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 user
s

to log in to secure

“Contribu
tor”
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

access
Level

VARCHAR
(10)

Must be “Contributor” or “Validator.”

Default: “Contributor”

Access level
used to authorize
user operations
.

passw
or
d

VARCHAR
(16)

Pas
sword must be at least 8 characters
long, and must contain at least one
digit. The password cannot be the
same as the userID, and is case
sensitive.

Password used
to
authenticate

a user’s ID when logging into
the system.

userID
(PK)

VARCHAR
(16)

UserID
must be 8
-
16 characters and/or
numbers, must be unique within the
system, and is case sensitive.

Identifier for a person logging
into system.

.

Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

17


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 s
emantics of OWL can be found in the OWL Web
Ontology Language Reference document

[10]
.

3.2.2.1.

Onto
log
y

[SRSreq 35]

An
ontolog
y

shall be maintained

in OWL forma
t and store
d

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 a
s 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

on
tology 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 M
etadata

Table Schema

Attribute

Type

Constraint

Comments/Description

OntoID (PK)

VARCHAR(
9
)


Unique identifier for the ontology

Ontology Name

VARCHAR(20)


Ontology Name

Domain

VARCHAR(20)

Valid entries: gr
avity,
seismology, magnetic, satellite
ima
gery, physical properties

The geoscience knowledge area
from which the ontology
knowledge is captured.

Validator ID

VARCHAR(16)


Identification of validator (FK to
UserID in Access Table)

Validated

BOOLEAN

Defau
lt: False

True if ontology has been
validated; false otherwise

Description

VARCHAR(100)


Description of ontology and
community that contributes to it.

Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

18


OntoRef

VARCHAR(30)


Ref. to the OWL file on the file
system component of the data
store.


3.2.2.3.

Re
lationsh
ip 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

Constr
aint

Comments/Description

OntoID

VARCHAR
(
9
)


Identifies ontology to which
the dictionary is associated
(FK
-
OntoID in Ontology
Metadata Table

Relationship
Name

VARCHAR
(20)

Naming Convention: lower
case letter for the first
character of the name, no
spaces
between words, and
the subsequent words begin
with a capital letter

Primary Key; n
ame of the
relationship, e.g., isInputTo

In
verse
Relationship
Name

VARCHAR(20)


Name of the in
verse
relationship, if any

DomainType

CHAR(3)

Valid entries include: D, P,
M, DP
, DM, PM, DPM

Type of the relationship’s
domain, where

D: Data

P: Product

M: Method

DP: Data or Product

DM: Data or Method

PM: Product or Method

DPM: Data, Product, or
Method

RangeType

CHAR(3)

Valid entries include: D, P,
M, DP, DM, PM, DPM

Type of the re
lationship’s
range; see above

Description

VARCHAR(75)


Description of the
relationship



Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

19


[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

Attribu
te

Type

Constraint

Comments/Description

RelationshipName1

VARCHAR(20)



Foreign key, Relationship
table)

RelationshipName2

VARCHAR(20)



Relationship name of the
synonym (Primary key)


[SRSreq 43]

A relationship shall be displayed as a tuple, <DomainConceptName, Re
lationshipName,
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 th
e ontology, if not a new ontology



Change
-

one of the following
:

o

(“Ontology,”

<”Add” >,
<newOntologyN
ame
>
,
<
OWLrepresentation
>
,
<dictionary
Table>,
<
OntologyM
etadata>
)

o


(”Concept,”
<”Add”


| “Modify”>
, <conceptN
ame
>
,
<
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 des
cription of the added ontology or changes.



Status
-

Pending/Ac
cept/Reject

[SRSreq 48]

Entries by the contributor to the Change Request Table shall automatically be entered as

Pending


for Status.

Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

20


3.2.3.

Related Features

This section describes requirements of r
e
lated
f
eatures

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 li
st 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 n
ame
; d
omain
;

d
escription
;

the OWL representation of the
ontology
; and the metadata associated with the
ontology
.

[SRSreq 54]

A
n

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 associa
ted 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:
NN
YYMMDDL, where
NN

are

the first two characters of the corresponding domain

name
;
YYMMDD is the year, month, and day of th
e 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 s
tore 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 suppo
rt a request
that returns a list of ontology IDs and ontology n
ames 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 supp
ort a request that includes an o
nto
logy ID of a changed

ontology that

is
pending va
lidation 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

21


[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 rece
ives a
retrieval
request

based on
browsing
, the OMS shall return OntoID,
OntoName, and Des
cription (cf. Table 3) for each o
ntology in the data store.

[SRSreq 64]

When the OMS receives a request for
r
etrieving 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 li
st 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 wit
h 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 Re
quest into the table, that sets

the
“Validated” field to false and that
enters

a reference to the

f
ile

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]

I
f one or more

relationship
s

in
a submitted

ontol
ogy

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 spelli
ng before resubmitting your ontology.”

Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

22


[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 s
hall return the following
error
message: “Change
request on invalid
concept name.


[SRSreq 74]

When a chang
e 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 s
hall 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 t
he following concepts: <<list of concept names
>>
.”

[SRSreq 77]

When a contribution has been
successfully
submitted

for validation
, t
he OMS shall
send the
following
acknowledgement
message via e
-
mail to

the registered va
lidator: “The following
ontology has been submit
ted for validation: <ontoID>.”

[SRSreq 78]

When
the OMS responds to a submission with a warning message, the OMS shall wait fo
r
confirmation from the user before
accept
ing

the contribution
.

[SRSreq 79]


When the OMS accepts a contribution, the OMS shall return the following messa
ge: “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 v
alidation 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 r
eturn 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
on
tology 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 stat
us 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 v
alidator rejects
a

contribution

to an existing ontology, the client application
sends a
requ
est 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

23


[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
“T
he
contribution

to ontology <ontoID>

was rejected
”,

and
the OMS shall send the

feedback
provided by t
he 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: Meta
data, 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
<m
etadata>, 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]

Wh
en 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
mess
age 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, maint
ainability,
portability, security, and design implementation and contraints.

Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

24


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.

Main
tainability

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 c
lient 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 se
ction 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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

25


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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

26


A.2
Data Flow Diagrams

i.

Scenario #1:
Retrieve


Figure A
-

2
: Level 1
Retrieve

DFD

Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

27


ii.

Scenario #2:
Contribute

iii.

Scenario #3:
Validate

A.3
State Charts

iv.

Scenario #3:
Contribute


Figure A
-

3
: Editing StateChart

v.

Scenario #4: Validat
e


Software Requirements Specification




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

28


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 Produ
ct 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 rd
f: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




Software Requirements Specification

CS 4310 Fall 2005

Version:

1
.4

2
/
16
/200
6

Page

29



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:Annotatio
nProperty rdf:about="<<resource URI>>
" />