Semantic Web model representation and integration can be exploited to provide organizations that deal with a large amount of data sources with an integrated view on the overall information managed. In order to support semantic Web model representation and integration in the large users must be provided with light-weight languages to represent and integrate the models, in particular avoiding the design of complex Tbox axioms. Assuming to adopt at the frontend level graph-based Concept-to-Concept Relationship (CCR) representations, in this paper we question about two semantic issues. First, we inquire whether light-weight semantic Web languages such as RDFS and DL-Lite can be used to provide the semantics of individual CCR models. Second, we inquire whether these languages can be used to provide appropriate semantics for the mappings needed for model integration. Discussing a case study in the eGovernment domain we claim that both the answer are negative. Therefore, we propose a new semantic interpretation for CCR models and we define three main classes of integration and abstraction relations defining their semantics.
Semantic Web technologies and languages such as RDF, RDFS and OWL provide
knowledge sharing and logical modeling capabilities based on ontologies [
This paper focuses on the latter scalability problem in semantic Web ontologies,
which is gaining more and more attention in the last few years. A number of studies
showed that rich Web ontologies represented in languages like OWL-DL are too costly
in the large and are difficult to use for people with little formal background [
Based on the above considerations, it seems that the languages/tools that are more
used in fact by non skilled ontology designers, e.g. RDFS and semantic wikis, tend to
present ontologies, at the front-end level, as graphs where nodes represent concepts and
arcs represent relationships among these concepts in this paper we will call these
models Concept-To-Concept Relationship (CCR) models. Different languages or subsets of
them isomorphic to CCR models (e.g. RDFS, and DL-Lite, the Semantic Media Wiki
syntax), or visual interfaces based on graphs or quantifiers-free forms (e.g. [
Of course the expressiveness/cost trade-off need to be considered w.r.t. a cost/benefit model, where the benefit depends on specific application contexts (e.g. DL-Lite is particularly useful for vertical data integration applications with few information sources because of its good computational properties). In this paper, we focus on contexts where conceptual models of many different sources, semantically heterogeneous and referring to different domains need to be represented and integrated; as an example consider to represent and integrate about 500 models representing the databases of the Italian public administrations. This scenario is typical when large organizations need to be provided with an overall view of the information they manage, and of their semantics, to improve the government of their data. We refer to this context as to conceptual schema representation and integration in the large. In this context, we often call conceptual schemata, or schemata for short, the semantic Web models to represent and integrate.
Assuming to represent light-weight ontologies as isomorphic to CCR schemata at the front-end level, this paper questions whether the current available semantic Web language are suitable in this context. In particular; a first research question considered in the paper is the following “in the context of conceptual schema representation and integration in the large, are the available light-weight semantic Web languages and their traditional semantics appropriate for the representation of each CCR schema?” (Q1). A second research question considered in the paper is “in the context of conceptual schema representation and integration in the large, are the current light-weight semantic Web languages, and their traditional semantics, suitable for designing the integration of such schemata?” (Q2).
By discussing a case study in conceptual schema representation and integration in the large in the eGovernment domain, the paper argues that the answer to both the questions is negative. W.r.t. Q1, the interpretation of CCR models based on standard proposal (RDFS, DL-Light) are too restrictive. An alternative semantics for CCR models is proposed to overcome the discussed limitations. W.r.t. Q2, the available languages fails to cover important loose abstraction relations among concepts of different conceptual schemata needed in the integration process. Based on the literature the paper proposes three kinds of integration-abstraction relationships, and discusses their semantics.
The paper is organized as follows: the problem context and the case study are introduced in Section 2; the problems and the proposed solution for individual schema representation and their integration are discussed in Section 3; related works are discussed in Section 4; conclusions end the paper in Section 5. 2
Schema representation and integration in the large support conceptual meta-data management, in order to provide large organizations, or networked enterprises with an integrated view of the information managed. To make an example we consider a case study referring to past experiences in the design of repository of conceptual schemata in the eGovernment domain.
Experiences in the design and exploitation of structured repositories of conceptual
schemata (Entity Realtionship schemata) related to the most relevant databases of the
Italian central public administrations are described in [
The benefits of exploiting structured repositories of schemata at the back-end and at
the front-end level, e.g. to improve government-to-citizen and government-to-business
relationships, have been discussed in [
Focusing on the representation of individual schemata in the repository, the context of
conceptual schema integration in the large is characterized by the necessity of
representing and integrating many schemata (about 500 in the example), referring to many
heterogeneous domains (e.g. financial resources, certifications, justice, security,
education, and so on). However, a number of concepts are shared among the different
schemata (e.g. the concept of Subject appear in most of the different eGovernment
domains); these concepts are the key concepts to integrate the different schemata [
In order to support scalable design of the schamas in the large, it is important to
consider the knowledge continuum perspective [
Given the amount of schemata to represent, their levels of detail and the need for a collaborative design process carried out by domain experts, the CCR expressivity level can be considered a good compromise between the need of exploiting at the front-end level a language easy to be used, and the need of going beyond taxonomies representing at least the relationships between concepts. Considering the case study discussed, although the CPA repository is based on the ER model, the schemata represented are not far from CCR models (no cardinality restrictions are used and relationships with arity greater than 2 represents less than 5% of the total number of relationships used). 2.2
In the context addressed in the paper (when many schemata are considered) a
onestep integration is nearly impossible, and schemata need to be integrated in a recursive
way: sets of schemata clustered according to similarity criteria and balanced according
to their levels of detail (LOD) are merged together by means of a schema integration
primitive (see [
For the details of the methodology to carry out this iterative integration process
we refer to [
The question Q2 addressed in the paper concerns the suitability of available lightweight ontology Web languages to represent these kind of integration-abstraction primitives. Assuming to represent each source schema as a Web ontology, standard import and namespace mechanisms in OWL and RDFS easily allows for the integration of schemata at the architectural level (e.g. to define that C2 integrates the three schemata CA1, CD1 and IC1 one could define a Web ontology C2 importing CA1, CD1 and IC1). The question therefore focuses on the representation of the mappings between the schema concepts: are the available language suitable to represent the set of significant relations occurring between the entities of the source and the target schemata? As an example, is it possible to trace out that the specific locations associated with the three types of custom agencies in the schema C0 of Figure 2 are forgot in CA1?
In order to better define the problem, we introduce the notion of schema integrationabstraction framework and an abstract CCR formalism.
Given a set of schemata Σ, a schema integration-abstraction framework can be formalized by a schema integration-abstraction operation f Σ : P (Σ) !−→ Σ; as an example, the schema integration-abstraction framework based on Figure 2 is defined by a f Σ such that f Σ ({CA0, CD0, IC0}) = C1, and f Σ ({C1}) = C2. In the following we assume that the schema integration-abstraction frameworks are partitive, that is, each schema is integrated-abstracted in only one schema).
The abstract CCR formalism is defined through a language (CCR language from now on) that represents concepts, binary relationships between concepts and subconcept relationships; moreover, since the notion of inverse property is quite intuitive for binary directed relationships, the notion of inverse property is introduced (scalability w.r.t. reasoning is not addressed in this paper); finally, specific relationships to represent inter-schema integration-abstractions mappings are introduced. In order to avoid misunderstandings w.r.t. to technical notions from standard ontology Web languages (in particular in the next sections when a translation-based semantics is provided), we adopt the following conventions inspired by the Entity Relationship model: concepts in the CCR formalisms will be called entities and subconcept relationships will be called generalization relationships.
Formally, the CCR syntax is defined as follows.
Definition 1. Concept-to-Concept Relationship (CCR) Alphabet. An CCR alphabet A = (Σ, E, R, gen, IA, iinv), is a tuple where: Σ is a set of schema names, E is a set of entity names, R is a set of binary relationship names, gen is the generalization relation symbol, IA is a set of names of integration-abstraction relations, iinv = R → R associates relation names with names of their inverse relations, and the sets Σ, E, R, gen, IA are pairwise disjoint.
Definition 2. CCR language and CCR schemata. Given a CCR alphabet A = (Σ, E, R, gen, IA, iinv), a CCR language LCCR based on A is the set of sentences having the form: – intra-schema LCCR sentences • S:r(S:e, S:f ); • S:r−(S:e, S:f ); • gen(S:e, S:f ); – inter-schema LCCR sentences
• ia ∗ (S:e, S":f ) where S ∈ Σ, r ∈ R,{e, f } ∈ E, and ia∗ ∈ IA, and (r− is a short for iinv(r)). Given a language LCCR defined over an alphabet A, an CCR schema S is a set of intra-schema sentences Φ ⊆ LCCR. Statements having the form S:r(S:e, S:f ) and S:r−(S:e, S:f ) are called CCR patterns; a CCR pattern whose relation is r is called CCR r-pattern. Given a schema integration-abstraction framework defined on Σ by a structuring function f Σ , a set of inter-schema LCCR sentences Ψ is valid iff for every S and S" such that ia ∗ (S:e, S":f ) ∈ Ψ there exist a set of schemata T ⊆ Σ such that S ∈ T and f Σ (S) = S".
As an example, the schema CD1 of Figure 2) is conceptually represented in the CCR language by means of the following statements: CD1:import − export(CD1:Subject, CD1:Good), CD1:declared in(CD1:Good, CD1:Cus. Decl.), CD1:presented to(CD1:Cus. Decl., CD1:Cus. Agency) (in order to avoid long names the following abbreviations are used in the paper: “Cus.” for Custom, “Decl.” for declaration, “Adv.” for adventure). In the following, when the schema that intraschema LCCR sentences refer to is clear from the context, or not relevant, the schema reference will be avoided for sake of clearness (the more compact notation r(e, f ) will be used to denote CCR patterns).
One of the peculiar characteristics of CCR schemata is the Multiple Use of Relationship Names (MURN) in a same schema; as an example, more than one in relationships are represented in the CA0 schema of Figure 2. Many conceptual modeling languages, e.g. the ER language, formally assume the Single Use of Relationship Names (SURN). SURN means that a schema such as CA0 of Figure 2 cannot be represented and specific different names for each of the involved relationship need to be introduced (e.g. in#1, in#2, etc.). SURN can be defined more formally as follows.
Definition 3. SURN condition and SURN assumption. Given a schema S = ϕ1, ..., ϕn defined over a language LCCR, the SURN property holds for S iff there not exist two CCR patterns r(e1, e2) and r"(f1, f2) in S such that r = r". We call a SURN-schema a schema for which the SURN property holds. Given a set Σ of CCR schamas, the SURN assumption holds for Σ iff every schema S ∈ Σ is a SURN-schema.
We call MURN-schemata the CCR schemata for which the SURN property is not required to hold, and we call MURN the relaxation of the SURN assumption for a set of schemata. Observe that SURN-schemata are MURN-schemata, while the converse does not hold. 3.1
In the following we exploit a DL notation defined for OWL (SHOIQD) and RDFS
(based on DL − Lite), as defined respectively in [
The representation of MURN schemata is a crucial but often overlooked issue in
light-weight ontology modeling. First, consider the abstract nature of the models
represented in the schemata. SURN forces a proliferation of relationship names for
relationships with a unique intuitive meaning (e.g. three relationship names in 1,in 2,
and in 3 would be needed - under SURN - in the CA0 schema of Figure 2). In the
context addressed in this paper this point is particularly relevant: besides the amount
of schemata to represent, many generic relationships are used (e.g. has, use, is related
to, part of, and so on), and particularly in the more abstract schemata. Second, there
are many references to MURN schemata in the literature: SURN is not assumed in the
early semantic nets and is often violated even for languages such as ER for which it
is supposed to hold (e.g. see examples in [
Representing MURN CCR schemata by means of a light-weight language such as RDFS is not possible. RDFS easily maps to CCR under the assumption that CCR patterns are represented by domain and range restrictions; e.g. in(Aiport Cus., Airport) of CA0 in Figure 2 is interpreted as the assertion that Aiport Cus. and Airport are respectively domain and range of the relationship in. However, according to the semantics of RDFS, multiple domain and range assumptions have a conjunctive interpretation; which means that in the CA0 schema the domain of in consists of the intersection of all the concepts the arcs labelled as in start from (Aiport Cus.,Airport, and so on). As a result, RDFS semantics does not capture the intended semantics of CCR patterns in MURN schemata.
However, there can be other possible DL-Lite and OWL-DL interpretations of CCR patterns that conflict with specific CCR pattern combinations, as shown in Figure 3. In particular, it is remarkable that participation constraints that can be represented in DLLite do not allow for (0,n) cardinality restrictions, which when representing abstract schemata can be assumed as default cardinality restrictions (they impose the lighter possible constraints on the underlying data models).
To address the above problems we propose a new semantic interpretation for CCR patterns based on an automatic deterministic translation of CCR light-weight schemata into OWL-DL ontolgies. As usual, LCCR entities are interpreted as OWL-DL concepts and LCCR relationship names are interpreted as OWL-DL properties. Our interpretation is characterized by three main assumptions. A very light interpretation of the first entity in a CCR R-pattern as a concept included in the domain of R, and of the second entity in the CCR R-pattern as a concept included in the range of R (domain/range inclusion). A first epistemic closure that states that the domain (range) of a relationships R is the disjunction of all the concepts corresponding to the entities occurring as first (second) elements in any CCR R-pattern (domain/range global union). A second epistemic closure that captures the conditional constraint represented in a CCR pattern of the form r(e, f ), that is, that when the first element of a tuple in r is of type e, then the second element of the tuple is of type f ; of course we need to consider MURN and adequately treat multiple conditional range (domain) restrictions (e.g. when two CCR patterns r(e, f ) and r(e, f ") are considered); the strategy is analogous to domain/range global union but it is conditional to specific domain/range concepts (domain/range conditional union). Observe that domain/range inclusion and domain/range global union can be represented by defining the domain/range to be equivalent to the union of all the concepts occurring in the domain/range global union specifications (domain/range global equivalence).
As an example, consider the relation in and the in-related patterns of schema CA0. The concepts Aiport Cus., Sea Cus., Ground Cus., Airport, Border Station, P ort are subconcepts of the in domain (domain inclusion), which in CA0 consists of the union of these concepts (domain global union); the concepts Airport, Border Station, P ort, and City are subconcepts of the in range (range inclusion), which in CA0 consists of the union of these concepts (range global union); moreover, given a tuple < x, y >∈ in: if x ∈ Aiport Cus., then y ∈ Airport; if x ∈ Sea Cus., then y ∈ P ort; if x ∈ Ground Cus., then y ∈ Border Station; analogous conditional interpretations occur for the other in-patterns in the schema; as for domain conditional union, let us focus on the three in-patterns in(Airport, City), in(Border Station, City), and in(P ort, City): in this case the interpretation is that, given a tuple < x, y >∈ in, if y ∈ City, then x ∈ Airport ) Border Station ) P ort.
The formal conceptual semantics for LCCR can be defined translating LCCR schemata into OWL-DL ontologies, where entities are represented by OWL concepts, relationships by OWL properties and CCR patterns by restrictions on properties, according to the mappings defined in Table 1. In the table we adopt the following compact notation: r(e, {f1, ..., fk}) represents the set of LCCR assertions where e occurs as a first element in a relation r, r({e1, ..., eh} , f ) represents the set of LCCR assertions where f occurs as second element in a relation r, and r({e1, ..., eh} , {f1, ..., fk}) represent the set of all the LCCR assertions about a relation r where one element of the first set occurs as first element and one element in the second set occurs as second element.
Observe that based on the epistemic closures, this semantic provides an interpretation of schemata that is relative to an epistemic state. If the schemata are changed, the semantics should be computed again. This is consistent with the aim of this paper: we do not propose to design CCR models with the OWL-DL language (we would not be consistent with our assumptions). The semantics proposed is aimed at providing formal translations at the back-end level for front-end CCR models, that is, in a transparent way to the designers. In this paper we claim that our proposals allows for the more freedom in the design of CCR models without conflicts with possible CCR patterns and without giving up a set-theoretic semantics. A set of source schemata are integrated-abstracted in order to provide a target schema that accounts for the knowledge represented in the source schemata at a coarse LOD. The integration-abstraction primitive is based on the application of a set of abstraction mechanisms that, given a set of source concepts, provide an abstract target concept that represent the source concepts. The issue addressed in this paper is related to the representation of the relationships (or mappings) that might occur between the source concepts and the target concept that abstracts them.
Different kinds of abstraction mechanisms can be applied as to a set of entities, resulting in different kinds of integration-abstraction relations. In this paper we focus on three abstraction mechanisms for CCR schemata, namely abstraction by generalization, abstraction by forgetting and abstraction by collapsing; these abstraction mechanisms are used in the case study described in Figure 2 and have been acknowledged in the literature, althought sometimes under different naming (see Section 4 for details). Figure 4 provides some examples of the application of three mechanisms taken from the case study represented in Figure 2; sets of source concepts are replaced in the target schema by one concept (observe that these sets might trivially consists of one schema, and that the target concept might have the same name of the source schema).
We discuss the semantics of these abstraction mechanisms by introducing three different integration-abstraction relations - and the respective inverse relations - needed to represent the respective abstraction mechanisms. These relations provide the characterization of the IA set in a LCCR language: 1. abstract−by−generalization (a-generalize for short), and the inverse abstracted− by − generalization (a-generalized for short). This relation represents generalizations between sets of entities of different schemata with standard subsumption semantics; looking at the right-most example in the top-most section of Figure 4), the entities Cus. Agency, Sea Cus., Airport Cus., and Ground Cus. of CA1 are a-generalized by the entity Cus. Agency of C2 (i.e.
a-generalized(C1:sea cus., C2:cus. agency), and so on). 2. abstract − by − f orgetting (a-f orget for short), and the inverse a-f orgot. It represents abstractions of source entities that are “sunk” in a more abstract target entity, discarding some details in the source representations; looking at the rightmost example in the middle section of Figure 4), the entities Good and Category of IC1 are a-f orgot in the entity Good of C2 (i.e. a-f orgot(IC1:category, C2:good) and a-f orget(IC1:good, C2:good)). 3. abstract − by − collapsing (a-collapse for short), and the inverse a-collapsed.
It represents abstraction mechanisms in which the target concept has a different meaning w.r.t. all the source concepts; looking at the example in the bottom-most section of Figure 4), the entities Cus. Agency and Cus. Decl. of schema C2 are a-collapsed in the entity Customs of schema C3 (i.e. a-collapsed(C2:cus. agency, C3:cus) and a-collapsed(C2:cus decl., C3:cus)).
Intuitively, a-collapse and a-f orget are quite similar, but a-f orget relations are
polarized on an entity: there exists one entity in the source schema whose instances
can be considered also instances of the abstract entity. This can be modeled by
introducing also an abstraction by generalization relation for such an entity: e.g. in Figure
4 the entity Good of C2 a-generalize the entity Good of IC1, which is represented
by the sentence a-generalize(C2:good, IC1:good). Generalizations cannot be
established for a-collapse, where for none of the source entities it can be assumed that
instances are also instances of the target entity; as an example, the entity Customs
in schema C3 represents the general notion of customs as public institutions; custom
declarations and custom agencies are not “customs” according to this meaning. For this
reason, the intuitive meaning of a-collapse includes “part of”-like aggregation and the
grouping relations introduced in [
How do available light-weight semantic Web languages behave w.r.t. the
representation of the above mechanisms? First, consider that only abstraction by generalizations
can be natively codified as relations, namely subsumption relations (*), between two
concepts. These relations can easily be interpreted as subsumptive mappings
traditionally used in data integration [
In order to overcome these problems one could introduce specific relations, e.g.
a-f orgot and a-collapsed to be used in more complex axioms; as an example,
consider to represent that Cus. Agency of C2 is a-collapsed in Customs of C3. Here
different options are available: (A) Cus. Agency and Customs are respectively
domain and range of a-collapsed; (B) Cus. Agency * ∀a-collapsed.Customs; (C)
Cus. Agency * ∃a-collapsed.Customs. The option (A) cannot be adopted because
a-collapsed relations have more than one concept as domain, as clearly represented in
Figure 4 (the label “0,n” in the figure refers to intended interpretations of a CCR pattern
r(c, d) as [O,n] cardinality constraints between two classes C and D, e.g. in the UML
model [
Moreover, assume to represent these multi-layered mappings (multi-layering) by means of one ontology that import all the CCR schemata and defines their mappings. The resulting ontology is clearly based on MURN, which means that more complex strategies are needed to represent integration-abstraction relations in the context addressed in this paper. This is another argument against the adoption of the option (A).
The option (B) is safe against the above arguments, but does not capture the strong commitments in the definition of the integration-abstraction relations. If option (C) is applied to a-collapse and a-f orget, we have a case similar to qualified universal restriction depicted in Figure 3. However, this does not occur if we consider their inverse relations a-collapsed and a-f orgot because a set of source concepts are a-collapsed and a-f orgot into at most one schema. We therefore propose a solution based on the functional interpretation of the relations a-collapsed and a-f orgot, and the exploitation of inverse property axioms (last two rows of Table 2). Formally, this interpretation is represented in Table 2. 4
CCR models largely overlap with simple semantic nets whose nodes represent concepts
(and not instances). CCR models are isomorphic to Concept Maps [
The work more related to our proposal the translation from concept maps to OWL
ontologies proposed in [
The approach to schema integration in the large based on integration-abstraction
primitive is based on the approach introduced in [
Abstractions in conceptual modeling have been studied to support database design
[
Generic relationships and their semantics in conceptual models are analyzed in [
In this paper we consider a context where the representation and integration of semantic Web models (or schemata) is exploited to provide large organizations with an integrated view of the information they manage. Discussing a case study in the eGovernment domain and previous works of colleagues, we assume to adopt at the front-end level light weight graph-based Concept-to-Concept Relationship (CCR) representations. We therefore claim that, in the context of schema representation and integration in the large, light-weight semantic Web languages such as RDFS and DL-Lite (i) cannot be used to provide the semantics of individual CCR models and (ii) are not sufficient to provide appropriate semantics for the definition of the loose mappings needed for model integration. We therefore propose a new interpretation of CCR models semantics; moreover, based on the identification of three abstraction mechanisms exploited in the integration process, we define three main classes of integration-abstraction relations and their semantics.
The approach and the translations defined in the paper allow for the reuse of the
methodology and the schemata in the repositories described in [