Abstract

This document discusses the Function Ontology, a way to semantically declare and describe function. It uses SKOS to define relations between functions, problems, and algorithms.

A list of the publications concerning the Function Ontology can be viewed at http://users.ugent.be/~bjdmeest/#function

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.

Namespace

The Function Ontology's namespace is http://w3id.org/function/ontology

The preferred prefix is fno:

Status of This Document

This document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.

This is an early draft, expect this document to change much and often.

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:

Furthermore, we define following concepts:

3. The Function Ontology

The Function Ontology
Fig. 1 The 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.

3.1 fno:Function

Example 1
ex:sumFunction a fno:Function;
    fno:name "The sum function"^^xsd:string;
    dcterms:description "This function can do the sum of two integers."^^xsd:string;

3.2 fno:Problem

Example 2
ex:sumFunction a fno:Function;
    fno:solves ex:sumProblem.

ex:sumProblem a fno:Problem;
    fno:name "The sum problem"^^xsd:string;
    dcterms:description "This handles the problem of adding two integers to each other."^^xsd:string;
    skos:broader ex:mathProblem.
Note

skos terms can be used to relate problems with each other. This can also be done for algorithms and functions.

3.2.1 fno:solves

Domain fno:Function

Range fno:Problem

3.3 fno:Algorithm

Example 3
ex:sumFunction a fno:Function;
    fno:implements ex:sumAlgorithm.

ex:sumAlgorithm a fno:Algorithm;
    fno:name "The sum algorithm"^^xsd:string;
    dcterms:description "About how to add two integers to each other."^^xsd:string;

3.3.1 fno:implements

Domain fno:Function

Range fno:Algorithm

3.4 fno:Parameter

Example 4
ex:sumFunction a fno:Function;
    fno:expects ( ex:intParameterA ex:intParameterB ).
    
ex:intParameterA a fno:Parameter;
    fno:predicate ex:startValue;
    fno:required "true"^^xsd:boolean.
    
ex:startValue fno:type xsd:integer.
    
ex:intParameterB a fno:Parameter;
    fno:predicate ex:sumValue;
    fno:required "true"^^xsd:boolean.  
    
ex:sumValue fno:type xsd:integer.

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.1 fno:expects

Domain fno:Function

Range rdf:List of fno:Parameter

3.4.2 fno:predicate

Domain fno:Function

Range rdf:Property

3.5 fno:Execution

Example 5
ex:sumExecution a fno:Execution;
    fno:executes ex:sumFunction;
    ex:startValue "2"^^xsd:integer;
    ex:sumValue "4"^^xsd:integer.

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.

3.5.1 fno:executes

Domain fno:Execution

Range fno:Function

3.6 fno:Output

Example 6
ex:sumFunction a fno:Function;
    fno:returns ex:sumOutput.
    
ex:sumOutput a fno:Output;
    fno:predicate ex:sumResult;
    fno:required "true"^^xsd:boolean.
    
ex:sumResult fno:type xsd:integer.

Similar as with fno:Parameter, the connecting predicate is described for fno:Output. After the execution of the function with the correct parameter values, we could return the following turtle:

Example 7
ex:sumExecution a fno:Execution;
    ex:sumResult "6"^^xsd:integer.

Similarly as with the parameter descriptions, the output descriptions can be reused across functions.

3.6.1 fno:returns

Domain fno:Execution

Range fno:Output

3.7 Complete example

Declaration and description of the function and one execution:

Example 8
ex:sumFunction a fno:Function;
    fno:name "The sum function"^^xsd:string;
    dcterms:description "This function can do the sum of two integers."^^xsd:string;
    fno:solves ex:sumProblem;
    fno:implements ex:sumAlgorithm;
    fno:expects ( ex:intParameterA ex:intParameterB );
    fno:returns ex:sumOutput.
    
ex:intParameterA a fno:Parameter;
    fno:predicate ex:startValue;
    fno:required "true"^^xsd:boolean.
    
ex:startValue fno:type xsd:integer.
    
ex:intParameterB a fno:Parameter;
    fno:predicate ex:sumValue;
    fno:required "true"^^xsd:boolean.  
    
ex:sumValue fno:type xsd:integer.

ex:sumOutput a fno:Output;
    fno:predicate ex:sumResult;
    fno:required "true"^^xsd:boolean.
    
ex:sumResult fno:type xsd:integer.

ex:sumProblem a fno:Problem;
    fno:name "The sum problem"^^xsd:string;
    dcterms:description "This handles the problem of adding two integers to each other."^^xsd:string;
    skos:broader ex:mathProblem;

ex:sumAlgorithm a fno:Algorithm;
    fno:name "The sum algorithm"^^xsd:string;
    dcterms:description "About how to add two integers to each other."^^xsd:string;
    
ex:sumExecution a fno:Execution;
    fno:executes ex:sumFunction;
    ex:startValue "2"^^xsd:integer;
    ex:sumValue "4"^^xsd:integer.

Resulting output triples:

Example 9
ex:sumExecution a fno:Execution;
    ex:sumResult "6"^^xsd:integer.

4. Abstraction of the Hydra specification

The Hydra specification defines Web services semantically. The Function Ontology describes functions. hydra:Operation is a sub-class of fno:Function. As such are hydra:expects and hydra:returns sub-properties of fno:expects and fno:returns, respectively.

All other vocabulary terms in Hydra are related to the definition of the Web service, and are thus out of scope for the Function Ontology.

5. Examples

The following sections are a set of FAQs and How-to's regarding the Function Ontology.

5.1 Array of parameters

The model allows for arrays of parameters. For example, the following function function findInString(str, [searchValues...]) could be described as follows:

Example 10
ex:findInString a fno:Function;
    fno:name "Finding multiple values in a string function"^^xsd:string;
    dcterms:description "This function returns true if any of the input values is found in the string."^^xsd:string;
    fno:expects (
        [
            fno:predicate ex:body;
            fno:required "true"^^xsd:boolean
        ]
        [
            fno:predicate ex:searchValues;
            fno:required "true"^^xsd:boolean
        ]
        [
            fno:predicate ex:found;
            fno:required "true"^^xsd:boolean
        ]
    ).

ex:findExecution a fno:Execution;
    fno:executes ex:findInString;
    ex:body "Try and find some values in this string."^^xsd:string;
    ex:searchValues ("Paris" "Brussels" "Tokyo" "Los Angeles") .

5.2 Required output

Output can be assigned required or not. For example, thrown errors are an example of optional output.

5.3 Reification explained

TODO

5.4 Reference model

TODO

5.5 System architecture example

TODO

58391