metamodels like RDF or UML, it is
tempting to assume that users of the
API will use the same metamodel as
the provider. As a result, these API designers use their system metamodel
as the exchange metamodel. We have
identified this tendency to use system
models as exchange models in Web
contexts as Web blindness. 5 Instead of
creating an architecture based on the
smallest possible set of assumptions
(which in the case of Web data and
services should be XML metamodels),
the exchange metamodel then is dictated by the environment of the data
or service provider.
We argue it is better practice in
API design to think of an API as being
designed by its users, rather than its
providers, a point that also has been
made for function-oriented APIs. 3
Such a consumer-oriented definition
of the exchange model focuses on the
simplest possible set of assumptions
about the consumers, making the API
as usable and accessible as possible.
metamodels in Practice
The following example illustrates how
these metamodel considerations can
inform the design of a resource-oriented API to use the smallest possible
set of assumptions.
Let’s assume that in a procurement application based on an ER
system model, a purchase order is assembled to be sent to a supplier. The
exchange model is defined as an XML
Schema with additional semantic annotations, so that the application semantics (such as billing address and
shipping address) are defined in the
model. The order can then be assembled by matching the ER concepts of
addresses to the corresponding XML
concepts of the order document, that
is, by mapping addresses in the system
model to addresses in the exchange
model. The order is then serialized as
an XML document and sent to the supplier through some communications
channel.
On the supplier side, when the order is received, the XML document
is parsed and the exchange model is
reconstructed so that it can be used
by the supplier’s order management
application. Just to illustrate the
point that the system models on the
two sides can be radically different,
the argument
that ‘we use xmL,
which is a widely
accepted data
format, and thus
our interface is
easy to use’ makes
about as much
sense as ‘we use
bits, which are a
widely accepted
data format, and
thus our interface
is easy to use.’
let’s make the unlikely assumption
that the supplier uses Semantic Web
technologies. Using a mapping from
XML to RDF, the exchange data can be
mapped to RDF triples representing
the order, because a matching process
was used to identify how concepts in
the exchange model can be mapped to
the receiver’s system model.
In such a scenario, the order is represented in three different conceptual
models on its way from the sender to
the receiver. This process is shown
in the accompanying figure and described here in more detail.
model matching and mapping
The existence of system and exchange
models makes it necessary to match
and map models. Model matching is
the process of finding identical concepts in two models.d In most cases,
this process has to be done manually.
If both models use the same metamodel, it often is possible to use tools
to identify matching concepts, and
even to generate code that will map
data from one model to the other.
For example, a popular functionality
in XML editors is schema matching,
where candidate conceptual matches
between two schemas are made based
on element and attribute names, and
then refined manually in the editor if
these matches are not exact.
It is important to point out that
model matching usually is only partial. As there is no “one true model”
of the domain, the system models of
the participants typically cover larger
application areas than the exchange
model. It is also possible that the exchange model defines concepts that
are not used in one of the system models, in which case this part of the exchange model will be ignored in the
respective mapping. In this case, it is
important which parts of the exchange
model are mandatory and which are
optional.
Model mapping is the process that
takes data represented in one model, uses the conceptual matching of
two models, and maps this data to
another model. Mapping can take
d This conveniently ignores the fact that in
many cases concepts in different models are
never fully identical; they often are partial and/
or conditional matches only.