Actions

OpenOntologyRepository Requirement and OpenOntologyRepository Scope: Difference between pages

Ontolog Forum

(Difference between pages)
No edit summary
 
No edit summary
 
Line 1: Line 1:
[[File:OOR-Logo.png]]
[[File:OOR-Logo.png]]
= [[OpenOntologyRepository]] ([[OOR]]) Initiative - Requirement =
= [[OpenOntologyRepository]] ([[OOR]]) Initiative - Scope =


This page is for the documentation related to the requirements of the "open ontology repository" we are planning to implement through the [[OOR]] initiative.
This page is for the documentation related to the [[OOR]] initiative's mission, charter, objectives, goals, terms of reference, definitions, scope, ... etc.
 
== Basic Principles and Capabilities  ==
 
* The 2008 Ontology Summit provides a foundation for the implementation of the OOR
 
== Criteria for Adoption  ==
 
* Each requirement should clearly map to one of the subcategories identified in the candidate ideas or other references as listed on this page
 
* Each requirement should contribute to the usability of the OOR
 
* Each requirement should be designed to include any possible user, regardless of country of origin or potential use


== Adopted  ==
== Adopted  ==


*
* '''Definition of "Ontology Repository"'''
** ref. http://ontolog.cim3.net/forum/oor-forum/2008-04/msg00012.html
** Four Objectives
*** 1. Make the Data Visible. This means that all the consumers of the data can discover the existence of that data.
*** 2. Make the Data Accessible. This means that the consumers have appropriate authority to access the data.
*** 3. Make the Data Understandable. This basically means make it self-descriptive.
*** 4. Support the Unanticipated User. This essentially means no limit on the number of the users, in a style similar to the World Wide Web.


:'''"An ontology repository is a facility where ontologies and related information artifacts can be stored, retrieved and managed."'''  
** Goals of the Open Ontology Repository
*** Provide an architecture and an infrastructure that supports the
#### Storing,
#### Sharing,
#### Searching,
#### Governance,
#### Management of Ontologies.
*** Requirements, High Level Assumptions
#### Not all capabilities will be implemented at any single version.
#### The architecture will evolve. There will be multiple versions each successor implanting additional capabilities and/or evolving the previous version.
#### Instance data, which are themselves not ontologies, will not be stored in the repository
#### The repository will meet the needs of operational or commercial systems.
#### Applicable standards will be used.
*** General
#### The repository architecture shall be scalable
#### The repository shall be distributed.
#### The specification of the repository shall be sufficiently detailed and platform independent to allow multiple implementations.
#### The repository shall be capable of supporting ontologies in languages that have reasoners.
#### The repository architecture shall support distributed repositories.
#### The repository architecture shall not require a hierarchical structure.
*** Discovery
#### The repository shall provide metadata capabilities to support
##### search capabilities,
##### governance process,
##### management
#### The repository shall provide a content discovery mechanism that supports discovery by
##### domain
##### author/creator/source
##### version
##### usage
##### language
##### terminology
##### quality
*** Search
#### The repository shall provide a capability to
##### search locally
##### search globally
#### The repository shall provide a capability to browse a repository
##### locally
##### globally    (011)
*** Subscription / Notification
#### The repository shall provide the ability for a user to subscribe to/for alerts associated with one or more repository items.
#### The repository shall provide the ability for a user to subscribe to/for automatic updates of one or more repository items.
*** Management
**** The repository shall provide a mechanism to enforce access policies
#### The repository shall provide a mechanism to enforce submission policies
#### The repository shall provide a mechanism to enforce governance policies
#### The repository shall provide a mechanism to enforce tracking policies
#### The repository shall provide a mechanism to create usage reports
#### The repository shall provide syntax validation mechanisms
#### The repository shall provide a logical consistency checking mechanism
#### The repository shall provide a mechanism to automatically categorize a submission
#### The repository shall provide a mechanism to maintain state change of repository items (i.e. versioning)
#### The repository shall provide user and administrator access control mechanisms
*** Governance
#### The repository shall provide explicit machine usable/accessible repository semantics
#### The repository shall provide a mechanism to avoid intellectual property and related legal issues/problems
** '''Functional Requirements of an RDF/OWL Repository:'''  
*** Provide Capability to Submit an Ontology to the Repository.
**** Extract administrative and descriptive data from the metadata fields of an OWL ontology.
***** Metadata should follow existing metadata standards.
***** Submitted items should be tracked with version numbers (after determining the levels of granularity needed for versioning).
***** Generate a meta-card entry for the ontology.
*** Provide Centralized Data Storage.
**** Ontology metadata (ontology metadata includes the source, date, version number and other core metadata as defined by appropriate standards bodies).
**** OWL ontology.
**** RDF store.
**** Linkage to XML and database data and documents.
*** Metrics and Logging Requirements.
**** Provide data access metrics.
**** Provide data storage metrics.
**** Provide audit logs of repository activity.
*** Provide User Services via a Web Interface to.
**** Search metadata indices.
**** Link from the metadata index to the specific OWL or RDF storage location.
**** Browse repository contents.
**** Provide visual representation of ontologies.
**** Search RDF instance stores with ontology-assistance.
**** Specify agent-directed searches of instance store content.
*** Machine User Services.
**** Query repository and triples store using a conceptual query language, such as SPARQL.
**** Query the repository and triples store using REST.
**** Query the repository and triples store using SOAP.
**** Use an API to programmatically create, view, and modify repository contents.
**** Define machine services in appropriate machine-interpretable format, such as OWL-S.
*** Provide a Repository of Downloadable Web Tools.
**** Define a process with criteria for determining what kinds of tools to make available.
**** Provide an index to available tools.
**** Provide search capability to available tools.
*** Validation Requirements.
**** Validate an OWL ontology to ensure that it is valid OWL.
**** Confirm the RDF against its terminology defined in RDFS.
*** OWL Services.
**** Browsing Services.
**** Query Services.
**** Indexing Services.
***** Provides services for external search engines and entity extractors to index and mine repository contents.
**** Visualization Services.
**** Edit Services.
**** Validation Services.
**** Annotation Services.
**** Web-Page Markup.
**** Semantic Search Services.
**** Crawl and Index.
***** OWL Semantic Search Services crawl and index OWL content on the Web. Users submit logical queries which are answered with exact data. It can broaden queries with simple inference, such as equivalence, inversion, generalization and specialization.
*** Reasoning Services.
**** Provide services to check ontology consistency, build classification, verify concepts, satisfiability and check entailment.
**** Provide services to support rules and execute minimally automated deductive reasoning and proof.
*** Import Services.
**** Support importing of modular ontologies into larger ontologies; this is at least partially a function of the knowledge representation language itself.
*** Semantic Mapping Services.
**** Schema Translation.
***** Automatically generate translation code between database schemas with an OWL mapping specification.
**** Visually-aided Mapping.
***** A user would generate a mapping between an existing ontology and the ontology expected by the custom visualization tool. The data would then be translated according to the mappings. The resulting data can then be viewed by the custom visualization tool.
**** Disambiguation.
***** A user would generate a mapping between multiple ontologies to identify where classes and properties are the same. The data from multiple sources could then be imported into a repository where a reasoning tool can determine what objects are the same. The results could then be viewed in a browser.
*** Ontology and Instance Versioning Services.
**** Provide services to support semantic versioning of ontologies and knowledge bases (instances).
*** Terminology to Concept Mapping Services.
**** Provide services to support mapping user terminology to the concepts that represent the meaning of that terminology, using thesauri, lexicons, and other terminological resources.  
** '''Conceptual high-level Requirements of an RDF/OWL Repository:'''
*** Allows authors to create ontology content and store it in a "local" repository
*** Allow communities to manage a shared "community" repository
*** Provide a "root" repository that keeps tracks of community repositories and provides the most universal ontology content and metadata
*** Supports a [http://maven.apache.org/ maven] like distributed model where content from "local" repository may be "deployed" to the "community" repository or the "root" repository
*** Allows standard and extensible metadata to be associated with Ontology elements
*** Supports flexible search mechanism where domain and community specific parameterized queries may be defined for metadata based searches
*** Supports flexible subscription and notification feature to keep interested parties notified of changes to artifacts
*** Supports automatic cataloging of published artifacts
*** Supports automatic rule-based validation of submitted artifacts
*** Supports different life cycle states for ontological content and provides a process for transitioning from one state to the other in a controlled manner. Note that the notification feature would notify interested parties of such state changes.
*** Maintains change history for all artifacts in repository
*** Supports a set of minimal authentication mechanisms (e.g. Basic, HTTPS mutual, OpenId)
*** Provide fine grained role-based access control and authorization over all actions
*** Support seamless search over multiple repositorys (local + community, local + community + root, other...)


== Proposed for Adoption  ==
::''(ref. http://ontolog.cim3.net/forum/oor-forum/2008-02/msg00071.html#nid03 ''


... ''(enter proposed items here)''  
:: also ref: '''[[OntologySummit2008_Communique]]'''  


== Ideas & Candidates  ==
== Ideas & Candidates  ==


... ''(enter ideas and candidates below)''  
... ''(enter ideas and candidates here)''  


* '''Candidate01''' - proposed by LeoObrst/2008.01.03
* Candidate01 - proposed by: LeoObrst/2008.01.21
** slides #7~11 from [http://ontolog.cim3.net/file/work/OpenOntologyRepository/ConferenceCall_2008_01_03/Open-Ontology-Repository-Planning-Meeting_20080103b.pdf the planning meeting slide deck]:
** ref. http://ontolog.cim3.net/forum/oor-forum/2008-01/msg00018.html
** '''Functional Requirements of an RDF/OWL Repository:'''
*** Provide Capability to Submit an Ontology to the Repository.
**** Extract administrative and descriptive data from the metadata fields of an OWL ontology.
***** Metadata should follow existing metadata standards.
***** Submitted items should be tracked with version numbers (after determining the levels of granularity needed for versioning).
***** Generate a meta-card entry for the ontology.
*** Provide Centralized Data Storage.
**** Ontology metadata (ontology metadata includes the source, date, version number and other core metadata as defined by appropriate standards bodies).
**** OWL ontology.
**** RDF store.
**** Linkage to XML and database data and documents.
*** Metrics and Logging Requirements.
**** Provide data access metrics.
**** Provide data storage metrics.
**** Provide audit logs of repository activity.
*** Provide User Services via a Web Interface to.
**** Search metadata indices.
**** Link from the metadata index to the specific OWL or RDF storage location.
**** Browse repository contents.
**** Provide visual representation of ontologies.
**** Search RDF instance stores with ontology-assistance.
**** Specify agent-directed searches of instance store content.
*** Machine User Services.
**** Query repository and triples store using a conceptual query language, such as SPARQL.
**** Query the repository and triples store using REST.
**** Query the repository and triples store using SOAP.
**** Use an API to programmatically create, view, and modify repository contents.
**** Define machine services in appropriate machine-interpretable format, such as OWL-S.
*** Provide a Repository of Downloadable Web Tools.
**** Define a process with criteria for determining what kinds of tools to make available.
**** Provide an index to available tools.
**** Provide search capability to available tools.
*** Validation Requirements.
**** Validate an OWL ontology to ensure that it is valid OWL.
**** Confirm the RDF against its terminology defined in RDFS.
*** OWL Services.
**** Browsing Services.
**** Query Services.
**** Indexing Services.
***** Provides services for external search engines and entity extractors to index and mine repository contents.
**** Visualization Services.
**** Edit Services.
**** Validation Services.
**** Annotation Services.
**** Web-Page Markup.
**** Semantic Search Services.
**** Crawl and Index.
***** OWL Semantic Search Services crawl and index OWL content on the Web. Users submit logical queries which are answered with exact data. It can broaden queries with simple inference, such as equivalence, inversion, generalization and specialization.
*** Reasoning Services.
**** Provide services to check ontology consistency, build classification, verify concepts, satisfiability and check entailment.
**** Provide services to support rules and execute minimally automated deductive reasoning and proof.
*** Import Services.
**** Support importing of modular ontologies into larger ontologies; this is at least partially a function of the knowledge representation language itself.
*** Semantic Mapping Services.
**** Schema Translation.
***** Automatically generate translation code between database schemas with an OWL mapping specification.
**** Visually-aided Mapping.
***** A user would generate a mapping between an existing ontology and the ontology expected by the custom visualization tool. The data would then be translated according to the mappings. The resulting data can then be viewed by the custom visualization tool.
**** Disambiguation.
***** A user would generate a mapping between multiple ontologies to identify where classes and properties are the same. The data from multiple sources could then be imported into a repository where a reasoning tool can determine what objects are the same. The results could then be viewed in a browser.
*** Ontology and Instance Versioning Services.
**** Provide services to support semantic versioning of ontologies and knowledge bases (instances).
*** Terminology to Concept Mapping Services.
**** Provide services to support mapping user terminology to the concepts that represent the meaning of that terminology, using thesauri, lexicons, and other terminological resources.  


* '''Candidate02''' - proposed by FarrukhNajmi/2008.01.24
*
** ref. http://ontolog.cim3.net/forum/oor-forum/2008-01/msg00033.html
** '''Definitions: Registry vs. Repository'''  
** '''Farrukh's quick brain dump''' / 2008.01.24
*** Allows authors to create ontology content and store it in a "local" repository
*** Allow communities to manage a shared "community" repository
*** Provide a "root" repository that keeps tracks of community repositories and provides the most universal ontology content and metadata
*** Supports a [http://maven.apache.org/ maven] like distributed model where content from "local" repository may be "deployed" to the "community" repository or the "root" repository
*** Allows standard and extensible metadata to be associated with Ontology elements
*** Supports flexible search mechanism where domain and community specific parameterized queries may be defined for metadata based searches
*** Supports flexible subscription and notification feature to keep interested parties notified of changes to artifacts
*** Supports automatic cataloging of published artifacts
*** Supports automatic rule-based validation of submitted artifacts
*** Supports different life cycle states for ontological content and provides a process for transitioning from one state to the other in a controlled manner. Note that the notification feature would notify interested parties of such state changes.
*** Maintains change history for all artifacts in repository
*** Supports a set of minimal authentication mechanisms (e.g. Basic, HTTPS mutual, OpenId)
*** Provide fine grained role-based access control and authorization over all actions
*** Support seamless search over multiple repositorys (local + community, local + community + root, other...)


* '''Candidate03''' - proposed by EvanWallace/2008.04.17
::There is often confusion over the distinction between a registry and a repository. Both are data structures or stores. For the purposes of this paper, a registry is defined to be a data structure where data, metadata, knowledge or semantic objects are listed as being available, along with who placed them there, and their conditions of use. A repository is a data structure where data, metadata, knowledge or semantic objects and related artifacts are placed, and can be accessed from; typically repositories include management software. A registry therefore can be considered a portion of a repository, a listing or table of contents for the repository, rather than the entire contents of the repository (which repository can be either centralized or distributed). A simple example of a registry is the Windows Registry, which is a listing or table of installed programs, rather than the entire set of programs themselves and their data.  
** ref. http://ontolog.cim3.net/forum/oor-forum/2008-04/msg00011.html
** Bare minimum requirements:  
### Need to support ontologies in at least OWL and Common Logic (CL).  
** Need to provide means for users to Discover content via browsing and query of exposed elements of the content and metadata related to that content.
## Need to serve content reliably in an appropriate standard exchange
form and using protocols associated with each content type.  
## Need to provide persistent and available access to this content and associated metadata for multiple versions as the content evolves.  
** I would characterize requirements 1 and 2 as requirements on a Registry functionality and 3 and 4 as requirements on a Repository functionality of an OOR.  


* '''Candidate04''' - proposed by ToddSchneider/2008.04.17
** ref. http://ontolog.cim3.net/forum/oor-forum/2008-04/msg00012.html
** '''Goals'''  
** Goals of the Open Ontology Repository
*** Provide an architecture and an infrastructure that supports the
#### Storing,
#### Sharing,
#### Searching,
#### Governance,
#### Management of Ontologies.
*** Requirements, High Level Assumptions
#### Not all capabilities will be implemented at any single version.
#### The architecture will evolve. There will be multiple versions each successor implanting additional capabilities and/or evolving the previous version.
#### Instance data, which are themselves not ontologies, will not be stored in the repository
#### The repository will meet the needs of operational or commercial systems.
#### Applicable standards will be used.
*** General
#### The repository architecture shall be scalable
#### The repository shall be distributed.
#### The specification of the repository shall be sufficiently detailed and platform independent to allow multiple implementations.
#### The repository shall be capable of supporting ontologies in languages that have reasoners.
#### The repository architecture shall support distributed repositories.
#### The repository architecture shall not require a hierarchical structure.
*** Discovery
#### The repository shall provide metadata capabilities to support
##### search capabilities,
##### governance process,
##### management
#### The repository shall provide a content discovery mechanism that supports discovery by
##### domain
##### author/creator/source
##### version
##### usage
##### language
##### terminology
##### quality
*** Search
#### The repository shall provide a capability to
##### search locally
##### search globally
#### The repository shall provide a capability to browse a repository
##### locally
##### globally    (011)
*** Subscription / Notification
#### The repository shall provide the ability for a user to subscribe to/for alerts associated with one or more repository items.
#### The repository shall provide the ability for a user to subscribe to/for automatic updates of one or more repository items.
*** Management
**** The repository shall provide a mechanism to enforce access policies
#### The repository shall provide a mechanism to enforce submission policies
#### The repository shall provide a mechanism to enforce governance policies
#### The repository shall provide a mechanism to enforce tracking policies
#### The repository shall provide a mechanism to create usage reports
#### The repository shall provide syntax validation mechanisms
#### The repository shall provide a logical consistency checking mechanism
#### The repository shall provide a mechanism to automatically categorize a submission
#### The repository shall provide a mechanism to maintain state change of repository items (i.e. versioning)
#### The repository shall provide user and administrator access control mechanisms
*** Governance
#### The repository shall provide explicit machine usable/accessible repository semantics
#### The repository shall provide a mechanism to avoid intellectual property and related legal issues/problems


----
::The purpose of an RDF/OWL Repository is to provide an architecture and an infrastructure that supports a) the creation, sharing, searching, and management of ontologies, and b) linkage to database and XML Schema structured data and documents. Complementary goals include fostering the Semantic Web community, the identification and promotion of best practices, and the provision of services relevant to the RDFS and OWL ontologies and RDF instance stores. In addition, because the Semantic Web languages are represented as formal logics, automated semantic interpretation of content expressed in Semantic Web languages and inference over this content is enabled. Such repositories ultimately will support a broad range of semantic services and applications of interest to enterprises and communities.


* see: '''Proceedings from the Joint [[OpenOntologyRepository]]-OntologySummit2008 "Requirements Panel" sessions''':
::Achieving these goals will help reduce semantic ambiguity whenever and wherever information is shared, thereby allowing information to be located, searched, categorized and exchanged with a more precise _expression_ of its content and meaning. The artifacts of the repository will provide a semantic grounding for diverse formats and domains, ranging from the conceptual domains and disciplines of communities to technical schema such as WSDL, UDDI, RSS, and XML schema. Perhaps most importantly, the repository will enable wide-scale knowledge re-use and reduce the need to re-invent the wheel to define concepts and relationships that are already understood. An example of the latter are "portals" that contain manually hard-coded information derived from another source.
** 2008_03_27 - Thursday: Joint OOR-OntologySummit2008 Panel Discussion: "An Open Ontology Repository: Rationale, Expectations & Requirements - Session-1" - Chair: [[LeoObrst|Leo Obrst]] & [[FabianNeuhaus|Fabian Neuhaus]]; Panelists: [[WilliamBug|William Bug]], [[EvanWallace|Evan Wallace]], [[JohnLMcCarthy]], [[User:KennethBaclawski|Ken Baclawski]], [[PeterBenson|Peter Benson]] & [[RexBrooks|Rex Brooks]] - ConferenceCall_2008_03_27   
** 2008_04_03 - Thursday: Joint OOR-OntologySummit2008 Panel Discussion: "An Open Ontology Repository: Rationale, Expectations & Requirements - Session-2" - Chair: [[LeoObrst|Leo Obrst]] & [[FabianNeuhaus|Fabian Neuhaus]]; Panelists: [[DougLenat|Doug Lenat]], [[DekeSmith|Deke Smith]], [[MarciaZeng|Marcia Zeng]], [[DeniseBedford|Denise Bedford]], [[PatHayes|Pat Hayes]], [[MalaMehrotra|Mala Mehrotra]] & [[RobRaskin|Rob Raskin]] - ConferenceCall_2008_04_03   


* see '''the [http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008/FaceToFaceAgenda#nid1BLS OOR Presentation] by this team on 29-Apr-2008''' at the [http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008/FaceToFaceAgenda [[OntologySummit2008|Ontology Summit 2008]] F2F workshop].
::These goals cannot be achieved at once, and must track the evolution of best practices as well as technology itself. It is also good system development practice to bound complexity by defining a system in terms of a series of short-term, achievable objectives. For this reason, as for other such initiatives, it?s envisioned that the RDF/OWL Repository will be developed in a series of phases, proceeding from the simple to the complex, with achievable goals that capitalize on previous experience and the emergence of technology over time. It is important to note that for any given phase, planning and prototyping is always in progress for subsequent phases. These phases are notionally described in the following sections.  
** note, in particular, [http://ontolog.cim3.net/file/work/OntologySummit2008/2008-04-2829_F2F-workshop/OntologySummit2008_OOR-Presentation--MikeDean-LeoObrst-PeterYim_20080429.ppt slides #8 to #43]


* '''see: the [[OntologySummit2008_Communique]]'''
* /Candidate02 - proposed by ... --(name)/(date)
** ref. ...


* '''see: [[OpenOntologyRepository_UseCases]]'''  
* see also: '''OntologySummit2008''' proceedings


[[Category:OOR]]
[[Category:OOR]]

Latest revision as of 15:15, 14 December 2022

OOR-Logo.png

OpenOntologyRepository (OOR) Initiative - Scope

This page is for the documentation related to the OOR initiative's mission, charter, objectives, goals, terms of reference, definitions, scope, ... etc.

Adopted

  • Definition of "Ontology Repository"
"An ontology repository is a facility where ontologies and related information artifacts can be stored, retrieved and managed."
(ref. http://ontolog.cim3.net/forum/oor-forum/2008-02/msg00071.html#nid03
also ref: OntologySummit2008_Communique

Ideas & Candidates

... (enter ideas and candidates here)

    • Definitions: Registry vs. Repository
There is often confusion over the distinction between a registry and a repository. Both are data structures or stores. For the purposes of this paper, a registry is defined to be a data structure where data, metadata, knowledge or semantic objects are listed as being available, along with who placed them there, and their conditions of use. A repository is a data structure where data, metadata, knowledge or semantic objects and related artifacts are placed, and can be accessed from; typically repositories include management software. A registry therefore can be considered a portion of a repository, a listing or table of contents for the repository, rather than the entire contents of the repository (which repository can be either centralized or distributed). A simple example of a registry is the Windows Registry, which is a listing or table of installed programs, rather than the entire set of programs themselves and their data.
    • Goals
The purpose of an RDF/OWL Repository is to provide an architecture and an infrastructure that supports a) the creation, sharing, searching, and management of ontologies, and b) linkage to database and XML Schema structured data and documents. Complementary goals include fostering the Semantic Web community, the identification and promotion of best practices, and the provision of services relevant to the RDFS and OWL ontologies and RDF instance stores. In addition, because the Semantic Web languages are represented as formal logics, automated semantic interpretation of content expressed in Semantic Web languages and inference over this content is enabled. Such repositories ultimately will support a broad range of semantic services and applications of interest to enterprises and communities.
Achieving these goals will help reduce semantic ambiguity whenever and wherever information is shared, thereby allowing information to be located, searched, categorized and exchanged with a more precise _expression_ of its content and meaning. The artifacts of the repository will provide a semantic grounding for diverse formats and domains, ranging from the conceptual domains and disciplines of communities to technical schema such as WSDL, UDDI, RSS, and XML schema. Perhaps most importantly, the repository will enable wide-scale knowledge re-use and reduce the need to re-invent the wheel to define concepts and relationships that are already understood. An example of the latter are "portals" that contain manually hard-coded information derived from another source.
These goals cannot be achieved at once, and must track the evolution of best practices as well as technology itself. It is also good system development practice to bound complexity by defining a system in terms of a series of short-term, achievable objectives. For this reason, as for other such initiatives, it?s envisioned that the RDF/OWL Repository will be developed in a series of phases, proceeding from the simple to the complex, with achievable goals that capitalize on previous experience and the emergence of technology over time. It is important to note that for any given phase, planning and prototyping is always in progress for subsequent phases. These phases are notionally described in the following sections.
  • /Candidate02 - proposed by ... --(name)/(date)
    • ref. ...
  • see also: OntologySummit2008 proceedings