2006 Ontopia AS1 Towards an Ontology Design Methodology Initial work Lars Marius Garshol CTO, Ontopia TMRA 2006 2006-10-11.

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Language Technologies Reality and Promise in AKT Yorick Wilks and Fabio Ciravegna Department of Computer Science, University of Sheffield.
Australian Curriculum
Account Planning The purpose of these slides is to describe the Account Planning Process, the methodology, and the workload involved in running an account.
Chapter 5 Buying business services. Program The increasing importance of services Differences between goods and services A classification of services.
Karolina Muszyńska Based on
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
2006 Ontopia AS1 TMSync Topic map-to-topic map updates Lars Marius Garshol CTO, Ontopia TMRA
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Chapter 3: The Project Management Process Groups
IIBA Denver | may 20, 2015 | Kym Byron , MBA, CBAP, PMP, CSM, CSPO
UFCEPM-15-M Object-oriented Design and Programming Jin Sa.
Stoimen Stoimenov QA Engineer QA Engineer SitefinityLeads,SitefinityTeam6 Telerik QA Academy Telerik QA Academy.
Software Documentation Written By: Ian Sommerville Presentation By: Stephen Lopez-Couto.
Information Technology Project Management, Sixth Edition Note: See the text itself for full citations.
System Implementation
Effectively applying ISO9001:2000 clauses 5 and 8
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter 1 The Systems.
What is Business Analysis Planning & Monitoring?
Continuation From Chapter From Chapter 1
The Software Development Life Cycle: An Overview
S/W Project Management
How To Apply Quality Management
UML - Development Process 1 Software Development Process Using UML (2)
LESSON 8 Booklet Sections: 12 & 13 Systems Analysis.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Quick Guide to help your transition
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Business Analysis and Essential Competencies
Copyright © 2013 Curt Hill The Zachman Framework What is it all about?
Process Design (Requirements). Recall the Four Steps of Problem Solving * Orient Plan Execute Test These apply to any kind of problem, not just spreadsheet.
1 Bonham, chapter 8 Knowledge Management. 2  8.1 Success Levels  8.2 Externally Focused KM  8.3 Internally Focused KM  8.4 PMO-Supported KM
1.  Project: temporary endeavor to achieve some specific objectives in a defined time  Project management ◦ Dynamic process ◦ Controlled and structured.
A COMPETENCY APPROACH TO HUMAN RESOURCE MANAGEMENT
Team Skill 2 Understanding User and Stakeholder Needs Requirements Workshop (11)
Domain Modeling In FREMA David Millard Yvonne Howard Hugh Davis Gary Wills Lester Gilbert Learning Societies Lab University of Southampton, UK.
Strong9 Consulting Services, LLC 1 PMI - SVC I-80 Breakfast Roundtable Monthly Meeting Thursday, October 12, :00 am – 9:00 am.
1 © 2005 course technology1 1 1 University Of Palestine Chapter 5 (Cont.) Scoping the IT Project with System Use Cases.
1 Ideas of Problem-based Learning As a learner-centred process, problem- based learning meets the learners' interests and as such gives room for developing.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
Microsoft Office Project 2003: Selling EPM in your Organization Matt Wilson Business Solutions Specialist LMR Solutions.
System Context and Domain Analysis Abbas Rasoolzadegan.
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
CS251 – Software Engineering Lecture 9: Software Design Slides by Mohammad El-Ramly, PhD
A State Perspective Mentoring Conference New Orleans, LA 2/28/2005 RCRAInfo Network Exchange.
BSBPMG501A Manage Project Integrative Processes Manage Project Integrative Processes Project Integration Processes – Part 1 Diploma of Project Management.
The Software Development Process
Domain Modeling In FREMA Yvonne Howard David Millard Hugh Davis Gary Wills Lester Gilbert Learning Societies Lab University of Southampton, UK.
Chapter 6: THE EIGHT STEP PROCESS FOCUS: This chapter provides a description of the application of customer-driven project management.
1 / x CMMI Technical Solution Rob Vanden Meersche Dieter Van den Bulcke.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 Class exercise II: Use Case Implementation Deborah McGuinness and Peter Fox CSCI Week 8, October 20, 2008.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
IS2210: Systems Analysis and Systems Design and Change Twitter:
1A FAST EXCELLENCE THROUGH FACILITATION Gary Rush The FAST Process MGR Consulting
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
DEVELOPMENT OF A WHITE PAPER ON CORRECTIONAL SERVICES Ministry of Correctional Services.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Application Analysis. Application Interaction Model The purpose of analysis is to understand the problem so.
CHAPTER 3 Systems Considerations in the Design of an HRIS.
Statistical process model Workshop in Ukraine October 2015 Karin Blix Quality coordinator
The Project Management Process Groups
© University of Manchester Creative Commons Attribution-NonCommercial 3.0 unported 3.0 license Quality Assurance, Ontology Engineering, and Semantic Interoperability.
Requirements Analysis Scenes
Systems Analysis and Design
Process Improvement With Roles and Responsibilities explained
Description of Revision
Engineering Processes
{Project Name} Organizational Chart, Roles and Responsibilities
Presentation transcript:

Ontopia AS1 Towards an Ontology Design Methodology Initial work Lars Marius Garshol CTO, Ontopia TMRA

Ontopia AS2 Agenda Background –why this is important –what it includes The process –some background –roles –steps The guidelines –examples Conclusion –further work

Ontopia AS3 Background Why this is important What it includes

Ontopia AS4 The ontology challenge For many customers, creating the ontology is the biggest hurdle –it’s something new to them, and they don’t know how to approach it –the technology is new, and so most consultants are not familiar with it –this makes the process of creating the ontology seem very intimidating –it also means that the costs and challenges are unknown Successfully developing an ontology is non-trivial –it can be politically challenging –the ontology interacts with every other part of the project... –ontology modelling requires analytical skill –the ontology is constrained by economical and technical considerations

Ontopia AS5 The methodology: vision A defined process –roles involved in the process –a defined series of steps to follow A set of modelling guidelines –essentially heuristics for the correct use of the constructs in Topic Maps A pattern library –common solutions to common problems A base ontology –PSIs for common concepts like “person”, “description”,... In the paper

Ontopia AS6 Scope There are two general classes of applications –information retrieval-type applications portals, library systems, publishing solutions, KM solutions,... –“traditional” applications CRM systems, product configuration applications, business process modelling,... Ontology design is different for these two applications –in “traditional” applications the domain is already well-understood the needs of the end-users are well-understood –none of this applies to information retrieval applications Methodology focuses on information retrieval applications –process especially –guidelines are general

Ontopia AS7 The process Background Roles Steps

Ontopia AS8 Simplified process view Vision Lacking source data Can’t analyse domain Lack of project consensus

Ontopia AS9 The process exists to handle these challenges Source data gap or analysis gap –make sure you discover the gap in time –make sure you can find ways to plug it, or work around it Project consensus –including the right people in the right way at the right time builds consensus –it also ensures people know what they need to know Manage dependencies –keep track of what depends on the ontology

Ontopia AS10 Roles Project manager –runs the project Developers –write the code System owners –make the decisions regarding the project Data source owners –manage systems which provide data to the new system –usually not part of the project End-user –user of the final system Ontology modeller –person responsible for ontology Editors –people responsible for data in the system Authors –people who write the content in the system Domain expert –someone with knowledge of the domain

Ontopia AS11 The role of the ontology Ontology Developers Project manager End-users Editors Authors Data integration Presentation logic Editorial system

Ontopia AS12 Ontology considerations Requirements End-user needs Interface issues Ontology Existing data

Ontopia AS13 Startup Usually a workshop –project manager, editors, ontology modeller –presentation + Q&A Key goals –establish requirements –get overview of data sources Startup Analysis End-user Drafting Interaction design Verification

Ontopia AS14 Analysis Usually interviews with data source owners –extract documentation, schemas, exports,... –use torture if necessary Key goals –understanding of what really is in the data sources Startup Analysis End-user Drafting Interaction design Verification

Ontopia AS15 End-user Well-known IA/UX exercise –competency questions –personas –end-user interviews –card sorting –... Ontology modeller + IA/UX person + end-user examples Startup Analysis End-user Drafting Interaction design Verification

Ontopia AS16 Drafting The ontology modeller produces a draft –should use diagrams to communicate design –UML, ORM, boxes-and-arrows, or (later) GTM Draft must be reviewed with project team –editors, developers, project manager –nobody reads documentation –if they do, they don’t understand it, anyway Startup Analysis End-user Drafting Interaction design Verification

Ontopia AS17 Interaction design A well-known exercise –experienced interaction designers are out there Ensure that –ontology supports proposed design –ontology and proposed design use a consistent vocabulary Output –normal interaction design documentation –updated ontology Startup Analysis End-user Drafting Interaction design Verification

Ontopia AS18 Verification Final quality assurance on ontology –first conversion from data sources –review interaction design against ontology –verify ontology against output from end-user phase –verify ontology against requirements from startup phase –final team review of ontology Startup Analysis End-user Drafting Interaction design Verification

Ontopia AS19 Guidelines Some examples

Ontopia AS20 What is in the guidelines Heuristics for the correct use of Topic Maps constructs –topic types –type hierarchy –association types –occurrence types (internal and external) –name types The Ontopia ontology design course has the full set –taught in Kevin Trainor’s tutorial yesterday –only a small subset covered here for illustration purposes

Ontopia AS21 Criteria for a good topic type Instances should, by their intrinsic nature, be instances of the type –when shown an example instance and asked “what is this?” end-users should reply with the name of the topic type –instances should be instances of this topic type from the moment they come into being, until they cease existing Should not be context-dependent –not a role type (like “composer”, “employee”, or “subject”) The topic type should be a “natural kind”

Ontopia AS22 Heuristics for association types Keep number of roles as low as possible –decompose n-ary associations if possible Have a consistent set of role types –all instances should have the same set of role types omissible roles is acceptable –do not attach semantics to variation in role types Create a topic for an n-ary association if (and only if) –you want to say something more about the association

Ontopia AS23 Conclusion Further work

Ontopia AS24 Further work The methodology has moved on since the draft was written –need to flesh it out and bring it into line with this presentation Pattern library and base ontology need to be developed –this will follow in a separate phase after the paper is done Input from practitioners wanted! –