Service

IPAS project:

Providing a Knowledge Desktop

Gary Wills,
Richard Crowder
, Nigel Shadbolt

and Sylvia Wong


July2008

Structure

•
Overview of the project’s aims

•
Southampton’s aims

•
Demonstrators

–
One for each year


Why IPAS

•
A fundamental shift is occurring in many industries away
from the selling of products to the provision of services.

–
Essential to the long
-
term success of businesses in this
emerging global environment is the creation of new
Integrated Products And Services (IPAS).

–
These require knowledge transfer between three very
different worlds:

•
new service design,

•
new product design, and

•
the operation of existing products and services in the
field.

The primary objective of IPAS

•
“to develop and exploit technologies aligned to the call,
such as meta
-
data, semantics, ontologies, text mining,
search, social interactions, knowledge representation and
semantic web services to enable the right information to be
provided to the right person in the right form at the right
time”.

•
Large heterogeneous resources, in many location around
the world.

IPAS
–

the concept

IPAS

New
Product

Design

New
Service
Design

Operation of
Existing
Products &
Services

Involving:


-

knowledge extraction


-

process modelling


-

life cycle cost

Partners

•
Partners

–
University of Aberdeen: Ont0logy Management

–
University of Cambridge: 2 groups Engineering Processes

–
University of Leeds: Work Psychology

–
University of Sheffield: NLP

–
University of Southampton

•
Semantic infrastructure (AKT)

•
Life Cycle Costing modelling (UTP)

–
Epistemics

–
Rolls Royce

–
DS&S

IPAS Deliverables

•
IPAS deliverables include:

–

a Designer Knowledge Desktop,

–

defined work social issues and solutions,

–

process simulations and optimisation,

–

and a life cycle cost modelling toolkit.


Southampton’s aims

Southampton AKT: Project goals

•
Design a Semantic Web infrastructure for the designer’s
desktop

–
Define services and applications from partners for
integration

•
Deliver and evaluate demonstrators with RR

•
Inform industrial partners of the benefits of Semantic Web
technology and Web Services.

Southampton (AKT) deliverables

•
Knowledge desktop

demonstrator 1

–
Based on existing AKT technologies

–
easy to integrate third part tools (e.g. Google
search API)

•
Knowledge desktop

demonstrator 2

–
Development of middleware

–
Limited set of web services to answer general
question

•
Knowledge desktop

demonstrator 3

–
Focused in solving a particular KM problem in RR

–
Inclusion of further web services

Planned Architecture

Design

documents

Service

reports

Other

databases

Collate data

User interacts

with GUI

Semantically aware middleware

Reasoner accepts and

replies to query requests

Heterogeneous
resources


Service Oriented Architecture

Web Browser

Designer

Desktop

Portal

User

Applications

Middleware

External

Services

Workflow

engine

Service

registry

Application

ontologies

Authentication,

access control

Web/Grid Service Communication Fabric

Design

document

archive

Service

report

archive

Life cycle

cost modeller

Ontological

reasoning

engine

Demonstrators

Demonstrator one

•
Demonstrated how to integrate web services

–
20 web services based on AKTive space

–
Simple semantic search using drop down boxes
to control the vocabulary.

–
Presented data in graphs

–
Google search as an outside web service

–
Just Southampton, other getting there
technology together

Engine parts

Engine

From

To

1996

1997

1998

1999

2000

2001

1999

2000

2001

2002

2003

2004

Compression

Variable vane

Bushing assembly

Turbine

HP turbine blade

HP nozzle guide v

…

…

Trent 500

Trent 700

Trent 800

Trent 900

Year

Select for y
-
axis:

Failures per million,

Hours delayed,

Cost of repairs, etc

Links to docs

in design

definition

folder
–


DEM

DDR

Comms sheet

Expert search

Select
parameter

Select point of interest to
link to supporting
documents

Demo 1

Demo 2:

•
Started to focus on the needs of RR more.

•
Cambridge set out 39 questions that designers would like
answered.

–
Supported by interviews and literature survey

–
Aberdeen, Sheffield and Soton provided services to
supply answers to the 4 questions. These gave the
widest functionality. i.e.

•
What are the common failure mechanisms associated
with part X.

•
Can I see a picture showing a failed/damaged part?

Technologies Demonstrated 2

–
Dynamic pruning of tree menu for user navigation
of parts

–
Automatic generation of summary statistics from
RDF

–
Retrieval of images from semantic annotation

–
Semantic queries with reasoning

–
Links to original documents (legacy documents)

–
Creating new semantic (RDF) documents using
forms and IPAS ontology

–
Portal framework (liferay) used, and modular

Deterioration Mechanisms

Fault

Found

Reports where

above fault

were found

Creating new semantic (RDF) documents
using forms and IPAS ontology

Editing repairability

requirements

Picture of Deteriorated Part

Demo 2:

•
Infrastructure not as wide as proposed

–
Used Sesame for triple store.

–
Workflow engine not required by RR.

–
Any commercial partner needed to be careful about
realising confidential documents.

–
Not so easy to extract triples from legacy documents.

•
Sparse data in lagacy documents



Demo 3:

•
Focused on a RR business process.

•
To demonstration an abstraction of the core
technologies to permit the delivery of the IPAS
vision.

•
It must demonstrate how technology could be use
to address a realistic number of questions from the
service and design world.

Demonstrator 3 Overview

Service Engineer

Information access
& synthesis

Service Designer

Identifies the fault

and contains the problem

Knowledge Builder

Develops

Mechanism Records

Product Designer

Designs

Problem Out

Knowledge Builder

Populates

Solution folder

Definitions

•
Mechanism Record

–
Applies to specific fault on a specific part

•
Solution folder

–
Used to design “against”

–
An audited collection of fault reports

–
Applies to a part or system in a product

–
Major parts only (circa 100 per product)



Demo 3:

•
The questions should be technology challenging to address,
and thereby highlighting the capabilities of the technologies
within the demonstrator.

•
To provide an environment that will permit the knowledge
builder to build the Mechanism Record.

•
It should be noted that the end user will not be knowledge
specialist, but domain specialist (designer). The Knowledge
builder will be considered a knowledge specialist.


Demonstrator 3 domain

Launch task

Create new

Solution

folder

Brainstorm

new

mechanisms

Evidence


search

Accept reject

and group

mechanisms

Design for
service tool

IPAS document
search

Maintain

Solution

folder

Create new

Mechanism

Record

Mechanism


Record

Documents

Solution

folder

Problem

Investigate

problem

Solution

Verification

Mechanism


Record

Documents

Solution

folder

Root cause

analysis

Contain

problem

Content Management

System

Information

on other servers

Mechanism Record

Mechanism

Record

Documents

Solution

folder

Mechanism


Record Repository

IPAS
Glue

Infrastructure
–

3

Client

Server

Internet

Authentication

Provenance

Workflow

Middleware

Mechanism

Record

Disruption Index

Help

Solution

Folders

User Interface

Portal

Portal

Framework

Knowledge Builder

Update

Storage

Triple store


Sesame

K
-
Search

Services

External

Resources

Enter new Mechanism Record

Enter free form text

Select from

pull down

boxes

Select k
-
search

Search and Review

Search from pull

down boxes

Advanced search

Review all

returns

Review Mechanism Record

Solution Mechanism Record

Folder name

Included

Mechanism

Record

Excludes

Mechanism Record

Include/exclude

Mechanism Record

Process

IPAS MR

Window

K
-
Search

Process

IPAS MR

Window

Triple

store

K
-
Search

Searching legacy documents for snippets of
information to include in a new mechanism
record

K
-
Search is loosely coupled, all

interaction is via web services

Evaluation

•
Expert Review with 12 designers at Rolls Royce Derby

•
Functionality evaluation was undertaken

•
Limited to a knowledge view
–

how quickly could a designer
extract knowledge to resolve a specific query

•
Positive response, main points related to HCI, not the
concept


•
Further evaluation is underway


Summary

•
Demonstrators incorporate knowledge desktop
functionality

•
The desktop both creates and searches semantically
enabled documents. On the creation side, each piece
of information is stored as a triple, with the property
+ value pair as shown on screen .

•
Documents entered can then be searched using the
ontology. For example over the engine parts, feature,
and mechanism axes.



Summary
-

2

•
The desktop also demonstrates the loose coupling
nature of web services.

•
The server software is developed in Java and hosted
on Linux. The user interface software is written in C#
and hosted in Windows, demonstrating how two parts
of the software can be developed and deployed on
two different platforms using a language neutral
interface.


Questions and Comments?