What is a SADI service?

A SADI service is quite unlike other kinds of web services, so it’s best to just start at the beginning. The requirements and expected behaviour of a SADI service are enumerated here, exemplified by a simple Hello, World! service.

  1. A SADI service is identified by a URI that is also an HTTP URL.

    We will use the service http://sadiframework.org/examples/hello as an example.

  2. When an HTTP GET request is sent to the service URL, the response is an RDF document containing an instance of the SADI service OWL class identified by the service URI. For more information, see SADI service description.

    The service description contains, among other things, the URIs of two OWL classes: the input class and the output class. Each of these URIs should also be an HTTP URL that resolves to the OWL definition of the class. The property restrictions on the input class define the properties required to execute the service and the property restrictions on the output class define the properties the service attaches to its input. For more information, see SADI input and output classes.

    In our example, the input class URI is http://sadiframework.org/examples/hello.owl#NamedIndividual. This class has a single property restriction, indicating that it must contain at least one value of the http://xmlns.com/foaf/0.1/name property.

    The output class URI is http://sadiframework.org/examples/hello.owl#GreetedIndividual. This class has a single property restriction, indicating that it will contain at least one value of the
    http://sadiframework.org/examples/hello.owl#greeting
    property.

  3. When an HTTP POST request is sent to the service URL, the service is executed and the output is returned.

    The body of the POST request must be an RDF document containing one or more instances of the input OWL class. Each input instance must be explicitly typed (i.e.: it must have a value of the http://www.w3.org/1999/02/22-rdf-syntax-ns#type property that is the input class URI) and must not be anonymous (i.e.: it must be identified by a URI).

    The response to the POST is an RDF document containing instances of the output OWL class. Each output instance will be identified by the URI of the corresponding input instance. A SADI service can therefore be seen as "decorating" its input instances by adding additional properties to them.

    Here is an example input document for our service:

    <rdf:RDF
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:foaf="http://xmlns.com/foaf/0.1/"
      xmlns:hello="http://sadiframework.org/examples/hello.owl#">
        <hello:NamedIndividual rdf:about="http://sadiframework.org/examples/hello-input.rdf#1">
          <foaf:name>Guy Incognito</foaf:name>
        </hello:NamedIndividual>
    </rdf:RDF>

    And the corresponding output document:

    <rdf:RDF
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:hello="http://sadiframework.org/examples/hello.owl#">
        <hello:GreetedIndividual rdf:about="http://sadiframework.org/examples/hello-input.rdf#1">
          <hello:greeting>Hello, Guy Incognito!</hello:greeting>
        </hello:GreetedIndividual>
    </rdf:RDF>

    Note: a SADI service can also be asynchronous, returning a response to the original request before processing the input. For more information, see Asynchronous SADI services.

To simplify the task of implementing this specification, we have provided tools to help build services in Java and in Perl. If you have questions, visit the SADI Google Group.