View source for IServe vocabulary

==iServe Vocabulary==

In order to reduce the amount of manual effort required for ﬁnding, combining and using services, it is necessary to provide a common vocabulary based on existing Web standards and practices able to describe services in a way that allows machines to automatically locate and ﬁlter services according to their functionality or the data they handle independently from the underlying formalism originally used for describing them.

The most well-known approaches to annotating services semantically are OWL-S, WSMO, SAWSDL, WSMO-Lite when it comes to WSDL services, and MicroWSMO, and SA-REST for Web APIs. In order to cater for interoperability, iServe uses what can essentially be considered the maximum common denominator 
between these formalisms which we refer to as the Minimal Service Model (MSM). The MSM, ﬁrst introduced together with [http://www.vitvar.com/doc/WI2008-KopeckyGV.pdf hRESTS] and [http://www.eswc2008.org/final-pdfs-for-web-site/swsII-3.pdf WSMO-Lite], is thus a simple RDF(S) ontology able to capture (part of ) the semantics of both Web services and Web APIs in a common model supporting the common publishing and search of services while it allows speciﬁc extensions to beneﬁt from the added expressivity of other formalisms should tools and applications require it.


[[File:Minimal_Service_Model-v5.png|600px|thumb|left|iServe Vocabularies]]


The MSM, denoted with the ’msm’ namespace in the figure, deﬁnes Services as having a number of operations each of which have an Input and Output MessageContent and Faults. In turn, a MessageContent may be composed of MessageParts which may be mandatory or optional. The renaming of Message into MessageContent and the inclusion of message parts introduced herein extends the previous versions of the MSM as described in the orginal definition to support ﬁner-grain discovery based on MessageParts in a similar way to OWL-S, as well as in order to distinguish between mandatory and optional parts.

iServe additionally uses the SAWSDL, WSMO-Lite and hRESTS vocabularies, depicted in the ﬁgure with the ’sawsdl’, ’wl’, and ’rest’ namespaces respectively. The SAWSDL vocabulary captures in RDF the three main kinds of annotations over WSDL and XML Schema, including modelReference, liftingSchemaMapping and loweringSchemaMapping that SAWSDL supports. The modelReference enables the linking of service elements to semantic models via URIs, while the two SchemaMappings are used to deﬁne data transformations from a syntactic representation to its semantic counterpart and vice versa. SAWSDL allows to 
annotate services and XML-Schema with semantic annotations but does not specify a particular representation language nor does it provide any speciﬁc vocabulary that users should adopt.

WSMO-Lite builds upon SAWSDL by extending it with a model specifying the semantics of the particular service annotations. It provides a simple RDFS ontology together with a methodology for expressing functional and non-functional semantics, and an information model for WSDL services based on 
SAWSDLs modelReference hooks. In particular, WSMO-Lite makes explicit the intended meaning for modelReference annotations without modifying SAWSDL but rather informing users on how they should structure the models their annotations point to. To this end the WSMO-Lite vocabulary includes the classes NonFunctionalParameter, FunctionalClassiﬁcationRoot, Condition, Effect and Ontology. 

The [http://www.vitvar.com/doc/WI2008-KopeckyGV.pdf hRESTS vocabulary], extends the MSM with speciﬁc attributes for operations so as to allow modeling addtional details necessary for Web APIs such as a URITemplate informing how to construct the URI for invocation, and an invocation Method. For completeness iServe includes the most typical methods used – those deﬁned by HTTP – by reusing the [http://www.w3.org/TR/HTTP-in-RDF10/ HTTP vocabulary].