There exist many specifications that define Web services, both non-semantically (e.g., WSDL and WADL) and semantically (e.g., OWL-S and Hydra) These specifications target different facets (e.g., HTTP-based vs SOAP-based access, defining RESTful APIs, etc.), but have in common that they define Web services. Thus, they clearly specify, e.g., which HTTP method to invoke with which parameter to correctly call the Web service. The big drawback of these specifications is thus that they are very coupled with the technology stack. However, not all actions can be executed using Web APIs, either because of performance or practicality reasons. For example, the nurse call system is a near real-time system, which implies that unnecessary HTTP connections should be avoided.

In this specification, we present a more general vocabulary as a data model, specification, and ontology to semantically declare and describe functions. Instead of defining technology-specifics, the functions are described independent of the technology that implements them. By semantically defining these functions using an ontology, we provide a uniform and unambiguous solution, and thus, we can close the gap between semantic data and any real-world action, and enable semantic applications to be used in real-world scenarios.

1. The Problem

Applications built on top of Linked Data and the Semantic Web are emerging as a novel solution in many different areas, such as -- among others -- decision making and route planning. However, to connect results of these solutions (i.e., the semantic data) with real-world applications, we need a generic way to connect actionable events to semantic data.

This specification (and accompanying ontology) explains how to semantically declare and describe functions, their input parameters, and possible outputs.

2. Definitions

The following document makes a clear distinction between following concepts:

A function declaration is stating that a function exists, without further ado. For example, function sum; is a function declaration.

A function description describes the function, i.e., talks about the inputs and outputs of the function. For example, the function above could have the following description: function int sum(int a, int b), namely, the function sum has two input parameters, int a and int b, and returns an integer.

A function definition defines the internal workings of a function. As this can be very dependent on the used programming language and/or execution environment, this is not taken into account by the Function Ontology.

An assignment fills in the values of the parameters of a functions. For example, a possible assignment for the exemplary function could be sum(2, 4), namely, assigning the values 2 to a and 4 to b.

Furthermore, we define following concepts:

A function is an actionable thing that can have input parameters, output, solve certain problems, and implement certain algorithms.

A problem is problem that can be solved by executing a certain function. For example, the above function solves the doing a sum problem.

An algorithm is a specified set of instructions, independent of its implementation (e.g., Dijkstra's shortest path algorithm). A function can implement one single algorithm, or use a combination of multiple algorithms to solve a certain problem. A function does not have to implement any algorithm or have to be mapped one-on-one to an algorithm.

A parameter is the description of the input value of a function. For example, the above function has two parameters, a and b.

An output is the description of the output value of a function. For example, the above function has one output, an integer. A function can have multiple outputs (e.g., callbacks in JavaScript can return multiple results, or a function could throw multiple types of errors).

An execution is the assignment of the values of the parameters of a function. An execution has as result the value of the output of the function. For example, sum(2, 4) is an execution of the example function. The value of the output is known after the function is executed, and should in this case be the integer 6.

3. The Function Ontology

Fig. 1The Function Ontology

The Function Ontology follows the Content Ontology Design Pattern and consists of a couple of base classes that need to be instantiated for real world use cases. Input parameters and output values are connected to functions via executions, using a reification paradigm.

To remain consistent with the paradigms used in SKOS, axioms need to be made instead of subclassing the base classes of the Function Ontology. The reification paradigm allows to define the connection between an execution and the input parameters and output values. This allows for re-use of these connection definitions, and more meaningful connections between input parameter and execution.

No cardinalities are defined in the Function Ontology, as there are no hard limits on cardinality to be defined. A function can implement multiple algorithms, solve multiple problems, and have multiple executions. All executions can have multiple input parameters and output values. Vice versa, input parameters and output values can be linked to multiple executions, and an execution (i.e., a set of input values and output values) can be linked to multiple functions.

This description actually defines which predicates to use when binding the values to the execution of the function (using the fno:predicate predicate). All predicates are allowed, except for rdf:type and fno:executes.

In the example ex:intParameterA and ex:intParameterB can be reused across function descriptions. As they only describe the parameters, and not the actual values, they can be reused. For example, the function function match(str, regex) and function split(str, regex) could reuse the same parameter instantiatons.

The fno:expects has as range an rdf:List. This could be used to hint applications how many parameters are used, and in what order, however, this is not enforced. This to accommodate technologies where the order of parameters is not of importance.

Note

The range of the predicates used by the parameters don't have to be defined. However, by do defining them, we achieve type hinting.

3.4.2 fno:predicate

3.5 fno:Execution

As can be seen here, are the predicates used as described as parameters of the function.
rdf:type and fno:executes cannot be used as parameter predicates, as this would conflict with the description of the execution.