IPAS project:

1
IPAS project

• Providing a Knowledge Desktop

Gary Wills, Richard Crowder, Nigel Shadbolt and
Sylvia Wong July2008
2
Structure

• Overview of the projects aims
• Southamptons aims
• Demonstrators
• One for each year

3
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.

4
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.

5
IPAS the concept
Involving - knowledge extraction - process
modelling - life cycle cost
6
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
• DSS

7
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.

8
Southamptons aims
9
Southampton AKT Project goals

• Design a Semantic Web infrastructure for the
  designers 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.

10
Soton High Level Research Goals

• Role based
• Limits the viewing of information including
  triples, graphs data etc, based on the persons
  role and the document meta data.
• User model, to allow definition access
  parameters.
• Document metadata contains provenance and
  associated document classification.
• Sociotechnical approach to Engineering Design
  Web 2.0.

11
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

12
Planned Architecture
Heterogeneous resources
13
Service Oriented Architecture
Web Browser
Designer Desktop
User Applications
Portal
Workflow engine
Authentication, access control
Middleware
Service registry
Ontological reasoning engine
Web/Grid Service Communication Fabric
Design document archive
Service report archive
Application ontologies
Life cycle cost modeller
External Services
14
Demonstrators
15
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

16
Demo 1
17
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?

18
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

19
Deterioration Mechanisms
20
Creating new semantic (RDF) documents using forms
and IPAS ontology
Editing repairability requirements
21
Picture of Deteriorated Part
22
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

23
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.

24
Demonstrator 3 Overview
Service Designer Identifies the fault and
contains the problem
Product Designer Designs Problem Out
Knowledge Builder Develops Mechanism Records
Knowledge Builder Populates Solution folder
Service Engineer Information access synthesis
25
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)

26
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.

27
Demonstrator 3 domain
IPAS Glue
Information on other servers
Content Management System
Investigate problem
Contain problem
Problem
Root cause analysis
Create new Mechanism Record
Verification
Launch task
Solution
Create new Solution folder
Brainstorm new mechanisms
Accept reject and group mechanisms
Maintain Solutionfolder
Evidence search
Design for service tool IPAS document search
28
Infrastructure 3
User Interface
Client
Portal
Portal Framework
Provenance
Workflow
Authentication
Server
Middleware
Triple store Sesame
K-Search
Mechanism Record
Knowledge Builder Update
Internet
Disruption Index Help
Solution Folders
External Resources
Storage
Services
29
Enter new Mechanism Record
Select k-search
Select from pull down boxes
Enter free form text
30
Search and Review
Search from pull down boxes
Advanced search
Review all returns
31
Review Mechanism Record
32
Solution Mechanism Record
Folder name
Included Mechanism Record
Include/exclude Mechanism Record
Excludes Mechanism Record
33
Process
K-Search Searching legacy documents for snippets
of information to include in a new mechanism
record
IPAS MR Window
K-Search Process
IPAS MR Window
K-Search is loosely coupled, all interaction is
via web services
Triple store
34
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

35
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.

36
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.

37

• Questions and Comments?