Information Technology Reference
In-Depth Information
O
: {
=
lastName firstName birthDate
,
,
}
(1)
request
(2)
O
: { (
= 1
d lastName firstName d email d birthDate
,
);
(
);
(
)}
divided
2
3
Mapping
partial {
d WS d WS
Þ
;
Þ
}
(3)
2
1
3
2
Mapping
exact { ,
d d WS
(
),
d WS
(
)
Þ
WS
}
(4)
1
2
1
3
2
3
expected by the consumer. The partial compliance
of a WS is happened when the requirements can
be divided into logical parts. If the WS complies
with a part, then it can be used to handle the
information in collaboration with another Web
Services. Failure compliance is happened when
the WS does not comply with the request or parts
of that request.
To clarify the abovementioned compliance
types we can give the following example: suppose
a data set about a customer that has to be validated
and stored and it contains his first and last names,
email and birth date. The validation of the email
address and the birth date can be done partially
and independently from storing the customer's
information (see 2).
Web Services WS 1 and WS 2 are partially
complaint to the request (see 1) where WS 1
complies with the customer's email address and
WS 2 complies with his birth date (see 3). They
are used to handle the validation. WS 3 (see 4) is
an exact match because it complies with all of
the customer's information and it will be used to
store this information.
From a provider's perspective, this provides a
possibility to integrate low capacity Web Services
into ambitious requests by making crossing among
the possible requests. But the challenge is to ana-
lyze the structure of the information by machines
not by humans. To do so, the person within the
ontology has to be broken down into properties.
Typically, literals are used to store information
like the name of a person and in this way, a first
name can be everything described as an array of
characters. However, in the real world this is not
totally true because there are small quantities of
character combinations that are valid to be first
names. Considering this fact, the correct data
type for the property first name would be an
enumeration or an object that contains a table of
valid entries. An email address is not a random
literal too and the previous example showed that
the design of the ontology has to start at the level
of the properties not the level of entities.
Another challenge is the reflection of an ontol-
ogy to an information system. Even at the level
of primitive data types, there are many possible
incompatibilities. The size of an xsd:string for
example is limited by the storage file system
(Malhotra et al., 2009). It is not a big deal to create
an xsd:string with the size of 3 Gbytes but it is
not possible to load this string into a Java-based
software because the Java:string length is limited
to (2 31 - 1) bytes. If the data has to be stored in a
database, which size is the right one for a text field?
Another issues can be the handling of numbers, so
if an xsd:PositiveInteger has to be handled, from
one side the same problems will appear and from
the other side there is no PositiveInteger data type
in a lot of software platforms, and this will give
the possibility to handle such invalid values from
the ontology's perspective.
Search WWH ::




Custom Search