ontology-summit
[Top] [All Lists]

Re: [ontology-summit] [requirements] Top three (3) services you expect f

To: Ontology Summit 2008 <ontology-summit@xxxxxxxxxxxxxxxx>
From: Andrew Schain <andrew.schain@xxxxxxxx>
Date: Tue, 1 Apr 2008 18:08:14 -0400
Message-id: <6C46622B-C8E9-481F-9BBE-CB2D0D3970A1@xxxxxxxx>
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

~A





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.)

Thanks & regards.  =ppy
--

_________________________________________________________________
Community Portal: http://ontolog.cim3.net/

|||| ||||| || |||||| ||||||| ||| ||||||| || ||| |||||||

Andrew Schain
the HQ CTO & EA
Deputy CIO (Acting)
Chief Security & Information Systems Branch (Acting)
202-358-0066


_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/ 
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/  
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2008/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008 
Community Portal: http://ontolog.cim3.net/    (01)
<Prev in Thread] Current Thread [Next in Thread>