Keywords

1 Introduction

Semantic applications are emerging as a solution to data-driven problems. For instance, the ORCA project aims at automatically assigning nurses to patient calls in a hospital based on their context [1]. Linked Connections define a way to publish raw transit data, to be used for intermodal route planning [3]. In projects like the aforementioned, it is common that the Semantic Web is not solely used as a means to publish data, but also as a catalyst to execute other actions, e.g., calling a real-world nurse, or executing a route planning algorithm. Usually, this implies querying the RDF results for possible actions, parsing the data using custom parsing rules, and executing the actual function. E.g., in the ORCA project, a semantic reasoning system derives the most suitable nurse. The resulting turtle data is queried, resulting in the triple ex:call1 ex:assign ex:nurseA. How to convert this triple to the execution of the function callNurse(nurseA, call1) is not semantically defined, but is defined ad hoc per use case.

There exist many specifications handling Web services, both non-semantically (e.g., WSDL and WADL) and semantically (e.g., OWL-S and Hydra)Footnote 1. 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 paper, we present a general vocabulary as a data model, specification, and ontology to semantically declare and describe functions. Instead of defining technology-specifics, i.e., hard-coding executable actions, the functions are described independently of the technology that implements them. Complementary to the current specifications that describe how to execute a certain service, this vocabulary describes what a functions does. By semantically defining these functions, we provide a uniform and unambiguous solution, and thus, we close the gap between semantic data and any real-world action, enabling semantic applications to be used in real-world scenarios.

2 The Function Ontology

The Function model allows users to declare that a certain function exists, and associates this function with certain problems and the algorithms it implements. Furthermore, it allows for the description of executions of functions. Execution descriptions of functions assign values to the input parameters, e.g., function int sum(int a, int b) is a description of a function, whilst sum(2, 4) is a description of the execution of the sum function. The Function model does not describe the internals of a function, as this depends on the used technology. E.g., the aforementioned sum function can be interpreted for implementation in JavaScript as return a + b, in PHP as return $a + $b;, using a Web service, or via another technology.

The Function OntologyFootnote 2 consists of a set of base classes. A problem, algorithm or function can be defined as an instance of those base classes. As new problems and algorithmic solution arise daily, it would not be beneficial to include all possible problems and algorithms in the Function Ontology. Problems, functions, and algorithms can be classified using the SKOS model [4]. For example, a sumProblem can be classified as ex:sumProblem skos:broader ex:mathProblem. These classifications can be reused across domains, independent of the used technologies.

Fig. 1.
figure 1

The Function ontology, with an example of how reification is used to connect named parameters and output values to the function execution.

Full size image

The Function Ontology (see Fig. 1) consists of the following classes:

  • Function The declared function (e.g., function sum)

  • Problem A problem that a function solves, e.g., adding two numbers.

  • Algorithm A declaration of an algorithm. We separate the algorithm concept, as there are no one-to-one mappings between problems, functions, and algorithms [2].

  • Parameter A parameter of a function (e.g., function sum has two parameters, a and b). rdfs:range can be used to describe the type of that parameter, and reification (as opposed to, e.g., using RDF lists) is used to create named connections between a function and its parameters (cfr. the parameter and execution declaration in Fig. 1).

  • Output An output of a function, e.g., function sum(a, b) has sumResult as output. Typing and reification paradigms are similar as with parameters.

  • Execution An execution assigns actual input values to function parameters, and holds the output values. E.g., sum(2, 3) is an execution of int function sum(a,b).

3 Example and Conclusions

These base classes do not define any specific problem, function or algorithm, but allow to declare and describe any specific problem, function, or algorithm. For example, if John Doe needs a description of a sum function – given it does not already exist – he can publish his own descriptions as shown in Listing 1. Software systems supporting this description are thus able to compute the execution of that function. The deployment/implementation of the described functions is independent of the programming language and the access interface.

figure a

This example shows how the Function Ontology allows for semantic systems to connect to non-semantic processing functions. By remaining technology-agnostic, both small and large-scale RDF processing actions can be defined, without solely depending on Web services as execution platform. As such, it will be evaluated in the frame of, among others, ORCA, Linked ConnectionsFootnote 3, and the COMBUST projectFootnote 4. Future work includes the creation of an upper level reference function model and a specification of the technical integration process.