extreme Design rapid prototyping of ontologies

eXtreme Design – “rapid prototyping” of ontologies Eva Blomqvist [email protected] Department of Computer and Information Science (IDA) Linköpings ...
Author: Marian Shepherd
7 downloads 2 Views 1MB Size
eXtreme Design – “rapid prototyping” of ontologies Eva Blomqvist [email protected] Department of Computer and Information Science (IDA) Linköpings universitet Sweden Slides partly by Valentina Presutti, STLab, ISTC-CNR, Italy September 24, 2012

1

Example: METHONTOLOGY (~1997) n 

Waterfall-like process consisting of (overlapping) phases 1. 

2. 

3. 

4.  5.  6.  7. 

Specification – document requirements, scope, level of formality etc. Knowledge Acquisition – gathering and studying sources of information Conceptualization – structure the terminology identified in 1, going from glossary to logical formulas Integration – find and select other ontologies to reuse Implementation – represent in formal language using tool Evaluation – verification and validation Documentation

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

eXtreme Design (XD) – Method and tool support n 

eXtreme Design (XD) q 

n 

a method for developing ontologies with Content Patterns

XD tools a tool that supports the XD method q  released as both an Eclipse plugin and a NeOn Toolkit plugin q  Can be used with the NeOn toolkit version 2.3.2 and older http://neon-toolkit.org/wiki/Download/2.3.2 q 

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

eXtreme Design – General idea n  n 

XD is a general approach to ontology engineering Local Use Case (LUC) q 

n 

Generic Use Case (GUC) q 

n  n 

represents the current modeling issue represents a generic problem that is solved by the associated ODP

GUC and LUC are represented in a compatible comparable way – Competency Questions? What ODP to reuse? q  q 

The one where LUC matches GUC Note: GUC are often more abstract than LUC

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

What kinds of “requirements” are used to describe use cases? n 

n 

Viewing an ontology as a black box… what should that box provide? “Functional requirements” q  q  q  q 

n 

Query results? Inferences? Error checking? …

Internal structure, and content

“Non-functional requirements” q  q  q  q  q 

Coverage Efficiency Documentation Changeability – extendibility …

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

5

Overall structure, acceptance è Guidelines and rules for development

Requirements Engineering – Competency Questions n 

Competency Questions (CQ) = Natural language questions that ask for information the ontology should be able to provide to a user (or system) q  q 

n 

C.f. functional requirements for software Related to software requirements – “input” and “output” of the “ontology component” (including query engine, reasoner…)

Different kinds q 

Simple lookup queries n 

q 

Who are the participants of a certain course?

Expressing inferences or constraints n 

n 

Given that people may have children, is a specific person a grandparent or not? Is a person married to two people valid according to Swedish law?

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

6

Requirements Engineering – Competency Questions (cont.) n 

To clarify complex CQs we use q  q 

n 

A contextual statement expresses an axiom that needs to hold in the ontology, in natural language q  q 

q 

n 

Contextual statements Inference (reasoning) requirements

Every course has at least one participant A grandparent is someone who has a child who in turn also has a child In Sweden you can only marry one person

Reasoning requirements specify the input and output data for a reasoning task q 

We would like to be able to query directly for all the grandparents – classification based on the axiom above

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

7

Reuse n 

Ontology Design Patterns q  q  q 

C.f. software design patterns Different kinds – for different purposes Content ODPs – solves modelling problems in a domain n  n 

n 

Available as components Ontologydesignpatterns.org

Existing ontologies q  q 

You have already used FOAF for other task Search engines for finding ontologies, e.g. http://kmi-web05.open.ac.uk/WatsonWUI/

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

8

Matching GUC and LUC n 

A LUC can be completely or partly described exactly in terms of the GUC q  q 

n 

A LUC is a more specific case of the GUC q  q 

n 

Guc: Performing in a concert Luc: John Coltrane performed in a concert in Japan in 1966 Guc: Participating in an event Luc: Mary attended a scientific conference

A LUC can be described in terms of part of the GUC q 

q 

Guc: Participating in an event held in a certain place at a certain time Luc: Mary attended a conference in Italy

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

Why the name “XD”? n  n  n 

Inspired by XP J with focus on design An agile methodology for web ontology design It is part of the NeOn methodology

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

XD principles n  n 

n  n  n  n  n 

Customer involvement and feedback Customer stories to derive CQs (+ contextual statements, reasoning requirements)

CP reuse and modular design (ontology networks) Collaboration and integration Task-oriented design Test-driven design Pair design

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

XD Iteration

Project(( idea(

Project(ini2a2on(( and(scoping(

Iden2fying(CP(( catalogues(

Design(team(

CP(( catalogues(

Seman2c( Web(

Design(team(

Collec2ng(( requirement(stories(

Stories( Customer(

Design(team( Selec2ng( story(

Design(pair(

Elici2ng(requirements( and(construc2ng( module(s)(( from(CPs( No(

Releasing(( module(s)(

All(stories( covered?(

Integra2ng(par2al( solu2ons,(evalua2ng(( and(revising(

Integra2on(team(

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

Releasing(( new(version(of( Ontology(Network(

Ontology(( Network( Customer(

XD Iteration

Project(( idea(

Project(ini2a2on(( and(scoping(

Iden2fying(CP(( catalogues(

Design(team(

CP(( catalogues(

Seman2c( Web(

Design(team(

Collec2ng(( requirement(stories(

Select' story'

Stories( Customer(

Design(team( Elici$ng'' requirements'

Selec2ng( story(

Select' set'

Matching'and'' selec$ng'pa8erns'

Design(pair(

Elici2ng(requirements( and(construc2ng( module(s)(( from(CPs(

Reusing'and' integra$ng'CPs'

No( No'

Tes$ng'' module''

Releasing(( module(s)(

All'require= ments' covered?'

All(stories( covered?(

No'

Releasing'' module(s)'

All'stories' covered?'

Integra2ng(par2al( solu2ons,(evalua2ng(( and(revising(

Integra2on(team(

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

Releasing(( new(version(of( Ontology(Network(

Ontology(( Network( Customer(

XD – Method steps n 

Tasks 1-2: Project initiation and scoping, collecting resources q 

q  q 

q 

n 

Task 3 – Collect requirements stories q  q 

n 

Essential to understand the context and task of the ontology Customer involvement – domain experts Setup the project environment (collaboration support) + the resources to be used Agree on general “rules”, e.g. naming conventions Example scenarios (cf. the stories of the exercise) Should be short and “modular”

Select a story (each design pair!)

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

XD – Method steps n 

Task 4.1 – Transform the story into CQs q  Divide&Conquer strategy in the large – each pair works on one story at the time Stories are associated with priority values n  Based also on design pair competencies Derive requirements from the text n 

q 

n  n 

q 

n 

CQs, contextual statements and reasoning requirements Check with customer representative & SW developers

Should correspond to actual queries/tasks that the user/ system need to pose/perform

Select a CQ (each pair iterates) q  q 

q 

…or coherent set of CQs Together with associated contextual statements & reasoning requirements Divide&Conquer strategy in the small – pair iterates over CQs and creates module(s)

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

XD – Method steps n 

Task 4.2 – Matching and selecting ODPs q 

q 

q  q  q  q  q  q 

How? Either only intellectually or with some tool support e.g. XD Selector Can I describe my local problem in terms of the general problem of the ODP? Does the ODP solve the same “design issue”? Partial match – Is it worth the overhead? Several ODPs needed – Composition of ODPs In case there is no matching ODP – consider to create one! May exist several options “Rule of thumb” – use the most (domain) specific one applicable

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

XD – Method steps

n 

Task 4.3 – Reuse and integrate selected Content ODPs q  q  q  q 

Specialize Import Extend Integrate (compose)

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

XD – Method steps n  Task 4.3. Test and Fix – Unit tests 1. 

SPARQL queries Assume the following CQ: What role did a certain person play in the production of a certain play during a certain time period? SELECT ?person ?role ?play ?startTime ?endTime WHERE { ?rolePlaying a :PlayingSituation . ?rolePlaying :personPlayingRole ?person . ?rolePlaying :rolePlayed ?role . ?rolePlaying :playedInProduction ?production . ?production :productionOfPlay ?play ?rolePlaying :playedDuringTime ?timeInterval . ?timeInterval :hasStartDate ?startTime . ?timeInterval :hasEndDate ?endTime . }

2.  3. 

Producing inferences “Stress testing”

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

XD – Method steps n 

Task 5 – Release module q  q  q  q 

n 

Make sure the module is commented and ready Post the module so that it is accessible by the other pairs Post any new reusable Content ODP developed Taken over by integration pair

Task 6 – Integrate, test and fix (integration team) q 

Integrate with overall ontology so far n  n 

q 

n 

Alignment may be needed Refactoring may be needed

Run all unit tests based on all included requirements

Task 7 – Release new version of the ontology q  q  q 

Distribute Generate documentation Check customer satisfaction, i.e. evaluation of overall ontology including non-functional requirements

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

XD Summary n 

n 

n  n 

XD is an agile method – start building small modules that solve a few requirements, then add more, we don’t decide on all the requirements at once Testing is essential – by figuring out the test you figure out how the model should work! Collaboration is essential Many problems are resolved in the integration phase – alignments or refactoring? q 

n 

Need for good overall design policies

You are about to experience the method!

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

Exercise n  n  n 

Build an ontology collaboratively From scenario, via requirements to implemented model Follow the XD methodology q  q  q  q 

Derive requirements Reuse Model Document n 

n 

q 

n 

Try to finish one module at least by 2pm

Joint hand-in by all groups q  q 

n 

Release and integrate

Second group who is finished – integration team! q 

n 

In the module use RDFS-annotation properties and/or an annotation schema like http://www.ontologydesignpatterns.org/schemas/cpannotationschema.owl In the wiki (request an account to be able to edit page): http://ontologydesignpatterns.org/wiki/ Training:Semantic_Technologies_in_Practice_PhD_course_in_Link %C3%B6ping_2012/XD_collaborative_OE

Each group sends what they have produced Integration team sends integrated ontology to everybody

Short discussion at 15:50

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

21

Department of Computer and Information Science (IDA) Linköpings universitet, Sweden

September 24, 2012

22