=Paper=
{{Paper
|id=None
|storemode=property
|title=SPARQL Query Mediation over RDF Data Sources with Disparate Contexts
|pdfUrl=https://ceur-ws.org/Vol-937/ldow2012-paper-07.pdf
|volume=Vol-937
|dblpUrl=https://dblp.org/rec/conf/www/ZhengML12
}}
==SPARQL Query Mediation over RDF Data Sources with Disparate Contexts==
https://ceur-ws.org/Vol-937/ldow2012-paper-07.pdf
SPARQL Query Mediation over RDF Data
Sources with Disparate Contexts
Xiaoqing Zheng Stuart E. Madnick Xitong Li
School of Computer Science Sloan School of Management Sloan School of Management
Fudan University Massachusetts Institute of Technology Massachusetts Institute of Technology
Shanghai, 201203, China Cambridge, MA 02142, USA Cambridge, MA 02142, USA
zhengxq@fudan.edu.cn smadnick@mit.edu xitongli@mit.edu
ABSTRACT loss of meaning. The data do not need to be stored in RDF but can
Many Semantic Web applications require the integration of data be created on the fly from relational databases [3] or other non-
from distributed and autonomous RDF data sources. However, the RDF sources. We expect that more and more content providers
values in the RDF triples would be frequently recorded simply as will make their data available via SPARQL endpoints. However,
the literal, and additional contextual information such as unit and much existing data on the Web takes the form of simple values for
format is often omitted, relying on consistent understanding of the properties such as weights, costs, etc., and contextually dependent
context. In the wider context of the Web, it is generally not safe to information such as unit and format is often omitted. Due to the
make this assumption. The Context Interchange strategy provides openness of the Web, it is generally not safe to make the
a systematic approach for mediated data access in which semantic assumption that anyone accessing the value of a property will
conflicts among heterogeneous data sources are automatically understand the units being used. For example, an U.K. site might
detected and reconciled by a context mediator. In this paper, we give a height value in feet, but someone accessing that data
show that SPARQL queries that involve multiple RDF graphs outside the U.K. might assume that heights are given in meters.
originating from different contexts can be mediated in the way Another example is that a gallon in the U.K. (the so-called
using the Context Interchange (COIN) Framework. Imperial gallon) is approximately 4546 ml, while in the U.S. the
"same" gallon (the so-called Winchester gallon) is 3785 ml,
almost 1 liter less. The principle that such simple values are often
Categories and Subject Descriptors insufficient to adequately describe these values is an important
H.2.5 [Database Management]: Heterogeneous Databases – one. If the data originating from different contexts are brought
data translation; H.2.4 [Database Management]: Systems – together and we pose queries on the whole dataset, many semantic
query processing; H.3.5 [Information Storage and Retrieval]: conflicts can happen (see a motivational example in Section 2 for
Online Information Services – data sharing. more detail). Proper interpretation of RDF data would depend on
information that is not explicitly provided in the RDF dataset, and
General Terms hence such information may be not available to other applications
Algorithms, Design that need to interpret this data.
With the above observations in mind, the goal of this paper is to
Keywords illustrate the novel features of the Context Interchange mediation
Semantic heterogeneity, semantic interoperability, query mediator, strategy, and to describe how the semantic conflicts in RDF data
data integration sources can be automatically detected and reconciled by query
rewriting technique. Specifically, the paper makes the following
contributions:
1. INTRODUCTION
An increasing amount of data is published in RDF format due to y We describe how to use the Context Interchange strategy to
the activity of the linked data community. The Web of linked data achieve semantic interoperability among heterogeneous RDF
that is emerging by integrating data from different sources via sources and receivers by rewriting the user SPARQL query to
URIs can be considered as a single, globally distributed dataspace a mediated query. The mediated query can return the answer
[1]. With SPARQL [2], a W3C Recommendation for a query collated and presented in the receiver context.
language for RDF, data from different sources can be aggregated y We propose a formal and logical COIN framework to model
and applications can pose complex queries over the RDF dataset, contexts, i.e., the factual statements present in a data source
which were not possible before. The presence on the Web of such are true relative to the context associated with the source but
a huge distributed and autonomous RDF sources poses a great not necessarily so in a different context. With the framework,
challenge when it comes to achieve semantic interoperability the users are not burdened with the diverse data semantics in
among heterogeneous sources and receivers. sources, all of which are declared in the context representation
components and can be automatically taken into consideration
RDF is a data model for expressing the information that needs to by the mediator.
be processed by applications, so that it can be exchanged without
y A SPARQL query rewriting algorithm is described and tested
with the real data from CIA Factbook 1 and DBpedia 2 . The
Copyright is held by the author/owner(s).
1
LDOW2012, April 16, 2012, Lyon, France. http://www4.wiwiss.fu-berlin.de/factbook/
CONTEXT: RECEIVER CONTEXT: SOURCE 1
y Currency is USD with a scale-factor of 1; y Currency is USD with a scale-factor of 1;
y Datetime is expressed in US style; y Datetime is expressed in US style;
y Locations are expressed as city name. y Locations are expressed as IATA airport codes.
NAÏVE SPARQL QUERY # Named graph: http://usairline.com/flights
@prefix : .
1: SELECT ?airline1 ?airline2 ?total
2: :us339 fts:depDateTime "12:30 PM 02/09/2011" .
3: FROM NAMED :us339 fts:arrDateTime "7:25 AM 02/10/2011" .
4: FROM NAMED :us339 fts:depCity "BOS" .
5: :us339 fts:arrCity "TYO" .
6: WHERE { :us339 fts:price 950 .
7: GRAPH ?graph1
8: { ?airline1 fts:depDateTime ?depDateTime1 ; :us512 fts:depDateTime "9:45 AM 02/10/2011" .
9: fts:arrDateTime ?arrDateTime1 ; :us512 fts:arrDateTime "10:30 PM 02/10/2011" .
10: fts:depCity "Boston" ; :us512 fts:depCity "TYO" .
11: fts:arrCity "Tokyo" ; :us512 fts:arrCity "SHA" .
12: fts:price ?price1 . } :us512 fts:price 380 .
13: GRAPH ?graph2
14: { ?airline2 fts:depDateTime ?depDateTime2 ; CONTEXT: SOURCE 2
15: fts:arrDateTime ?arrDateTime2 ;
16: fts:depCity "Tokyo" ; y Currency is JPY with a scale-factor of 1000;
17: fts:arrCity "Shanghai" ; y Datetime is expressed in xsd:dateTime type;
18: fts:price ?price2 . } y Locations are expressed as city names.
19:
20: FILTER ( ?arrDateTime1 < ?depDateTime2 ) . # Named graph: http://japanairline.com/flights
21: FILTER ( ?depDateTime1 >= "9:30 AM 02/09/2011" ) . @prefix : .
22: FILTER ( ?arrDateTime2 <= "11:30 PM 02/10/2011" ) .
23: :jp241 fts:depDateTime "2011-02-10T09:25:00Z"^^xsd:dateTime .
24: LET ( ?total := ?price1 + ?price2 ) } :jp241 fts:arrDateTime "2011-02-10T22:05:00Z"^^xsd:dateTime .
25: :jp241 fts:depCity "Tokyo" .
26: ORDER BY ASC(?total) :jp241 fts:arrCity "Shanghai" .
27: LIMIT 1 :jp241 fts:price 25 .
Figure 1. Example scenario
results show that the approach is promising and effective. The Feb 10th, 2011. This query can be formulated on the schema of
source code and some test cases can be downloaded from the the two sources as the naïve query shown in Figure 1. The query
web site http://homepage.fudan.edu.cn/zhengxq/coin/. will return the empty answer without any mediation if it is
The rest of the paper is organized as follows. Following this executed over the given dataset.
introduction, a motivational example is presented to highlight the
The query, however, does not take into account the fact that both
Context Interchange strategy toward semantic interoperability.
sources and receivers may operate with different contexts, i.e.,
The COIN framework is described by introducing the formalism
they may have different assumptions on how the property values
in section 3. The SPARQL query mediation via query rewriting
should be interpreted. Specifically, the user operates with city
technique is explained in section 4. A preliminary implementation
names and US style datetimes, while the locations are recorded
is introduced in section 5. Section 6 presents a brief overview of
using IATA airport codes in the source 1 and the source 2
related work. The conclusions are summarized in section 7.
assumes xsd:dateTime format. It requires that certain constraints
typed by the user should be transformed properly to comply with
2. MOTIVATIONAL EXAMPLE assumptions in the contexts of data sources (for example, from
Consider the scenario of finding cheap airfare on the Web shown "Boston" to "BOS"; from "9:30 AM 02/09/2011" to "2011-02-
in Figure 1, deliberately kept simple for didactical reasons. In this 09T09:30:00Z"). Besides, she works with US dollars with a scale-
paper, examples assume the namespace prefix bindings given in factor of 1, whereas the source 2 reports all ticket prices in
Appendix A unless otherwise stated. Data on scheduled-service Japanese Yen with a scale-factor of 1000, which shows that the
flights are available in two autonomously administered data data might vary in two or more aspects (in that case, currency and
sources. We assume that the flights are described by the terms scale). So there must be more than one conversion of the data.
from shared vocabularies to highlight the data-level conflicts. Even if these specific differences were carefully dealt with by
Suppose a user looks for a one-way ticket from Boston to writing a new query with appropriate datetime formats, currencies
Shanghai with one stop in Tokyo. She wants to leave Boston after and city codes for each individual source (which might be a
9:30 a.m., Feb 9th, 2011 and arrive in Shanghai before 11:30 p.m., significant challenge for the user, especially if unfamiliar with the
details of each of the multiple sources involved), the result still
2
http://dbpedia.org/
would be misleading. For the source 1, the graph pattern of naïve optimizers. We have shown only one user in this scenario.
query needs to be rewritten to the following one: However, other users with different contexts could also issue their
GRAPH ?graph1 queries and get the results in their own contexts by simply
{ ?airline1 fts:depDateTime ?depDateTime1; declaring or choosing their contexts. Similarly, other RDF data
fts:arrDateTime ?arrDateTime1; sources can be added to the system with the declaration of their
fts:depCity "BOS"; contexts, and queries over multiple sources with different contexts
fts:arrCity "TYO"; could be mediated in the similar way.
fts:price ?price1 . }
GRAPH ?graph2 3. CONTEXT REPRESENTATION
{ ?airline2 fts:depDateTime ?depDateTime2; The purpose of knowledge representation in COIN is to provide a
fts:arrDateTime ?arrDateTime2; formal way of making explicit disparate assumptions about data.
fts:depCity "TYO"; Knowledge about the source and user contexts is declared under a
fts:arrCity "SHA"; formal, logical COIN framework consisting of the following four
fts:price ?price2 . } core components (see Figure 2):
But the result below still is incorrect because it is not cheapest
airfare:
airline1 airline2 total
us339 us512 1330.00
The above result is a solution corresponding to the way in which
the query's pattern matches the RDF data, all from the source 1.
For the source 2, the result returned is empty because there is only
one flight from "Tokyo" to "Shanghai". SPARQL, however, can
be used to express queries across diverse data sources, and a
SPARQL query can match different parts of the query pattern
against different graphs. In the example, it does not work by
rewriting the naïve query into two separate queries, one for
executing over source 1 and one for source 2, and combining the
results. A solution is required to make these context conversions
in dynamic way, depending on which data sources is involved.
Further, the answers should be transformed so that they conform Figure 2. An illustration of the COIN framework
to the context of the user.
In the Context Interchange system, the semantics of data of those y O = , the Context Ontology, is a description of generic
present in a source, or of those expected by a receiver can be concepts C that would be interpreted differently across data
explicitly represented in the form of a context theory and a set of sources and receivers (e.g. "MonetaryValue"), and the conflict
context statements with reference to a context ontology (see dimensions (or modifiers) that are defined as the properties P
Section 3). Queries submitted to the system would be rewritten for these concepts (e.g. "hasCurrency").
into the mediated queries by a Context Mediator, in which the y A, the Context Pool, is a set of instantiations of the context
semantic conflicts between the sources and the receiver would be ontology. Value assignments are made for each modifier to
automatically recognized and reconciled. explicate the meaning of a concept in a data source or receiver
The naïve query can be transformed to the mediated query by the (e.g. ctx:JP_yen coin:scale "1000"^^xsd:integer).
rewriting algorithm described in the Section 4. This mediated y M, the Context Mappings, defined a set of context statements
query considers all potential conflicts between the sources and the that associate the sources or receivers with their contexts. A
receiver when matching, restricting and testing values. Moreover, context statement can identify the correspondences between a
the answers returned can be transformed so that they conform to property used in the sources and a context instance defined in
the context of the receiver. The mediated query, when executed, A (e.g. fts:price coin:monetaryValue ctx:JP_yen).
returns the "correct" answer below, which helps the user to make y F, the Conversion Function Bindings, specified which
the right choice. functions should be used to make data transforms. Conversion
airline1 airline2 total functions are defined to achieve conversions between different
us339 jp241 1255.59 contexts. For each modifier at least one conversion function
Exchange rate: 100 USD = 8181 JPY will be defined to transform a value in one (source) context
In the COIN system, query mediation and query answering are into a corresponding value in another (target) context (e.g.
separated as shown in the above example. Since the mediated fn:cvt_currency("JPY", "USD", 25000), which converts
queries encode all the necessary data transformations, they can be 25000 Japanese Yen to the equivalent US dollars).
executed by existing query engines such as ARQ3, AllegroGraph4, In the remaining subsections, we describe each of the components
OpenRDF Sesame5, taking advantage of their sophisticated query in turn with examples. RDF and OWL have been used to describe
context knowledge in the framework. The adoption of RDF and
OWL provides us with greater flexibility in representing, reusing
3
http://jena.sourceforge.net/ARQ/ and exchanging data semantics captured in different contexts.
4
http://www.franz.com/
5
http://www.openrdf.org/
3.1 Context Ontology are incorporated in the system. If all sources and receivers hold a
Context ontology is a collection of generic concepts (or classes in common meaning for a given concept, no modifier is required at
the OWL language), which provides a common type system for that time. When that situation changes at a later time, modifiers
can be introduced to handle the variations.
describing data semantics exchanged between disparate systems.
A context ontology corresponding to the motivational example in
Section 2 can be seen in Figure 2. Concepts, denoted by C, are 3.3 Context Mappings
depicted by ellipses, and the "Context" is the special concept from Context mappings provide the articulation of the data semantics
which all other concepts inherit. Concepts may have properties, for the sources and receivers, which are often implicit in the given
called modifiers and denoted by P, which serve as annotations contexts. For each concept in the context ontology, a predicate
that make explicit the semantics of data in different contexts. with the same name as the concept was defined (for example, the
predicate coin:monetaryValue needs to be defined for the concept
Contexts are the actual specializations of the concepts subject to
"MonetaryValue"). These predicates are used to associate the
multiple meanings across sources and receivers. For sources, the
properties used in the sources with the corresponding context
contexts are defined as the specializations used for the underlying
instances in order to make explicit the data semantics of the
data values. For receivers, on the other hand, the contexts are
values of the properties. The statements of the context mappings
defined as the specializations assumed in viewing the data values.
These specializations could be the representation of date or the are defined over the domain (R D) × T × A, where R is a set
number scale being used. of the IRIs that represent the properties appeared in the data
sources, D is a set of IRIs used to identify specific applications,
The modifiers, as properties, will be inherited by the sub-concept and T is a set of predefined vocabulary that have the same names
relations from its ancestors. A concept can have multiple as the concepts defined in the context ontology, but begin with a
modifiers, each of which indicates an orthogonal dimension of the lower case letter. T is used to indicate the types of the context
variations. For example, the concept "MonetaryValue" has four instances assigned in the context mapping statements.
modifiers, two of which are "hasCurrency" introduced by the
"MonetaryValue" and "hasScale" inherited from the "Number", For example, the fact that the values of the "fts:price" property are
which indicates that its instances could be interpreted according to reported in US dollars using a scale-factor of 1 is made explicit by
two dimensions: scale factor and money currency. All the the following statement:
concepts and their properties of the context ontology are defined fts:price coin:monetaryValue ctx:US_dollar .
in the namespace bound to the prefix "coin". The "ctx:US_dollar" is a context instance of the "MonetaryValue"
concept, and was defined in the example of Section 3.2. If the
3.2 Context Pool data is structured in the form: subject-predicate-[ ]-predicate-
Context pool contains a set of instantiations of the concepts in the object, using an intermediate blank node, as the example similar
context ontology. As we mentioned above, modifiers are special to the following definition:
properties that affect the interpretation of data values. The context item hasPrice _:blanknode
ontology defines what types of modifiers apply to which concepts. _:blanknode price "100"
A context instance or individual is defined by a set of RDF _:blanknode currency "USD "
statements that determine the values of modifiers. Such In that case, the context mapping will be defined by associating
statements are defined over the domain A × P × (I L), where the "price" property with the appropriate context instance to make
I is a set of the IRIs, and L is a set of the RDF literals. If {s, p, o} explicit the data semantics of the value "100" of that property. For
is a statement about a context instance s, and s belongs to a the sources, the context mappings are defined by attaching the
concept C C, the property p P should be able to apply to the context instances to the properties, which could be considered as
class C, and a value o must be in the range of the property p. some extensions to the RDF Schema vocabulary. The extensions
support the description of context information indicating how the
For example, a context instance "ctx:US_dollar" can be described values of a given property are interpreted.
with the following statements:
ctx:US_dollar coin:hasDataType xsd:long . We cannot assume that the users have intimate knowledge of the
ctx:US_dollar coin:hasScale "1"^^xsd:integer . data sources being accessed since this assumption is generally
ctx:US_dollar coin:hasCurrency "USD" . non-tenable when the number of systems involved is large and
These modifier assignments explicitly indicate that any data value when changes are frequent. The users should remain isolated from
associated with the "ctx:US_dollar" is in US dollars with a scale- underlying semantic heterogeneity, i.e., they are not required to
factor of 1 and is represented by the typed literal "xsd:long". All be sufficiently familiar with the properties in different schemas
the context instances are defined in the namespace bound to the (so as to construct a query). There are some graphic tools (Gruff6
prefix "ctx". The objects (xsd:long, "1", and "USD") in the above for example) to assist the users to create SPARQL queries. The
RDF statements are called modifier values. COIN enables the users to identify their contexts independent of
the data sources. Receiver's contexts can be declared by assigning
We can declare new context instances or reuse which are already the instances in A to D with the aid of vocabulary in T. For
defined in the pool. For each concept of the context ontology that example, a user could declare that she use US dollars by the
is interpreted differently by sources and receivers, modifiers are following statement:
introduced to explicate those differences. The advantage of this
:flight coin:monetaryValue ctx:US_dollar .
approach is that it allows conflicts between sources and receivers
to be introduced gradually as they are discovered. Many conflicts
emerge later in the integration process as more sources and users 6
http://www.franz.com/agraph/gruff/
The ":flight" is used to indicate an application domain, so a Conversion function bindings, denoted by F, are defined by a set
meaningful name is recommended. A user is allowed to make of RDF triples that determine which functions can be used to
different context definitions for different applications. make necessary data transforms for the modifiers of the concepts.
All context statements for a data source or a receiver should be Such statements are defined over the domain C × P × N, where N
made in a separate namespace. The correspondences between the is a set of IRIs used to identify and retrieve conversion functions.
sources or receivers and their context definitions then need to be
further identified. We assume that all context statements about the 4. SPARQL QUERY MEDIATION
source 1 were described at . The goal of the COIN framework is to provide a formal, logical
The following triple asserts that the context of the source 1 is basis that allows for the automatic mediation of queries such as
defined in the RDF graph , those described in Section 2. The semantic conflicts would happen
where the source 1 is identified by : when the RDF literals typed by a receiver are attempted to match
coin:hasContext against source graphs or the RDF terms from different graphs are
. compared. In this section, we describe the process of rewriting a
Such RDF statements, called context bindings, are defined over naïve SPARQL query (i.e. query ignoring semantic differences
between sources and/or receivers) to a mediated query with all the
the domain I × coin:hasContext × I. The context bindings,
semantic conflicts reconciled and the query results transformed
denoted by B, will be added in the mediated query to retrieve the
appropriately according to user expectation.
context mappings of the data sources and/or receivers (more about
these in the section 4).
4.1 Well-Formed Query
Given a naïve SPARQL query, context mediation is bootstrapped
3.4 Conversion Function Bindings by transforming this user query into a logically equivalent query.
The preceding statements are not yet sufficient for resolving The mediation process starts by converting the naïve query into
conflicts of data present in disparate contexts, since we have to its well-formed query that must satisfy the following requirements:
define how values in one (source) context are to be reported in
y All the data sources are introduced as named graphs by using
another (target) context with different assumptions (i.e., modifier
the FROM NAMED clause.
values). This is accomplished via the introduction of conversion
y All the graph patterns (i.e., basic or group graph patterns) are
functions that are defined for each modifier between two different
defined inside the scope of GRAPH keywords.
modifier values. A general representation of conversion functions
is shown as follows: y There is no such variable that is used in two different GRAPH
clauses.
fn:cvt_modifier(mvs, mvt, vs)
The translation to meet the first two requirements is obviously a
where mvs and mvt are two distinct values of the modifier in the trivial exercise. Note that the GRAPH keyword could be followed
source and target contexts respectively. The function returns the by a variable or an IRI. If a variable is provided, it is not possible
equivalent value vt that complies with assumptions in the target to know in advance which named graph will be matched since the
context for the source value vs. For example, a scale conversion variable will range over the IRIs of all the named graphs in the
fn:cvt_scale could be defined by multiplying a given value with query's RDF dataset. Query variables in SPARQL queries have
the appropriate ratio as shown below: global scope and use of a given variable name anywhere in a
fn:cvt_scale: vt = vs * mvs / mvt query identifies the same variable. However, a variable shared by
Note that the conversion function will return vt directly if mvs or different named graphs might be bound to the logically-equivalent
mvt is undefined. term, but with different representations in different contexts. So
the last requirement is necessary and can always be guaranteed by
In some cases, ancillary data sources may be used for defining renaming variables and adding the corresponding FILTERs to the
appropriate functions. For instance, currency conversions need to WHERE clause. For example, if a ?var variable is used across two
be supported by external data sources that provide the exchange different GRAPH clauses, one variable would be renamed ?nvar,
rate between two different currencies. Atomic conversions can be and a FILTER(sameTerm (?var ,?nvar)) constraint will be created.
composited to construct composite conversions. As we mentioned,
each modifier captures one aspect of interpretation that may vary
across contexts. After invoking an atomic conversion, the source 4.2 Semantic Conflicts Detection
value is transformed to a (intermediate) context that is the same as The semantic conflicts are detected by a context mediator through
the target context in terms of this aspect; by invoking the atomic the comparison of context statements corresponding to the sources
conversions consecutively, the value is converted through a series and receivers engaged in query patterns. The algorithm 1 shows
of intermediate contexts, each having one aspect being different how to detect the potential conflicts among heterogeneous sources
from the target context; it reaches the target context in the end and receivers for given a pair of properties, where a three-place
when no aspect is different from the target context. Thus, in the notation Tripleg(s, p, o) is used to represent a typical RDF triple
case of "MonetaryValue" that has two modifiers, currency and and if the subscript g is given it indicates that the triple
scale, we may have: is defined under the named graph g. The subscript g could be an
IRI or a variable. In this paper, Tripleg(s, p, o) is also used to
fn:cvt_scale(1000, 1, fn:cvt_currency("JPY", "USD", 25))
denote a triple pattern.
Hence, if the function for currency returns the value 0.30559, it
will be rewritten to 305.59 by the scale conversion function. All Note that the properties P1 and P2 are not required to be
the COIN components for the motivational example are given in associated with the same concept in C, which makes it possible to
Appendix B except the context ontology that has already shown express the constraints like FILTER (?price < ?weight). If the
in Figure 2. properties of ?price and ?weight have a common modifier,
Algorithm 1. Detection of semantic conflicts between sources 1: SELECT ?concept1 ?concept2 ?modifier ?mv1 ?mv2
and/or receivers for a given property 2: WHERE {
Input: K:COIN components, K = < O, A, M, F > including B 3: S1 coin:hasContext ?def1
S1 :
a data source IRI (could be a variable) 4: S2 coin:hasContext ?def2
S2 :
another data source IRI (could be a variable) or an 5: GRAPH ?def1 { P1 ?concept1 ?ctx1 }
IRI used to identify a receiver 6: GRAPH ?def2 { P2 ?concept2 ?ctx2 }
P1 : a property IRI used in S1 7: ?ctx1 ?modifier ?mv1 .
P2 : a property IRI used in S2 or an IRI used to identify a 8: ?ctx2 ?modifier ?mv2 .
application domain if S2 is a receiver identifier 9: FILTER(!sameTerm(?mv1, ?mv2)) } .
Output: SC : a set of semantic conflicts detected
Figure 3. The equivalent SPARQL query for Algorithm 1
1 SC shown in Table 1. Note that we just need to detect the conflicts
2: def1 = { def | Triple(S1, coin:hasContext, def) B } that are required to make necessary conversions for queries.
3: def2 = { def | Triple(S2, coin:hasContext, def) B }
4: ctx1 = { ctx | Tripledef1(P1, concept, ctx) M } Table 1. The semantic conflicts detected in the motivational
5: C1 = { concept | Tripledef1(P1, concept, ctx1) M concept T } example for the property fts:price
6: if S2 is a data source identifier then modifier mv1 mv2
7: ctx2 = { ctx | Tripledef2(P2, concept, ctx) M coin:hasScale 1 1000
8: C2 = { concept | Tripledef2(P2, concept, ctx2) M coin:hasCurrency USD JPY
concept T }
9: else ctx2 { ctx | Tripledef2(P2, C1, ctx) M } For the same reason, in some cases it is not possible to know in
10: C2 = C1 advance how to interpret the value of a property because we
11: for each modifier { p | Triple(ctx1, p, mv) A p P } do cannot know in advance the sources of the value. However, in
12: mv1 { mv | Triple(ctx1, modifier, mv) A } most cases, we are able to know with which concept the property
13: mv2 { mv | Triple(ctx2, modifier, mv) A } was associated by looking up the context mappings. With the
14: if mv1 mv2 and mv1 NULL and mv2 NULL then concept name, we can get all the modifiers applied to the concept,
15: SC SC { S1, S2, P1, P2, C1, C2, modifier, mv1, mv2 } access the values of the modifiers, and then use them to construct
16: return SC the appropriate conversion functions. An OPTIONAL keyword
will be used when we cannot know in a static way whether certain
"hasScale" for example, and different modifier values, this
modifiers or modifier values are defined in the context statements.
conflict will also be detected and be used to construct the Notice that if a concept has no modifier, there is no conversion
conversion function (see Section 4.3). Recall that the users are not function defined for the concept, so the values are assumed not to
required to be sufficiently familiar with the underlying schemas of vary across any context.
data sources, and their contexts are declared by assigning the
context instances to the concepts C via T. If S2 identifies a receiver, Algorithm 2. Conversion function construction
the context instance ctx2 could be retrieved directly by looking up Input: K : COIN components, K = < O, A, M, F> including B
M for the concept C1 as shown in line 9 of the algorithm 1. SC : a set of semantic conflicts detected by the algorithm 1
MV : a data value or a variable in source context
The algorithm 1 can only be used to statically detect the semantic D : a boolean variable to indicate conversion direction
conflicts between sources and/or the receiver. Sometimes it is Output: CF : a composite conversion (default value is NULL)
impossible to know in advance which sources the query pattern
1: for each { S1, S2, P1, P2, C1, C2, modifier, mv1, mv2 } SC do
will be matched until the query is executed, not to mention the
2: if CF = = NULL then
contexts of the sources. For example, the following group graph
3: function { f | Triple(C, modifier, f ) F C C
pattern in the query of the motivational example can be matched ( C = C1 C is a closest super-concept of C1 ) }
against both source 1 and 2 (assuming the city names, "Shanghai" 4: if D = = TRUE
and "Tokyo", are automatically transformed so that they conform 5: CF function(mv1, mv2, MV)
to the contexts of the corresponding sources). 6: else CF function(mv2, mv1, MV)
GRAPH ?graph2 7: else function { f | Triple(C, modifier, f ) F C C
{ ?airline2 fts:depDateTime ?depDateTime2 ; ( C = C1 C is a closest super-concept of C1 ) }
fts:arrDateTime ?arrDateTime2 ; 8: if D = = TRUE
fts:depCity "Tokyo" ; 9: CF function(mv1, mv2, CF)
fts:arrCity "Shanghai" ; 10: else CF function(mv2, mv1, CF)
fts:price ?price2 . } 11: return CF
The trick is that we are able to access the graph name by making a
variable (i.e., ?graph2 used in the above pattern) bound to IRIs of 4.3 Conversion Function Construction
the graph being matched, and then use the graph name to obtain The conversion functions are introduced to define how values of a
its context definition via context bindings (see Section 3.3). given concept are transformed between different contexts. In the
SPARQL queries can be used to find all the potential semantic COIN framework, an "ontology-based" representation is adopted
conflicts instead of the algorithm 1, and the algorithm can be where conversion functions are attached to concepts in different
trivially translated to the equivalent SPARQL query shown in contexts. This mechanism allows for greater sharing and reuse of
Figure 3. If this query is applied to the source 1 and 2 for the semantic encoding. For example, the same concept may appear
property fts:price, two semantic conflicts would be detected as many times in different properties (e.g., consider the concept
"MonetaryValue"). Rather than writing a function conversion for
each property that redundantly describes how different reporting Algorithm 3. SPARQL query rewriting
currencies are resolved, we can simply associate the conversion
Input: K : COIN components, K = < O, A, M, F > including B
function with the concept "MonetaryValue".
WQ : a well-formed SPARQL query
In addition, when a property involves two or more conflicts, a r: an IRI used to identify a receiver
composite function can be constructed to reconcile those conflicts a : an IRI used to identify a application domain
by the algorithm 2. It is also scalable because it can compose all Output: MQ : an mediated SPARQL query
necessary conversions using a small set of component conversions.
The composition can be obtained as a series of invocations on the 1: MQ WQ
conversion function defined for each modifier pertaining to the 2: pattern
3: parse the query WQ and extract its triple patterns into bgp
concept in the context ontology.
4: M and A are included into the dataset of MQ as named graphs
The function-finding method in the algorithm 2 (line 3 and 7) at 5: for each var { v | v is a RESULT variable
first will try to find the specific conversion function defined for Tripleg(s, p, v) bgp } do
the modifier of the concept. If it cannot be found, the method will 6: if SC Algorithm1(K, g, r, p, a) SC then
try to find the function defined for the same modifier under the 7: pattern pattern PatternCreator(g, r, p, a, SC) / bgp
direct super-concept. The step will repeat until a function is 8: CF Algorithm2(K, SC, v, TRUE)
retrieved or it reaches the top "Context" concept. For example, the 9: adds the assignment LET ( nvar := CF ) into MQ and
function cvt_format_dateTime( ) is defined for the modifier replace var with nvar in the SELECT clause, where nvar
"hasFormat" under the concept "dateTime" that has no sub- is a new variable never used before.
concepts, while cvt_scale( ) function is defined under the concept /* if the variable v is introduced by a LET clause, the
"Number" and the function can be used by all its sub-concepts context conversion will be done in the LET clause */
10: for each cont = { c | c is a constant Tripleg(s, p, c) bgp } do
such as "Weight", "Height" and "MonetaryValue" for scale-factor
11: if SC Algorithm1(K, g, r, p, a) SC then
adjustment.
12: pattern pattern PatternCreator(g, r, p, a, SC) / bgp
Note that the translation from one context to another is embedded 13: CF Algorithm2(K, SC, cont, FALSE)
in conversion functions present in individual context theories, and 14: adds the FILTER( nvar := CF ) into MQ and replace
they are not part of the context ontology. This means that there is cont with nvar in Tripleg(s, p, c), where nvar is a new
greater scope for different users to introduce conversion functions variable never used before.
which are most appropriate for their purposes without requiring 15: for each EXPRESSION ( expr1 op expr2 ) or
these differences to be accounted globally. For example, different FUNCTION( expr1, expr2 ) do
16: if expr1 is a constant expr2 is a variable
currency exchange system would be used in different countries or
Tripleg(s, p, expr2) bgp
for different purposes.
SC Algorithm1(K, g, r, p, a) SC then
The modifiers of the concept are called orthogonal if the value 17: pattern pattern PatternCreator(g, r, p, a, SC) / bgp
derived from its composite conversion is not affected by the order 18: CF Algorithm2(K, SC, expr1, FALSE)
in which the component conversions are invoked. For example, 19: replace expr1 with CF in the expression or function
the currency and scale modifiers of the "MonetaryValue" concept 20: if expr2 is a constant expr1 is a variable
are orthogonal. We will get the same value either by converting Tripleg(s, p, expr1) bgp
currency first followed by scale-factor adjustment or by adjusting SC Algorithm1(K, g, p, r, a) SC then
21: pattern pattern PatternCreator(g, r, p, a, SC) / bgp
scale-factor first followed by currency conversion. For any pair of
22: CF Algorithm2(K, SC, expr2, FALSE)
modifiers that are not orthogonal, the component conversions are
23: replace expr2 with CF in the expression or function
required to be invoked in a particular order to return right value. 24: if expr1 is a variable expr2 is a variable
The order depends on how the component conversion is specified. Tripleg1(s1, p1, expr1) bgp
An in-depth discussion on this issue can be found in [6]. Tripleg2(s2, p2, expr2) bgp
SC Algorithm1(K, g1, g2, p1, p2) SC then
4.4 Query Rewriting 25: pattern pattern
The context mediator uses the algorithm 3 to undertake the role of PatternCreator(g1, g2, p1, p2, SC) / bgp
detecting and reconciling potential conflicts at the time a query is 26: CF Algorithm2(K, SC, expr1, TRUE)
27: replace expr1 with CF in the expression or function
submitted. The following parts in a query might be rewritten to
28: adds pattern into MQ
the corresponding forms that all semantic conflicts, when detected,
29: return MQ
are resolved:
y SELECT: the answers returned should be further transformed Function PatternCreator(S1, S2, P1, P2, SC)
so that they conform to the context of the receiver. 1: pattern
y WHERE: the constants should be transformed to comply with 2: pattern { Triple(S1, coin:hasContext, def1) ,
assumptions in the source contexts. Triple(S2, coin:hasContext, def2) ,
y EXPRESSION and FUNCTION: one of two arguments might Tripledef1(P1, C1, ctx1) ,
be transformed so that the two arguments conform to the same Tripledef2(P2, C2, ctx2)
context. 3: for each { S1, S2, P1, P2, C1, C2, modifier, mv1, mv2 SC
First, the context mappings M and context pool A will be added 4: pattern pattern ,
Triple(ctx1, modifier, mv1) ,
into the RDF dataset as named graphs (line 4). A mediated query
Triple(ctx2, modifier, mv2)
is executed against the RDF dataset that comprises one or more
5: return pattern
data sources and the two graphs generated from M and A. In the
current SPARQL core standard, SELECT queries only project out xiv: ?ctxr coin:hasCurrency ?mvcr . }
variables bound in the query and there is no way to return the xv: LET ( ?total := fn:cvt_currency(?mvc1, ?mvcr,
values of expressions over result bindings. The mediated queries fn:cvt_scale(?mvs1, ?mvsr, ?price1)) +
fn:cvt_currency(?mvc2, ?mvcr,
need the ability to project expressions rather than just variables fn:cvt_scale(?mvs2, ?mvsr, ?price2)) )
because the results need to be transformed to comply with
The line i-iv was generated to retrieve the context definitions of
assumptions in the receiver context. An example is returning the the two possible data sources (one is ?graph1 in which ?price1
total cost of two air tickets. LET assignments are used to enable will be retrieved; the other is ?graph2 that will provide ?price2)
transformation on the results by using the conversion functions and the receiver. Note that the duplicate patterns will be deleted
(line 9). For the same reason, we also use FILTER clauses in the from the mediated query when the patterns are merged into the
line 14 to transform the constants in the queries to comply with previously-generated ones. The context instances and their
assumptions in the sources contexts. modifier values will be obtained by the line v-xiv. To rewrite the
Considering the naïve query in the motivational example, the first LET assignment (line xv), the algorithm 2 will be called twice,
triple pattern encountered that needs to be processed is the one: each for ?price1 and ?price2, to make the sum of the two prices
GRAPH ?graph1 { ?airline1 fts:depCity "Boston" . } comply with assumptions in the receiver context.
The line 10-14 of the algorithm 3 will transform this triple into the
following patterns. 5. IMPLEMENTATION
i: GRAPH ?graph1 { ?airline1 fts:depCity ?depCity . } We use Jena7 to implement COIN SPARQL framework to provide
ii: GRAPH a demonstration of the feasibility of Context Interchange strategy.
iii: { ?graph1 coin:hasContext ?def1 . As shown in Figure 4, queries submitted to the system will be
iv: coin:receiver coin:hasContext ?recv . } intercepted by a Context Mediator, which rewrites the user query
v: GRAPH ?def1 { fts:depCity coin:city ?ctx1 . } into a mediated query and pass it to ARQ, the SPARQL query
vi: GRAPH ?recv { :flight coin:city ?ctx2 . } engine for Jena. COIN also can easily be plugged in to other
vii: GRAPH existing SPARQL query engines to take advantage of their state
viii: { ?ctx1 coin:hasEncoding ?mv1 .
of the art query optimization and execution techniques. We tested
ix: ?ctx2 coin:hasEncoding ?mv2 . } the solution with the real data from CIA Factbook and DBpedia.
x: FILTER ( ?depCity = fn:cvt_encoding_city(?mv2, ?mv1,
"Boston") ) . Context Mediation User
Conversion Context Context Context
A new variable ?depCity was generated and replaced "Boston" at Local Functions Pool Ontology Mappings
the line i. The context statements of the data sources can be Databases
accessed dynamically via the variables ?graph1 that will bound to
IRIs of the sources being matched (line iii). The pattern of the line SPARQL Optimized
Query
Mediated
Query
Query
Query Context
iv was used to retrieve the receiver's context definition. The two Query Optimizer Mediator
Engine
context instances of the concept "City" will be obtained by the
line v-vi. One was associated with the property fts:depCity of the
Query Answers Extensional Anssers
data sources; the other was referenced in the receiver's context Query Query Answers
statements. The modifier values of those two context instances Query
Context Context
can be retrieved by the line viii-xi, which will be taken as inputs Mappings Mappings RDF Views
to the conversion function fn:cvt_encoding_city. In the FILTER RDF
Data
clause of the line x, the English city name "Boston" might be RDF
Data
transformed to comply with the contexts of the data sources. If the RDF Relational
Data Databases
variable ?graph is bound to the IRI of the source 1 (USA airlines),
"Boston" will be rewritten into "BOS". If ?graph is bound to the RDF Data Sources Other Data Sources
IRI of the source 2 (Japan airlines), "Boston" will stay unchanged.
Figure 4. Architecture of a COIN SPARQL system
For the result variables of the naïve query, only the variable ?total
needs to be processed because it is the sum of the prices of the OWL is used to represent the context ontology, and the pool and
two tickets, ?price1 and ?price2 that occur as objects in the triple mapping components are described by using RDF. All conversion
patterns. The following fragment of the mediated query will be functions now are implemented as FILTER (extension) functions,
generated by the line 6-9 of the algorithm 3 for the variable ?total. which use the advanced feature of ARQ that goes beyond the core
i: GRAPH SPARQL specification. The conversion functions extend the
ii: { ?graph1 coin:hasContext ?def1 . abstract class FunctionBase3 that takes three parameters. The
iii: ?graph2 coin:hasContext ?def2 . query engine can dynamically call the functions based on the
iv: coin:receiver coin:hasContext ?recv . } function URIs. This is done by either registering it or using the
v: GRAPH ?def1 { fts:price coin:monetaryValue ?ctxp1 . } fake java: URI scheme.
vi: GRAPH ?def2 { fts:price coin:monetaryValue ?ctxp2 . } Conversion functions are defined as parametric functions that can
vii: GRAPH ?recv { :flight coin:monetaryValue ?ctxr } express the conversion between all possible modifier value pairs,
viii: GRAPH not only a specific one. For example, fn:cvt_ currency can be used
ix: { ?ctxp1 coin:hasScale ?mvs1 . to make currency conversion among any different currencies. For
x: ?ctxp1 coin:hasCurrency ?mvc1 . "hasFormat" and "hasEncoding" modifiers, the value at first is
xi: ?ctxp2 coin:hasScale ?mvs2 .
xii: ?ctxp2 coin:hasCurrency ?mvc2 .
7
xiii: ?ctxr coin:hasScale ?mvsr . http://jena.sourceforge.net/
translated from the source context into an internal representation The context interchange strategy is mediator-based approach for
and then into the target context. A datetime value, for example, is achieving semantic interoperability among heterogeneous sources
firstly transformed into xsd:dateTime by fn:cvt_format_dateTime and receivers. As realizations of the strategy, COIN [4], [7] and a
before being transformed again in order to comply with the target recent extension [9], [19], are working prototypes that implement
context. Notice that the number of conversion functions is not the Context Interchange strategy. COIN uses FOL/Prolog as the
generally proportional to the number of sources and receivers in representation and implementation language for the application
the system. The COIN framework facilitates the maximum reuse ontology in the context mediation. Various sample applications
of existing conversion functions, and thus the number of newly- have been implemented to illustrate its ability to solve semantic
introduced conversion functions would diminish rapidly with the interoperability problems in areas such as financial services,
addition of each source or receiver. A more in-depth analysis of weather information, and airfare aggregation and comparison. Our
scalability can be found in [18]. goal in this paper is to illustrate how to extend COIN strategy to
solve context conflicts in the emerging linked data by SPARQL
With the COIN framework, the users are not burdened with the
query rewriting.
diverse data semantics in sources, all of which are declared in the
context representation components and can be automatically taken It is worth noting some interesting work which is complementary
into consideration by the mediator. A receiver in any context is to our approach. A system, called Sesame, as well as its index
able to issue queries over any set of data sources in other contexts structure was presented for query processing and optimization in
as if they were in the same context. For example, it is easy for distributed RDF repositories in [11]. Glimm and Krötzsch extend
users to modify their context definition. Continue the motivational the SPARQL query language by defining the semantics of queries
example in Section 2. Here the receiver wants to use CNY instead under the entailment regimes of RDF, RDFS, and OWL [16]. An
of USD. After the modification is made, the query results will approach is proposed to discover data that might be relevant for
immediately be reported in CNY as follows. answering a query during the query execution itself [5]. The
discovery is driven by following RDF links between data sources
airline1 airline2 total
based on URIs in the query and in partial results.
us339 jp241 8172.32
Exchange rate: 100 USD = 651.56 CNY; 100 JPY = 7.93 CNY. 7. CONCLUSIONS
The sources are not required to make any change or commit to The "Web of linked data" can be understood as a single, globally
any criteria under the COIN framework; they only need to record distributed dataspace, and SPARQL queries can be executed over
data semantics declaratively. Adding or removing a data source is this huge dataspace. But semantic heterogeneity widely exists
accomplished by adding or removing the corresponding context among the RDF data sources originating from different contexts,
declarations, which does not require any changes to the mediator and severely hampers their integration and interoperability. This
or query processor. Conversion functions are defined for each paper describes how to use the Context Interchange strategy to
modifier between distinct modifier values, not between pair-wise achieve semantic interoperability among heterogeneous RDF
sources. Thus only a small number of atomic or component sources and receivers by rewriting the user query to a mediated
conversions need to be defined, which are used by the mediator to query. The semantic conflicts can be automatically detected and
compose necessary composite conversions in a dynamic way to reconciled by the context mediator using the context definitions
reconcile all semantic differences involved in a query. In many associated with both the data sources and the data receivers. The
practical cases, an atomic function can be parameterized for the mediated query, when executed, returns the answer collated and
modifier to convert from any given context to any other context. presented in the receiver context. The core components of COIN
The COIN strategy requires significantly less conversions than are represented by using the Semantic Web constructs such as
traditional global or interchange standardization approaches [18], RDF and OWL, which make them possible to be exchanged and
and therefore is easy to be maintained. processed by other applications.
The mediated query uses extension functions to transform values
6. RELATED WORK between different contexts, which might be likely to have limited
We can roughly distinguish between two types of data conflicts in interoperability. It might require transformation between datatype
data integration: schematic conflicts and semantic conflicts. The formats not supported by the core SPARQL specification, and the
first has been well-documented in the database and Semantic Web orderings of some application datatype also need to be defined. A
literature. A language, called CQuery was described in [10] to promising alternative is to use nest query (i.e. to nest the results of
represent the domain knowledge in the form of a vocabulary or a query within another query) to provide conversion. The current
ontology as semantic metadata, and use the ontology to overcome SPARQL core standard does not support nested query, but the
heterogeneity among different data sources. Gracia et al. proposed standard is still evolving (see [8]). In the future, we plan to
a technique to perform the integration of ontology terms in order consider temporal semantic heterogeneities which refer to the
to cluster the most similar ones in [12]. Networked Graphs was situation where the semantics between data sources, even in the
proposed as a means for describing RDF graphs that are partially same data source, change over time. For example, the profit of a
derived from other graphs using a declarative view mechanism. company might be represented in DEM before 1998 and in EUR
The relationships between graphs are described in a declarative since 1999. The approach partitions graph patterns of a given
way using SPARQL queries in [13]. Some surveys of schematic "naive" query into multiple GRAPH clauses, each of which uses a
integration can be found in [14], [15], and [17]. Our approach is unique set of query variables. This solution need to add FILTER
different because we have chosen to focus on the semantics of clauses that ensure the equality of values bound to newly
data level as opposed to the conflicts at schematic level. To the introduced variables. These filters increase the complexity of
best of our knowledge, very little existing work has addressed the queries and have a negative effect on performance. The focus of
semantic conflicts at data level among RDF data sources. the paper has been on the query mediation, but an implementation
with query optimization is also planned.
8. ACKNOWLEDGMENTS [14] Noy, N.F. Semantic integration: a survey of ontology-based
The work was supported, in part, by a grant from the National approaches. SIGMOD Record, 33, 4, (2004), 65-70.
Natural Science Foundation (No. 60903078). [15] Shvaiko, P., Euzenat, J. A survey of schema-based matching
approaches. Journal of Data Semantics IV, (2005), 146-171.
9. REFERENCES [16] Glimm, B., Krötzsch, M. SPARQL beyond subgraph
[1] Franklin, M.J., Halevy, A.Y., Maier, D. From databases to matching. In Proceedings of the International Conference on
dataspaces: A new abstraction for information management. Semantic Web (ISWC'10), 2010.
SIGMOD Record, 34, 4, (2005), 27-33. [17] Wache, H., Vögele, T., Visser, U., Stuckenschmidt, H.
[2] Prud'hommeaux, E., Seaborne, A. SPARQL query language Schuster, G., Neumann, H., Hübner, S. Ontology-based
for RDF. W3C Recommendation, 2008. Retrieved April 25, integration of information – a survey of existing approaches.
2011, from http://www.w3.org/TR/2008/REC-rdf-sparql- In Proceedings of the International Joint Conferences on
query-20080115/ Artificial Intelligence Workshop, (IJCAI'01), 2001, 108-117.
[3] Sahoo, S.S., Halb, W., Hellmann, S., Idehen, K., et al. A [18] Gannon, T., Madnick, S., Moulton, A., Siegel, M., Sabbouh,
survey of current approaches of mapping of relational M., Zhu, H. Framework for the analysis of the adaptability,
database to RDF, 2009. Retrieved April 25, 2011, from extensibility, and scalability of semantic information
http://www.w3.org/2005/Incubator/rdb2rdf/RDB2RDF_Suve integration and context mediation approach. In Proceedings
yReport.pdf of the Hawaii International Conference on System Sciences,
[4] Goh, G.H., Bressan, S., Madnick, S., Siegel, M. Context (HICSS'09), 2009, 1-11.
Interchange: New Features and Formalisms for the [19] Mihai, L., Madnick, S. Using Semantic Web tools for
Intelligent Integration of Information. ACM Transactions on context interchange. In Proceedings of the VLDB Workshop
Information Systems, 17, 3, (1999), 270-293. on Ontologies-Based Techniques for Databases and
[5] Hartig, O., Bizer, C., Freytag, J.-C. Executing SPARQL Information System, (ODBIS'07), 2007.
queries over the Web of linked data. In Proceedings of the APPENDIX A. NAMESPACE
International Conference on Semantic Web, (ISWC'09). 2009, PREFIX rdfs:
293-309. PREFIX xsd:
PREFIX coin:
[6] Zhu, H. Effective information integration and reutilization PREFIX ctx:
solutions: to technological deficiency and legal uncertainty. PREFIX fts:
Ph.D. Thesis, Massachusetts Institute of Technology, PREFIX fn:
Cambridge, MA, 2005. APPENDIX B. THE EXAMPLE SCENARIO
[7] Zhu, H., Madnick, S. Scalable interoperability through the Context Pool:
use of COIN lightweight ontology. In Proceedings of the # Default graph: http://coin.mit.edu/contexts
ctx:US_dollar coin:hasScale "1"^^xsd:integer .
VLDB Workshop on Ontologies-Based Techniques for ctx:US_dollar coin:hasCurrency "USD" .
Databases and Information System, (ODBIS'06), 2006, 37-50. ctx:JP_yen coin:hasScale "1000"^^xsd:integer .
ctx:JP_yen coin:hasCurrency "JPY" .
[8] Kjernsmo, K., Passant, A. SPARQL New Features and
ctx:US_dateTime coin:hasFormat "US_dateTime" .
Rationale. W3C Working Draft 2, 2009. Retrieved April 25, ctx:XSD_dateTime coin:hasFormat "XSD_dateTime" .
2011, from http://www.w3.org/TR/sparql-features/ ctx:IATA_airportCode coin:hasEncoding "IATA_airportCode" .
ctx:EN_city coin:hasEncoding "EN_city" .
[9] Li, X., Madnick, S., Zhu, H., Fan, Y.S. An approach to
composing Web services with context heterogeneity. In Context Mappings:
Proceedings of the International Conference on Information # Named graph: http://coin.mit.edu/sources/usairline (Source 1)
System, (ICIS'09), 2009, 695-702. fts:depDateTime coin:dateTime ctx:US_dateTime .
fts:arrDateTime coin:dateTime ctx:US_dateTime .
[10] Sattler, K.U., Geist, I., Schallehn, E. Concept-based querying fts:depCity coin:city ctx:IATA_airportCode .
in mediator systems. The VLDB Journal, 14, (2005), 97-111. fts:arrCity coin:city ctx:IATA_airportCode .
fts:price coin:monetaryValue ctx:US_dollar .
[11] Stuckenschmidt, H. Vdovjak, R. Houben, G.J., Broekstra, J.,
Amerfoort, A.B.V. Index structures and algorithms for # Named graph: http://coin.mit.edu/sources/japanairline (Source 2)
querying distributed RDF repositories. In Proceedings of the fts:depDateTime coin:dateTime ctx:XSD_dateTime .
fts:arrDateTime coin:dateTime ctx:XSD_dateTime .
International Conference on World Wide Web, (WWW'04), fts:depCity coin:city ctx:EN_city .
2004, 631-639. fts:arrCity coin:city ctx:EN_city .
[12] Gracia, J., d'Aquin, M., Mena, E. Large scale integration of fts:price coin:monetaryValue ctx:JP_yen .
senses for the Semantic Web. In Proceedings of the # Named graph: http://coin.mit.edu/receivers/myContext (Receiver)
International Conference on World Wide Web, (WWW'09), :flight coin:dateTime ctx:US_dateTime .
2009, 611-620. :flight coin:city ctx:EN_city .
:flight coin:monetaryValue ctx:US_dollar .
[13] Schenk, S., Staab, S. Networked graphs: a declarative
mechanism for SPARQL rules, SPARQL views and RDF # Named graph: http://coin.mit.edu/bindings/flight (Context binding)
data integration on the Web. In Proceedings of the coin:hasContext
International Conference on World Wide Web, (WWW'08), .
2008, 585-594. coin:hasContext
.
coin:receiver coin:hasContext .