First Agricultural Ontology Service (AOS) Project Workshop
FAO Headquarters, Rome, Italy Note: Duplications of comments and questions are included. It was felt that it would be more comprehensive and enlightening if all comments received were organized, rather than a selective few. Comments are organized within sub-sections from first received to last received.
Contents
* A quite ambitious endeavour, but with fascinating possibilities, and definitely a lot of impact given the standing of the FAO as the central body (which is crucial for the success of this kind of project).
* I have just read your project proposal with great interest. I AM impressed. The goal is formidable, but the work to be done even more formidable.
* The project appears interesting and potentially valuable.
* A lot of flexibility should be foreseen if one wants to see this AOS proposal as an attractive initiative.
* The work described in this proposal is definitely needed, mainly to enlist the aid of hundreds (and perhaps thousands) of individuals world-wide whose collective effort would be needed to manually construct such an ontology. Automation should be applied where possible of course.
* It is a very well thought out plan and approach involving inter-agency collaboration.
* Similar attempts at building ontologies for specific disciplines have been made with mixed results. The EI Thesaurus evolved into a mega-thesaurus, the use of which it was hoped would be used by all in building disciplinary mini-thesauruses. This eventually failed partly due to lack of thesaurus maintenance and lack of funding. The ERIC education thesaurus was built in a similar way, working with various existing sources. This thesaurus was also overburdened with unresolved relationships and had to be totally revised after several years of use. The API multidiscipline thesaurus was built using the natural text of thousands of words in the text of hundreds of abstracts. Most importantly, revisions to the thesaurus are relatively simple because an accompanying non-disciplinary classification system based on faceting is used to maintain the thesaurus.
* What kind of project should it be? RTD, demonstration, combined? Developing new artefacts (RTD) or just testing viability of existing technologies (demonstration project)?
* What change you want to make in comparison with status quo? It is important to say something about innovation in terms of products, services, quality, access, costs, ... (what will be better in comparison with state-of-the-art?). Innovation can be in respect of integration of KOSs, interoperability, multilinguality, use of NLP (natural language processing) techniques, automatic indexing ...
* What is the functionality of the intended result? What is delivered? What are target users of the result? What effects should be realized with the result?
* Better access to resources (Better compared to what? Quantify 'better'? Criteria?)
* What is the problem to be solved? Which aspects of the state of the art are to be improved?
* Criteria for project success?
* Needs clarification on methodology and project process.
* Does the scope of the AOS go so far as creating and amassing the different ontologies or beyond that, in creating a database with materials in five different languages?
* Will the new AOS render obsolete existing materials and apply only to material developed with the AOS ontology in mind? Is there a need to preserve and extend the existing materials? Background to this question: Semantic Web proponents will render obsolete all existing web content, since they require RDF descriptions for each web resource that is a member of their universe. This poses a barrier to commercial acceptance of RDF.
* Most information providers will want to incorporate the ontology into their service so users don't have to go one place to refine their search before issuing the search at another place. If the only access FAO provides is a closed-box online service, information providers will turn elsewhere for a thesaurus/ontology.
* The UMLS is an example of what I hope FAO does NOT build. If FAO does take on building such a system, then I hope you make the ontology itself, and associated software toolkits, available to all.
* I think it is conceivable to run this project as a series of pilot projects, provided strong interest is stated by the parties to the pilot projects. I would see the overall AOS project has a general guiding framework, initially at theoretical and strategical level, then as a way to share and learn from experience once the various pilot projects have started, playing a federating type of role, identifying needs and issues and providing advice, finally refining tool requirements, analysis and coordinating/managing its development.
* The AOS will be primarily dependant on partners' constraints and opportunities, establishing relationships within and between thesauri will be implemented in various ways, and with resources that will be identified on a case-by-case basis.
* Another goal would be to ultimately support natural language processing. Machine translation of text among different languages is an obvious use of AOS. This would probably require a richer representation (including phrase patterns associated with lexical entries, for example) than is being considered, and is probably outside the immediate goals of AOS. But again it is difficult to separate since a richer database supporting NLP is a natural extension of AOS.
* The best way to approach the problem is to start off with a "seed" vocabulary or ontology which all the organizations participating in the project agree on. After user testing and validation, it should be enhanced incrementally.
* In addition to KOSs, information sources being used by various organizations such as databases (probably stored in Oracle, etc.), document databases should also been analyzed. Important information can be gleaned from the schemas of the underlying databases.
* Collections of queries issued to various search applications should be analyzed to determine the scope, granularity and perspectives on which the core and other ontologies need to be based.
* Will it be a centralised/distributed/ ... system? What is the "business model"?
* Who is financing this project?
* Full partners should be global information system initiatives, and peripheral partners the regional systems embarked in the global initiatives. Full partners will collect and synthetise needs, and generally play an interface role between the AOS framework and the peripheral partners, on their field of speciality. Who will effectively establish the relationships is to be decided between the global initiatives and the partners.
* A strategy of respecting some central decisions and constructs should be agreed on between all partners. To my understanding we should agree on a top-level ontology and on some steering committee.
* European dimension: creation of synergy, complementarity of skills/roles of project partners, European standards, ... Relevance for EU enlargement: will it help NAS (New Associate Countries) to become familiar with EU legislation, standards, good practices, ...
* Inventorying partners is important. Increases chances to get funding!
* A few words about "ethics" would be good.
* In which IST projects call are you planning to submit the project proposal?
* The proposal vaguely indicates that you will look at and incorporate existing vocabularies and seek participation from other organizations. A definite list of at least several existing vocabularies (e.g., classification schemas or thesauri) and organizations (e.g., government agencies) that could participate in the development of the FAO ontology would strengthen this proposal because it would give readers an idea of who should be involved.
System/Business Plan
* To encourage the researchers, cataloguers and others at the local level to use the tool we see it as very important to have a common plan for marketing.
* What is the timetable for the this project-when will it up and ready to go?
* Looking at the project phases and timeline, I noticed you did not include any "marketing" of the AOS after the building phase. I thought that it would be perhaps useful at the end of the building phase and after the tests have proven positive to make AOS known to the worldwide agricultural information community who has not participated in the project.
* In general, your approach seems correct to me. Some of the issues are really big, so you better have a clear strategy to stay at a tight selection of some feasible steps.
* The time-frame is not too large, and both consensus building in a heterogeneous user group and identification of the foundational concepts for ontology harmonization is extremely time consuming.
* I cannot over-emphasize the maintenance issue. Have you budgeted for it? It can be very expensive.
* An incremental approach with well defined intermediate stages would be sensible.
* I was VERY impressed by the time allotment for project completion, especially given that most proposals of this nature *under-estimate* the time required. The construction of a "very detailed" ontology, covering all of FAO's subject domains and linking them on a very specified level, will be a long-term project, taking place over a series of years.
* FAO needs to consider access to and publication of the ontology, e.g., "Will the ontology be freely accessible (e.g., over the Internet) or available for a fee?" Publication options could include the Internet, print, and CD-ROM (only worthwhile if the ontology is extensive). The benefits of making the ontology freely accessible or available for a small fee (e.g., "interoperability" and "greater use") will most likely outweigh small financial gains made if the ontology is only accessible at a high cost.
* It is never too premature to think about the longevity and maintenance for an ontology. The proposal will be stronger if this information is included.
* Who decides on project, funding, partners? Who (person) is principal client? Project leader?
KOSs and the AOS
* Will there be central updating of new terms at FAO?
* The report often refers to the case of "overlapping" ontologies that are to be integrated. It seems to me that in the report the problem of integrating ontologies is overlooked. This is a very complex problem, requiring sophisticated techniques. In particular, I found no mention in the report of the problem of discovering and representing overlapping properties in different ontologies.
* There are many local databases using AGROVOC terms-will it be possible to integrate the AOS in these systems?
* I did not see any reference to the problem of mutually incoherent ontologies. Do you know in advance that the local ontologies are coherent? If not, did you think about this problem? Are local ontologies autonomous? Can they evolve independently from each other? If yes, the problem of inconsistency is even more severe.
* We approached the problem of loosely integrating thesauri in LAURIN and one of the key issues was the management of the updates. It seems to me that the problem of propagation / reconciliation of updates is not discussed in the report, but it should be considered.
* How will you manage the changes of the ontologies hosted by AOS? Some policy should already have been made or considered for the changes because it will happen anyway. But currently there is no concrete solution exising in the ontology research area. Some of the works done by my colleague Michel Klein are worthwhile to try. Adopting the policy of SHOE is also a good idea.
* The issue of versioning would have to be addressed since some of the software packages using the AOS might refer to an older definition of a term.
* If terminology under continuous development is going to be integrated in a central ontology, a strategy of versioning and incremental update from the provider side must be agreed on. Systems sharing can be a nightmare. One machine-readable and human-readable form of complete contents and of incremental update definitions is the best base for integration. The rest is helpful on the level of experience exchange.
* Integration, redeveloping, growing KOSs into ontologies is risk-prone, and in the width stated here it goes far beyond the framework of one project. The better the functional purposes of the various resources for integration fit, the more we can expect any success. To all our knowledge, merging or matching complexity increases with the resource size, in particular foundational questions and issues of overall structuring become very difficult. To find a "golden way" of pragmatics, effectiveness and efficiency needs experience, a clear definition of intended functionality and clear methodological principles.
* Better not try to integrate everything. This may require enormous resources. The selection of what is worth-while and feasible to be integrated seems to be important for the project.
* I regard the question of semantic compatibility between integrated efforts as mission-critical. Only a clear hierarchy and migration strategy between levels of sophistication allows one to experiment with more advanced relationships within one integrated project.
* You may wish to apply API's model for maintaining the thesaurus and operating in conjunction with KOSs and others. API was responsible for maintaining the integrity of the structure of the thesaurus. API's lexicographer would meet with petroleum information users (in your case KOS personnel) whose responsibility would be to make sure the AOS fully understood the meaning of new keywords being proposed.
* There are potentially unresolved issues involved with multi-lingual thesauri and thesaurus mapping - there is often not a 1-1 correspondence between terms and the precise nature of the multi-lingual support needs to be identified.
* Which are the knowledge representation ambitions? In the project proposal, current system KOSs are taken as standard. Structured and leveled ontologies, aiming at conceptual leveling, ontology mapping and ... seem not to be included in the project aim. Especially when multilingual access is offered, the pure syntactic level seems inappropriate to offer full coverage of knowledge.
Domains and Sub-Domains
* In your choice of KOSs do not concentrate only on these in agriculture and fishery field, do not forget about the relevant fragments (parts) of the general systems (at least from the structural point of view).
* I think also that certainly it is very good for the project if organisations like CAB or the NAL are interested; nevertheless it will also be very beneficial to have numerous partners who have developed specialised KOS in sub-domains of agriculture (like the fishery one you mention) as it will help the AOS in growing and becoming more complete and more precise.
* I think it's also necessary to recall another GIL Project's initiative falling within exactly the same area entitled "Development of an Enhanced Online Multilingual Fishery Thesaurus", where various fishery information system parties have already mentioned their particular interest in developing fishery related ontologies. I have been exposed to discussing interoperability between FIGIS and 3 new partner-systems (regional information systems in marine fisheries, in aquaculture, and in fish utilisation and industry) and one of the main conclusion for doing so is always the same: letting the thesauri develop independently for their own purpose, and establishing relationships between thesauri, and mechanisms to maintain these relationships.
* The more detail that is desired, the more complex becomes the task of constructing the ontology, and more expert skill and time required. A more general ontology will take less time to construct and can provide an "umbrella" leading to more domain-specific thesauri, taxonomies, keywords lists, and other tools.
* Which domains are to be covered? What is the domain of interest of the AOS? In AGROVOC, the system boundary is not very clear. Some aspects of the agricultural domain seem to be included, some others are not. How is this defined in AOS?
Elements of the AOS
* From the veterinary point of view the AOS should also include veterinary medicine terms which are not so well covered in AGROVOC.
* One of the central notions in the report is the one of "resource." What is exactly a resource? Do you have a method for "describing" resources? Do you have a method for specifying what's in a resource with respect to the integrated ontology?
* You mentioned that the taxonomy of AOS should be controlled vocabulary. I disagree with it. Controlled vocabulary is a failed strategy in Information Retrieval area. In the very early stage of Library and Information Science, controlled vocabulary is adopted to catalog library materials but it leads to many unsolvable or un-controllable problems. Because you will never assume that the vocabulary from the users will be controlled. Besides, there is no intermediary (normally librarian) available from the web. So now in IR area, free-text or full-text searching are replacing the old controlled vocabulary ideas. To increase the search varieties is one of the most essential parts for the successful IR system. My idea is that you can use the controlled vocabulary to model or build up your ontology, but you also have to allow the difference (synonym, similar terms, or related terms) to link to the concept of your ontology. Search variety should be guaranteed. [Note: The AOS would include all possible variant terms and relationships.]
* The ontology should be simple and layered. Please don't have so many relations and complicated class and subclass relations. Especially the ontology hosted by AOS belongs to the upper-level ontology, so it should be as simple as possible.
* I have some doubts when you write about "extending set of relationships", "formalising rules for their development", "formally defined ontological relationships", etc. Not too much formalization? Remember that the user must have the impression that the end product is something that he/she already knows (at least from his native language or from general knowledge).
* My main concern with the establishment of relationships is to decide on the scope of the relationships that we are going to create (and maintain ...). In priority order, our needs are: 1) to establish hierarchical relationships within thesauri 2) to establish equivalences within and between thesauri.
* With respect to associative relationships, we must be very prudent, as this may never reach an end. To me, this can hardly be centrally driven. The generation of associative relationships will be decided by the partners according to their needs.
* Probably the direction for extensions is not to focus on adding more named relationships (type of plant, cultivar, location, ...) as suggested in the proposal. Such terms should actually be part of the ontology, and there would be thousands of them. Also, that approach confuses terms occurring in the ontology with languages primitives used to define the ontology. A better direction is towards a richer set of language primitives (beyond BT/NT/RT/UF). These might include class/instance, part/whole, properties, association, inverse relations, attribute values such as int, float, string, dollar, or defined types, or sets/sequences/ranges, cardinality constraints, attribute restrictions, or a range of such elements.
* We are very interested in "description logics", developed in the 1980s as an approach to semantic networks, and which are now beginning to reappear in XML-based ontology modeling languages such as OIL/DAML. Description logics contain a well-defined set of language primitives (such as listed above), with special sensitivity to their computational properties. It is also possible to have languages in which certain primitives may be switched on or off as needed for various purposes.
* We are using description logic languages as a basis for building databases (with agriculture as our application domain). We utilize new object database management systems as a platform. In such an environment, thesaurus, ontology, knowledge representation, and databases are all tightly integrated. There is no big distinction between data and meta-data since all data are represented in the system. Fine-grained, detailed concept descriptions can be built using description logics. For example, a phrase such as "photo of leafminer larva feeding on celery leaf" can be represented as an instance in such a language. Such detail ultimately leads to very precise information retrieval.
* Pre-coordination is a dead end, post-coordination needs elaborate rules. The question is very complex, and the purpose of the terms plays a strong role. Subject terms behave differently than classification of real world facts. Researchers ask not for things like "plant production" but for propositions: "What is the effect of fertilizers on insect attack?" A good analysis can tremendously improve effectiveness, a quick one may be a complete waste of time.
* As far as relationships between ontological terms are concerned, it may be a good idea to start off with simple relationships such as synonymy, hyponymy and hypernymy and then enhance the effort to include more sophisticated relationships.
* It might be useful to represent term definition (based on other terms) in a formal manner. This might help discovery of overlaps across vocabularies and enable automatic integration of the vocabularies.
* The interdisciplinary problem in building a thesaurus can be overcome by building a faceted classification of the keywords to accompany the thesaurus.
* Scope notes, of course, will help to disambiguate keywords where necessary, but must not be overused. The thesaurus must not turn into a dictionary.
* Specify the resources. Of different types, in different formats, ... Web sites, Word documents, guides, good practices, ...
* My background lies in KOS (as a computer scientist) and from this perspective I consider the linkage of KOS with Topic Maps as probably inappropriate and potentially leading to confusion. Simply labelling a (Topic Map) relationship type between an information item and an indexing term does not constitute a formal ontology or an enhanced thesaurus in my opinion.
* The UMLS metathesaurus type approach and its semantic network may offer an alternative route towards higher level relationships connecting thesaural elements should such be needed. Having said this, on reading the proposal and the accompanying examples, it is not clear to me that AOS requirements necessarily call for an extended set of *relationships*, as opposed to an extended set of KOS vocabularies - to take in, for example, product uses - (or extending the different facets/hierarchies of existing vocabularies) using conventional relationships. While there is current interest in augmenting the core set of internal thesaurus relationships, I would argue that it should be via a limited hierarchical specialisation.
* From my perspective, an information item (resource) might be indexed by several terms which could belong to quite different facets or hierarchies. A controlled vocabulary term would be associated with an underlying concept in a KOS (thesaurus), where the concepts exists in a network of semantic relationships which give a broader context for each concept (and associated terms) and allow the potential of matching or making some form of equivalence between semantically close terms. A KOS might have several facets or hierarchies. Thus different facets in the KOS could represent Product Type and Product Use (taking an example given in the proposal) and these could be used to limit searches. Other facet categories might represent Agents, Materials, Products, Processes, Location, Time, etc. Multiple index terms could be applied to information items (resources), including vegetable type and infecting agents. For example, the different types of infecting agent (say) could exist in a network of semantic KOS relationships, including hierarchical relationships. Thus a query on tomatoes combined with (broader term) infecting agent could (if desired) retrieve all sub-types of infecting agent. I would argue this is a more powerful approach than what appears to be intended as a scalar unorganised list of relationships. In a facet of a KOS such terms could exist in a hierarchy where this relationship could be expressed via standard BT/NT type relationships.
* It might be good to include a "statement" of the types of information resources (e.g., Web resources, monographs, journals, etc.) and information systems (e.g., databases) to which the ontology can be applied.
* Access to resources? What are resources? Resources (Documents, Databases, Models, ...)
* If there is to be a single high-level ontology, what happens when changes are made? There might need to be detailed guidelines for further additions/deletions/alterations to terms existing in the AOS. I say this because of two reasons: 1. If the ontologies in other four languages are translations from English, then the issue of versioning will arise and 2. there can be problems when a new term is added to the translated ontology, for ex. how can a term added to the Chinese version be added to the high level ontology written in English or ontologies in other languages.
* Another area we'd like to explore is how we might use ontology-like techniques to assist with multilingual support. It's been suggested by a faculty member here that if someone for whom English is a second language could just enter their search terms in their native tongue, they could most likely deal with having the results returned in English -- it's easier to read (react to) a second language than to speak (pro-act to) it. Could we support multi-lingual searching if we just had a translation of all thesauri terms?
* Multilinguality and federation of resources can be seen as the same problem. Concepts differ from thesaurus to thesaurus, as they do from language to language. A sound system of equivalence establishment is needed. There are good and bad prototypes for that. It is in general not difficult, but a bit more complex than often expected. Global consistency control algorithms can be helpful. I heard that a well-known meta-thesaurus contains "BT cycles", a situation which limits term expansion in query and retrieval, and indicates misunderstandings in the meaning of terms.
* How about adding new languages?
Standards
* The ontology representation languages mentioned in your proposal are XML and RDF. There is an important one missing: DAML+OIL. Actually it is the currently widely adopted ontology representation language providing some enriched functions and also compatible with RDF and RDFs. For ontology language, there are two policies: select one single ontology language and force your partner to stick to it or support ontology language translation. This is going to be a tough task. (example: Ontolingua)
* Currently a lot of discussion has been taking place on the DC Registry list to tackle the problem of character encoding. I am assuming a lot of effort will be needed for tackling this issue as well.
* I think this should be one of the first things tackled by the project team as the answer is tied up in exactly what functionality the resulting service (software toolkit??) will offer.
* I propose: RDF for contents, eventually TNM for packaging update increments (the increment problem lies in the identification of referred, defined and deleted concepts). XML is document biased and inappropriate to transport ontologies, except if it simulates an RDF-like structure (as e.g., in cidoc.ics.forth.gr/data_transformations.html). A standard format is much needed world-wide, and the project could help with that.
* I am not an expert in the RDF but it might also be desirable to have intermediate stages before proceeding to full RDF representation if that is the direction
* The proposal might include a brief statement about the use of AOS with metadata and it might even endorse the Dublin Core for web resources, or additional metadata standards.
Tool Development and Testing
* The requirements from a technology perspective would be a: scalable architecture/solution, ability to collaborate in order to build ontologies, mapping from existing ontologies or knowledge systems to the AGROVOC ontology, internationalization or ability to store ontologies in multiple languages and verification.
* Is the AOS going to be on the Internet or in some Intranet? How does that affect the choice of tools?
* Possible tools: Ontoweb (www.ontoweb.org) has a SIG for ontology tools. I think you will get the very extensive list of currently available ontology tools. A good ontology tool provider is Ontoprise (www.ontoprise.de).
* You need to describe a set of services for using the ontology that focus on what might be called "back-end" services. That is, if the ontology were in a database, what "calls" to the database would be necessary to fully exploit the ontology schema? This is opposed to trying to define a user-interface.
* From this description, one could build a series of open-source toolkits in a variety of languages that could be distributed to those who wish to exploit the ontology. What you want is for everyone to see the same functionality (returning the same exact results), regardless of programming language, as long as they use your toolkit.
* You should plan on toolkit implementations in Perl, Java, C/C++, Python. You should also plan a relational database SQL version (MySQL/PostgreSQL).
* Data visualization is something we're very active in. People need to be able to see ontology data structures to browse them as well as to design them. 2D and even 3D visualization environments would be beneficial
* The notion of an ontology broker (server), which is the logical and physical implementation of a server that provides terms associated with a particular domain. Interlinking ontology brokers world-wide gives access to the full ontology. Needs protocols for interacting with the ontology broker.
* The need for a tool to help in localizing terminology appearing in the user interface of an application program. For example, the "Print" button should show the correct word for "Print" in the appropriate language where the application is being used. The application could query AOS to get the correct word.
* Automatic classification tools. Description logics provide basic inferencing operations, subsumption and classification, which can automatically determine where new concepts fit in the ontology, which is a task useful for lots of purposes. We need to explore how far these tools can be applied.
* Parsers. I don't know how far we can go with natural language processing at this point, but we are working on tools for automatically building concept descriptions from natural language phrases.
* For updating, you need a strategy to trace renaming and definition shifts. If referred concepts change, there must be an automatic way to adapt the references and to identify the least number of human decisions necessary to resolve ambiguities.
* The more groups you can engage in testing or using different mapping mechanisms, the better.
* Manual ontology matching and integration is efficient, if a reasonable automatic pre-selection of candidate terms is available. Few automatic methods have sufficient precision by themselves, so intellectual control is necessary. Automatic methods do exist, they need not be developed.
* The retrieval tools should pre-exist. There is a risk of loss of focus, and retrieval tools are since long on the market. Only if advanced ontological relationships are to be explored, an adaptation of retrieval tools may be beneficial.
* Semi-automatic techniques for integration of current ontologies based on reasoning with description logics should be investigated. Techniques for conversion of thesauri into ontologies should also be investigated.
* Techniques for classification of documents according to concepts present in the ontologies should be investigated. These techniques might be based on machine learning, latent semantic indexing or statistical techniques.
Users and User Testing
* An evaluation of the current view of terminology with respect to the existing thesauri like AGROVOC. Do the topical structurings made by people (e.g., at conferences or in their selection of keywords) mirror the grouping of terms in the thesaurus, which, at least for navigational purposes, is important if people should find a thesaurus intuitive to use.
* IMHO, user analysis (identification, use cases, etc.) should start earlier than presently stated, since this analysis will shape/alter some of the end requirements and scope. The users whose requirements have been taken could then be later asked to do user-testing.
* If the AOS is primarily the ontology and associated software (but not an online service), then it seems the primary users are those folks developing information portals of one kind or another. If the AOS is to be some kind of online service (I type "pig" into a search box and the AOS returns "use swine") then the audience is theoretically every end user out there who is interested in agricultural stuff.
* In terms of functions, primary users will be information system developers, data administrators, statisticians, librarian, subject editors. Actual beneficiaries will be users of information systems finding richer and more focussed information.
* The more the better, a sound strategy given: to set up relevant experiments, to engage enough users in real work, to create results that can be evaluated.
* Who will be beneficiaries? Define (if possible more) target groups. Define "users" mode specifically (if possible classify them into several categories with specific requirements).
How the AOS Could Be Used
* Is the ontology / ontologies used to retrieve documents (resources), or are they used for directly answering user queries? This is a very important issue. Indeed, if the ontology is used only to GUIDE the search towards documents, then the formalism for expressing the ontology can be of a certain type. Otherwise, the formalism for expressing and representing the ontology should be much more complex and sophisticated.
* I did see that you plan to have usability tests and to analyze user profiles for this. This is a very good idea. However, in my opinion, such efforts could be exploited also for enriching the ontology with a module based on user prototypes and user profiling which allows the system to slightly adapt to the different (registered) users accessing it. This would permit the system to show a view of the information closer to the user's interests and also reduce the search time.
* I very much liked your mentioning of the user interface aspects of the thesaurus, which unfortunately is often forgotten in many terminology projects. One aspect that might be worth considering in this context is natural language query interfaces. They are becoming extremely popular in the tourism and e-commerce domains, i.e., in domains where people who are not primarily computer scientists or experts on the given IS system structure are led to use an information system. These interfaces build on ontologies and help the user in formulating a query without knowledge of Boolean query languages and the like. I think this very nicely combines with your notion of allowing, analyzing and defining new relationships between terms, and should definitely be considered.
* From my perspective, what would be most useful to me would be the ontology itself. Next would be some open-source software that could manage the ontology. I would want full access to the software so that I could incorporate it into the system and distribute it to any partner that might want to run a node "back home." Less useful, and I'm not sure here how much less is "less", would be a central service providing dynamic access to the ontology: my site queries the central AOS for the info around a particular term, the AOS service returns the relevant broader, narrower, use/use for terms.
* How does an individual faculty member build and catalog a collection of slide sets? How do we catalog a collection of several thousand publications for a cooperative extension service? How do crop modelers organize their simulation components within some conceptual framework. This is more user-based, but we are in a research mode trying to figure out how individuals would make use of shared thesaurus/ontology and associated tools.
* Will there be also a "training package" as a project deliverable?
Compiled comments - 25 November 2001 21:58
|