From OntologPSMW

Jump to: navigation, search
[ ]

Contents

OpenOntologyRepository (OOR) Initiative - Requirement     (2)

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

Basic Principles and Capabilities     (2B)

  • The 2008 Ontology Summit provides a foundation for the implementation of the OOR     (2B1)

Criteria for Adoption     (2C)

  • Each requirement should clearly map to one of the subcategories identified in the candidate ideas or other references as listed on this page     (2C1)
  • Each requirement should contribute to the usability of the OOR     (2C2)
  • Each requirement should be designed to include any possible user, regardless of country of origin or potential use     (2C3)

Adopted     (2D)

        1. Searching,     (2D3A1C)
        2. Governance,     (2D3A1D)
        3. Management of Ontologies.     (2D3A1E)
        1. Not all capabilities will be implemented at any single version.     (2D5A1A)
        2. The architecture will evolve. There will be multiple versions each successor implanting additional capabilities and/or evolving the previous version.     (2D5A1B)
        3. Instance data, which are themselves not ontologies, will not be stored in the repository     (2D5A1C)
        4. The repository will meet the needs of operational or commercial systems.     (2D5A1D)
        5. Applicable standards will be used.     (2D5A1E)
        1. The repository architecture shall be scalable     (2D7A1A)
        2. The repository shall be distributed.     (2D7A1B)
        3. The specification of the repository shall be sufficiently detailed and platform independent to allow multiple implementations.     (2D7A1C)
        4. The repository shall be capable of supporting ontologies in languages that have reasoners.     (2D7A1D)
        5. The repository architecture shall support distributed repositories.     (2D7A1E)
        6. The repository architecture shall not require a hierarchical structure.     (2D7A1F)
        1. The repository shall provide metadata capabilities to support     (2D9A1A)
          1. search capabilities,     (2D9A1A1)
          2. governance process,     (2D9A1A2)
          3. management     (2D9A1A3)
        2. The repository shall provide a content discovery mechanism that supports discovery by     (2D9A1B)
          1. author/creator/source     (2D9A1B2)
          2. terminology     (2D9A1B6)
        1. The repository shall provide a capability to     (2D11A1A)
          1. search locally     (2D11A1A1)
          2. search globally     (2D11A1A2)
        2. The repository shall provide a capability to browse a repository     (2D11A1B)
          1. globally (011)     (2D11A1B2)
        1. The repository shall provide the ability for a user to subscribe to/for alerts associated with one or more repository items.     (2D13A1A)
        2. The repository shall provide the ability for a user to subscribe to/for automatic updates of one or more repository items.     (2D13A1B)
        1. The repository shall provide a mechanism to enforce submission policies     (2D15A1A)
        2. The repository shall provide a mechanism to enforce governance policies     (2D15A1B)
        3. The repository shall provide a mechanism to enforce tracking policies     (2D15A1C)
        4. The repository shall provide a mechanism to create usage reports     (2D15A1D)
        5. The repository shall provide syntax validation mechanisms     (2D15A1E)
        6. The repository shall provide a logical consistency checking mechanism     (2D15A1F)
        7. The repository shall provide a mechanism to automatically categorize a submission     (2D15A1G)
        8. The repository shall provide a mechanism to maintain state change of repository items (i.e. versioning)     (2D15A1H)
        9. The repository shall provide user and administrator access control mechanisms     (2D15A1I)
        1. The repository shall provide explicit machine usable/accessible repository semantics     (2D17A1A)
        2. The repository shall provide a mechanism to avoid intellectual property and related legal issues/problems     (2D17A1B)
    • Functional Requirements of an RDF/OWL Repository:     (2D18A)
    • Conceptual high-level Requirements of an RDF/OWL Repository:     (2D18B)
      • Allows authors to create ontology content and store it in a "local" repository     (2D18B1)
      • Allow communities to manage a shared "community" repository     (2D18B2)
      • Provide a "root" repository that keeps tracks of community repositories and provides the most universal ontology content and metadata     (2D18B3)
      • Supports a maven like distributed model where content from "local" repository may be "deployed" to the "community" repository or the "root" repository     (2D18B4)
      • Allows standard and extensible metadata to be associated with Ontology elements     (2D18B5)
      • Supports flexible search mechanism where domain and community specific parameterized queries may be defined for metadata based searches     (2D18B6)
      • Supports flexible subscription and notification feature to keep interested parties notified of changes to artifacts     (2D18B7)
      • Supports automatic cataloging of published artifacts     (2D18B8)
      • Supports automatic rule-based validation of submitted artifacts     (2D18B9)
      • 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.     (2D18B10)
      • Maintains change history for all artifacts in repository     (2D18B11)
      • Supports a set of minimal authentication mechanisms (e.g. Basic, HTTPS mutual, OpenId)     (2D18B12)
      • Provide fine grained role-based access control and authorization over all actions     (2D18B13)
      • Support seamless search over multiple repositorys (local + community, local + community + root, other...)     (2D18B14)

Proposed for Adoption     (2E)

... (enter proposed items here)     (2E1)

Ideas & Candidates     (2F)

... (enter ideas and candidates below)     (2F1)

  • Candidate02 - proposed by FarrukhNajmi/2008.01.24     (2F3)
    • Farrukh's quick brain dump / 2008.01.24     (2F3B)
      • Allows authors to create ontology content and store it in a "local" repository     (2F3B1)
      • Allow communities to manage a shared "community" repository     (2F3B2)
      • Provide a "root" repository that keeps tracks of community repositories and provides the most universal ontology content and metadata     (2F3B3)
      • Supports a maven like distributed model where content from "local" repository may be "deployed" to the "community" repository or the "root" repository     (2F3B4)
      • Allows standard and extensible metadata to be associated with Ontology elements     (2F3B5)
      • Supports flexible search mechanism where domain and community specific parameterized queries may be defined for metadata based searches     (2F3B6)
      • Supports flexible subscription and notification feature to keep interested parties notified of changes to artifacts     (2F3B7)
      • Supports automatic cataloging of published artifacts     (2F3B8)
      • Supports automatic rule-based validation of submitted artifacts     (2F3B9)
      • 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.     (2F3B10)
      • Maintains change history for all artifacts in repository     (2F3B11)
      • Supports a set of minimal authentication mechanisms (e.g. Basic, HTTPS mutual, OpenId)     (2F3B12)
      • Provide fine grained role-based access control and authorization over all actions     (2F3B13)
      • Support seamless search over multiple repositorys (local + community, local + community + root, other...)     (2F3B14)
      1. Need to support ontologies in at least OWL and Common Logic (CL).     (2F5A1)
    • 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.     (2F6A)
    1. Need to serve content reliably in an appropriate standard exchange     (2F7A)

form and using protocols associated with each content type.     (2F8)

    1. Need to provide persistent and available access to this content and associated metadata for multiple versions as the content evolves.     (2F9A)
    • 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.     (2F10A)
        1. Searching,     (2F12A1C)
        2. Governance,     (2F12A1D)
        3. Management of Ontologies.     (2F12A1E)
        1. Not all capabilities will be implemented at any single version.     (2F14A1A)
        2. The architecture will evolve. There will be multiple versions each successor implanting additional capabilities and/or evolving the previous version.     (2F14A1B)
        3. Instance data, which are themselves not ontologies, will not be stored in the repository     (2F14A1C)
        4. The repository will meet the needs of operational or commercial systems.     (2F14A1D)
        5. Applicable standards will be used.     (2F14A1E)
        1. The repository architecture shall be scalable     (2F16A1A)
        2. The repository shall be distributed.     (2F16A1B)
        3. The specification of the repository shall be sufficiently detailed and platform independent to allow multiple implementations.     (2F16A1C)
        4. The repository shall be capable of supporting ontologies in languages that have reasoners.     (2F16A1D)
        5. The repository architecture shall support distributed repositories.     (2F16A1E)
        6. The repository architecture shall not require a hierarchical structure.     (2F16A1F)
        1. The repository shall provide metadata capabilities to support     (2F18A1A)
          1. search capabilities,     (2F18A1A1)
          2. governance process,     (2F18A1A2)
          3. management     (2F18A1A3)
        2. The repository shall provide a content discovery mechanism that supports discovery by     (2F18A1B)
          1. author/creator/source     (2F18A1B2)
          2. terminology     (2F18A1B6)
        1. The repository shall provide a capability to     (2F20A1A)
          1. search locally     (2F20A1A1)
          2. search globally     (2F20A1A2)
        2. The repository shall provide a capability to browse a repository     (2F20A1B)
          1. globally (011)     (2F20A1B2)
        1. The repository shall provide the ability for a user to subscribe to/for alerts associated with one or more repository items.     (2F22A1A)
        2. The repository shall provide the ability for a user to subscribe to/for automatic updates of one or more repository items.     (2F22A1B)
        1. The repository shall provide a mechanism to enforce submission policies     (2F24A1A)
        2. The repository shall provide a mechanism to enforce governance policies     (2F24A1B)
        3. The repository shall provide a mechanism to enforce tracking policies     (2F24A1C)
        4. The repository shall provide a mechanism to create usage reports     (2F24A1D)
        5. The repository shall provide syntax validation mechanisms     (2F24A1E)
        6. The repository shall provide a logical consistency checking mechanism     (2F24A1F)
        7. The repository shall provide a mechanism to automatically categorize a submission     (2F24A1G)
        8. The repository shall provide a mechanism to maintain state change of repository items (i.e. versioning)     (2F24A1H)
        9. The repository shall provide user and administrator access control mechanisms     (2F24A1I)
        1. The repository shall provide explicit machine usable/accessible repository semantics     (2F26A1A)
        2. The repository shall provide a mechanism to avoid intellectual property and related legal issues/problems     (2F26A1B)


This page has been migrated from the OntologWiki - Click here for original page     (2F31)