Ravi
(Dr. Ravi Sharma) Senior Enterprise Architect
Vangent, Inc. Technology Excellence Center (TEC)
8618 Westwood Center Drive, Suite 310, Vienna VA 22182
(o) 703-827-0638, (c)
313-204-1740 www.vangent.com
Professional viewpoints do
not necessarily imply organizational endorsement.
From:
ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Andrew Schain
Sent: Tuesday, April 01, 2008 6:08
PM
To: Ontology Summit 2008
Subject: Re: [ontology-summit]
[requirements] Top three (3) services youexpect from the OOR
Peter - here are NASA's requirements for (basically) an
Ontology Repository.
M=mandatory (the system must do these things otherwise
it cannot be deployed as "completed")
P=preferred (the system should do these things)
O=optional (it would be nice if the system did these
things)
don't know if this helps, if not apologies for the spam
Data Reference Model Registry
The purpose of the Data Reference Model registry is to
provide sufficient and timely information regarding which data models within
specific domains and using specific concepts are available for re-purposing in
other applications. The registry must provide sufficient information regarding
the technologies used by the models (e.g. RDMS, XMLS, RDFS, OWL) and their
current use for a potential customer to determine if further investigation is
warranted. It is assumed that in most cases the service will not contain any
models but will have a conical link to them. In either case, the models must be
available for potential customers to view.
|
Description
|
Level
|
Functional Area
|
Id
|
|
|
Ad-hoc query (human)
|
M
|
Application Interface
|
M1
|
|
|
Ad-hoc query (machine)
|
M
|
Models Application Interface
|
M2
|
|
|
Browsing the dataset (human)
|
M
|
Models Application Interface
|
M3
|
|
|
Browsing the dataset (machine)
|
M
|
Models Application Interface
|
M4
|
|
|
Notification service (human & machine)
|
P
|
Models Application Interface
|
M5
|
|
|
Subscription service (human &machine)
|
P
|
Models Application Interface
|
M6
|
|
|
Ability to annotate metadata
|
O
|
Models Application Interface
|
M7
|
|
|
Automatically check for compliance where possible
|
P
|
Models Analysis Services
|
M8
|
|
|
Automatically check for coherence or validity where
possible
|
M
|
Models Analysis
|
M9
|
|
|
Automatically check for containment where possible
|
P
|
Models Analysis Services
|
M10
|
|
|
Basic Matchmaking
|
P
|
Models Analysis Services
|
M11
|
|
|
Basic description of the model
|
M
|
Metadata
|
M12
|
|
|
Basic concepts in the model
|
M
|
Metadata
|
M13
|
|
|
Creation date and last update
|
M
|
Metadata
|
M14
|
|
|
Validation and mechanism
|
M
|
Metadata
|
M15
|
|
|
Authorship & curation
|
M
|
Metadata
|
M16
|
|
|
Trust (used successfully where?)
|
M
|
Metadata
|
M17
|
|
|
Trust (tested for soundness)
|
M
|
Metadata
|
M18
|
|
|
Trust (documentation)
|
M
|
Metadata
|
M19
|
|
|
Trust (concepts vetted)
|
M
|
Metadata
|
M20
|
|
|
Trust (vetted linkage)
|
P
|
Metadata
|
M21
|
|
|
Other (actual) use cases
|
P
|
Metadata
|
M22
|
|
|
Submitted to OMB as DRM
|
P
|
Metadata
|
M23
|
|
|
Support versioning
|
M
|
Metadata
|
M24
|
1
|
|
What is the model’s technology?
|
M
|
Metadata
|
M25
|
1
|
|
Model’s standards compliance
|
M
|
Metadata
|
M26
|
1
|
|
Access controls to see models
|
M
|
IT Security
|
M27
|
1
|
|
Assure mechanism to access to models (e.g. URL)
|
M
|
System Design
|
M28
|
|
|
Mechanism for customers to register models
|
M
|
System Design
|
M29
|
1
|
|
Mechanism for a super user to register a model
|
M
|
System Design
|
M30
|
1
|
|
Mechanism for service to be available without a
specific client
|
M
|
System Design
|
M31
|
1
|
Agreement Repository
The purpose of Service Level Agreement and Interface
Control Documents is to encourage information re-use and integration, as well
as to provide a basis for managing the connections and integrations between
NASA systems by providing relevant data, heuristics, and analysis services. It
is assumed that in this case the official version of the documents will be
securely hosted within the service.
|
Description
|
Level
|
Functional Area
|
Id
|
|
|
Parties to the agreement
|
M
|
Metadata
|
A1
|
|
|
Purpose
|
M
|
Metadata
|
A2
|
|
|
Scope
|
M
|
Metadata
|
A3
|
|
|
Dates
|
M
|
Metadata
|
A4
|
|
|
Change process
|
P
|
Metadata
|
A5
|
|
|
Availability
|
M
|
Metadata
|
A6
|
|
|
Contact information
|
M
|
Metadata
|
A7
|
|
|
Carrying capacity
|
P
|
Metadata
|
A8
|
|
|
Service interface
|
P
|
Metadata
|
A9
|
|
|
Security classification of systems
|
M
|
Metadata
|
A10
|
|
|
Relevant ICDs
|
P
|
Metadata
|
A11
|
|
|
Relevant ACLs
|
P
|
Metadata
|
A12
|
|
|
Applicable policies
|
P
|
System design
|
A13
|
|
|
Associated agreements
|
M
|
System design
|
A14
|
|
|
Sufficient storage to retain official copies of
agreements
|
M
|
System design
|
A15
|
|
|
Automated check-in and out tracking
|
M
|
System Design
|
A16
|
|
|
Mechanism for customers to submit agreements
|
M
|
System Design
|
A17
|
|
|
Mechanism for a super user to submit or delete
agreements
|
M
|
System Design
|
A18
|
|
|
or service to be securely available without a specific
client
|
M
|
System Design
|
A19
|
|
|
Access controls to see models
|
M
|
IT Security
|
A20
|
|
|
Sufficient controls to protect data at rest
|
M
|
IT Security
|
A21
|
|
Data Source Registry
It is assumed that some data sources do not have models
within the service and that some models may not initially have their data
sources listed; it is also to be understood that the service will not store
*data sources*, but, rather, securely store information about data sources.
|
Description
|
Level
|
Functional Area
|
Id
|
Stage
|
|
Purpose
|
M
|
Metadata
|
S1
|
|
|
Contact Information
|
M
|
Metadata
|
S2
|
|
|
Location
|
M
|
Metadata
|
S3
|
|
|
Access method
|
P
|
Metadata
|
S4
|
|
|
Type (e.g. RDMS, collection, etc)
|
M
|
Metadata
|
S5
|
|
|
Data model
|
M
|
Metadata
|
S8
|
|
|
Dates
|
M
|
Metadata
|
S9
|
|
|
Lifecycle
|
P
|
Metadata
|
S10
|
|
|
Status
|
M
|
Metadata
|
S11
|
|
|
IT security level
|
M
|
Metadata
|
S12
|
|
|
Policies
|
P
|
Metadata
|
S13
|
|
|
ACL
|
P
|
Metadata
|
S14
|
|
|
ACL contact information
|
P
|
Metadata
|
S15
|
|
|
Pointers
|
P
|
System Design
|
S16
|
|
On Mar 29, 2008, at 10:40 AM, Peter Yim wrote:
Leo asked a simple, yet useful question at Thursday's (2008.03.27"
OOR-Panel discussion "An Open Ontology Repository: Rationale,
Expectations & Requirements - Session-1" ...
LeoObrst:
Question to all: What is the most important service that
an OOR could provide to you, as a
content provider? What is the next most
important? and the
next? ... namely the top 3 services.
(I transcribed the last bits of it from
his verbal request during
the discussion into the chat transcript. =ppy)
Those who were there give some very interesting answers. See:
In fact, it will be great for everyone on this list, if you see
yourself as an ontological artifact provider that would be hosting
that content on an Open Ontology Repository (OOR),
*What would be YOUR top three services* ?
Treat this as a survey, and send your response by replying to this, so
we can capture the input through this thread. (Someone could then roll
up the answer, I guess, afterwards.)
_________________________________________________________________