AI for the Web — Ontology-based Community Web Portals

Steffen Staaba,b, Jurgen Angeleb, Stefan Deckera,b, Michael Erdmanna, Andreas Hothoa,Alexander Maedchea, Hans-Peter Schnurra,b, Rudi Studera,b, York Surea

email:fstaab, angele, decker, erdmann, hotho, maedche, schnurr, studer, sureg@aifb.uni-karlsruhe.deaInstitute AIFB, University of Karlsruhe, 76128 Karlsruhe, Germany

http://www.aifb.uni-karlsruhe.de/WBSbontoprise GmbH, Hermann-L¨ons-Weg 19, 76275 Ettlingen, Germany

http://www.ontoprise.com

Abstract

Community web portals serve as portals for the informationneeds of particular communities on the web. We here discusshow a comprehensive, ontology-based approach for buildingand maintaining a high-value community web portal has beenconceived and implemented. The ontology serves as a seman-tic backbone for accessing knowledge on the portal, for con-tributing information, as well as for developing and maintain-ing the portal. In particular, the ontology allows for flexiblequerying and inferencing of knowledge. Actual usage of ourtechnology is facilitated through a set of tools that are about toturn our research system into a portal for wide-spread usageright now. The development of these tools has greatly ben-efited from some first experiences we had with actual usersof the community web portal of the knowledge acquisitioncommunity.

1 IntroductionOne of the major strengths of the World Wide Web is thatvirtually everyone who owns a computer may contributehigh-value information — the real challenge is to make valu-able information be found. Search machines help with thistask, but ultimately they fail to provide appropriatly struc-tured views onto the web.

From the very beginning of the web, communities of in-terest have formed that covered what they deemed to be ofinterest to their members in — what we here call — com-munity web portals. Community web portals are similar toYahoo!TM and its likes by their goal of presenting a struc-tured view onto the web, however they are dissimilar by theway knowledge is provided in a collaborative process withonly few resources (manpower, money) for maintaining andediting the portal. Thus, their is a need for automation ofmanagement of community web portals.

Community web portals try to weave loose pieces of in-formation into a coherent presentation adequate for sharingknowledge with the user. Support through ontologies ap-pears as an appropriate means in order to facilitate the tool-supported structuring of knowledge. The ontology formallyrepresents common knowledge and interests that peopleshare within their community. It is used to support the majortasks of a portal, viz. accessing the portal through manifold,dynamic, conceptually plausible views onto the information

Copyright c 2000, American Association for Artificial Intelli-gence (www.aaai.org). All rights reserved.

of interest in a particular community (Section 2), and pro-viding information in a number of ways that reflect differenttypes of information resources held by the individuals (Sec-tion 3). The subsequent Section 4 shows how an ontology-based web portal may be developed and maintained usingour set of methods and tools and how the overall architec-ture of the portal looks like. Before we conclude, we com-pare our work with related approaches (Section 5).

The Example. The example that we draw from in the restof this paper is the portal for the“Knowledge AnnotationInitiative of the Knowledge Acquisition community”(KA2;cf.(Benjamins, Fensel, & Decker 1999)). The KA2 initiativehas been conceived for semantic knowledge retrieval fromthe web building on knowledge created in the KA commu-nity. To structure knowledge, an ontology has been built inan international collaboration of researchers. The ontologyconstitutes the basis to annotate WWW documents of theknowledge acquisition community in order to enable intelli-gent access to these documents and to infer implicit knowl-edge from explicitly stated facts and rules from the ontology.

Given this basic scenario, which may be easily transferredtowards other settings for community web portals, we haveinvestigated the techniques and built the tools that we de-scribe in the rest of this paper. Nevertheless the reader maynote that we have not yet achieved a complete integrationof all tools and neither have we exploited all our technicalcapabilities in our up and running demonstration KA2 com-munity web portal (http://ka2portal.aifb.uni-karlsruhe.de).

2 Accessing the Community Web PortalNavigating through a, maybe unknown, portal is a rather dif-ficult task in general. Information retrieval may of coursehelp, but it may also be more of a hindrance, because theuser may not know the conceptualization that underlies theportal. Hence, we provide query and navigating capabilitiesand make the conceptual background transparent to the user.

Our description of access capabilities in this section startswith the query capabilities of our representation framework.The framework builds on the very same F-Logic (Kifer,Lausen, & Wu 1995) mechanism for querying as it does forontology representation and, thus, it may also exploit and ex-plicate the ontological background knowledge. In additionto these facilities for explanation and exploration, the on-tology also acts as a mediator between proprietary informa-

From: IAAI-00 Proceedings. Copyright © 2000, AAAI (www.aaai.org). All rights reserved.

tion sources that provide additional background knowledgeto the portal (cf. (Wiederhold & Genesereth 1997) on medi-ators). Nevertheless, F-Logic is as poorly suited for presen-tation to naive users as any other query language. Hence, itsuse is mostly disguised in various easy-to-use mechanismsthat more properly serve the needs of the common user (cf.Section 2.2), while it still gives the editor all the power ofthe principal F-Logic representation and query capabilities.Finally in this section, we touch upon some very mission-critical issues of the actual inference engine that answersqueries and derives new facts by combining facts with struc-tures and rules from the ontology.

2.1 Query CapabilitiesThough information may be provided in a number of differ-ent formats our underlying language for representation andquerying is F-Logic. For instance, using a concrete examplefrom our showcase the following query asks for all publica-tions of the researcher “Steffen Staab”.

(1) FORALL Pub EXISTS ResID ResID:Researcher[NAME !!\Steffen Staab"; PUBLICATION !!Pub]:

The substitutions for the variablePubare the desired pub-lications. The expressiveness and usability of such queriesis strongly increased by the possibility to use a simple formof information retrieval using regular expressions whithinqueries.

In addition, the query capabilities enable using the back-ground knowledge expressed in the KA2 ontology usingrules. For example, one rule states that, two researchers co-operate, if aResearcherX works at aProjectProj and ifa ResearcherY works at the sameProjectProj andX isanother person thanY . The rule is formulated in F-Logic asfollows:

(2) FORALL X;Y; ProjX : Researcher[COOPERATESWITH !! Y : Researcher] X : Researcher[WORKSATPROJECT!! Proj : Project]ANDY : Researcher[WORKSATPROJECT!! Proj : Project]ANDNOT equal(X;Y ):

If we take a look at web pages about research projects,typically information about the researchers (e.g.their names,their affiliation, ...) involved in the projects is explicitlystated in HTML. However, the fact that researchers who areworking together in projects are cooperating is not explicitlystated on the web pages. A question might be: “Which re-searchers are cooperating with other researchers?” Queryingfor cooperating researchers the implicit information aboutproject cooperation of researchers is retrieved. The querymay be formulated using F-Logic:

(3) FORALL ResID1;ResID2 ResID1: Researcher[COOPERATESWITH !!ResID2]:

The result set includes explicit information about a re-searchers cooperation relationships, which are stored in theknowledge warehouse, and also implicit information aboutproject cooperation between researchers derived using theproject-cooperation rule modeled in (2)..

2.2 Navigating and Querying the PortalUsually it is too inconvenient for users to query the portalusing F-Logic. Therefore, we offer a range of techniquesthat allow for navigating and querying the community web:

� A hypertext linkmay contain a query which is dynami-cally evaluated when one clicks on the link. Browsing isrealized by defining views on the top-level concepts of theKA2 ontology, such asPersons, Projects, Organizations,Publications, Research TopicsandEvents. For exampleclicking on theProjectshyperlink results in a query for allprojects known to the portal. The query is evaluated andthe results are presented to the user in a table.

� A choice of concepts, instances, or combinations of bothmay be issued to the user inHTML forms. Choice optionsmay be selected through check boxes or radio buttons. Forinstance, clicking on theProjectslink (cf. upper part ofFigure 1) an F-Logic query is evaluated and all projectscontained in the portal are retrieved. The results can berestricted using topic-specific attributes contained in theKA2 ontology for projects, such as topics of a project,people involved etc. The selection list (e.g.for all peopleinvolved in projects) is generated dynamically from theinformation contained in the knowledge warehouse (cf.Section 3.4).

Figure 1: Accessing the Community Web Portal

� A query may also be generated by using thehyperbolicview interface. The hyperbolic view visualizes the on-tology as a hierarchy of concepts. The presentation isbased on hyperbolic geometry (cf. (Lamping, Rao, &Pirolli 1995)). When a user selects a node from the hy-perbolic concept hierarchy, a form is presented which al-lows the user to select attributes or to insert values for theattributes. A result of the user request searching for thecommunity member “Rudi Studer” and his photo is shown

in the left part of Figure 1. Based on the selected node andthe corresponding attributes, a query is compiled.

� Furthermore, queries created by the hyperbolic view in-terface may be stored using the personalization feature.Queries are personalized for the different users and areavailable for the user in a selection list. The stored queriescan be considered assemantic bookmarks. By selectinga previously created bookmark, the underlying query isevaluated and the updated results are presented to the user.By this way, every user may create a personalized view onthe portal.

� Finally, we offer an expert mode. The most technical (butalso most powerful and flexible) way for querying the por-tal requires that F-Logic is typed in by the user. This wayis only appropriate for users who are very familiar withF-Logic and the KA2 ontology.

2.3 The Inference EngineThe inference engine answers queries and it performsderivations of new knowledge by an combination of factsand the ontology. While the expressiveness of F-Logic andits Java powered realization in our inference engine is oneof the major arguments for using it in a semantic commu-nity web portal, wide acceptance of a service like this alsodepends onprima facieunexciting features like speed of ser-vice. The principal problem we encounter here is that thereexist worst case situations (not always recognizable as suchby the user) where a very large set of facts must be derivedby the inference engine in order to solve a particular query.While we cannot guarantee for extremely fast response timesin all cases, unless we drastically cut back on the expres-siveness of our representation formalism, we provide severalstrategies to cope with performance problems:

� The inference engine may be configured to subsequentlydeliver answers to the query instead of waiting for the en-tire set of answers before these answers are presented tothe user. This has the consequence that answers which aredirectly available as facts may be presented immediatelywhile other anwers which have to be derived using rulesare presented later.

� The inference engine caches all facts and intermediatefacts derived from earlier queries. Thus, similar queriesor queries that build on previously derived facts may beanswered fast.

� Finally, we allow the inference engine to be split into sev-eral inference engines that execute in parallel. Every en-gine may run on a different processor or even a differ-ent computer. Every inference engine administers a sub-set of the rules and facts. A master engine coordinatesuser queries and distributes subqueries to the slave en-gines. These slave engines either answer these subqueriesdirectly or distribute incoming subqueries to other infer-ence engines.

3 Providing InformationAn essential feature of a community web portal is the con-tribution of information from all (or at least many) membersof the community. Though they share some common under-standing, the pieces of information they may contribute may

come in many different (legacy) formats. Hence, one needsa set of methods and tools that may account for the diversityof information sources of potential interest to the commu-nity portal. These methods and tools must be able to copewith different syntactic mechanisms and they must be ableto integrate different semantic formats based on the commonontology.

Considering the syntactic and/or interface side, we sup-port three major, different, modes of information provision-ing: First, we handlemetadata-based information sourcesthat explicitly describe contents of documents on a semanticbasis. Second, we align regularities found in documents ordata structures with the corresponding semantic backgroundknowledge inwrapper-basedapproaches. Third, we allowthe direct provisioning of facts through ourfact editor. Allthe information is brought together in the knowledge ware-house. Thus, it mediates between the original heterogeneousinformation sources.

3.1 Metadata-based Information

Metadata-based information enriches documents with se-mantic information by explicitly adding metadata to the in-formation sources. Over the last years several metadata lan-guages have been proposed which can be used to annotateinformation sources. Current web standards can be handledwithin our semantic web portal approach. On the one hand,RDF (W3C 1999) facts serve as direct input for the knowl-edge warehouse, on the other hand, RDF facts can be gen-erated from information contained in the portal knowledgewarehouse. We developedSiLRI (Simple Logic-based RDFInterpreter), a logic-based inference engine implemented inJava that can draw inferences based on the RDF data model(Deckeret al. 1998). XML provides the chance to get meta-data for free,i.e. as a side product of defining the documentstructure. For this reason, we have developed a method anda tool calledDTDMaker for generating DTDs out of on-tologies (Erdmann & Studer 1999). DTDMaker derives anXML document type definition from a given ontology in F-Logic, so that XML instances can be linked to an ontology.The linkage has the advantage that the document structureis grounded on a true semantic basis and, thus, facts fromXML documents may be directly integrated into the knowl-edge warehouse.

HTML-A, our HTML extension, adds annotations toHTML documents using an ontology as a metadata schema.HTML-A has the advantage to smoothly integrate semanticannotations into HTML and prevents the duplication of in-formation. To facilitate the annotation of HTML, we havedeveloped an HTML-A annotation tool calledOntoPad.

3.2 Wrapper-based Information

In general, annotating information sources by hand is a timeconsuming task. Often, however, annotation may be auto-mated when one findes regularities in a larger number ofdocuments. The principle idea behind wrapper-based in-formation is that there are large information collections thathave a similar structure. We here distinguish between semi-structured information sources (e.g.HTML) and structuredinformation sources (e.g.relational databases).

Semi-structured Sources. In recent years several ap-proaches have been proposed for wrapping semi-structureddocuments, such as HTML documents. Wrapper factories(cf. (Sahuguet & Azavant 1999)) have considerably facil-itated the task of wrapper construction. In order to wrapdirectly into our knowledge warehouse we have developedour own wrapper approach OntoWrapper that directly alignsregularities in semi-structured documents with their corre-sponding ontological meaning.

Structured Sources. Though, in the KA2 community webthere are no existing information systems, we would like toemphasize that existing databases and other legacy-systemsmay contain valuable information for building a communityweb portal.

3.3 Fact EditorThe process of providing new facts into the knowledge ware-house should be as easy as possible. For this reason we offertheFact Editor, which is another mode in which the hyper-bolic interface tool may be used. At this time the forms arenot used to ask for values, but to introduce values for at-tributes of instances of a corresponding concept from theontology. The Fact Editor is also used for maintaining theportal to add, modify, or delete facts.

3.4 Knowledge WarehouseThe different methods and tools we have just described feeddirectly into the knowledge warehouse or indirectly whenthey are triggered by a web crawl. The warehouse itselfhosts the ontology,i.e. the metadata level, as well as the dataproper. The knowledge warehouse is indirectly accessed,through a user query or a query by an inference engine suchas described in Section 2. Hence, one may take full advan-tage of the distribution capabilities of the inference engineand, likewise, separate the knowledge warehouse into sev-eral knowledge bases or knowledge marts. Facts and con-cepts are stored in a relational database, however, they arestored in areified format that treats relations and conceptsas first-order objects and that is therefore very flexible withregard to changes and amendments of the ontology.

4 Development of Web Portals4.1 The Development and Maintenance ProcessEven with the methodological and tool support we have de-scribed so far, developing a web portal for a communityof non-trivial size remains a complex task. Strictly ad-hocrapid prototyping approaches easily doom the constructionto fail or they easily lead up to unsatisfactory results. Hence,we have thought about a more principled approach towardsthe development process that serves as means for document-ing development, as well as for communicating principalstructures to co-developers and editors of the web portal. Wedistinguish different phases in the development process thatare illustrated in Figure 2. For the main part this model is asequential one. Nevertheless, at each stage there is an eval-uation as to whether and as to how easily further develop-ment may proceed with the design decisions that have beenaccomplished before. The results feed back into the resultsof earlier stages of development.

Require-ment

Eliciation

WebSite Design

Ontology Engineering

Termi-nology

RuleDevelopment

Query

Form-ation

PORTAL

Prov. facts

Maintain

Dyna-mic

WebPages

Figure 2: The Development Process of the Community WebPortal

The main stages of the development process and their keycharacteristics are given in the following:

� The process starts with theelicitation of user require-ments in the requirements elicitation phase. In this phase,requirements about important and interesting topics in thedomain are collected, the information goals of potentialusers of the portal are elicited, and preferences or expecta-tions concerning the structure and layout of presented in-formation is documented. Results of this very first phaseconstitute the input for the design of the web site and forpreliminary HTML pages and affect the formal domainmodel embodied in the ontology.

� The requirements determine,e.g., which views andqueries are useful for users of the portal, which navigationpaths they expect, how different web pages are linked, orwhich functionality is provided in different areas of theportal. Requirements like these are realized in thewebsite design. This design phase may be performed indepen-dently to a very large extent from the underlying formalstructuring,i.e. the ontology.

� In parallel to the development of the structure and lay-out of the web site anontology engineeringprocess isstarted. The first phase elicits relevantdomain termsthatneed to be refined and amended in the ontology engineer-ing phase. First, the static ontology parts,i.e. the concepthierarchy, the attributes, and relations between conceptsare formally defined. Thereafter,rulesand constraints aredeveloped. Rule development may incur a major revisionof the concept hierarchy as consequence.

� In thequery developmentstep the views and queries de-scribed in one of the earlier phases are formalized. Atfirst, their functionality is tested independently from theweb site design. To express the information needs for-mally, the developer has to access the ontology, wherebyadditional rules or relations that define new views or easethe definition of queries may become necessary.

� Finally, web pages are populated,i.e. the queries andviews developed during website design, and formalizedand tested during query formalization are integrated intothe operational portal. Information may be accessed viathe portal as soon as a sufficient amount has been madeavailable as outlined in Section 3.

During operation of the community portal it must be fedand maintained:

� The user community provides facts via numerous inputchannels (cf. Section 3).

� These facts may contain errors or undesired contents, orthe integration of different sources may lead to inconsis-tencies. To counter problems like these a person is re-sponsible to detect these cases and act appropriately. Thedetection of inconsistencies is supported by the inferenceengine via constraints formulated in F-Logic. The editorthen has to decide how to proceed. He may contact re-sponsible authors of conflicting information, he may sim-ply ignore it, or he may manually edit the information.

� Changing requirements of the community must be re-flected in the portal,e.g. popularity increasing in newfields of interests or technologies or viewpoints that shiftmay incur changes to the ontology, new queries, or even anew web site structure. In order to meet such new require-ments, the above mentioned development process mayhave to be partially restarted.

4.2 Tools for Development and MaintenanceThe previous subsection has described the principal steps fordeveloping a community web portal. For efficient develop-ment of a community web portal, however, the process mustbe supported by tools. In the following, we describe the mostimportant tools that allow us to facilitate and speed up thedevelopment and maintenance process. The tools cover thewhole range from ontology engineering (OntoEdit), queryformulation (Query Builder), up to the creation of dynamicweb pages with the help of HTML/JavaScript templates. Anoverview of the tool suit is given in Table 1.

Table 1: Tool Suit for Community Portals

Tool DescriptionOntoEdit Ontology Engineering EnvironmentOntoPad HTML Annotation ToolInference Engine Reasoning service for query answeringOntoWrapper Extracting information from semi-

structured documentsQuery Builder Visual creation of queriesFact Editor Manual provision and maintenance of factsKnowledge Ware-house

Fact base of the community web portal

HTML and Java-Script templates

Support the development of virtual HTMLpages

Hyperbolic View Visual querying the community web portal

OntoEdit. OntoEdit is a Ontology Engineering Environ-ment delivering a wide range of functionalities for the en-gineering of ontologies including the modeling of concepts,relations, rules, and general ontology metadata (cf. (Maed-cheet al. 2000)). It includes several views on the model-ing primitives that enable the user to state common legalities(e.g.the symmetry of the cooperation relationship betweentwo persons).Query Builder. While queries with low complexity can beexpressed in F-Logic using the rule debugger alone, in othercases it is more convenient to create queries using our QueryBuilder tool. Such queries may then be integrated as linksin a web page within a web editor by copying and pastingit into the web editors form. The Query Builder also con-tains a rule debugger, providing different views on different

levels of detail to the proof tree that visualize relevant rulesand rule parts for tracing the derivation process. In addi-tion, generated queries by the Query Builder can be directlyembedded into HTML/JavaScript Templates.HTML/JavaScript Templates. Another time consumingactivity is the development of the web pages that assemblequeries from parts and that display the query results. Forthat purpose we have developed a library of template pages:

� Templates with check boxes, radio boxes, and selectionlists are available. These HTML forms produce datawhich are used in Javascript functions to generate queries.

� The results of a query are fed into a template page asJavascript arrays. From these data different presentationforms may be generated:

– A general purpose template contains a table thatpresents answer tuples returned by the inference enginein a HTML table. The template provides functions tosort the table in ascending or descending order on dif-ferent columns. Substitutions of certain variables maybe used as URLs for other entries in the table. Differentdata formats are recognized and processed according totheir suffixes,i.e. a “.gif” or “.jpg” suffix is interpretedas a picture and rendered as such (cf. Figure 1 for anexample).

– Results may also be fed into selection lists, radio boxes,or check lists. Thus, query results can provide the ini-tial setting of further HTML form fields.

� As a personalization feature of our web portal users storequeries by assigning a personal label. All stored queriescan be accessed through a selection list, to restart thequery and retrieve the most up to date answers. This listof stored queries provides individual short cuts to oftenneeded information.

5 Related WorkOur work combines approaches from different areas and ex-tends these concepts in many directions. We here just give ashort survey of this related work — a more detailed compar-ison may be found in (Staabet al. 2000).Portals: Typically, portals like Yahoo!TM are indices of webpages that are maintained by editors that manually classifyweb documents into a tree-like taxonomy of topics. In con-trast to our approach those portals only utilize a very light-weight ontology that solely consists of categories arrangedin a hierarchical manner. Due to its weak ontology Yahoo!cannot extend given information with facts derived by onto-logical axioms.

A community focused and ontology-based portal is Ri-boWeb (Altmannet al. 1999) that offers ribosome data andcomputational models for their processing. RiboWeb spec-ifies ontologies in OKBC (Chaudriet al. 1998). The pri-mary source of data is given by scientific literature which ismanually linked to the different ontologies. Both systems,RiboWeb and our community portal, rely on ontologies foroffering a semantic-based access to the stored data. How-ever, the OKBC component of RiboWeb does not supportthe kind of automatic deduction that is offered by the in-ference engine of Ontobroker. Furthermore, RiboWeb does

not include wrappers for automatically extracting informa-tion from the given published articles. On the other hand, thecomputational modules of RiboWeb offer processing func-tionalities that are not part of (but also not intended for) ourcommunity web portal.Database approaches: STRUDEL (Fernandezet al.1998) and Hyperwave (Maurer 1996) apply concepts fromdatabase management systems to the process of buildingWeb sites. They use database queries to generate web pagesfrom database contents — allowing for multiple views ontothe same content. When compared to our approach, thesesystems lack the semantic level that is provided in our ap-proach by the domain ontology and the associated inferenceengine.Knowledge representation for the web: The Ontobrokerproject (Deckeret al. 1999) lays the technological founda-tions for the KA2 portal. Similar to Ontobroker are SHOE(Luke et al. 1997) and WebKB (Martin & Eklund 1999).All three systems aim at providing intelligent access to Webdocuments (though, with different means). However, theyall lack an environment of methods and tools that are neededto build a community portal on their top and, thus, to makean application out of a core technology.

From our point of view, our community portal system isa rather unique AI application with respect to the collectionof methods used and the functionality provided. Our ap-proach for accessing information, providing information andmaintaining the portal are more comprehensive than thosefound in other portals. We are able to offer this function-ality since our backbone system Ontobroker and its add-onsprovide more powerful techniques fore.g.inferencing or ex-tracting information from various sources than those offeredby comparable systems.

6 ConclusionWe have demonstrated in this paper how a community maybuild a community web portal. The portal is centered aroundan ontology that structures information for the purpose ofpresenting and provisoning information, as well as for thedevelopment and maintenance of the portal. We have de-scribed a particular application, the KA2 community webportal, that illustrates some of our techniques and meth-ods.In particular, we have developed a set of ontology-basedtools that allow to present multiple views onto the same in-formation appropriate for browsing, querying, and personal-izing web pages. Queries are responded to by an inferenceengine for F(rame)-Logic that integrates knowledge frommany different sources.

For the future we are planning to integrate several semi-automatic information extraction-based approaches support-ing the information provisoning part of our portal frame-work. Ontology revision and maintenance and the impacton the facts stored in the knowledge warehouse are currentlynot well understood and have to be researched further.

ReferencesAltmann, R.; Bada, M.; Chai, X.; Carillo, M. W.; Chen, R.; andAbernethy, N. 1999. RiboWeb: An Ontology-based Systemfor Collaborative Molecular Biology.IEEE Intelligent Systems14(5):68–76.Benjamins, R.; Fensel, D.; and Decker, S. 1999. KA2: BuildingOntologies for the Internet: A Midterm Report.InternationalJournal of Human Computer Studies51(3):687.Chaudri, V.; Farquhar, A.; Fikes, R.; Karp, P.; and Rice, J. 1998.OKBC: A Programmatic Foundation for Knowledge Base Inter-operability. InProceedings 15th National Conference on Artifi-cial Intelligence (AAAI-98), 600–607.Decker, S.; Brickley, D.; Saarela, J.; and Angele, J. 1998. AQuery and Inference Service for RDF. InProceedings of the W3CQuery Language Workshop (QL-98), December 3-4.Decker, S.; Erdmann, M.; Fensel, D.; and Studer, R. 1999.Ontobroker: Ontology Based Access to Distributed and Semi-Structured Information. In Meersman, R., et al., eds.,DatabaseSemantics: Semantic Issues in Multimedia Systems. Kluwer Aca-demic Publisher. 351–369.Erdmann, M., and Studer, R. 1999. Ontologies as ConceptualModels for XML Documents. InProceedings of the 12th In-ternational Workshop on Knowledge Acquisition, Modelling andMangement (KAW’99), Banff, Canada, October.Fernandez, M.; Florescu, D.; Kang, J.; and Levy, A. 1998. Catch-ing the Boat with Strudel: Experiences with a Web-Site Man-agement System. InProceedings of the 1998 ACM Int. Conf. onManagement of Data (SIGMOD’98) , Seattle, WA.Kifer, M.; Lausen, G.; and Wu, J. 1995. Logical Foundationsof Object-Oriented and Frame-Based Languages.Journal of theACM42.Lamping, L.; Rao, R.; and Pirolli, P. 1995. A Focus+ContextTechnique Based on Hyperbolic Geometry for Visualizing LargeHierarchies. InProceedings of the ACM SIGCHI Conference onHuman Factors in Computing Systems.Luke, S.; Spector, L.; Rager, D.; and Hendler, J. 1997. Ontology-based Web Agents. InProceedings of First International Confer-ence on Autonomous Agents.Maedche, A.; Schnurr, H.-P.; Staab, S.; and Studer, R. 2000.Representation language-neutral modeling of ontologies. InModellierung-2000: Proceedings of the German Workshop onModeling. Koblenz, April, 2000. Folbach-Verlag.Martin, P., and Eklund, P. 1999. Embedding Knowledge in WebDocuments. InProceedings of the 8th Int. World Wide Web Conf.(WWW‘8), Toronto, May 1999. Elsevier Science B.V.Maurer, H. 1996.Hyperwave. The Next Generation Web Solution.Addison Wesley.Sahuguet, A., and Azavant, F. 1999. WysiWygWeb Wrapper Factory (W4F). Technical Report.http://db.cis.upenn.edu/DL/WWW8/index.html.Staab, S.; Angele, J.; Decker, S.; Erdmann, M.; Hotho, A.; Maed-che, A.; Studer, R.; and Sure, Y. 2000. Semantic CommunityWeb Portals. InProceedings of the 9th World Wide Web Confer-ence (WWW-9), Amsterdam, Netherlands.W3C. 1999. RDF Schema Specification.http://www.w3.org/TR/PR-rdf-schema/.Wiederhold, G., and Genesereth, M. 1997. The Conceptual Ba-sis for Mediation Services.IEEE Expert / Intelligent Systems12(5):38–47.