OntologySummit2008 - Repository Architecture    (18T9)

(Keep checking back for updates! ...)    (18U6)

This page is a Summary Workspace for information relevant to Repository Architecture that moves us Toward an Open Ontology Repository.    (1A7X)

We include, but aren't limited to, discussion thread summaries, expansions on points of interest, discourse on related work and relevant references and links.    (1A81)

Table of Contents    (1A86)

Repository Architecture for Open Ontology Repositories    (1GA5)

(coming soon)    (1GA1)

(will be further filled in soon)    (1GA3)

11:00 Repository Architecure Session (1 hour)    (1GAW)

This 'part one' session shall comprise of a 10 minute summary, 20 minutes of topic area overviews and a 30 minute discussion period.    (1GAX)

* The summary will overview the discussions and background materials provided by the community.    (1GAY)

* The topic area overviews will succinctly cover specific areas of the intellectual space pertaining to Open Ontology Repository Architectures.    (1GAZ)

* The discussion will be focused around the topic areas presented.    (1GB0)

12:00 Lunch    (1GB1)

1:15 Repository Architecture Session (1 hour)    (1GB2)

This 'part two' session shall comprise of a short pre-lunch discussion recap, 10 to 15 minutes of relevant architecture presentations with a short period for questions, brief overview of discussion points with at least 30 minutes for discussion period.    (1GB3)

* The presentations will be 2-4 minute demonstrations and architecture mockups.    (1GB4)

* The discussion points will be focused around the architecture topics noted for the communique.    (1GB5)

1. Archival Approach    (1AID)

2. Federated versus Centralized Architecture Approach    (1AIF)

The OOR will support a federated architecture - Multiple OOR instances may belong to a federation - Membership of an OOR in a Federation is driven by shared interest - A federation typically maps to a community of interest which is often a vertically specialized domain (e.g. Healthcare, Ocean Science, Automotive, Telco etc.) - Multiple OOR instances may belong to a federation - Membership of an OOR in a Federation is driven by shared interest - A federation typically maps to a community of interest which is often a vertically specialized domain (e.g. Healthcare, Ocean Science, Automotive, Telco etc.) - During development Ontological content may be authored and stored in a local OOR instance - Finished Ontological content may be promoted / deployed to a shared community repo. This process should have human review and approval process    (1GEN)

- Changes to shared community repo are notified to interested subscribers (other authors)    (1GEO)

- Local repos may synchronize with community repo and community repo may synchronize with root repo periodically    (1GEP)

MatthewWest Responds to several points above: Re- Vertical domain: Well this is our first real requirement. We have communities of interest that might want to manage the development of an ontology for a domain. But why is it necessary that these should be implemented in a federated environment? Why is it impossible to implement this in a single repository that recognises separate ontologies under separate management? On Local Vs Distributed: I'm not quite sure if this is supposed to mean that in the federation there is some central repository, or whether it means that for each OOR in the federation it should be possible work on a local copy rather than on the central repository for that OOR. If you mean the latter, then this would certainly be useful, none of us are on-line all the time. However, most of the systems I know that work like this have significant performance problems because of the long locks that are required. Not to mention the problems that come from people effectively preventing write access to areas they are only reading rather than looking to make changes to. How would you intend to overcome this? Why does this have to be a separate OOR? Why could it not be an area of a single OOR? The processes required to support community approval of content are somewhat more complex than this. Again, this is all easier if you have a single repository in the first place. Governance is the main issue for a Community Ontology. The purpose of the OOR is to hold a variety of ontologies and support the governance processes for their content. I therefore suggest that if we really want to be requirements driven, then we should start to look at the governance of content (since an ontology meta-model is the subject of another theme), rather than starting with solutions dressed as requirements like a federated architecture    (1GEQ)

RaviSharma expressed:    (1GER)

This Is Open Ontology Repository Architecture Discussion.    (1GES)

What I understand from Word OPEN is that it is to be decided by this Community that:    (1GET)

OPEN implies: Open standards based Open access to all who can be identified or authenticated Open access to all members of community who want to post comments suggestions and opinion Open access to all trusted and authenticable communities (at least Read only)    (1GEU)

Federated Architectures Allow: Multiple authorized communities to access each other's content. Where Communities are closely aligned, cross populate or review content. Organizations that have legitimate authorized needs can extract and analyze content - an example in information architectures will be that State level Justice department wants access to their or neighboring States driver records or - that Homeland Security or red-cross needs access to normally private records in healthcare situations of disasters?    (1GEV)

3. Requirements of Repository (Some Examples - please see discussion threads for detailed flow of thoughts and inputs from Community)    (1EM5)

<noWiki>    (1G28)

Todd Schneider's requirements {nid 1EMD} (includes Summary of Discussion Threads and Presentations over last few months.) {nid 1EM6} Todd ======================================================================== Goals of the Open Ontology Repository    (1FW6)

  Provide an architecture and an infrastructure that supports the
   a) Storing,
   b) Sharing,
   c) Searching,
   d) Governance,
   e) Management of Ontologies.    (1FW7)

Requirements, High Level - Candidate 2    (1FW8)

Assumptions    (1FW9)

  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.    (1FWA)

General    (1FWB)

  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.    (1FWC)

Discovery    (1FWD)

  1. The repository shall provide metadata capabilities to support
    a. search capabilities,
    b. governance process,
    c. management    (1FWE)
  2. The repository shall provide a content discovery mechanism that supports
     discovery by
    a) domain
    b) author/creator/source
    c) version
    d) usage
    e) language
    f) terminology
    g) quality    (1FWF)

Search    (1FWG)

  1. The repository shall provide a capability to
    a. search locally
    b. search globally    (1FWH)
  2. The repository shall provide a capability to ‘browse’ a repository
    a. locally
    b. globally    (1FWI)
  3. The repository shall provide a mechanism to support semantic searches.    (1FWJ)

Subscription/Notification    (1FWK)

  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.    (1FWL)

Management    (1FWM)

  1. The repository shall provide a mechanism to enforce access policies
  2. The repository shall provide a mechanism to enforce submission policies
  3. The repository shall provide a mechanism to enforce governance policies
  4. The repository shall provide a mechanism to enforce ‘tracking’ policies
  5. The repository shall provide a mechanism to create usage reports
  6. The repository shall provide syntax validation mechanisms
  7. The repository shall provide a logical consistency checking mechanism
  8. The repository shall provide a mechanism to automatically categorize a
     submission
  9.The repository shall provide a mechanism to maintain state change of
    repository items (i.e. versioning)
  10. The repository shall provide user and administrator access control
      mechanisms    (1FWN)

Governance    (1FWO)

  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    (1FWP)

</noWiki>    (1G4L)

I haven't had the time to study the latest incarnation of the requirements, but some of the first posts included most of the ones I cared about:    (1G4P)

 - manage core metadata associated with the ontology (when stored, who provided, rights, previous version, size, ...)
 - list and find what ontologies are served (by name, content, or metadata)
 - list and find terms within those ontologies (by name, content, or metadata)
 - manage extended metadata associated with the ontology (who is using, expert and other commentary, update frequency, ...)    (1G4Q)

And of course, providing interfaces for others to manage their ontologies via my community service (rather than hosting their own repository software).    (1G4R)

These are the functions I hope OOR either *does* (writes software for), or points to reference applications and service providers *for* (where I can either host the software or utilize the services). Even if all OOR does is specify a nice list of capabilities and best practices, and how they should be provided (user interface specs), that would be a start. And the talks I've heard so far have been great for this purpose!    (1G4S)

LuisBermudez Response to Todd Schneider's requirements summary: One of the problems with not taking into account the repository model is that a registry, when asked for all the statements about a resource, will not be able to answer the complete set of statements (include infer ones) in a descend amount of time. For example:    (1GAQ)

1) I have an ontology A and an ontology B, that two organizations could submit ( let say registering a URL, that points to the OWL file) 2) There is a third ontology, ontology C, that declares relations between A and B. For example termA is a term of ontology A and termB is a term of ontology B. The statement in ontology C says termA subclassOf termB. 3) If I ask the registry about statements about termA, the registry should include the previous statement, and possibly any infer statements, as well. So, if the registry, every time is being queried, is going to reach all the URLs it knows, check if something about a resource has being declared, create a graph, infer statements and respond, then it is going to consume a lot of time.    (1GAR)

So there is a need to have a repository to cache the statements, the graph, the inference model, etc. Another benefit is: if on ontology is registered, but then the original location is not available ( e.g. site is down ) then the registry uses its repository version to access it.    (1GAS)

This is why the underlying data model of the registry is important. For example are we talking about an ontology being composed of triples, every time I register an ontology the triples are extracted and stored in the repository. Then the registry is able to respond fast to any query about the ontologies and the concepts contained, which I think is what I will use the registry for.    (1GAT)

-luis    (1GAU)

</noWiki> {nid 1G4T} Other reponses on Architecture and Todd's requirements Summary <noWiki>    (1GBK)

• John Sowa’s Comments: Todd and Denise,    (1GB9)

That is a serious issue:    (1GBA)

DB- We are using the term 'repository' but we mean essentially a registry not the storage of actual ontologies, correct?    (1GBB)

TS- I've heard both notions bandied about.    (1GBC)

Ideally, the developers of a resource should be the official maintainers of the resource. But many issues arise:    (1GBD)

  1. The developers may disappear, go out of business, die, or
     change their web site.    (1GBE)
  2. Different developers have different policies for retention,
     version control, backups, etc.  An application that has
     critical dependencies on version 2.7 of ontology X should
     not be disrupted if the developer suddenly upgrades to
     v 2.8, drops support for 2.7, or just makes it unavailable.
     (I'm sure that we have all seen things like that happen
     with software from major vendors.)    (1GBF)
  3. The OOR should maintain all comments, reviews, validations,
     etc., both positive and negative.  The developers of a
     resource might be tempted to "accentuate the positive
     and eliminate the negative."  Therefore, they should not
     have the right to delete or modify any reviews.  On the
     other hand, some reviewers might be uninformed or hostile.
     So some responsible party should have the right to review
     the reviewers and adjudicate any disputes.    (1GBG)

John Sowa    (1GBH)

Todd Schneider’s Requirements Summary • DeniseBedford’s response Denise's comments -- I've heard both notions bandied about. Operationally, I think [an] OORx will have both types of entities. Some organizations will want to have or provide persistence while others may only wish to host a registry. This is an architectural decision that will need to be made. In my mind I think the functionality among a registry and a repository can be partitioned in such a way that will allow plug-n-play deployment and operation. Thanks for the reply. In one of the panel sessions there was a discussion about the different set of requirements for actually storing versus describing ontologies. At least two of the speakers agreed that two distinct data models underlie storing an ontology and describing an ontology. The overlap between thosee data models -- from my experience working with and describing ontologies each day -- will be quite minimal. So, in our requirements for an OOR, are we targeting the set that is common to both a repository and a registry? • Evan Wallace response EKW - A minimal repository could have a very simple datamodel which treats ontology files as blobs. Whereas a registry is going to require a richer datamodel if it is to usefully support things like discovery and metadata tagged to model elements. One question I have is how we are going to handle the different types of elements from different types of ontology languages in one registry.    (1GBI)

</noWiki>    (1GBJ)

For Open Ontology Repository Architecture (OOR), relating to Ontology Summit 2008.    (1G9J)

What are the minimum metadata fields that would be -    (1G9K)

1. Required 2. Desired 3. Nice to have    (1G9L)

- to capture the essential attributes or metamodel - definition of a general ontology.    (1G9M)

A straw man could be started by those in the Ontology areas, e.g. 1. Language, 2. Relationships - type (meaning), Directionality (from - to), and Symmetric or Asymmetric... 3. Information (or data) storage capacity or extensibility for expansion... Etc.    (1G9N)

Your opinions and threads will help capture essentials relating to repository architecture.    (1G9O)

Thanks.    (1G9P)

Ravi    (1G9Q)

(Dr. Ravi Sharma) Co-Champion, OOR Architecture, Ontology Summit 2008    (1G9R)

________________________    (1G9S)

Affiliation:    (1G9T)

Senior Enterprise Architect    (1G9U)

Vangent, Inc. Technology Excellence Center (TEC)    (1G9V)

8618 Westwood Center Drive, Suite 310, Vienna VA 22182 (o) 703-827-0638, (c) 313-204-1740 www.vangent.com PS Professional Views experessed here are not necessarily endorsed by Organization </noWiki>    (1G9W)

I'm not sure how this "[ontology-summit][Repository-Arch] Minimum required metadata for OOR" thread on the ontology-summit forum is meant to interact with the OOR-Forum, so I will post this message to both. I was planning to post a message like the following to the OOR-Forum only until I saw this thread on ontology-summit. Sorry to those of you who get this message twice.    (1G91)

I think that there is some good input available for the subject of this thread. A lot of time has been spent thinking about and modeling required metadata for "metadata registries" by participants of the eXtended Metadata Registry (XMDR) project and related efforts in ISO/IEC JTC 1/SC 32/WG 2 (and INCITS L8 in the US). In development work for ISO/IEC 11179 Edition 3, we are extending metadata registries--previously focused on data elements & classification systems--to improve registration of concept systems (thesauri, taxonomies, ontologies, etc). There is particular attention on how semantics in concept systems relate to semantics in metadata and to semantics in data. The XMDR project also developed a modular architecture for the XMDR prototype metadata registry (prototype of ISO/IEC 11179 Edition 3). The work should at least be useful to this effort. Here are some links:    (1G92)

Architecture:    (1G93)

Here is a link to a software architecture page for the XMDR prototype. It was written quite some time ago, but has stood up pretty well: http://www.xmdr.org/arch.html    (1G94)

I have attached an updated version of the architecture. It is a slide from a presentation that I recently presented during an OOR panel discussion. Note that there are many possible software selections for each module in the architecture; some of these are named on the web site. In the XMDR prototype, we used all open source software, but commercial software could be substituted for reasons of functionality or performance.    (1G95)

Metadata for OOR:    (1G96)

I think that much of the minimum metadata for an OOR has been identified. Here are the latest UML figures proposed for the Edition 3 of ISO/IEC 11179. These are the result of some mixture of proposals from XMDR and comments made by SC 32/WG 2 (including INCITS L8) participants.    (1G97)

https://xmdr.lbl.gov/mediawiki/index.php/Latest_Diagrams    (1G98)

Diagrams of particular interest, might be: 1 Package Dependencies -- shows the major metadata modules 3.2 Registration metamodel region 3.3 Concept System metamodel region 3.4 Designation and Definition metamodel region 3.6 Ontology metamodel region 3.10 Classification metamodel region 3.12 Relations metamodel region    (1G99)

Work is currently underway to consolidate four of the figures: Classification, Concept System, Ontology, and Relations. Hopefully, this will make a good overview (if not replacement of) the four figures, which are a bit difficult.    (1G9A)

The above figures are still being discussed and refined. Several of the other figures on the "Latest Diagrams" page are more stable, some mostly derived from Edition 2 of 11179.    (1G9B)

Text for the figures is under development. A version of the text is available in the document for Committee Draft 1 of ISO/IEC 11179 Part 3 (Edition 3), which was balloted in the fall of 2007. A few hundred comments were received on that ballot and a lot of editing is being done. To get a look at an old version of the text, see: https://xmdr.lbl.gov/mediawiki/images/6/6f/32N1667-CD1-11179-3_3rd-ed_2007-0 8-15.doc    (1G9C)

Note that for development of the XMDR prototype, the UML model figures (ISO/IEC 11179-3 (E3)) were translated into an ontology as the basis for implementation. I hope that the figures on the "Latest Figures" page will be translated into a new version of the ontology.    (1G9D)

I think that the above gives more than the "minimum" required metadata. The minimum might be approximated by leaving out some of what is specified in the UML model. The figures may lack some metadata that we would like for the OOR, so we may need to add something. However, I think the above are useful input to the discussion.    (1G9E)

Bruce Bargmeyer    (1G9F)

----Sent by-------------------------- Bruce Bargmeyer University of California, Berkeley and Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS 50B-3238 Berkeley, California 94720 Tel: +1 510-495-2905 Fax: +1 510-486-4004 email: bebargmeyer@lbl.gov    (1G9G)

</noWiki>    (1G9H)

<noWiki> Response from Matthew West - please also refer to the document Meta-Model.rft in EXPRESS.    (1GA9)

To capture the essential attributes or metamodel - definition of a {nid 1GAA} general ontology.    (1GAB)

MW: Hmmm. Well it seems to me you first need a data model of the elements of an ontology, before you start talking about the attributes of those elements.    (1GAC)

MW: OK. I'll start the ball rolling. Attached is an incomplete draft data model written in EXPRESS (ISO 10303-11) which desribes many of the objects that are needed to create an ontology.    (1GAD)

Response from RexBrooks: Thanks Matthew,    (1GAH)

The work itself is valuable, and provides much material to discuss, but it poses two immediate questions that open up other threads:    (1GAI)

1. What are the MetaModel Description Languages appropriate to our tasks, and which should we use for which tasks? (corollary: Do we have the time to wrestle with the issues of representations versus descriptions of metadata attributes/properties?); and 2. Is this thread aiming for the compilation of a list of properly qualified attributes or a more general set of prioritized attributes/properties?    (1GAJ)

Please note that this is a request for a clarification of what this thread is addressing, not the relative values of the two questions that fall out of this first stake in the sand of this thread. This is not a comment on the EXPRESS document itself, which will take more time to digest than this response could include.    (1GAK)

Cheers, Rex    (1GAL)

</noWiki>    (1GAE)

Comment by RaviSharma {nid 196G} I like what I see proposed by FarrukhNajmi. T Federated can also imply peer or equal access authority - peer type of organizations sharing access to the repository. Distributed repository example can be more general if FarrukhNajmi could kindly modify the diagram (visual) to include at least one place where the author can write to more than one local repository - this would imply distributed repository for a given ontology and not necessarily all local only, some could be remote. T {nid 196H} Could we get more visuals for conceptual architectures that are implementation oriented with known IT elements and also showing Gaps that exist for repository architecture to be completed, at least for simply authenticated open repositories? T {nid 1932} Comment from RexBrooks {nid 1A7W} I also think Farrukh's Candidate Architecture is excellent.    (1A84)

hmmm something got messed up here... will need to check what should be a "link" and which is the true purple number.    (1GA7)

(- not complete -- more to come)    (1GA8)

1. Overview of Ontology Servers Research: Ahmad, Mohammad Nazir, & Colomb, Robert M. (2007). "Overview of Ontology Servers Research." Webology, 4(2), Article 43. Available at: http://www.webology.ir/2007/v4n2/a43.html    (1GAV)

2. Ontology Repository (TONES), Ontology Browser and OWL Syntax Converter at Manchester School of Computer Science http://owl.cs.manchester.ac.uk/ (currently has a registry of 112 ontologies, use the URI to access the actual OWL XML files)    (1GB7)

<nowiki>    (1GBS)

3. Quality-oriented software architecture development http://www.vtt.fi/inf/pdf/publications/2007/P636.pdf Evesti, Antti, 2007. VTT, Espoo. 79 p., VTT Publications : 636, Thesis: diploma thesis Keywords: quality-oriented software architecture, software development, quality requirements, ontologies, quality meta-data management, quality modelling, quality evaluation, Unified Modeling Language (Useful with Architecture examples, Eclipse Development, UML, XML, OWL and Ontology)    (1GBT)

4. Peter Haase, OMV Ontology Metadata Vocabulary, April 10, 2008    (1GBU)

5. eXtended Metadata Registry (XMDR): Input for Open Ontology Repository OOR Panel - “Ontology Registry and Repository Technology & Infrastructure Landscape” February 28, 2008 Bruce Bargmeyer Lawrence Berkeley National Laboratory and University of California, Berkeley bebargmeyer@lbl.gov http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2008_02_28    (1GBV)

6. Lifecycle-Support in Architectures for Ontology-Based Information Systems, Thanh Tran and Peter Haase and Holger Lewen and Óscar Muñoz-García and Asunción Gómez-Pérez and Rudi Studer http://www.springerlink.com/content/c8p2722511625788/    (1GBW)

7. Designing a Semantic Repository Integrating architectures for reuse and integration Cory Casanave Cory-c (at) modeldriven.org ModelDriven.org May 2007. Overview: The Semantic Metadata infrastructure will provide a “smart” repository for architectures at multiple levels of abstraction, from multiple sources and with multiple views. This infrastructure will integrate the OMG-Meta Object Facility (MOF) and Resource Description Framework (RDF) and RDF-Schema as defined by W3C as part of the “Semantic Web” initiative and will integrate the specification and provisioning concepts of the OMG Model Driven Architecture (MDA). The semantic repository is an open source project at modeldriven.org. www.w3.org/2007/06/eGov-dc/papers/SemanticRepository.pdf    (1GBX)

8. http://www.semanticweb.org/wiki/KWTR:_Ontology_repositories    (1GBY)

9. Distributed Repositories of Highly Expressive Reusable Ontologies Source IEEE Intelligent Systems archive Volume 14 , Issue 2 (March 1999) Pages: 73 - 79 ISSN:1541-1672 Authors Richard Fikes Adam Farquhar http://portal.acm.org/citation.cfm?id=631319 also http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/ex/&toc=comp/mags/ex/1999/02/x2toc.xml&DOI=10.1109/5254.757634    (1GBZ)

10. Ontology Access in Grids with WS-DAIOnt. and the RDF(S) Realization. Miguel Esteban Gutiérrez, Asunción Gómez-Pérez, Oscar Muñoz García, Boris Villazón www.semanticgrid.org/OGF/ggf16/papers/GGF-v10_asun_.pdf    (1GC2)

11. NCBO - MarkMusen et. al. (Also Sponsors of Ontology Summit 2008) National Center for Biomedical Ontology BioPortal. BioPortal provides access to the Open Biomedical Ontologies repository a library of publicly accessible biomedical ontologies. Total Number of Ontologies 72 - NCBO Library 59 - Remote 13 - Number of Classes/Types 300109* (*ontologies that have been parsed and indexed) http://alpha.bioontology.org/ontologies also http://alpha.bioontology.org    (1GC3)

12. WSMX – An Architecture for Semantic Web Service Discovery, Mediation and. Invocation. Matthew Moran, Adrian Mocan. Digital Enterprise Research Institute http://iswc2004.semanticweb.org/posters/PID-SUWKWXSK-1090263770.pdf    (1GC4)

13. In: M. Hepp, K. Hinkelmann, D. Karagiannis, R. Klein, N. Stojanovic (eds.): Semantic Business Process and Product Lifecycle Management. Proceedings of the Workshop SBPM 2007, Innsbruck, April 7, 2007, CEUR Workshop Proceedings, ISSN 1613-0073, online CEUR-WS.org/Vol-251/    (1GC5)

14. Service-Oriented Architectures ISO 11179 Versus Ontologies 02/12/2006 By Dr. Chris Harding, The Open Group http://www.opengroup.org/    (1GC6)

15. Julie Allinson, Jessie Hey, Chris Awre and Mahendra Mahey report on the Open Repositories 2007 conference, held in San Antonio Texas over 23-26 January. http://www.ariadne.ac.uk/issue51/    (1GC7)

16. http://www.springerlink.com/content/tr7816141645/?p=4fdb2d3a73164b0daa975b45ec355501&pi=0An Advanced Semantic Search and Browse Facility, Alistair Duke, Tim Glover and John Davies http://www.springerlink.com/content/tr7816141645/?p=4fdb2d3a73164b0daa975b45ec355501&pi=0    (1GC8)

17. An Open Ontology Repository: Rationale, Expectations & Requirements Session 1, Joint OOR-Ontology Summit 2008 Panel Discussion March 27, 2008, Leo Obrst MITRE, Fabian Neuhaus NIST (on this Wiki under Summit Pages links). Similarly Series of Presentations and panel Discussion and Threads on Repository Architecture are found on this Wiki.    (1GC9)

18. Example of OOR Architecture, by RaviSharma - Slide format - particularly note the Architectural drawing.    (1GCF)

19. OntoSelect Ontology Library OntoSelect monitors the web to provide an access point for ontologies on any possible topic or domain that is automatically updated, organized in a meaningful way and with support for ontology search and selection. Selected ontologies may be used for instance in: knowledge markup for Semantic Web applications, semantic tagging for Natural Language Processing systems, ontology search ... which ontology fits best to this topic? multilingual labels ... are there ontologies with class/property labels in languages other than English? top labels ... Paul Buitelaar, et.al. http://olp.dfki.de/ontoselect/    (1GCH)

OOR Use Cases    (1GST)

What follows is an initial list of use cases (sans details) grouped by stakeholder type.    (1GSU)

Ontolgy User:    (1GSV)

 Name: Find Ontology
 Name: Browse Ontology
 Name: Add Comment/Uncontrolled Review
 Name: Add Change Request    (1GSW)

Ontology Designer:    (1GSX)

 Name: Upload Ontology
 Name: Update Ontology
 Name: Create Mapping among existing ontologies    (1GSY)

Agents:    (1GSZ)

</nowiki>    (1GC0)

This page is maintained by: MichelleRaymond and RaviSharma    (1GCG)

    (1G4M)