bjdmeest
commented
3 years ago Thanks for this! It looks really interesting!
First of all: indeed, piping/composition/nesting functions is not described within FnO (yet). I would need to have a closer look on your proposal, one thing that immediately comes to mind is that maybe the mappingExecutiong range should be an rdf:List, otherwise you semantically don't know the order. You can probably infer it in this case, but I'm not sure that would work for any sequence of piped functions.
One of the ideas I had in mind for a composition of functions, is to make sure that a function that is a composition of functions is in fact described similarily than a 'normal' function, i.e., an implementation could transparently choose between an implementation that implements the entire composited function, or by compositing different implementations dynamically.
Let's say we have a function h(a, c, d) described using FnO, that describes one atomary action: "add c and d, and multiply a with the result ". You could also have a multiplication function f(a, b), and a sum function g(c, d), so you could describe h as
h(a, c, d) === f(a, g(c, d))When describing compositions of functions, I think you could create more flexible systems if you allow implementations to dynamically choose between h(a, c, d) or f(a, g(c, d)), depending on the implementations available to them (and also maybe based on other parameters such as performance, memory consumption, etc.)
This would then require some kind of meta-description that specifies that h(a, c, d) === f(a, g(c, d)), with a structure like below
- h'(a', c', d') is a complexFunction for h
- root function: f
- parameter a' of f' === parameter a of f
- parameter b' of f' === output of g
- parameter c' -> parameter c of g
- parameter d' -> parameter d of gHowever, this is verrry draft, I'm not sure yet how it aligns with your proposal, and which one would be best, but you asked for my input, so here it is ;).
Happy to discuss further!
fkleedorfer
SemanticBeeng
I am using fno for a mapping use case: You have a feature F1 in system S1 that should be mapped to feature F2 in system S2. The idea is that, if you define mappings for all features, you are able to transform a document that uses system S1 into a document that uses system S2.
That requires a definition of a mapping using fno, which doesn't seem to be covered by the ontology (and tools) as it is. The difficulty arises where we define mappings as
fno:Executions, but we are not actually recording a specific execution: it is a definition of the function that has to be applied to any concrete instance of the input feature(s). However, some of the function's parameters have already been set (for example regex and replace strings), so it's not taking these parameters any more. You could say, the function has been curried.Our solution to the problem is to introduce a new kind of parameter/output: a Pipe. Basically it's an RDF resource that can be used as an output in one function and as a parameter in another. Thus, it's possible to concatenate function executions.
The structure of a mapping is:
I am interested in how you would approach the problem. I am halfway there in implementing it - now starting with function implementations in java - and I am not particularly keen on maintaining a fork, so if you think this could be useful, I'd be happy to work this into the framework and contribute here. Alternatively, I may have missed how this is already supported by fno, in which case I'd be grateful for a hint.
Example:
EDIT: added some
# ignore, this is domain-specificlines