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?
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο