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
--
_________________________________________________________________