odb course. mediation environment for object db integration leonid a. kalinichenko institute of...
Post on 26-Dec-2015
212 Views
Preview:
TRANSCRIPT
ODB Course. Mediation environment for object DB integration
Leonid A. Kalinichenko
Institute of Informatics Problems, Russian Academy of Sciences
leonidk@synth.ipi.ac.ru
Talk outline
Motivation Resource registration at a mediator Query rewriting for information integration Query rewriting algorithm in the typed environment
Motivation
Outline :
Application-driven EIS development Canonical Information Model Consolidation of a mediator Mediator schema example
4
Concerns of EIS development
Enterprise inter- and intra-organizational models: virtual corporations (e.g., virtual observatories in e-science)
Integrating at the model level - taking fragments of information within the enterprise and placing them in a larger context
What model is to be taken and how a proper context is to be formed Heterogeneous information resources of various kinds (data resources, service
resources, process resources, ontological resources) relevant to EIS are to be used in a specific context of an application
Often such resources are autonomous and evolve with time. A set of resources relevant to a specific EIS may be changed quite rapidly. The technologies applied for relevant resources are also rapidly evolving.
Justifiable identification of relevant to EIS resources, reaching semantic integration of various kinds of them in contexts of appropriate applications
Making EIS stable in the rapidly evolving world New methods and tools for EIS application development over multiple
distributed collections of data and services are required
5
Subject Domain in Natural Science
Material System Def in NLDomain Terminology and Concepts(abstract, methodological, concrete)
Theory (Model) 1. T1 Signature
Concretization A of T1
Concretization B of T1
(attributes, types, classes, processes) [simulators]
…
Semantics of T1…Tn constituents Observable/Measurable
Characteristics
Methods and Instruments for observa-tion, experimentation, measurement, data analysis, discovery
T1 Measurable Characteristics(attributes, types, classes, procs)
Observations, simulations, measurements for T1 Explaining, forecasting
Semantics
T2, … , Tn measu-rable characteristics
Theories (Models)T2, … , Tn
Problems, methods of solutions,algorithms, programs, workflows
Simulation
Interpreta-tion
6
Requirements for scientific results publishing
To publish means to make information resource available through services:
To unify theory, experiment, and simulation To query integrated information To allow independent checks of conclusions based on theoretical results,
reproducing certain results. To allow comparisons with similar results/methodologies or with the
corresponding data by observers/theoreticians. To make theoretical results more easily accessible and understandable for
observers. To establish invariants for observable classes, to treat observable classes as
interpretations of theories (models), triggers watching for inconsistencies of observations and theoretical models.
7
Two approaches to resource integration
Moving from resources to problems (an integrated schema of multiple resources is created independently of specific applications)
Moving from an application to resources (a description of an application subject domain (in terms of concepts, data structures, functions, processes) is created, in which resources relevant to the application are mapped)
The first approach driven by information resources is not scalable with respect to the number of resources, does not make semantic integration of resources in a context of specific application possible, does not lead to justifiable identification of relevant to EIS resources, does not provide for enhancing of EIS stability
The second approach (application-driven) assumes creation of subject mediator that supports an interaction between an application and resources on the basis of the application domain definition (description of the mediator)
Application-driven, subject mediation approach provides for overcoming of deficiencies of the resource-driven approach
Basic methods for application-driven approach will be characterized
8
Principles of application-driven EIS development
Basic principles of application-driven EIS development over multiple heterogeneous information resources are the following:1. independence of application (mediator) specification of the existing information
resources;2. definition of an application mediator as a result of consolidation effort of the
respective community;3. emphasizing semantic canonical definitions for the mediator specification;4. independence of user interfaces of the resources registered at the mediator:
application users should be only conscious of definition of the application domain (definition of mediator);
5. independence of publication of the newly developed information resources of the mediators
6. three stage identification of information resources relevant to mediator 7. semantic integration of relevant heterogeneous information resources in
canonical mediator specification 8. integrated access to the information resources registered at mediator applying
the canonical model and query rewriting system 9. recursive structure of mediators: each mediator can be registered as a new
information resource
9
Synthesis of canonical information model Explosive growth of various information representation models (OMG
architectures (e.g., MDA architecture), SemanticWeb and Web service architectures, digital library architectures as collective memories, information Grid architectures, languages and data models (ODMG, SQL, UML, XML and RDF stacks of data models), process models and workflow models, semantic models (including ontological models and models of metadata), models of digital repositories of data and knowledge in particular domains
Another trend — intensive development of based on such models information components and services, accelerating need for integration in various applications of components and services
Development of adequate methods for manipulation of various information models are required
The basis of these methods is constituted by the concept of a canonical information model serving as the common language, ”Esperanto”
Initially ideas of mapping structured data models and canonical model construction for them were developed
Main principle of mapping of an arbitrary resource data model (represented by its DDL and DML) into the target one (the canonical model) constituted the principle of commutative data model mapping
Preserving of operations and information of a resource data model while mapping it into the canonical one applying proofs in denotational semantics
10
Synthesis of canonical information model (2) For the object data models, the method of data model mapping and canonical
models constructions used as a formalism (metamodel) of the method the Abstract Machine Notation (AMN). It allowed to define the model-theoretic specifications in the first order logics and to prove the fact of specification refinement
The main principle of canonical model synthesis is that its extensibility is required for semantic integration and information interoperability in heterogeneous environment, including various models
A kernel of the canonical model is fixed. For each specific information model M of the environment an extension of the kernel is defined so that this extension together with the kernel is refined by M
The canonical model for the environment is synthesized as the union of extensions, constructed for models M of the environment. The resource schema refines the canonical model schema
The refinement of the schema mapping is formally checked Canonical data model synthesis method provides a seminal role for synthesis of
canonical models for various kinds of resource information models including process models (workflows), service models (Web services), ontological models (OWL)
11
Heterogeneous models absorbed by the canonical model
Core
Canonical Model
Extensions
Component Models(IDL, CDL, BOF)
Object & HeterogeneousDB Models
(ODL, SQL3, Garlic)
Knowledge BaseRepresentations
(OKBC, Ontolingua)
Unstructured Data(vocabularies, thesauri)
Semistructured Data Models
(OEM, ADM, OQL-doc)
Document ObjectModel
Metadata for DL(Dublin Core, Warwick,
Starts, Z.39.50)
Metadata Expressiblein Meta Models
(MOF, RDF)
is_refined_by
Workflow Models
12
Mediator Definition as Subject Metainformation ConsolidationFor the mediator's scalability two separate phases of the mediator's functioning are distinguished: consolidation phase and operational phase.
On the consolidation phase the efforts of the community are focused on the mediator subject definition by declaring its metainformation. The well-known representative resources of information in the subject domain are used during the process of metainformation definition. The metainformation created at the consolidation phase constitutes the mediated level of the integrated system.
During the operational phase arbitrary information resources can be registered at the mediator expressed in terms of the mediated level. Process of the registration is autonomous and can be done by resource providers independently of each other. Users of the mediator know only the metainformation defining the mediator’s subject and formulate their queries in terms of the mediator’s subject. For a query the mediator decides what registered resources are relevant to the query.
13
Mediator’s Recursion
Querymediator
Data frommediator
Querycollection
Data fromcollection
Registercollection
Registermediator(as collection)
Mediator
14
Advantages of subject domain mediation
1. Semantic integration of heterogeneous information collections is reached
2. Users should know only subject definitions as defined by a community
3. Information providers can disseminate their information for integration independently of each other and at any time.
4. Autonomous information collections are absolutely independent on the mediator and its consolidated metainformation definitions
5. Users have integrated access to all information registered up to the moment of a query.
6. Mediators form recursive structure. Multiple subjects can be semantically integrated defining mediators of the higher level.
15
Cultural Heritage Subject Domain
Person
Creator Collector Owner
Heritage_Entity
Painting Sculpture Antiquities
Repository
Museum Gallery Exhibition
created_by*date*narrative*idintifier*relation*…place_of_originhistory_periodcontentorigin_historyin_collectionowned_bydigital_form...
«type»
containsnearwithinfollows…
«type»Text
OntologiesThesauri:
Cultural Heritage
History
Jurisdiction
16
Cultural Heritage Subject Mediator
+value(in e : Entity) : real
-title-date
«type»Entity
-place_of_origin-date_of_origin-content
«type»Heritage_Entity
-material_medium-exposition_space
«type»Sculpture
-dimensions
«type»Painting
-type_specimen-archaeology
«type»Antiquities
-name-nationality-date_of_birth-date_of_death-residence
«type»Person
-culture-general_Info
«type»Creator
-name-place
«type»Repository
-name-description
«type»Collection
-in_repository1
-collections*
-created_by
1
*
1
-works
*
-contains
*-in_collection
1
Resource registration at a mediator
Outline :
Resource classes as views over mediator schema Example Resource registration facilities Contextualization of ontology Process of an information resource registration
18
Registration of relevant resources in mediator Definition of a subject mediator and registration of information resources in
mediator is based on ideas of compositional development of information systems
Registration of resources is a process of purposeful specification transformation including decomposition of mediator specifications into consistent fragments, search among specifications of relevant resources of data types treating as candidates for refining by them of the mediator specification types, construction of expressions defining resource classes as composition of the mediator classes
Specification composition calculus, type reducts, type algebra A process of registration of heterogeneous information resources in a subject
mediator is based on GLAV that combines two approaches - Local As View (LAV) and Global As View (GAV)
GAV views provide for reconciliation of various conflicts between resource and mediator specifications and provide rules for transformation of a query results from resource into mediator representation
The main registration result is a GLAV expression defining how a resource class is determined as a composition of the mediator classes
Such registration technique provides for stability of EIS application specification during any modifications of specific information resources and of their actual presence
Identification of resources relevant to a mediator (that precedes the registration) is based on three models: metadata model, ontological model, canonical information model
19
Heterogeneous Information resources Integration for Problem Solving
• integration information from pre-selected resources. A procedural approach is known to integrate information from resources through ad-hoc procedures. When information needs or resources change, a new mediator should be generated. This is known as Global as View (GAV) approach.
• integration information from arbitrary resources according to the predefined information needs. A declarative approach is known. Mediators contain mechanisms to rewrite queries according to resource descriptions. A rewritten query should be contained in the original query. This is known as Local as View (LAV) approach.
• combined LAV and GAV approaches (GLAV), applying partial materialization
20
Representation of Information resources
Formally, the contents of an information resource are described by a set of expressions:
V(Z) C1 (U 1) &…& Cn ( Un )
Where C1, … , Cn are classes on the mediator level, V is the class on the information resource level. This means that the resource can be asked a query of the form V(Z) (or any partial instantiation of it), and returns instances with state attributes that satisfy the following implication:
Z (V( Z) => U C1 (U 1) &…& Cn ( Un ))
Z are assumed to be free variables in U C1 (U 1) &…& Cn ( Un )
21
Resources Representation at Subject Mediator
Mediator level metainformation
Local into mediator level mapping
Hermitage Museum Web Site Louvre Museum Web Site Uffizi Museum Web Site
museum_objectP
titlenameplace_of_origindate_of_originr_namedimensions
museum_objecrS
titlenameplace_of_origindate_of_originr_namematerial
workP
titleauthorplace_of_origindate_of_originin_rep
workS
titleauthorplace_of_origindate_of_originin_repexp_space
artist
namegeneral_Infoworks
canvas
titlenamecultureplace_of_originr_name
museum_objectP(p/Museum_Object[title, name, place_of_origin, date_of_origin, r_name]) painting(p/Painting[title, name:created_by.name, place_of_origin, date_of_origin, r_name: in_collection.in_repository.name]), date_of_origin < 1700, date_of_origin > 1600 …
workP(p/Work[title, author, place_of_origin, date_of_origin, in_rep]) painting(p/Painting[title, author: created_by.name, place_of_origin, date_of_origin, in_rep: in_collection.in_repository.name]), in_rep = ‘Louvre’ …amount(h/Entity[title, name: created_by.name], v/real) value(h/Entity[title, name: created_by.name], v/real)
canvas(p/Canvas[title, name, culture, place_of_origin, r_name]) painting (p/Painting[title, name: created_by.name, place_of_origin, date_of_origin, r_name: in_collection.in_repository.name]), creator (c/Creator[name, culture]), r_name = 'Uffizi', date_of_origin >= 1550, date_of_origin < 1700artist (a/Artist[name, general_Info, works]) creator(a/Creator[name, general_Info, works/{set-of:Painting}])
Local views in terms of mediator classes
22
Uffizi views in terms of the mediator
canvas(p/Canvas[title, name, culture, place_of_origin, r_name])
painting (p/Painting[title, name: created_by.name, place_of_origin, date_of_origin, r_name: in_collection.in_repository.name]), creator (c/Creator[name, culture]), r_name = 'Uffizi', date_of_origin >= 1550, date_of_origin < 1700
artist (a/Artist[name, general_Info, works])
creator(a/Creator[name, general_Info, works/{set-of:Painting}])
amount(h/Entity[title, name: created_by.name], v/real)
value(h/Entity[title, name: created_by.name], v/real)
23
Resource Registration Facilities
The facilities intended to support functions of resource registration include:
• contextualization of ontology;
• constructing mapping of a resource data model and metadata into the canonical ones;
• structural and behavioral conflicts resolution;
• view definition: representation of resource classes in terms of the mediator's classes;
• semi-automatic construction of a resource wrapper;
• connecting the wrapper to the interoperation infrastructure.
24
Structure of the Resource Registration Tool
reresource context / mediator metainformation reconciliation
construction resource class specifications as views over mediator
classes
most common reduct identification
Reresource Registration Tool Mediator’s DBMS (Oracle 9i)
wrapper generation
B-Toolkit
metainformationrepository
B-AMN
wrapper code
25
Contextualization of Ontology
mapping of local ontological context to that of the mediator•by names and relationships•by natural language description•applying structural integration to concept specifications•introducing new concepts over existing ones
contextualization through structural correlation•establishing loose ontological relevance of specification elements applying analysis of intercontext concept relationships •establishing tight ontological relevance of specification elements introducing a subsumption relationship between concepts
26
Correlation of Ontological Concepts
evaluation of descriptor weights
establishing intercontext relationships between concepts
t
VkYk
t
VkXk
t
VVkYkXk
YX
YX
WW
WW
YXsim22
,
XVi ii
kk
Xk
nN
f
nN
f
W2
log
log
t
VkXk
t
VVkYkXk
X
YX
W
WWX,Yr
2
,min
t
VkYk
t
VVkYkXk
Y
YX
W
WWY,Xr
2
,min
27
Ontological Metainformation
Class ADT
-code: string
Category
-definition: string-wordClass: string
Concept
type
1*
-weight: float-name: string
Descriptor
descriptors
descriptorOf
*
1
-strength: float=1
ConceptRel
-weight: float-frequency: float-name: string
ConceptWeight
fromRelationtoConcept
*1
toRelation
fromConcept *1
weights
weightOf
*
1foreign*
*
collection1
*concept 1
*
*
1 category
PositiveRel
NarrowRel
PartRel
RelativeRel
28
Identification of Ontologically Relevant Elements
ArtAge<<concept>>
Period<<concept>>
FineArt.period<<attribute>>
Creator.culture_race<<attribute>>
positive(0.64)
29
Process of an Information Resource Registration For each resource class the following steps (of the compositional development
process) are required:
1. relevant mediator classes identification• Find mediator classes that ontologically can be used for defining resource
class in terms of mediator classes. To a resource class several mediator classes may correspond covering with their instance types different reducts of an instance type of the resource class.
2. most common reducts constructionFor an instance type of each identified mediator class do:
• Construct most common reducts for instance type of this mediator class and resource class instance type to concretize (partially) such mediator instance type.
• In this process for each attribute type of the common reduct a concretizing type, concretizing function or their combination should be constructed (this step should be recursively applied).
30
Process of an Information Resource Registration
3. partial resource view construction• For each relevant mediator class construct a partial resource view
expressing a constraints in terms of the mediator class that should be satisfied by values of respective most common reducts of resource class instances.
4. partial views composition• Construct compositions of the resource type most common reducts
obtained for instance types of all mediator classes involved.• Construct a resource view as a composition of partial views obtained
above. This is an expression of a materialized view of an information resource in terms of mediator classes. An instance type of this view is determined by the most common reducts composition constructed above.
Query rewriting for information integration
Outline :
Canonical model query language Query containment Query rewriting algorithms View definition and inverse rules construction Query rewriting algorithm schema and an example of rewriting Mediator architecture
32
Canonical model query language SYNTHESIS Conjunctive Query (SCQ) is a query of the form
q(v/Tv):- C1(v1/Tv1), … , Cn(vn/Tvn), F1(X1,Y1), … , Fm(Xm,Ym), B
where q(v/Tv), C1(v1/Tv1), … , Cn(vn/Tvn) are collection (class) atoms, F1(X1,Y1), … , Fm(Xm,Ym) are functional atoms, B, called constraint, is a conjunction of predicates over the variables v, v1, … , vn, typed by Tv, Tv1, … , Tvn , or output variables Y1Y2 … Ym of functional atoms. Each atom Ci(vi/Tvi) or Fj(Xj,Yj) (i = 1, … , n; j = 1, … ,m) is called a subgoal. The value v structured according to Tv is called the output value of the query. A union query is a finite union of SCQs.
Formal semantics of SCQ have been defined as a composition of Cartesian product of sets and classes, functional predicates execution, selection of instances satisfying B, typing of joins of product domains by join operation of the specifications of the respective argument types
Semantics of disjunctions Ci(vi/Tvi) Cj(vj/Tvj) requires that for Tvi and Tvj a resulting type of disjunction is defined by type operation meet
33
Query Containment Algorithms
A query Q1 is said to be contained in a query Q2 , if for all databases D, the set of tuples computed for Q1 is a subset of those computed for Q2
Query containment has been studied for the purposes of query optimization, detecting independence of queries from database updates, rewriting queries using views, maintenance of integrity constraints, semantic data caching, etc. Containment mapping for conjunctive queries [1977] Uniform containment of Datalog programs [1988] Containment of Conjunctive queries with built-in subgoals [1989] Containment of conjunctive queries in Datalog program [1989] Uniform containment for Datalog
programs [1996] Containment for Queries with Complex Objects [1997] Boolean query containment [1997] Containment for Conjunctive Queries With Regular Expressions [1998] Query containment relative to views [1999]
34
Query rewriting algorithms for data integration
U-join algorithm, Bucket algorithm: conjunctive queries using conjunctive views [1996]
Inverse-rule algorithm: Datalog programs using Datalog views [1998]
MiniCon algorithm, Shared-Variable-Bucket: improved versions of the Bucket algorithm [2000, 2001]
Algorithms for finding contained rewritings in the presence of functional dependencies [1998-2002]
Rewriting Unions of Relational Conjunctive Queries [John Wang Thesis,
Griffith University, Brisbane, 2002]
Resolution-based rewriting [2002]
35
View definition and inverse rules constructionDuring the registration a local resource class is described as a view over virtual classes of the mediator having the following general form of SCQ.
V(h/Th) P1(b1/Tb1), … , Pk(bk/Tbk), F1(X1,Y1), … , Fr(Xr,Yr), BA reduct of the view body instance type is to be refined by the concretizing type
Th designed above the resource.
To produce inverse rules out of the view definitions replace in the view each not
contained in Th attribute from Tb1, … ,Tbk with a distinct Skolem function of h/Th producing output value of the type of the respective attribute. Such Skolemizing mapping of the view is denoted as . After the Skolemizing mapping, inverse rules for the mediator classes in the view body are produced as
(Pi(bi/Tbi) V(h/Th)) (for i = 1, … , k)
For the mediator functions being type methods the inverse rules look like
(Tm.Fbj(Xbj,Ybj) Ts.Fhl(Xhl,Yhl)), for j = 1, … ,r, here Fbj and Fhl are
methods of Tm and Ts such that type of function of Fhl refines type of function of
Fbj.
(B) is the inferred constraint of the view predicate V(h/Th).
36
Example: View Def and Inverse Rules
Views definition for Uffizi site: canvas(p/Canvas[title, name, culture, place_of_origin, r_name])
painting(p/Painting[title, name: created_by.name, place_of_origin, date_of_origin, r_name: in_collection.in_repository.name]),
creator(c/Creator[name, culture]), r_name = 'Uffizi', date_of_origin >= 1550, date_of_origin < 1700
artist (a/Artist[name, general_Info, works]) creator(a/Creator[name, general_Info, works/{set-of:Painting}]) amount(h/Entity[title, name: created_by.name], v/real)
value(h/Entity[title, name: created_by.name], v/real)
Inverse rules for the first view def above painting(p/Painting[title, name: created_by.name, place_of_origin,
#1date_of_origin, r_name: in_collection.in_repository.name]) canvas(p/ Canvas[title, name, culture, place_of_origin, r_name])
creator(c/ Creator[name, culture]) canvas(p/ Canvas[title, name, culture, place_of_origin, r_name])
#1date_of_origin is a Skolem function
37
Query rewriting algorithm schema (1)
1. For each SCQ (denoted as Q) q(v/Tv):- C1(v1/Tv1), … , Cn(vn/Tvn), F1(X1,Y1), … , Fm(Xm,Ym), B in Qu generate a set of candidate formulae
valuable_Italian_heritage_entities(h/Heritage_Entity_Valued[title, c_name, r_name, v]) :-
heritage_entity(h/Heritage_Entity[title, c_name: created_by.name, place_of_origin, date_of_origin, r_name: in_collection.in_repository.name]), value(h/ Heritage_Entity [title, name: c_name], v/real),
v >= 200000, date_of_origin >= 1500, date_of_origin < 1750, place_of_origin = ‘Italy’
2. For each subgoal Ci(vi/Tvi) or Fj(Xj,Yj) of Q find inverse rule r I unifying with the subgoal its head Pl(bl/Tbl) or Fbo(Xbo,Ybo) (unification is based on subtyping and refinement relations*)
painting(p/Painting[title, name: created_by.name, place_of_origin, #1date_of_origin, r_name: in_collection.in_repository.name]) canvas(p/ Canvas[title, name, culture, place_of_origin, r_name])
* Painting is a subtype of Heritage_Entity+
38
Query rewriting algorithm schema (2)
3. A destination of Q is a sequence D of atoms P1(b1/Tb1), … , Pn (bn/Tbn), Fb1(Xb1,Yb1), … , Fbm (Xbm,Ybm) obtained as a result of the query subgoals unification with the heads of inverse rules from I. Several destinations can be produced as various combinations of SCQ subgoals unifications found.
painting(p/Painting[title, name: created_by.name, place_of_origin, #1date_of_origin, r_name: in_collection.in_repository.name]),
value(h/Painting[title, name: created_by.name], v/real)
4. To construct a candidate formula so that for each atom in D: establish a mapping i of attributes and variables in this atom and associated view to the attributes and variables of the respective atom of Q
mapping for the destination (only different name mappings are shown): 1 = { p → h, name: created_by.name → c_name: created_by.name,
#1date_of_origin → date_of_origin : #1date_of_origin } 2 = { name: created_by.name → name:c_name }
39
Query rewriting algorithm schema (3)
5. For each destination and variable mappings defined, construct a formula : 1(P1(b1/Tb1)), … , n(Pn(bn/Tbn)), n+1(Fb1(Xb1,Yb1)), … , n+m(Fbm(Xbm,Ybm))
6. Construct the mapping of a constraint of Q to a constraint in .
7. Replace heads of the inverse rules in the obtained SCQ with the associated inverse rules bodies to get the formula 2
q(v/Tv):- 1(V1(h1/Th1)), … , n(Vn(hn/Thn)), n+1(Fh1(Xh1,Yh1)), … , n+m(Fhm(Xhm,Yhm)), (B), E
Applying 1, 2, we get the a candidate formula: valuable_Italian_heritage_entities(h/Heritage_Entity_Valued[title, c_name,
r_name, v]) :- canvas(h/Canvas[title, c_name: name, culture, place_of_origin, date_of_origin: #1date_of_origin, r_name]), amount(h/Painting[title, name: c_name], v/real), v >= 200000, date_of_origin >= 1500, date_of_origin < 1750, place_of_origin = ‘Italy’
40
Query rewriting algorithm schema (4)8. If the constraint (B) E and the inferred constraints of the view atoms in the
candidate formula are consistent and there are no Skolem functions in the candidate of Q then the formula is a rewriting
9. Skolem functions elimination: if the inferred constraints of the view atoms imply the constraints in the candidate formula, then we can remove those constraints directly
The inferred constraint for canvas(h/Canvas[title, c_name: name, culture, place_of_origin, date_of_origin: #1date_of_origin, r_name]) that looks as r_name = 'Uffizi', #1date_of_origin >= 1550, #1date_of_origin < 1700 impliesdate_of_origin >= 1500, date_of_origin < 1750.
Due to that Skolem functions can be eliminated from this candidate formula and after the consistency check we get the rewriting:
valuable_Italian_heritage_entities(h/Heritage_Entity_Valued[title, c_name,
r_name, v]) :- canvas(h/ Canvas[title, c_name: name, culture, place_of_origin, r_name]), amount(h/Painting[title, name: c_name], v/real), v >= 200000, place_of_origin = ‘Italy’
41
Query rewriting algorithm schema (5)
10. Containment property of the candidate formulae: if we expand each view atom with the corresponding Skolemized view body and treat the Skolem functions as variables, then we will get a safe SCQ which is contained in Q (in particular, an instance type of a subgoal of 2 is a refinement of the instance type of the respective subgoal of Q )
42
Query Rewriting Example (1)Similarly, for Louvre the heritage_entity subgoal of a query unifies with painting,
sculpture as heritage_entity subclasses. Only rewriting formed for painting is shown here.
valuable_Italian_heritage_entities(h/Heritage_Entity_Valued[title, c_name, r_name, v]) :- workP(h/Work[title, c_name: author, place_of_origin, date_of_origin, r_name: in_rep]), amount(h/Work[title, name: c_name], v/real), v >= 200000, date_of_origin >= 1500, date_of_origin < 1750, place_of_origin = ‘Italy’
Finally, for Hermitage Museum heritage_entity subgoal of a query also unifies with painting, sculpture as heritage_entity subclasses. Only rewriting formed for painting is shown here.
valuable_Italian_heritage_entities(h/Heritage_Entity_Valued[title, c_name, r_name, v]) :- museum_objectP(h/Museum_Object[title, c_name:name, place_of_origin, date_of_origin, r_name]),pcost(h/Museum_Object [title, name], v/real), v >= 200000, date_of_origin >= 1500, date_of_origin < 1750, place_of_origin = ‘Italy’
43
Mediator
Query Rewriting Example (2)
Find data on valuable Italian heritage entities produced between 1500 and 1750 year
heritage_entity(h/Heritage_Entity[title, c_name: created_by.name, place_of_origin, date_of_origin, r_name: in_collection.in_repository.name]), value(h/ Heritage_Entity [title, name: c_name], v/real), v >= 200000, date_of_origin >= 1500, date_of_origin < 1750, place_of_origin = ‘Italy’
QueryRewriter
ThesaurusThesaurus extension may add ‘Italia’
museum_objectP(h/Museum_Object[title, c_name:name, place_of_origin, date_of_origin, r_name]), pcost(h/Museum_Object [title, name], v/real), v >= 200000, date_of_origin >= 1500, date_of_origin < 1750, place_of_origin = ‘Italy’
workP(h/Work[title, c_name: author, place_of_origin, date_of_origin, r_name: in_rep]), amount(h/Work[title, name: c_name], v/real), v >= 200000, date_of_origin >= 1500, date_of_origin < 1750, place_of_origin = ‘Italy’
canvas(h/ Canvas[title, c_name: name, culture, place_of_origin, r_name]), amount(h/Painting[title, name: c_name], v/real), v >= 200000, place_of_origin = ‘Italy’
HermitageLouvre
Uffizi
User
44
Mediator Architecture
Portal
Web Browser
Application Server
Web Page
Web Page
Servlets/JSP
EJB /WS
Application Client
Mediator
Oracle 10gMetainformation
Repository
DataRepository
RegistrationClient
Rewriter
Planner
Supervisor
Synth2Oracle
SOAPWrapper
ADQL2SYFSMetadataAccess
Collection Collection
Collection Adapter
Collection Adapter
4 4
4
5 9
Collection
Tool Adapter
4
Software Tools
5
1 2 1 2
6
7
6
3
3
3
3
3
top related