Actions

Ontolog Forum

OOR-Logo.png

OpenOntologyRepository (OOR) Initiative - Requirement

This page is for the documentation related to the requirements of the "open ontology repository" we are planning to implement through the OOR initiative.

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

    • 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.
    • Goals of the Open Ontology Repository
      • Provide an architecture and an infrastructure that supports the
        1. Storing,
        2. Sharing,
        3. Searching,
        4. Governance,
        5. Management of Ontologies.
      • Requirements, High Level Assumptions
        1. Not all capabilities will be implemented at any single version.
        2. The architecture will evolve. There will be multiple versions each successor implanting additional capabilities and/or evolving the previous version.
        3. Instance data, which are themselves not ontologies, will not be stored in the repository
        4. The repository will meet the needs of operational or commercial systems.
        5. Applicable standards will be used.
      • General
        1. The repository architecture shall be scalable
        2. The repository shall be distributed.
        3. The specification of the repository shall be sufficiently detailed and platform independent to allow multiple implementations.
        4. The repository shall be capable of supporting ontologies in languages that have reasoners.
        5. The repository architecture shall support distributed repositories.
        6. The repository architecture shall not require a hierarchical structure.
      • Discovery
        1. The repository shall provide metadata capabilities to support
          1. search capabilities,
          2. governance process,
          3. management
        2. The repository shall provide a content discovery mechanism that supports discovery by
          1. domain
          2. author/creator/source
          3. version
          4. usage
          5. language
          6. terminology
          7. quality
      • Search
        1. The repository shall provide a capability to
          1. search locally
          2. search globally
        2. The repository shall provide a capability to browse a repository
          1. locally
          2. globally (011)
      • Subscription / Notification
        1. The repository shall provide the ability for a user to subscribe to/for alerts associated with one or more repository items.
        2. 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
        1. The repository shall provide a mechanism to enforce submission policies
        2. The repository shall provide a mechanism to enforce governance policies
        3. The repository shall provide a mechanism to enforce tracking policies
        4. The repository shall provide a mechanism to create usage reports
        5. The repository shall provide syntax validation mechanisms
        6. The repository shall provide a logical consistency checking mechanism
        7. The repository shall provide a mechanism to automatically categorize a submission
        8. The repository shall provide a mechanism to maintain state change of repository items (i.e. versioning)
        9. The repository shall provide user and administrator access control mechanisms
      • Governance
        1. The repository shall provide explicit machine usable/accessible repository semantics
        2. 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 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

... (enter proposed items here)

Ideas & Candidates

... (enter ideas and candidates below)

  • Candidate01 - proposed by LeoObrst/2008.01.03
    • slides #7~11 from the planning meeting slide deck:
    • 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
    • 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 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...)
      1. 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.
    1. Need to serve content reliably in an appropriate standard exchange

form and using protocols associated with each content type.

    1. 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.
        1. Storing,
        2. Sharing,
        3. Searching,
        4. Governance,
        5. Management of Ontologies.
      • Requirements, High Level Assumptions
        1. Not all capabilities will be implemented at any single version.
        2. The architecture will evolve. There will be multiple versions each successor implanting additional capabilities and/or evolving the previous version.
        3. Instance data, which are themselves not ontologies, will not be stored in the repository
        4. The repository will meet the needs of operational or commercial systems.
        5. Applicable standards will be used.
      • General
        1. The repository architecture shall be scalable
        2. The repository shall be distributed.
        3. The specification of the repository shall be sufficiently detailed and platform independent to allow multiple implementations.
        4. The repository shall be capable of supporting ontologies in languages that have reasoners.
        5. The repository architecture shall support distributed repositories.
        6. The repository architecture shall not require a hierarchical structure.
      • Discovery
        1. The repository shall provide metadata capabilities to support
          1. search capabilities,
          2. governance process,
          3. management
        2. The repository shall provide a content discovery mechanism that supports discovery by
          1. domain
          2. author/creator/source
          3. version
          4. usage
          5. language
          6. terminology
          7. quality
      • Search
        1. The repository shall provide a capability to
          1. search locally
          2. search globally
        2. The repository shall provide a capability to browse a repository
          1. locally
          2. globally (011)
      • Subscription / Notification
        1. The repository shall provide the ability for a user to subscribe to/for alerts associated with one or more repository items.
        2. 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
        1. The repository shall provide a mechanism to enforce submission policies
        2. The repository shall provide a mechanism to enforce governance policies
        3. The repository shall provide a mechanism to enforce tracking policies
        4. The repository shall provide a mechanism to create usage reports
        5. The repository shall provide syntax validation mechanisms
        6. The repository shall provide a logical consistency checking mechanism
        7. The repository shall provide a mechanism to automatically categorize a submission
        8. The repository shall provide a mechanism to maintain state change of repository items (i.e. versioning)
        9. The repository shall provide user and administrator access control mechanisms
      • Governance
        1. The repository shall provide explicit machine usable/accessible repository semantics
        2. The repository shall provide a mechanism to avoid intellectual property and related legal issues/problems
Retrieved from "https://ontologforum.com/index.php?title=OpenOntologyRepository_Requirement&oldid=4110"