Using Ontologies to Support and Critique Decisions - 2004
- 1. Yannis Kalfoglou Advanced Knowledge Technologies (AKT) School of Electronics and Computer Science University of Southampton UK Ontology-based decision support Using ontologies to support and critique decisions
- 2. Overview Decision support and AI Historic references: from GDSSs to OLAP and Web-based systems Impact of new organisational culture: pervasive computing and KM @work Knowledge engineering in Design Design paradigms Ontology uses: Decision support: Ontology Network Analysis (ONA) to support Communities of Practice (CoP) Decision critiquing: Validation/Verification of Software Design Cost-effective insights
- 3. Decision support and AI Early work in decision support systems group-targeted; operational research principles; Early AI technology synergy with decision support: Expert systems & Group Decision Support Systems (GDSSs); Today’s trends ( Shim et.al. “DSS” journal/2002 ): Data warehousing; OLAP – Online Analytical Processing; Data mining; Web-based DSSs; Organisational culture shift: From Groups to Communities of Practice/Interest; Technological infrastructure shift: From monolithic, centralised systems to multi-tier, distributed, pervasive structures Semantic technologies & KM
- 4. Knowledge engineering in design Need for reusable, computational forms of domain knowledge AI solution: ontologies Ontologies could support decision making as part of a KM system Early stages of design ( software systems design ) Most commonly used design paradigms ( “Design rationale”, Moran & Carroll) and the use of knowledge engineering technology ( “Meta-knowledge” review, KER, Kalfoglou et.al. )
- 5. Knowledge engineering in design – cnt’d
- 6. Ontologies and decision support - ONA Organisational (or corporate) memories a widely used KM infrastructure But: there is little support for the initial set-up of an OM; How to select the right resources to include in an OM? manual selection is error-prone, time-consuming and overwhelming. used by other systems within the organization; ‘ Unspecified’, vaguely expressed, need to be composed; act as a qualitative measure for the OM. Need to automatically select content and set-up the OM (thus tackling the “cold start” syndrome); We used ontologies - Ontology Network Analysis (ONA) - to tackle this problem: Use of populated ontologies already in place; Automatically select resources based on their popularity; Number of instances particular classes have (class popularity) Number and type of relations’ paths between an entity and other entities (instance popularity) Proxy for importance: important objects stronger presence (“hubs” in the domain) – relations can be weighted according to their importance (automatically or manually)
- 7. Applying ONA to initiate OMs ONA plays a dual role: Could be used to ‘push’ knowledge to the user; Could also be used of OM developers to identify which entities should be presented to certain types of users; OM developers could also use ONA to help them link the underlying ontologies to an existing workflow engine; OM users can tune ONA to their needs ONA interface to the users is a light-weight Web accessible client; ONA interface to the OM developers is embedded in ontology editor.
- 8. ONA
- 9. ONA: Caveats and considerations Information overload: Progressive and query-based interaction with the user is a safeguard against unwanted information overload; But: progressive interaction results in cold start syndrome and query-based interaction requires expertise and domain familiarization; ONA might suffer from information overload but users can tune it Context-awareness: Marrying existing workflow processes to bring context-specific information to the user; But: workflow processes must be defined, should be integrated with OM, user often require information irrelevant to the process; ONA achieves context relevance thanks to its genericity: we could plug-in ad-hoc tools: user profiling, personalization filters Domain-independence: Desired feature for an OM ONA: is not specific to any kind of ontology or domain;
- 10. Ontologies and decision critiquing Software designers need to trace their decisions and verify/validate them; Software engineering technologies to tackle this: Experience Factories (EFs) and Experience Bases (EBs); Support exchange of experiences in the life-cycle of a software project; We applied EFs in an ontology development and deployment scenario Manage experience collected from ontology designers; Critique those decisions against commonly agreed constraints on the use of domain knowledge; EFs/EBs framework allows for re-use and adaptation of decision critiquing mechanism to similar projects within the same domain
- 11. EF
- 12. Cost-benefit analysis Ontology technology could benefit and improve decision support and critiquing But, there are costs involved: construction, reuse, maintenance costs Construction cost : Knowledge comes at a cost; Building an ontology from scratch: choice, adoption or creation of a design methodology, then build the ontology Re-using an ontology: adoption, familiarisation and installation cost. Empirical evidence: could be unreasonably high (e.g., CYC), but depends on the type (domain or task-specific ontologies are easier/cheaper to build) Re-use cost : Re-use pre-existing ontologies; Usefulness trade-off: particular types of ontologies (domain/task) more useful than others (generic) – HPKB study Location and familiarisation issues; Empirical evidence: ontologies must be learnt prior to use and this learning curve may have a non-trivial impact on the overall cost;
- 13. Cost-benefit analysis – cnt’d. Maintenance cost : The most unpredictable and arguably the higher cost; Intimately related to ontology stability: How common is ontology instability? Domain knowledge stable over time? If ontology should rarely stabilise then cost for maintenance, ontology evolution, ontology versioning, etc. Other non cost-related factors: Level of formality the more formal, the more usable, the more expensive but more appropriate for SE tasks and support automation; Level of support if ontologies are outsourced; translation costs, adaptation costs, maintenance caveats; Purpose of use an ontology is not a “magic stick”; can’t solve all problems but can greatly improve knowledge sharing and reuse and the more formal it is the more it can improve other areas, e.g., systems reliability & interoperability
- 14. Questions
- 15. Applying ONA to identify CoP: ONTOCOPI CoPs are an important resource for an OM: (a) informal, so difficult to spot (b) essential for learning, (c) recruitment and/or expert location, (d) access to codes and bodies of knowledge (private and tacit), (e) aimed at production of knowledge,… CoP management is a delegate issue and one of the most difficult tasks is to discover the extent of the community itself; We apply ONA to identify CoP: ONTOCOPI; Ontology relations are formal vs. CoP informality: Use formal relationships as a proxy to an informal one: E.g., co-authorship as a proxy for membership in the same CoP ONTOCOPI only support identification of CoP; ONTOCOPI can’t identify relationships that aren’t there; Boundary objects are problematic: ONTOCOPI can’t distinguish between CoPs
- 16. Ontology Network Analysis (ONA) In previous workshops we presented the idea and application of network analysis to an ontology for the purpose of identifying Communities of Practice (ONTOCOPI); We generalized the approach and applied to Organizational Memories (OMs): There is little support for the initial set-up of an OM; How to select the right resources to include in an OM? Ideally, with little or no initial interaction with the user: automatically select content and set-up the OM (thus tackling the “cold start” syndrome); To implement this idea we invented ONA, a generalization of ONTOCOPI; The most important nodes in the underlying ontology network are selected as the most appropriate ones to include in the OM; We measure importance in terms of popularity: spreading activation yields the most well connected nodes; Idea has been embraced by the OM community (ECAI02 OM workshop) but we are aware of its caveats and ways of overcoming them: Information overload: could be tackled with user tune ONA to its preferences; Context awareness: ONA could use ad-hoc tools (e.g. profiling); Domain independence: ONA could be applied to any ontology in any domain.
- 17. Ontology Network Analysis (ONA) We use one of the core elements of an OM: ontologies; We apply an algorithm to identify the most important objects in the ontology: We measure importance in terms of popularity; Those that have been identified are used as the initial seed to automatically populate the OM. ONA is based on an ontology: we use its structure to draw inferences and reason about relevance of selected information; ONA is ‘old’ information network analysis methods applied to a semantically-rich resource: ontology Semantics of relations or types provide another source of information over and above connectivity of nodes and simple subsumption.
- 18. User requirements and workflow processes as an aid to set-up an OM Two, broadly defined, areas are concerned with this problem: Eliciting users’ needs and what the OM will be used for; Build the OM around an existing workflow engine (KnowMore). Eliciting user requirements: Given the sheer size and range of applications an OM can serve, we should expect them to be incomplete and vague; Use an existing workflow engine: ‘ near perfect’ integration with existing IT organizational infrastructure and satisfying users’ (pre-) defined needs; BUT: Processes not easy to codify in a workflow engine; Not desirable to restrict OM users’ search only on those resources that are deemed to be relevant to the process they are involved; Challenging task to implement the merging of OMs and workflow engines.
- 19. Ontologies and decision support - ONTOCOPI Testbed for ONA: Identifying Communities of Practice (CoP) There are different types of collectivity in the organisational theory literature: Functional groups : centralised, hierarchical and specialised by function Teams : created to meet specific goals, integrate heterogeneous knowledge Project teams : short-lived, specific aim, budget Networks : allow suppliers and consumers of goods and services to coordinate knowledge/output decisions Epistemic communities (wider scope): Define framework in which codification can occur; Have some sort of procedural authority. Such communities are relatively formal and tightly bounded Community of Practice proper: Contains people with interests in the practice ; Self-organising ; Commitment, not formality .
- 20. CoP vs. other formal structures Accumulate & circulate best practice Homogeneous Increase skills CoP Construction & circulation of codes Heterogeneous Produce knowledge Epistemic community Knowledge exchange Heterogeneous Mutually negotiated specialisation Network Integration of functional knowledge Heterogeneous Realise a task Team/project team Disciplinary specialisation Homogeneous Ensure a function Functional group Cognitive activity Agents Objective
- 21. CoP vs. other formal structures Common passion Learning in working Self-selecting CoP Procedural authority Intended searching Peers Epistemic community Need for complementary knowledge Learning by exchange Mutual trust Network Job & goals Unintended – learning by interacting Team leader Team/project team Education & firm hierarchy Unintended - learning by doing Hierarchical Functional group Community glue Knowledge production Recruitment
- 22. ONTOCOPI