26.03.2015 Views

19SafQB

19SafQB

19SafQB

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

328 Semantic as an Interoperability Enabler in Internet of Things<br />

of service_identification, service_functionality, security_profile and<br />

grounding.<br />

• Service_identification provides all the information that will let<br />

identify uniquely a service, from the set of services in an ontology<br />

repository. This identification is composed of three objects: service_name,<br />

the name allocated to the service, service_explanation,<br />

a detailed explanation of the functionality of the service, and service_owner,<br />

a person, entity or process name.<br />

• Service_funcionality provides information about the data interchanged<br />

with the service. Input_description is a formal description<br />

of the input information that user (process or other) must provide<br />

to the service in a request. In the same way, output_description is<br />

the description of the output information generated by the service.<br />

Some services need configuration data, prior to a request that will<br />

customize the service delivery. The description of the configuration<br />

parameters is provided by the precondition_description.<br />

• Grounding is the specification of the protocol that will support the<br />

interaction between the service and the application. The protocol<br />

could be a well-known one or could be ad-hoc for a specific application.<br />

In any case, it will be compliant with the service features.<br />

• Security_profile is the description of the security framework that<br />

supports a specific service.<br />

9.2.2.2 Context<br />

An important element for a service oriented middleware managing information<br />

models based on ontologies is the specification of the context condition under<br />

which the service is provided. It is not the same to provide a temperature<br />

service indoor or outdoor or a heart-rate service at sea level that on top of a<br />

mountain. The context information can be stored in the ontology repository<br />

and can be used by processes to provide the service accurately.<br />

The context class is composed of location, motion, geo_coordinates,<br />

smartSpace and context_criticality, depicted in the following figure.<br />

Location has two subclasses, indoor_location and outdor_location. It lets<br />

know if the service is provide in an indoor location, such us a house or a public

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!