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
Rest
Rest may refer to:* Leisure* Human relaxation* SleepRest may also refer to:* Rest , a pause in a piece of music* Rest , the relation between two observers* Rest , a 2008 album by Gregor Samsa...
The Web Ontology Language is a family of knowledge representation languages for authoring ontologies.The languages are characterised by formal semantics and RDF/XML-based serializations for the Semantic Web...
(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
Web Ontology Language
The Web Ontology Language is a family of knowledge representation languages for authoring ontologies.The languages are characterised by formal semantics and RDF/XML-based serializations for the Semantic Web...
(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
Semantic Web
The Semantic Web is a collaborative movement led by the World Wide Web Consortium that promotes common formats for data on the World Wide Web. By encouraging the inclusion of semantic content in web pages, the Semantic Web aims at converting the current web of unstructured documents into a "web of...
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.
Semantic Web Services, like conventional web services, are the server end of a client–server system for machine-to-machine interaction via the World Wide Web...
architectures (the most prominent ones being OWL-S
OWL-S
OWL-S is an ontology built on top of Web Ontology Language by the DARPA DAML program. It replaces the former DAML-S ontology. "OWL-S is an ontology, within the OWL-based framework of the Semantic Web, for describing Semantic Web Services...
and SA-WSDL) by not adopting the XML-based Web Service technologies such as WSDL and SOAP
SOAP
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks...
. Instead, SSWAP adopts a simple approach based on a RESTful architecture. Services are identified by a URI
Úri
Úriis a village and commune in the comitatus of Pest in Hungary....
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 identifier
Fragment identifier
In computer hypertext, a fragment identifier is a short string of characters that refers to a resource that is subordinate to another, primary resource...
s. 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 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).
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.
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:
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:
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 output but changes the output to a completely new type that encodes the additional information returned by this service:
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 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
BioMOBY
BioMOBY is a registry of web services used in bioinformatics. It allows interoperability between biological data hosts and analytical services by annotating services with terms taken from standard ontologies.- The BioMOBY project :...
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.
The Semantic Web is a collaborative movement led by the World Wide Web Consortium that promotes common formats for data on the World Wide Web. By encouraging the inclusion of semantic content in web pages, the Semantic Web aims at converting the current web of unstructured documents into a "web of...
Semantic Web Services, like conventional web services, are the server end of a client–server system for machine-to-machine interaction via the World Wide Web...
The Web Ontology Language is a family of knowledge representation languages for authoring ontologies.The languages are characterised by formal semantics and RDF/XML-based serializations for the Semantic Web...
In computing, linked data describes a method of publishing structured data so that it can be interlinked and become more useful. It builds upon standard Web technologies such as HTTP and URIs, but rather than using them to serve web pages for human readers, it extends them to share information in a...
