This document is licensed under a Creative Commons Attribution 3.0 License.
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 https://fno.io
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.
The Function Ontology's namespace is http://w3id.org/function/ontology
The preferred prefix is fno:
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.
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.
The following document makes a clear distinction between following concepts:
function sum;
is a function declaration.
function int sum(int a, int b)
, namely, the function sum
has two input parameters, int a
and int b
, and returns an integer.
sum(2, 4)
, namely, assigning the values 2
to a
and 4
to b
.
Furthermore, we define following concepts:
doing a sum
problem.
a
and b
.
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
.
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.
fno:Function
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:Problem
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.
skos
terms can be used to relate problems with each other. This can also be done for algorithms and functions.
fno:solves
Domain fno:Function
Range fno:Problem
fno:Algorithm
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;
fno:implements
Domain fno:Function
Range fno:Algorithm
fno:Parameter
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.
The range of the predicates used by the parameters don't have to be defined. However, by do defining them, we achieve type hinting.
fno:expects
Domain fno:Function
Range rdf:List of fno:Parameter
fno:predicate
Domain fno:Function
Range rdf:Property
fno:Execution
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.
fno:executes
Domain fno:Execution
Range fno:Function
fno:Output
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:
ex:sumExecution a fno:Execution;
ex:sumResult "6"^^xsd:integer.
Similarly as with the parameter descriptions, the output descriptions can be reused across functions.
fno:returns
Domain fno:Execution
Range fno:Output
Declaration and description of the function and one execution:
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:
ex:sumExecution a fno:Execution;
ex:sumResult "6"^^xsd:integer.
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.
The following sections are a set of FAQs and How-to's regarding the Function Ontology.
The model allows for arrays of parameters. For example, the following function function findInString(str, [searchValues...])
could be described as follows:
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") .
Output can be assigned required or not. For example, thrown errors are an example of optional output.
TODO
TODO
TODO