|
David Booth, Ph. D. Hp software Semantic Technology Conference 20-May-2008
|
tarix | 08.08.2018 | ölçüsü | 1,45 Mb. | | #61364 |
|
Enterprise Information Integration using Semantic Web Technologies: RDF as the Lingua Franca David Booth, Ph.D. HP Software Semantic Technology Conference 20-May-2008 In collaboration with Steve Battle, HP Labs Latest version of these slides: http://dbooth.org/2008/stc/slides.ppt
Disclaimer This work reflects research and is presented for discussion purposes only. No product commitment whatsoever is expressed or implied. Furthermore, views expressed herein are those of the author and do not necessarily reflect those of HP.
Outline PART 1: RDF: The lingua franca for information exchange - Why
- Focus on semantics
- Easier data integration
- Easier to bridge other formats/models
- Looser coupling
- How
- RDF message semantics
- REST-based SPARQL endpoints
- XML with GRDDL transformations
- Aggregators
PART 2: POC: A SPARQL adaptor for UCMDB - What is UCMDB
- SPARQL adaptor
PART 0 The problem
Problem 1: Integration complexity Multiple producers/consumers need to share data Tight coupling hampers independent versioning
Problem 2: Babelization Proliferation of data models (XML schemas, etc.) Parsing issues influence data models No consistent semantics Data chaos
PART 1 RDF: The lingua franca for information exchange
Why?
Why? 1. Focus on semantics XML: - Schema is focused on how to serialize
- Constrains more than the model
- Parent/child and sibling relationships are not named
- Are their semantics documented? E.g., does sibling order matter?
RDF: Who cares about syntax?
Why? 2. Easier data integration
Why? 2. Easier data integration
Why? 2. Easier data integration Red App has model Need to integrate Red & Blue models
Why? 2. Easier data integration Step 1: Merge RDF Same nodes (URIs) join automatically
Why? 2. Easier data integration (Relationships are also RDF)
Why? 2. Easier data integration Step 3: Define Green model (Making use of Red & Blue models)
Why? 2. Easier data integration
Why? 2. Easier data integration What the Red app sees No difference!
Why? 3. RDF helps bridge other formats/models Producers and consumers may use different formats/models Rules can specify transformations Inference engine finds path to desired result model
Why? 4. Looser coupling Without breaking consumers: - Ontologies can be mixed and extended
- Triples can be added
Producer & consumer can be versioned more independently
RedCust and GreenCust ontologies added Blue app is not affected
How?
How? 1. RDF message semantics Interface contract specifies RDF, regardless of serialization RDF pins the semantics
How? 2. REST-based SPARQL endpoints
REST-based SPARQL endpoints Why REST: - HTTP is ubiquitous
- Simpler than SOAP-based Web services (WS*)
- Looser process coupling
REST-based SPARQL endpoints Why SPARQL: - One endpoint supports multiple data needs
- Each consumer gets what it wants
- Insulates consumers from internal model changes
- Inferencing transforms data to consumer's desired model
- Looser data coupling
How? 3. XML with GRDDL transformations GRDDL is a W3C standard GRDDL permits RDF to be "gleaned" from XML - XML document or schema specifies desired GRDDL transformation
- GRDDL transformation produces RDF from XML document
- Mostly intended for getting microformat and other data/metadata from HTML pages
Using GRDDL for XML document semantics - GRDDL transformation produces semantics of the XML document
Helps bridge XML and RDF worlds Same XML document can be consumed by: App interface contract can specify RDF - Serializations can vary
- Semantics are pinned by RDF
Using GRDDL for XML document semantics See: http://dbooth.org/2007/rdf-and-soa/rdf-and-soa-paper.htm
How? 4. Aggregators Gets data from multiple sources Provides data to consumers
Aggregator Conceptual component Handles mechanics of getting data - Different adaptors for different sources
- REST, WS*, Relational, XML, etc.
- Diverse data models
- Might do caching and query distribution (federation)
Provides model transformation - Plug in ontologies and inference rules as needed
PART 2 Proof-of-Concept: A SPARQL adaptor for UCMDB
IT Service Management (ITSM) Manage IT environment Configuration Management Data Base (CMDB) is central
The HP Universal CMDB (UCMDB) Goal: Maintain a comprehensive and current record of all configuration items (CIs) and their relationships
Example: host information
SPARQL adaptor Enables SPARQL queries Results can be RDF No model transformation (yet)
Architecture of SPARQL adaptor
UCMDB ontology The HP UCMDB ontology defines CI types and relationship hierarchies. Derived automatically from HP UCMDB metadata.
Jena based implementation Jena, ARQ, Joseki developed at HP Labs*.
Query returning a table
Query returning an RDF subgraph
Example RDF result set
Outline PART 0: The problem PART 1: RDF: The lingua franca for information exchange - Why
- Focus on semantics
- Easier data integration
- Easier to bridge other formats/models
- Looser coupling
- How
- RDF message semantics
- REST-based SPARQL endpoints
- XML with GRDDL transformations
- Aggregators
PART 2: POC: A SPARQL adaptor for UCMDB - What is UCMDB
- SPARQL adaptor
Dostları ilə paylaş: |
|
|