Post on 30-Dec-2015
transcript
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 11
WISDOM WISDOM (Web Intelligent Search based on DOMain ontologies):(Web Intelligent Search based on DOMain ontologies):
DemoDemo
Sonia BergamaschiSonia Bergamaschi [1], Paolo BouquetPaolo Bouquet [2], Paolo Ciaccia Paolo Ciaccia [3], and Paolo Paolo MerialdoMerialdo [4]
[1] Università degli Studi di Modena e Reggio Emilia[2] Università degli Studi di Trento
[3] Università degli Studi di Bologna [4] Università degli Studi Roma Tre
6 Dicembre 20066 Dicembre 2006
http://www.dbgroup.unimo.it/wisdomhttp://www.dbgroup.unimo.it/wisdom
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 22
OverviewOverview
The WISDOM project aims at studyingstudying, developingdeveloping and experimentingexperimenting methodsmethods and techniquestechniques for searching and querying data sourcessearching and querying data sources available on the Web.
The goal of the project:The goal of the project:
Definition of a software framework that allows computer applications to leverage the huge amount of information contents offered by Web sources (typically, as Web sites)
number of sources of interest might be extremely largesources are independent and autonomous one each other
The context:The context:
These factors raise significant issues, in particular because such an information space implies heterogeneities at different levels of abstraction (format, logical, semantics). Providing effective and efficient methods for answering queries in such a scenario is the challenging task of the project
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 33
OverviewOverview
In WISDOM, super-peers containing data from web-sources referred to the same domain are built. Super-peers are connected by semantic mappings in a Super-peer Network.
The end-user formulates a query according to a specific super-peer. The answer will include data extracted from all the super-peers relevant for the query.
From a functional point of view, the WISDOM project may be divided into two parts:
A) Building a super-peer Network, where Web sources are grouped into super-peers; Each super-peer exports a Semantic Peer Ontology synthesizing
the knowledge of the involved sources; The Semantic peer ontologies are related by means of simple
semantic mappings. B) Querying a super-peer Network, where: A graphical interface allows the user to formulate a query according to
a semantic peer ontology; The query is rewritten for each super-peer interesting for the answer; The query is reformulated inside each super-peer according to the
involved sources The query is locally executed and the results are provided to the user.
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 44
1) Data from web-sites are extracted by means of wrappers
2) Data are annotated according to a lexical reference
3) A semantic peer ontology is created for each semantic peer
4) The semantic peer ontologies are related by means of mappings
Functional Flow-DiagramFunctional Flow-Diagram
1) http://dbgroup.unimo.it/wisdom/prototipi/D1.P4.html
2) http://dbgroup.unimo.it/wisdom/prototipi/D1.P5.html
3) http://dbgroup.unimo.it/wisdom/prototipi/D1.P1.html
4) http://dbgroup.unimo.it/wisdom/prototipi/D2.P1.html
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 55
Building a Super-peer Network: the local Building a Super-peer Network: the local sources sources We tested the system by creating with MOMIS (http://dbgroup.unimo.it/Momis), Road
Runner(http://www.dia.uniroma3.it/db/roadRunner) and MELIS (http://dbgroup.unimo.it/wisdom-unimo/melis), a Super-peer Network composed of three peers, each one integrating 2-3 tourism Web sites:
Peer 1Peer 1 bbitaly http://www.bbitalia.it/default_eng.asptouring http://www.touring.it
Peer2Peer2guidacampeggi http://www.guidacampeggi.comsaperviaggiare http://www.touringclub.com/ITA/viaggiatori/dove_mangiarevenere.comhttp://www.venere.com
Peer 3Peer 3bedandbreakfast http://www.bed-and-breakfast.itbooking http://www.booking.com opificidigitali http://www.opificidigitali.it
…
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 66
Demonstration ScenarioDemonstration Scenario
Peer 1Peer 1 abstracts in the
global classes:
hotelsrestaurants
the local classes:
hotels (bbitaly)restaurants (touring)
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 77
Demonstration ScenarioDemonstration Scenario
Peer 2Peer 2 abstracts in theglobal classes:
hotelscampingsfacilities
the local classes:
hotels (venere)hotels (saperviaggiare)maps (venere)campings
(guidacampeggi)facilities
(guidacampeggi)facilities (venere)
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 88
Demonstration ScenarioDemonstration Scenario
Peer 3Peer 3 abstracts in theglobal classes:
hotelsrestaurantsfeatures
the local classes:
hotels (booking)judgement_hotel
(booking)bedandbreakfast
(bedandbreakfast)features
(bedandbreakfast)restaurants
(opificidigitali)features_bb
(bedandbreakfast)conditions_hotel
(booking)
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 99
Each Super-peer is created extracting data by Road Each Super-peer is created extracting data by Road Runner:Runner:1. Identify sources (Web sites) to be wrapped2. For each source: infer a site schema and collect pages containing information of interest3. From a set of sample pages, infer a wrapper library4. Apply the wrapper library over the set(s) of pages collected in step 2
Wrapping Web SourcesWrapping Web Sources
1. Identify sample pages
Wrapper libraryWrapper libraryOutputdata
2 Collect pages similar in structure to those of the sample set
3 Generate a wrapper library
4 Apply the wrapper library to extract data from pages
Wrapper generatorWrapper generator
All/InDesit: infer site schemaAll/InDesit: infer site schema
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1010
The demonstration:The demonstration:
11 web sites, delivering information about hotels, campings, b&bs, restaurants
The Web site schema inference module (Indesit) was configured (when possible) to collect pages of interest from these sites
Indesit generated a Web schema for each Web site: the output description was used to collect pages about 8000 pages
16 wrappers were inferred by means of the wrapper generation module RoadRunner
The extracted data were stored in 11 relational databases (one per source)
The Indesit Web schemas can be used to refresh data
Wrapping Web Sources: the Demo Wrapping Web Sources: the Demo
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1111
Annotating Data Sources wrt a lexical referenceAnnotating Data Sources wrt a lexical reference
MELIS: Meaning Elicitation and Lexical Integration SystemMELIS: Meaning Elicitation and Lexical Integration System
Reference Ontology
Source annotated with respect to the
Reference Ontology
User validation and further annotations
Input
Lexical Reference
Output
+ Extensions
Data source partially annotated
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1212
Annotating Data Sources wrt a lexical referenceAnnotating Data Sources wrt a lexical reference
Building
Hotel
Name
City
Restaurant
Home page
Building #1
Restaurant #2
Home page #1
City #1
Hotel #1
Name #2
City #1
B&B #1
Name #2Address
Edifice #2
Motel #1
Name #2
City #1
Address #3
Domain Ontology
Domain Ontology
Domain Ontology
Input Ontology
Meaning Elicitation ProcessMeaning Elicitation Process
For each (class and property) element in the Input Ontology, MELIS extracts all candidate senses from WordNet. After this step it filters out candidate senses by using Domain Ontologies and a collection of heuristic rules.
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1313
Annotating Data Sources wrt a lexical referenceAnnotating Data Sources wrt a lexical reference
<owl:Class rdf:ID="BB.bed_and_breakfast"> <rdfs:label>
bed_and_breakfast </rdfs:label> <db:PrimaryKey>
BB.bed_and_breakfast.url </db:PrimaryKey> <lex:wnAnnotation rdf:parseType="Literal"> <lex:lemmaValue>bed_and_breakfast</lex:lemmaValue> <lex:lemmaSyntacticCategory>1</lex:lemmaSyntacticCategory> <lex:lemmaSenseNumber>1</lex:lemmaSenseNumber> </lex:wnAnnotation></owl:Class>
OUTPUT Language: WISDOM-OWLOUTPUT Language: WISDOM-OWL
OWL DL
DB Annotations
Lexical Annotations
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1414
Building a Super-Peer OntologyBuilding a Super-Peer Ontology
Super-peer Ontologies were built by means of the MOMIS system, extended for the specific purposes of the project. In particular, techniques for adding/removing sources to/from a created ontology without restarting the process from scratch were introduced.
The MOMIS process for building a domain ontology is based on the following steps:
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1515
Building Peer 2Building Peer 2
Peer 2 was created integrating the local sources venere (493 hotels), saperviaggiare (977 hotels) and guidacampeggi (183 campings)
Source venerevenerelocal classes:
hotelsmapsfacilities
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1616
Source guidacampeggi guidacampeggi local classes:
campingsfacilities
Source saperviaggiare saperviaggiare local class:hotels
Building Peer 2Building Peer 2
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1717
Peer 2 OntologyPeer 2 Ontology
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1818
Creating inter-peer mappingsCreating inter-peer mappings
Hotels #1
Name #2
City #1
Hotel #1
Name #2
Address #3
Hotel #1
Name #2
PEER 2
PEER 1
PEER 3
URL #1
City #1
Address #3
Logo #1
Price #4
Address #3
Phone Number #1e-mail #1
URL #1
Hotel #1
BBItaly
Hotel #1
Booking
Venere
Hotel #1
For each node of the Peers that are compatible with other elements of other Peers we create a Mapping Element that describe the relationship between them
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 1919
Creating inter-peer mappingsCreating inter-peer mappings
<MappingElement>
<MappingElementID>mappingElement#3</MappingElementID>
<MappingType>Datatype2Datatype</MappingType>
<SourceElement>
</SourceElement>
<TargetElement>
</TargetElement>
<Relations>
<SemanticRelation>
<RelationType>equivalent</RelationType>
<RelationGrade>1</RelationGrade>
</SemanticRelation>
<RelationMeasure>
</RelationMeasure>
</Relations>
</MappingElement>
<SourceElement> <SourceElementID>Peer1.hotels.address </SourceElementID> <SourceElementLabel>address </SourceElementLabel> <AtomicMeaning>address#9#0#C </AtomicMeaning> <ContextualMeaning>address#9#0#C </ContextualMeaning> <DictionaryID>wordnet21</DictionaryID> <Senses> <Sense>107938889</Sense> </Senses></SourceElement>
<RelationalMeasure> <LessGeneralThan>0.0</LessGeneralThan> <MoreGeneralThan>0.0</MoreGeneralThan> <Equivalent> <SameGranularity>1.0</SameGranularity> <LowerGranularityThan>0.0</LowerGranularityThan> <HigherGranularityThan>0.0</HigherGranularityThan> </Equivalent> <Disjoint>0.0</Disjoint> <Overlapping>0.0</Overlapping></RelationalMeasure>
OUTPUT Mappings:OUTPUT Mappings:
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2020
Querying a Super-Peer NetworkQuerying a Super-Peer Network
Querying the Super-Peer Network involves: Formulating the query at a peer on the ontology local to that peer Rewriting the query according to neighboring peers’ ontologies using the
semantic mappings Selecting the peers that are more relevant to the query (using content
summaries and semantic information about the rewritings) Sending the rewritten query to the relevant neighboring peers Translating the query to execute it on the local sources
This involves relaxing preference expressions that are not directly manageable by the underlying query executor
Executing the query locally (by translating it using the local mappings) and sending the results to the local query processor
Collecting the results from both the local sources and the neighboring peers
Building the final result This may involve performing additional computations to enforce the
original preference relation that was relaxed to be performed locally Presenting the result to the user
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2121
Functional Flow-DiagramFunctional Flow-Diagram
GUI (M-FIRE)
Semantic Parser
Q
Query Processor
q
L0 GVV0
q0 (MOMIS Query Manager)
q0
qj
(QP of)peer pj
At peer p0, the user formulates a request using the M-FIRE interface, that produces a query Q in a SPARQL-like syntax.The semantic parser translates the query in an internal format to be easily manipulated by the query processor.The QP rewrites the query with respect to the local ontology (to send the query to the MOMIS Query Manager) or to a remote ontology (to be sent to the QP of a neighboring peer).
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2222
The user interface prototypeThe user interface prototype
The query formulation prototype implements the M-FIRE framework and includes two components: a client component for visual rendering and user interaction handling, and a server component implementing the M-FIRE representation and navigation engines.
Two alternative ways of representing the ontology schemaOne single way of formulating conjunctive queries on the
ontology schemaOne single table-like view of the query results
MetaphorsMetaphors
M-FIRE allows to declaratevely define how a give RDF document shall be graphically represented by supplying metaphors as parameters to a generic representation engine. Metaphors also determine how the user’s actions on the delivered representation shall be translated into queries over the underlying knowledge base. Our prototype includes two metaphors, featuring:
Query Formulation with M-FIREQuery Formulation with M-FIRE
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2323
Ontology schema representationOntology schema representation
After selecting a knowledge base to be explored and a metaphor for its presentation, the user is provided with a representation of the ontology schema. This is how the two alternative metaphors represent a schema:
Query Formulation with M-FIREQuery Formulation with M-FIRE
Classes are rendered as tables, where a left pane is showing an intuitive icon for the class, and the right pane is listing the set of properties which apply to that class.
Each datatype property has a light yellow background and a black font
Each object property has a yellow background and a dark red font; moreover, on the left of the property name, an icon is shown for each class which is in the range of the property
Classes are rendered as tables, where the upper pane is showing an intuitive icon for the class on the left of the class name, and the lower pane is listing the properties which apply to that class
Each datatype property has a cyan background, is written in italic and has a black font; on the right side, the name of each class in the property range is shown
Each object property has a light cyan background and a blue font; moreover, on the right side of the property name, the name of each class in the property range is shown
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2424
Query formulationQuery formulation
Query Formulation with M-FIREQuery Formulation with M-FIRE
Conjunctive queries are formulated by left-clicking or right-clicking on the properties to be included in the result (projection) or for which filters are to be specified (selection)
A left click on a datatype property selects that property for output (object property cannot be selected for output)
A left click on an object property means that the clicked property will be used to perform a join between two classes (each class can only participate in one join with each other class)
A right click on a datatype property allows to express a filter on that property (the operator for comparison and the target value may be specified through a proper dialog box)
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2525
Input to the Query ProcessorInput to the Query Processor
Query with joins are formulated similarly to queries without joins, by specifying the correct path between join properties through mouse clicks.The query is finally passed to the local query processor.
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2626
Query Processor ComponentsQuery Processor Components
Internally, the QP ranks the rewritten queries in order to only execute the “best” ones.Then, the optimizer produces the actual queries that will be sent to the local executor (e.g., by “relaxing” some preferences) or to neighboring peers
Rewriter Ranker
SemanticMappings Content
Summaries
Peers’Metadata
rq1
rqk
Optimizer
Plan Treej
qj,0 qj,i
qj,N
rq1
rqM
q (internal form)
Semantic Parser
Q (SPARQL-like) Ont0
ran
type
dom
name
Restaurant
closing-day
price
xsd:string
cuisine
phone
Rating guide
rates rdf:Property
rdfs:Class
type
rdfs:Datatype
type
type
xsd:boolean
type
dom
ran
dom
dom
dom dom
ranran
ran
type
type
type
weekDay cuisineType
type
dom
ran
value
guidesxsd:integer
typetype
ran
domran
has-smoking-area
ran
dom
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2727
Inter-Peer Query RewritingInter-Peer Query Rewriting
RelationGrade:RelationGrade: measures the similarity among the corresponding
elements
Mapping extension with scoresMapping extension with scores
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2828
Inter-Peer Query RewritingInter-Peer Query Rewriting
Query reformulation exampleQuery reformulation example
BASE <http://www.wisdom.net/ontology#> SELECT ?N ?A ?C ?P ?SFROM Peer2 WHERE {Peer2.hotels Peer2.hotels.name ?N ;
Peer2.hotels.address ?A ; Peer2.hotels.city ?C ; Peer2.hotels.price ?P ; Peer2.hotels.url ?HURL .
Peer2.services Peer2.services.faciltity ?S ; Peer2.services.url ?SURL .
FILTER ((?HURL=?SURL) && (?HURL='Rimini') && (?P>50) && (?P<80) && (?S = 'air conditioning')). }PREFERRING min(?P) LIMIT 50
BASE <http://www.wisdom.net/ontology#> SELECT ?N ?P ?SFROM Peer3 WHERE {Peer3.hotels Peer3.hotels.name ?N ;
Peer3.hotels.price_single ?P ; Peer3.hotels.url ?HURL .
Peer3.features Peer2.features.url ?SURL . FILTER ((?HURL=?SURL) && (?HURL='Rimini') && (?P>50) && (?P<80)). }PREFERRING min(?P) LIMIT 50
BASE <http://www.wisdom.net/ontology#> SELECT ?N ?P ?SFROM Peer3 WHERE {Peer3.hotels Peer3.hotels.name ?N ;
Peer3.hotels.price_double ?P ; Peer3.hotels.url ?HURL .
Peer3.features Peer2.features.url ?SURL . FILTER ((?HURL=?SURL) && (?HURL='Rimini') && (?P>50) && (?P<80)). }PREFERRING min(?P) LIMIT 50
BASE <http://www.wisdom.net/ontology#> SELECT ?N ?P ?SFROM Peer3 WHERE {Peer3.hotels Peer3.hotels.name ?N ;
Peer3.hotels.price_triple ?P ; Peer3.hotels.url ?HURL .
Peer3.features Peer2.features.url ?SURL . FILTER ((?HURL=?SURL) && (?HURL='Rimini') && (?P>50) && (?P<80)). }PREFERRING min(?P) LIMIT 50
Rewriter
UNION
UNION
Source:Source: Superpeer2Superpeer2
Target: Superpeer3Target: Superpeer3
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 2929
The WISDOM Project The WISDOM Project
Query reformulation: details of target outputQuery reformulation: details of target output
Target schema
1st rewritten query
1st query score & percentages
1st query terms rewriting details
Global union score
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3030
Inter-Peer Query RewritingInter-Peer Query Rewriting
The Ranker component of the query processor ranks all the available rewritings (according to user preferences) in order to only execute the “best” ones (e.g., in order to maximize the number of retrieved results, or the semantic similarity of the rewritten query wrt the original one)
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3131
Inter-Peer Query ForwardingInter-Peer Query Forwarding
The QP of the neighboring peer receives the query, solves it locally and (possibly) forwards it to its neighbors (care is taken to ensure that each peer only receives a query once).
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3232
Query Reformulation for Local ExecutionQuery Reformulation for Local Execution
The Optimizer component of the QP translates the rewritten query in SQL (e.g., preference expressions are relaxed into ORDER BY clauses). Finally, the Executor sends the query to the local query executor (MOMIS Query Manager), waiting for the results.
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3333
The MOMIS Query Manager reformulates the query taking into account the intra-peer mappings defined in a semantic peer among the local classes and the global classes of the GVV (Global Virtual View).The mappings are defined by using a GAV (Global as View) approach: each global class of the GVV is expressed by means of the full-disjunction operator over the local classes.
Local Query ExecutionLocal Query Execution
Query rewritingQuery rewriting GAV approachGAV approach: : the query is processed by means of
unfolding
Fusion and ReconciliationFusion and Reconciliation of the local answers into the global answer Object IdentificationObject Identification : Join conditions among local
classes Inconsistencies:Inconsistencies: Resolution functions to deal with
conflits
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3434
Query rewriting and execution Query rewriting and execution
Global Virtual View
(GVV)
query q0 = scqG1 scqG2
Hotels ServicesHotels Services
single class query
scqG1
single class queryscqG2
L3scqG1
L1scqG2
L2scqG1
L1scqG1
L2scqG2
VENERE
hotels facilitiesmap_hotelsLocal Schem
a
SAPERVIAGGIARE
hotelsLocal Schem
a
GUIDACAMPEGGI
facilitiesmap_hotelshotels facilitieshotels facilitiesLocal Schem
a
Query execution on the local sourcesQuery execution on the local sources
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3535
Query rewriting Query rewriting SELECT H.name, H.address, H.city, H.price, S.facility, S.structure_name, S.structure_cityFROM hotels as H, services as SWHERE H.city = S.structure_city and H.name = S.structure_nameand H.city = 'rimini‘ and H.price > 50 and H.price < 80 and S.facility = 'air conditioning'order by H.price
q0 =
SELECT H.name , H.address , H.city , H.price FROM hotels as H WHERE (H.city = 'rimini' ) and (H.price > 50) and (H.price < 80)
scqG1 =
SELECT S.facility , S.structure_name , S.structure_city FROM services as S WHERE (S.facility = 'air conditioning')
scqG2 =
SELECT hotels.name2, hotels.address, hotels.price, hotels.city FROM hotels WHERE ((city) = ('rimini') and ((price) > (50) and (price) < (80)))
L3scqG1 =
SELECT maps_hotels.hotels_name2, maps_hotels.hotels_city FROM maps_hotels WHERE (hotels_city) = ('rimini')
L2scqG1 =
SELECT hotels.name, hotels.address, hotels.city FROM hotels WHERE (city) = ('rimini')
L1scqG1 =
SELECT facilities_hotels.hotel_name2, facilities_hotels.hotels_city, facilities_hotels.facility FROM facilities_hotels WHERE (facility) = ('air conditioning')
L1scqG2 =
SELECT facilities_campings.campings_name, facilities_campings.campings_city, facilities_campings.name FROM facilities_campings WHERE (name) = ('air conditioning')
L2scqG2 =
SINGLE CLASS QUERIES
UNFOLDING UNFOLDING
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3636
Fusion and ReconciliationFusion and Reconciliation
L3scqG1result
set
L1scqG2result
set
L2scqG1result
set
L1scqG1result set
L2scqG2result
set
VENERESAPERVIAGGIARE GUIDACAMPEGGI
partial results
partial results
partial results
L1scqG1 full join full join L2scqG1 full joinfull join
L3scqG1
L1scqG2 full joinfull join L2scqG2
scqG1result
set
scqG2result
set
q0 result set
scqG1 joinjoin scqG2
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3737
Fusion and ReconciliationFusion and Reconciliation
scqG2 result set= L1scqG2 full join L2scqG2
guidacampeggi.facilities full outer join venere.facilities on ((venere.facilities.facility) = (guidacampeggi.facilities.name) AND (venere.facilities.hotels_city) = (guidacampeggi.facilities.campings_city) AND (venere.facilities.hotel_name2) = (guidacampeggi.facilities.campings_name))
scqG1 result set = L1scqG1 full join L2scqG1 full join L3scqG1
saperviaggiare.hotels full outer join venereEn.hotels on (((venereEn.hotels.name2) = (saperviaggiare.hotels.name) AND (venereEn.hotels.city) = (saperviaggiare.hotels.city))) full outer join venereEn.maps_hotels on (((venereEn.maps_hotels.hotels_name2) = (saperviaggiare.hotels.name) AND (venereEn.maps_hotels.hotels_city) = (saperviaggiare.hotels.city)) OR ((venereEn.maps_hotels.hotels_name2) = (venereEn.hotels.name2) AND (venereEn.maps_hotels.hotels_city) = (venereEn.hotels.city)))
SELECT H.name , H.address , H.city , H.price , S.facility , S.structure_name , S.structure_city FROM hotels as H , facilities as S WHERE (H.city = S.structure_city ) AND (H.name = S.structure_name )ORDER BY H.price ASC
q0 = scqG1 result set join scqG2 result set
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3838
Local Query ExecutionLocal Query Execution
The MOMIS Query Manager at work
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 3939
Building the Final ResultBuilding the Final Result
Local results are forwarded by MOMIS to the query processor. The Executor component also retrieves results from neighboring peers, computes the overall result by taking into account the original user preferences, and forwards it to the M-fire interface.
WISDOM D0.P1WISDOM D0.P1 – Integrated System Protoype – Integrated System Protoype 4040
Showing Results in M-FIREShowing Results in M-FIRE
Results are finally shown in M-fire using a table-based form:
Solutions are listed vertically, each one with its own table
For each solution, variable bindings are listed vertically
For each binding a row is provided, where the property name corresponding to the binding variable is shown on the right side, and the (literal) value is shown on the left side