Jump to content

SSWAP

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Chajadan (talk | contribs) at 10:06, 1 July 2015 (Link first page instance of "semantic web"). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Simple Semantic Web Architecture and Protocol (SSWAP pronounced "swap") is a lightweight, document-centric protocol and architecture for the Semantic Web. Employing notions drawn from REST, Web Ontology Language (OWL), and web services, SSWAP makes possible a scheme for information sharing and service invocation that allows information producers and consumers to coordinate their efforts in a decentralized and bottom-up fashion. Using SSWAP, users can create systems to enable creation, discovery and execution of RESTful and other web services. SSWAP utilizes Web Ontology Language (OWL) ontologies to describe the features and capabilities of web services and standard HTTP methods to execute these web services.

Overview

SSWAP aims to combine web services and semantic web technologies to enable high-throughput discovery, assessment, and integration of data and services between distributed parties. Semantic Web ontologies encoded in OWL are used to describe information about a web service such as the service category, types of input the service consumes, and the types of output the service produces. Using ontologies to describe such properties makes the service descriptions amenable to automated reasoning methods and allows inferencing to be used for tasks such as searching for service descriptions, basic matchmaking, and determining if the output of a service can be used as input to another service.

SSWAP differs from other Semantic Web Services architectures (the most prominent ones being OWL-S and SA-WSDL) by not adopting the XML-based Web Service technologies such as WSDL and SOAP. Instead, SSWAP adopts a simple approach based on a RESTful architecture. Services are identified by a URI and standard HTTP methods GET and POST are used to access the service descriptions and to invoke the services, respectively. SSWAP does not specify rules for authentication or security; but it is designed to work on protocols such as SSL and HTTPS that already address these issues.

At its core SSWAP is an OWL ontology specifically designed to describe web services. In SSWAP a service represents nothing more than an mapping from its inputs to its outputs. The SSWAP ontology defines a small set of terms that can be used to describe this transformation. The same representation is also used for service search requests and responses, as well as service execution requests and responses.

This representation can be thought of as an RDF graph template. There are immutable parts of the template, called the "canonical graph", that unambiguously establishes the web resource performing the service, as well as the subject and object of the service mapping. The mutable parts annotate this canonical structure, allowing the use of arbitrary OWL constructs to optionally refine the service's class and the subject and object mappings. For example, a service execution request fills in the value of an input parameter; but it leaves the output value blank, which is then filled as a result of the service execution and returned as the response. Thus, SSWAP defines a protocol where clients and servers exchange OWL documents that contain this graph structure for accomplishing the tasks of services discovery and execution.

SSWAP ontology is not domain-specific and can be combined with arbitrary domain ontologies to represent the relevant types of services, inputs, or outputs. But a distinctive feature of SSWAP is that it defines a convention for partitioning domain ontologies into smaller parts, such that each term definition (for a class, property, or an individual) is stored in a separate ontology document. According to SSWAP, the definition of a term to be all axioms whose subject is the term being defined. An existing ontology can be automatically partitioned into multiple term definition ontologies by adopting this convention. A term definition ontology is smaller compared to the original ontology because it contains a subset of the original axioms. In addition, SSWAP requires that the URIs that identify terms should not use fragment identifiers. These two conventions make sure that dereferencing a term URI will retrieve the definition ontology for that term. This makes it easier to use terms from very large ontologies to describe web services since the service description can refer to only the terms relevant for its functionality and only retrieve the corresponding definition ontologies rather the one large ontology that contains all the terms. The definition of a term (as described in SSWAP) does not contain all the inferences about the term that can be computed from the original ontology. The partitions of the ontology are still connected to each other using the standard OWL import mechanism and all the terms can be combined into a meta-ontology to compute the complete logical consequences of the original ontology.

Ontology and Protocol

The SSWAP architecture[1] is based on five basic concepts: Provider, Resource, Graph, Subject, and Object. Providers typically correspond to organizations that own and publish resources. Resources can be arbitrary resources like web pages or ontologies or datasets; but they are primarily used to describe web services. The transformation performed by the service is fully described as a SSWAP Graph concept. The graph defines a mapping from a SSWAP Subject (input) to a SSWAP Object (output). Multiple inputs and multiple outputs can be represented using multiple graphs or multiple mappings in a single graph, respectively. The description of resources are stored in a document that is referred as a Resource Description Graph (RDG).

The main concepts of the SSWAP protocol

Providers publish their resource descriptions on the Web, a key design decision behind most notions of the public Semantic Web, which uses the distributed domain naming system (DNS) as a means of avoiding name and identifier clashes. The clients can obtain these RDGs by dereferencing the URL for the resource. The RDGs can be collected and stored by a discovery server that will provide a search service. A discovery server can locate RDGs either by crawling the Web or by allowing providers to submit the URL for their resources to the discovery server. The discovery server stores resource descriptions and any other domain ontology imported by the RDG in its knowledge base. In this way, SSWAP is similar to the Linked Open Data (LOD) approach, which also relies on URL-identified documents to contain machine processable information.

SSWAP's emphasis on a canonical structured document means that service description, querying for new services, service invocation, and service response all occur around the structure of the same, mutable RDF/XML document. This is distinct from traditional web service protocols. In traditional web service protocols, the way a service describes itself may say little about how to query and discover the service via a search engine. Similarly, the way data is marshalled to invoke the service may have little connection to how the return data is packaged as a response.

In SSWAP, performing an HTTP GET on a service's URL returns the service description; that is, the RDG for that service. Removing the service's URL from the graph and sending the graph to a semantic search engine will query (i.e., discover) all similar services. This graph is called a Resource Query Graph (RQG). Adding input data to a SSWAP subject of the graph creates a graph ready for invocation which is called a Resource Invocation Graph (RIG). To invoke the service, the graph is POSTed to the service's URL or sent as a query string in an HTTP GET. The service's response is also embedded in the same graph. The response graphs is called a Resource Response Graph (RRG). A client may then simply remap the returned SSWAP object to another graph's SSWAP input and send it to another service, and so forth.

SSWAP specification also prescribes how to match a request to locate services with existing service descriptions. In other words, SSWAP defines when a service description RDG matches a RQG. The match between the service and the query is based on the semantic relations between the resource, subject, and object types. A discovery server will return all resources that are the same class or a subclass of the query graph's Resource, and superclass of the query graph's Subject, and subclass of the query graph's Object. This matching criteria ensures that the results will contain (1) all services that are tagged as at least as specific as requested (and maybe more specific); (2) that operate on data that is guaranteed to subsume the input provided (and may operate on more general data); and, (3), that return data that is at least as specific as the requested output (and maybe more specific).

Examples

The following examples show the description of a semantic web service using the SSWAP. The examples are illustrative; for an implemented example in the bioinformatics domain see SSWAP web site.

Example 1: A Resource Description Graph

@prefix rdf: «http://www.w3.org/1999/02/22-rdf-syntax-ns#» . 
@prefix owl: «http://www.w3.org/2002/07/owl#» . 
@prefix sswap: «http://sswapmeet.sswap.info/sswap/» . 
@prefix location: «http://www.example.org/locationOntology/» . 
@prefix weather: «http://www.example.org/weatherOntology/» . 
@prefix resource: «http://www.example.org/getTemperatureService/» .

resource:getTemperatureService 
        rdf:type sswap:Resource , weather:TemperatureInformationService; 
        sswap:providedBy resource:resourceProvider ; 
        sswap:name "Temperature lookup service" ; 
        sswap:oneLineDescription 
                "A service that accepts a location in US (identified by a 5-digit zipcode) and returns the current temperature in that location" 
        sswap:operatesOn [ 
                rdf:type sswap:Graph ; 
                sswap:hasMapping [ 
                       rdf:type sswap:Subject , location:Location ; 
                       location:zipcode "" ; 
                       sswap:mapsTo [ 
                              rdf:type sswap:Object , weather:Temperature 
                       ] 
                ] 
        ] .

In this example, the resource getTemperatureService is typed as a TemperatureInformationService to specify what kind of service category it belongs to. In the domain ontology that describes this term there may be other definitions such as an axiom saying TemperatureInformationService is a subclass of WeatherInformationService. Similarly, the inputs and outputs of the service are defined referring to terms from one or more domain ontologies. These definitions make it unambiguous that the service takes as input a zipcode and returns the temperature for that location.

Example 2: Backwards compatibility

The following example shows the changes to the RDG if the provider of the service expands the service's utility by allowing the service to map IP addresses as well as zip codes. The service accepts IP addresses as input subjects and looks up the IP address location information. This expansion of the location:Location class results in a revised RDG:

        rdf:type sswap:Subject , location:Location ; 
        location:zipcode "" ;
        location:ipAddress "" ;

With this change, the service still maintains backwards compatibility with clients. Clients that had neither knowledge nor need for the location:ipAddress enhancement would still continue to work with the location:zipcode predicate without any changes required on their part.

Example 3: Social propagation of domain semantics: Extension

The next example shows how another provider can extend the previous RDG and to provide a service that maps domain names and not just IP Addresses. Since the existing services already use the location:Location class, this provider can independently subclass location:Location to define a new class and put this new class definition and its own RDG on its own web site:

@prefix rdf: «http://www.w3.org/1999/02/22-rdf-syntax-ns#» . 
@prefix owl: «http://www.w3.org/2002/07/owl#» . 
@prefix sswap: «http://sswapmeet.sswap.info/sswap/» . 
@prefix myLocation: «http://www.myExample.org/locationOntology/» . 
@prefix weather: «http://www.example.org/weatherOntology/» .
@prefix myWeather: «http://www.myExample.org/weatherOntology/» . 
@prefix resource: «http://www.myExample.org/getTemperatureService/» .

resource:getTemperatureService 
        rdf:type sswap:Resource , myWeather:MyTemperatureInformationService; 
        sswap:providedBy resource:resourceProvider ; 
        sswap:name "Temperature lookup service" ; 
        sswap:oneLineDescription 
                "A service that accepts a domain name and returns the current temperature associated with that location" 
        sswap:operatesOn [ 
                rdf:type sswap:Graph ; 
                sswap:hasMapping [ 
                       rdf:type sswap:Subject , myLocation:Location ; 
                       myLocation:domainName "" ; 
                       sswap:mapsTo [ 
                              rdf:type sswap:Object , weather:Temperature 
                       ] 
                ] 
        ] .

The notable difference in this RDG is that the provider now hosts its own locationOntology at its own web site identified by the prefix myLocation. The subclass relation between the new class and location:Location would be expressed in the information and would be viewable by anyone by performing a HTTP GET on myLocation:Location. In a similar manner, the provider creates the new class myWeather:MyTemperatureInformationService as a subclass of weather:TemperatureInformationService and would be discovered by the users by retrieving the definition of myWeather:MyTemperatureInformationService.

Two different services can use the same local name but as long as the base URL is different (www.example.org vs. www.myExample.org) there would not be a name collision. The reuse of weather:Temperature class for the output makes it explicit that two service generate the same type of data.

Because this new provider is subclassing location:Location, it must support the location:zipcode and location:ipAddress predicates. There is a simple way for this provider to support the parent class' predicates. It can map domain names to IP addresses and then call the original weather service itself. In the same way, if it gets a zip code or IP address as input, it can simply pass them through unaltered.

Example 4: Social propagation of domain semantics: Expansion

The following example shows an RDG from a third provider whose service returns semantically tagged units (Fahrenheit and Celsius), as well as a time of day stamp for the temperature. This service subclasses the weather:TemperatureInformationService class (as the functionality is still same) and reuses the location:Location class for its input but changes the output to a completely new type that encodes the additional information returned by this service:

@prefix rdf: «http://www.w3.org/1999/02/22-rdf-syntax-ns#» . 
@prefix owl: «http://www.w3.org/2002/07/owl#» . 
@prefix sswap: «http://sswapmeet.sswap.info/sswap/» . 
@prefix location: «http://www.example.org/locationOntology/» . 
@prefix weather: «http://www.example.org/weatherOntology/» .
@prefix myComplicatedWeather: «http://www.ontologiesRUs.org/weatherOntology/»
@prefix resource: «http://www.yetAnotherExample.org/getTemperatureService/» .

resource:getTemperatureService 
        rdf:type sswap:Resource , weather:TemperatureInformationService; 
        sswap:providedBy resource:resourceProvider ; 
        sswap:name "A more complicated Temperature lookup service" ; 
        sswap:oneLineDescription 
                "A service that accepts a domain name and returns the current temperature associated with that location with the time stamp associated with that measurement" 
        sswap:operatesOn [ 
                rdf:type sswap:Graph ; 
                sswap:hasMapping [ 
                       rdf:type sswap:Subject , location:Location ; 
                       location:zipcode "" ; 
                       sswap:mapsTo [ 
                              rdf:type sswap:Object , myComplicatedWeather:TempAndTime 
                       ] 
                ] 
        ] .

Example 5: Semantic searching and service matchmaking

The following table shows several example Resource Query Graphs (RQG) and which of the examples RDGs shown above would match these RQGs. A 'X' symbol in a column indicates that the RDG shown in that example will be returned as a match to the RQG shown in the corresponding row.

Query RQG Example 1 Example 2 Example 3 Example 4
1 _:r rdf:type sswap:Resource, weather:TemperatureInformationService X X X X
2 _:r rdf:type sswap:Resource, myWeather:TemperatureInformationService   - - X -
3 _:s rdf:type sswap:Subject, location:Location X X X X
4 _:o rdf:type sswap:Object, weather:Temperature X X X -
5 _:s rdf:type sswap:Subject, location:Location
_:o rdf:type sswap:Object, myComplicatedWeather:TempAndTime
- - - X
6 _:s rdf:type sswap:Subject, myLocation:Location
_:o rdf:type sswap:Object, myComplicatedWeather:TempAndTime
- - - -

Query 1 asks for services that are of type weather:TemperatureInformationService and all services satisfy this condition when OWL subclass inferences are considered. Query 2 asks for a specific type of TemperatureInformationService which is satisfied by only the RDG in Example 3. Query 3 is to locate all services that accept inputs of type location:Location. This condition is again satisfied by all the example RDGs. Query 4 asks for service that output weather:Temperature instances. The RDG in Example 4 does not match this query since its output is no compatible with the requested type. Query 5 specifies both the types of input and output for the requested service which is satisfied by only the Example 4. Changing the type of the input as in Query 6 does not return any services since none of the example RDGs can satisfy both conditions at the same time.

Applications

SSWAP has been primarily deployed in the scientific domain and is used to integrate services in plant sciences cyberinfrastructure. The Legume Information System (LIS) is currently offering over 2 million FASTA DNA and RNA sequences using the SSWAP model. Soybase and Gramene offer approximately two dozen services. The Virtual Plant Information Network offers over 1500 wrapped web resources.

A discovery server is implemented that allows for on‐demand resource validation, publication, discovery, and invocation and runs at the SSWAP web site. SSWAP website also hosts several developer tools and provides a standard search engine interface for resource discovery that will perform semantic matching of resources. A semantic web service ontology portal SSWAPmeet contains ontologies from the biomedical domain that can be used in SSWAP service descriptions.

History

SSWAP originated from the Semantic MOBY project which was a branch of BioMOBY project. Under the umbrella of BioMOBY, Semantic MOBY developed the fundamental model for a semantic web approach, while MOBY Services developed the web services approach commonly referred to as "BioMOBY". Semantic MOBY project was followed by The Virtual Plant Information Network (VPIN) that eventually turned into SSWAP.

See also

References