005 Day3-semantic te.. - Buffalo Ontology Site

advertisement
Overview of Semantic Tools
Semantic Technology Boot Camp
Day 3
Overview
▼ Categories of Semantic Tools
▼ Category Overview
 Purpose & Role in Architecture
 Example Tools
 Tradeoffs and Evaluation Criteria
2
Categories of Semantic Tools
▼ RDF Parsers
▼ Triplestores
▼ Ontology Editors & Workbenches
▼ SPARQL Query Engines
▼ Reasoners
▼ Middleware & Servers
▼ Ontology Documentation Tools
▼ Web Development Kits
▼ Specialty Libraries
3
RDF Parsers
Like an XML parser, an RDF parser is a software library that
will interpret an RDF dataset (or ontology) and construct a
memory model of the graph described.
▼ Open Source: Jena, OWLAPI, Raptor.
4
Triplestores
A triplestore (also “triple store”) is a type of database
optimized for the storage and retrieval of RDF data.
▼ Commercial stores: Allegrograph, Stardog
▼ Open Source stores: Virtuoso, Sesame, Mulgara
5
Ontology Editors & Workbenches
An ontology editor offers a visual interface for the
composition of OWL ontologies. Many editors go
further and offer facilities for ontology publishing, batch
operations and script processing over a set of
ontologies.
▼ Commercial: TopBraid Composer
▼ Open Source: Protégé, NeOn Toolkit
6
SPARQL Query Engines
A SPARQL query engine will evaluate a SPARQL
expression over a specified graph and return an
appropriate response for the expression type (ASK,
CONSTRUCT, DELETE, SELECT, etc.).
▼OpenSource: ARQ
7
Reasoners
A semantic reasoner (aka “rules engine”) will apply inherent
and specified rules to infer new facts (as triples) from a given
set of asserted triples.
▼OpenSource: OWLIM, Pellet
▼Commercial: RacerPro, OntoBroker
8
Ontology Documentation Tools
Ontology documentation tools will parse an ontology file
and produce formatted documentation generally in HTML
or PDF form.
▼Open Source: Neologism
▼Commercial: UISPIN
9
Web Development Kits
Web development kits for RDF datasets and ontology
provide dynamic interfaces to a triplestore to facilitate
search and exploration of RDF content.
▼Open Source: Open Semantic Framework
10
Leveraging existing (non-RDF) data
Day 3 - Basics
Overview
▼ Mapping relational data to RDF using D2RQ
▼ Mapping Excel Documents to RDF
▼ Mapping XML to RDF/OWL
▼ Other Mappings (JSON, UML, Java/EMF Objects)
12
Mapping relational data to RDF using D2RQ
▼ Problem Description
▼ Custom Importers
▼ The D2RQ Approach
▼ Related Mappers
▼ Mapping SPARQL to SQL
13
Mapping Excel Documents to RDF
▼ Similar to the RDBMS conversion problem.
▼ Spreadsheets lend themselves to complex tabular
structures.
▼ Schema and data can appear anywhere.
▼ One sheet may have any number of independent
tables.
▼ Meaning given to style. I.E. bold, italic, font color or
cell color may encode meaning.
▼ Multiple cells and formulas.
14
Mapping XML to RDF/OWL
▼ The XML Data Model
▼ Mapping Between Data Models
 Finding Meaning between XML Nodes
▼ Custom Conversion
▼ Tools and Toolkits
15
Mapping XML to RDF/OWL
Differences in XML
• The XML model is a tree structure.
• XML provides structure to a document.
• The XML utility is data packaging for transmission as
messages.
• Uses schema for conformance validation.
• Provides a standard that allows parsers to interpret
any XML document.
16
Other Mappings
▼ Converting JSON
▼ Importing UML
▼ Importing EMF Objects
17
Sample Applications
18
Design time applications
19
Process for Inter-Agency Shared Understanding
▼ Completed Work on
 Weather
 Integrated Surveillance
▼ Started Work on
 Unmanned Aircraft System
 Flight and Flow
▼ Key Deliverables
 COI Ontology
 Business Context (DoDAF Artifacts)
 Other Artifacts
▼ Consistent with DoD Net-Centric Data Strategy
COI Ontology
(RDF/OWL)
Transformation Rules
(XSLT)
Business Process
Analysis
(OV-2)
Message Schema
(XSD)
Information Exchange
Description
(OV-3)
Service Description
(WSDL)
Operational Activity
Model
(OV-5b)
Architectural Impact
Report
Requirements Document
(SV-4)
Business Rules
Service Constraints
Systems Communications
Description
(SV-2)
20
Ontology Portals
▼ Purpose:
 To be a collaborative web application through which users can publish, access,
search, browse, map, and update ontologies and their terms.
 Reference Implementation only
▼ Supports:
 COI participants (e.g., ontologists, SMEs, and enterprise architects), developers
and managers.
Example Portals
National Center for
Biomedical Ontology
BioPortal
Marine Metadata
Interoperability Ontology
Registry and Repository
Air Force Vocabulary
OneSource
Open Biomedical
Ontologies Foundry
21
Semantic Metadata Catalog and Portal Architecture
Service
Registration
and Discovery
NextGen
Ontology
Community
Semantic Metadata Catalog and Portal
JPDO User Interface
Layer
Semantic Processing
Layer
Semantic
Metadata
Portal
Semantic
Metadata
Catalog
Ontology
Portal
External
Systems
Integration Layer
Integrated
Surveillance
Community
Service
Registration
and Discovery
Web Services Layer
Weather
Community
UDDI
Existing
SOA
Registry
Integration
of
Federated
Registry
ebXML
Artifact
Catalog
GIIEP
SWIM
Access
Color Key:
Semantic
External
Future
22
Sample Ontology Portals
▼ NCBO BioPortal
 http://bioportal.bioontology.org/
▼ One Source
 http://onesource.afc2ic.org/
▼ Marine Metadata Interoperabiligy (MMI) Ontology
Registry and Repository (ORR)
▼ http://mmisw.org/
23
Run time application
24
SMB Approach: Semantics to Solutions
SOA
Foundation for Service Interoperability
Semantics Mediation Bus™
Semantics
Common Understanding of Business Concepts
Runtime infrastructure enables semantic
interoperability through common ontologies, even
if the services are implemented using different
data models and message standards.
Problems
•
•
•
How I can improve Interoperability between different services
and reduce system integration costs?
I have already invested a lot in my SOA infrastructure, how
do I leverage it for for Semantic Interoperability?
How can Semantics help reduce service development cost
and help my enterprise operations?
25
SOA: Benefits and Limitations
•
Service Oriented Architecture (SOA)
•
Key Benefits:
− Provides standards based mechanism to access Services at the transport and protocol level
− Promotes re-use of existing services
− Enables fast adaptation to business needs
− Aligns information resources to business goals
•
Limitations:
− Current Web Service standards provide the syntactic description of the service interface, but do not
describe the meaning or the semantics of the data or behavior. Hence the consumer of the service;
whether another service or a human, needs to have intimate knowledge and awareness about the data
and its elements
− Current Enterprise Service Buses (ESBs) don’t have an out of the box ability to perform Semantic
Mediation, that is the transformation and co-relation of data elements and services based on a predefined vocabulary
− Manual intervention and deep domain knowledge is required to develop custom mappings to correctly
use data exposed by these related but different Web Services
26
Demo: Traditional SOA
Service Consumer
Google Earth
Client
FAA
Original
Track Data
Provider
27
SOA Silos
Airline Code Lookup Table
Data: UA
Flight
Track
Display
User
1
3
1
AF SME
AF Flight
Track
Web
Service
2
3
Developer
2
Reference
Human Communication
Custom
Mapping
Custom
Development
Field Name:
Commercial Flight
Data: 122
FAA Flight
Track Web
Service
Field Name: Flight of
Interest
Data: United 122
System Integration
SME
Custom
Mapping
Other
Data
Provider
HR
HR
Army
Marine
Field Name:
FlightID
Data: UA122
Excess time is spent interpreting data from different sources despite the
usage of advanced IT techniques like Web Services
SLIDE 28
28
Problem with Custom Development
▼ Discovery of Relevant Information
▼ Human in the Loop for Interoperability Assessment
▼ Custom Mapping and Custom Development
 Often requires significant resources and takes a long time
▼ Change Management
 Transformation often embed in code
 Code and ontology could become disconnected
29
Demo: SOA Silo
Service Consumer
Google Earth
Client
FAA
Original
Track Data
Provider
Air Force
Alternate
Track Data
Provider
30
Demo: Semantic Service Provisioning
Service Consumer
FAA
Google Earth
Client
Original
Track Data
Provider
SOA Infrastructure
Air Force
Alternate
Track Data
Provider
Discover
Semantic
Metadata Catalog
Annotation
31
Benefits of Semantic Service Provisioning
▼ Discovery of Relevant Information
 Beyond traditional keyword search
▼ No Need for Human in the Loop for Interoperability Assessment
 Machine readable ontologies describe relationships among concept
▼ Avoid Custom Mapping and Custom Development
 Faster Development Lifecycle
 Reduced Development Cost
▼ Built for Change
 Allow transformations and business rules to be managed independent of
the code
 Consistent with Model Driven Architecture principals
32
Open Standard Compliance
▼ Web Ontology Language (OWL)
▼ Semantic Annotations for WSDL and XML Schema (SAWSDL)
▼ Minimal Service Model (MSM) and WSMO-Lite
▼ Extensible Stylesheet Language Transformations (XSLT)
▼ Web Service Definition Language (WSDL)
Semantics
OWL
SAWSDL
WSMO-Lite
WSDL
SOAP
REST
XML
XSLT
URI
Services
Data
33
Minimal Service Model
Source: http://cms-wg.sti2.org/minimal-service-model/
34
Semantic Annotations for WSDL and
XML Schema (SAWSDL)
•
Relate the Service and Message description to the meaning captured in an Ontology.
– Annotations can be applied to all WSDL elements and XML Schema types.
•
Define transformation between wired message format and the ontology
representation.
XML Schema
Enterprise Vocabulary
ont:AirTrack
a rdfs:Class
… …
<xsd:ComplexType name=“FlightTrack”
sawsdl:modelReference=“… …”
sawsdl:liftingSchemaMapping=“…”
sawsdl:loweringSchemaMapping=“…”>
Import
XSLT
SPARQL+XSLT
WSDL
<operation
<input
Service Ontology
name=“getFlightTrack”
sawsdl:modelReference=“… …”>
svc:airTrackProvider
svc:payload ont:AirTrack
… …
message=”…”>
SLIDE 35
Alion Semantic Mediation Bus™
•
An ontology-based web services mediation component (Semantic Mediator) that enables
services with different message formats to interoperate
•
Embedding the Semantic Mediator in an Enterprise Service Bus (ESB) enables runtime
semantic mediation within traditional SOA infrastructure, creating a Semantic Mediation
BusTM
Common
Ontology
Semantic Mediation BusTM
Enterprise Service Bus
Semantic Mediator
Web Service Proxy
Message Schema Mapping
Registry/ Repository
Semantic Lookup and
Interoperability Assessment
Semantic
Annotation
Metadata
Management
Protocol Adaption
Traditional SOA infrastructure
Message
Transformation
Message Routing
Security
Service Discovery
Semantic Mediation
Infrastructure
36
Semantic Mediation:
Dynamically Map Information to User Needs
Flight
Track
Display
Semantic
Mediation
Bus™
FAA
Web
Service
HR
Army
Airline Code Lookup Table
Data: UA
Field Name:
Commercial Flight
Data: 211
Reference
User
Semantic Lookup
Field Name: Flight of
Interest
Data: UA211
Air Force
Web
Service
Common Air
Track Ontology
Message
Transformation
Web Service
Endpoint
3rd Party
Web
Service
HR
HR
Army
Marine
Field Name:
FlightID
Data: United 211
37
Demo: Semantic Service Mediation
SOA Infrastructure
Service Consumer
FAA
Google Earth
Client
Original
Track Data
Provider
Alion Semantic
Mediation Bus™
Dynamic
Service
Endpoint
Message
Transformation
Semantic Discovery
Interoperability Assessment
Air Force
Alternate
Track Data
Provider
Semantic
Metadata Catalog
Annotation
38
Key Characteristics
▼ Cooperation through federation, instead of standardization
 The ontology driven approach avoids imposing a standard that has to be agreed by
everybody, thus allowing the agencies to select the formats best suited for their
business needs, while still being able to use services offered by other agencies.
▼ Increased ability to adapt to the ever changing business needs in a timely
and cost effective manner
 The semantic mediation approach encourages transformation logic to be
declaratively defined in the ontology, instead of buried in the code, often in multiple
places.
▼ No need for rigid conformance
 Through loose coupling, the SMB allows transformation between message formats
which might not be a complete match.
▼ Building on SOA infrastructure, instead of replacing it
 By extending ESB infrastructure, organization can leverage their SOA investment
and the existing expertise of their personnel.
39
Extensibility Considerations
▼ Pluggable to SOA Platforms
 Integrate with existing Enterprise Service Buses (ESB)
 Interact with Service Registry (ebXML, UDDI, proprietary)
▼ Adaptable to Service Design Choices
 Mediate SOAP-based Web Services
 Support REST and Plain XML Data
 Service Metadata
▼ Provide Intelligent Mediation
 Assess service compatibilities based on semantics
40
Technical Architecture
Traditional SOA
infrastructure
Service Consumer cannot
process the WSDL as
implemented by the provider
WSDL
WSDL
However, the WSDL
messages can be traced to an
ontology understood by the
consumer.
XML
Schema
XML
Schema
SAWSDL
Annotation
Lifting and
Lowering Rules
SAWSDL
Annotation
OWL Ontology
Semantic Lookup
Message
Transformation
Web Service
Aggregation Proxy
Extension API
Semantic Mediation Bus
The engine
dynamically exposes
a web service
endpoint as a proxy
to the service. The
endpoint expose a
WSDL that can be
accepted by the
consumer
Semantic Mediation
Infrastructure
Registry/Repository
Initial implementation uses
SAWSDL lifting and lowering rules,
which define how XML messages
are transformed to and created from
an ontology
Lifting and
Lowering Rules
Extension Framework
XML/WSDL-OWL
Mapping
Interoperability
Assessment Algorithm
Mediation Engine
is implemented as
component of the
ESB.
ESB Adapter
Service Provider
Service Consumer
ESB API
Service
Endpoint
Enterprise Service Bus
Service
Endpoint
Service
Endpoint
The service proxy
may aggregate
service from
multiple providers
based on the
need of
consumer.
41
Building Block for Enterprise Solutions
▼ Enterprise Challenge: Data integration is as much an issue as in
the inter-organizational context
 Data mash up solution from disparate systems
 Incorporation of unanticipated sources in business intelligence
 Enhancement of situational awareness through on-demand integration of data
▼ Opportunity: Ontology is not only a tool for understanding, but also
a basis for executable solutions
42
The SMB Message
▼ Put Ontologies to Work
 Enhance service understandability at design time
 Facilitate service interoperability at runtime
▼ Leverage Existing SOA Investment
 Increase service discoverability and interoperability through semantic
annotation
 Build on existing services
 Use in-house expertise
 Ready to deployed now
▼ Streamline Service Integration
 Shorten development lifecycle by eliminating the need for custom message
mapping
 Reduce maintenance cost by leveraging existing infrastructure
43
Download