Provide direct associations between fno:Function | fno:Execution and fno:Implementation

[saxomoose]

Thank you for this open source work.

In the current model, the use of fno:Mapping is compulsory to tie a fno:Execution to a fno:Implementation.
However, some implementations may not require any mapping.

Example:

_:ageFromDateOfBirth a fno:Function ;
    fno:expects (_:personParameter) ;
    fno:returns (_:personOutput) .

_:ageFromDateOfBirthExecution a fno:Execution ;
    fno:executes _:ageFromDateOfBirth ;
    fno:uses _:ageFromDateOfBirthMapping ;
    example:personIn _:entity1 ;
    example:personOut _:entity2 .

_:ageFromDateOfBirthMapping a fno:Mapping ;
    fno:implementation _:ageFromDateOfBirthImplementation .

# PREFIX example: <https://example.org/ns#>
# PREFIX persoon: <https://data.vlaanderen.be/ns/persoon#>
# PREFIX prov: <http://www.w3.org/ns/prov#>
# PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

# CONSTRUCT {
#   ?persoon a persoon:GeregistreerdPersoon;
#     example:age ?age .
# }
# WHERE {
#   ?persoon a persoon:Geboorte ;
#           persoon:datum ?dob .

#   BIND(now() AS ?currentDateTime)

#   BIND(year(?currentDateTime) - year(?dob) AS ?yearsDiff)
#   BIND(month(?currentDateTime) - month(?dob) AS ?monthsDiff)
#   BIND(day(?currentDateTime) - day(?dob) AS ?daysDiff)

#   BIND(IF(?monthsDiff < 0 || (?monthsDiff = 0 && ?daysDiff < 0), ?yearsDiff - 1, ?yearsDiff) AS ?age)
# }
_:ageFromDateOfBirthImplementation a fnoi:SPARQLImplementation .

In this case, I would like to bypass the mapping and link _:ageFromDateOfBirthExecution directly with _:ageFromDateOfBirthImplementation.

What are your thoughts?

[bjdmeest]

how would you know that ?age is the output parameter, and not ?persoon? You could guess it from the SPARQL query, but the idea of the mapping is to make all those kinds of links explicit so a machine can automatically work with that

[saxomoose]

The objective behind my suggestion is to treat the function more like a black box, while still providing an implementation.

I do realize that this would only work with a specific type of implementations. Namely, those which can operate on the input without an explicit mapping (e.g. SPARQL queries). And which return a single result value.

[bjdmeest]

So basically, providing a shortcut for below

_:myFunction a fno:Function .
_:myImplementation a fno:Implementation .
_:b1 fno:function _:myFunction ; #rdfs reasoning will classify this as a fno:Mapping, but that's a detail in this context
    fno:implementation _:myImplementation .

with a quite loose relation [fno:Function] fno:hasAssociatedImplementation [fno:Implementation]?

_:myFunction a fno:Function .
_:myImplementation a fno:Implementation .
_:myFunction fno:hasAssociatedImplementation _:myImplementation .

I could live with that :D

[saxomoose]

That's definitely an option. Another would be to link fno:Execution and fno:Implementation with a direct association (bypassing fno:Mapping).

[bjdmeest]

Ah yes, my bad, I meant providing a shortcut for below

_:myExecution fno:uses _:myMapping .
_:myMapping fno:implementation _:myImplementation .

with a quite loose relation [fno:Execution] fno:hasAssociatedImplementation [fno:Implementation]?

_:myExecution fno:hasAssociatedImplementation _:myImplementation .

[saxomoose]

I continued thinking about this.

Consider the following example:

_:person a ex:Person ;
  adms:identifier _:id .

_:id a adms:Identifier ;
    ex:identifier "90110845865" ;
    ex:validationFunction _:validationFunction .

_:validationFunction a fno:Function ;
    fno:expects (_:parameter) ;
    fno:returns (_:output) .

_:parameter a fno:Parameter ;
    fno:type xsd:string .

_:output a fno:Output ;
    fno:type xsd:boolean .

# URI could point to https://github.com/NationalBankBelgium/stark/blob/b9cb07d7998a3e0616cd20dea4bd692b6b2ee9be/packages/stark-core/src/validation/validators/is-nin/is-nin.validator.fn.ts.
_:functionImplementation a fnoi:JavaScriptFunction .

What I thought I wanted is a loose association between fno:Execution and fno:Implementation, but what is much more useful is to link fno:Function directly with fno:Implementation. A bidirectional association.

For example:

_:validationFunction a fno:Function ;
    fno:expects (_:parameter) ;
    fno:returns (_:output) ;
    fno:implementation _:functionImplementation .

_:functionImplementation a fnoi:JavaScriptFunction ;
    fno:function _:validationFunction .

I would recommend to keep the same properties (fno:implementation and fno:function) but allow multiple domains / ranges by removing rdfs:domain and rdfs:range. If need be, range information can be added at class level.

Passing a datapoint together with a reference to its validation function could be quite nice and the function ontology seems cut out for this.