How to achieve Implementation-Independence of RML Functions?

[tobiasschweizer]

Hi there,

Last summer I started using RML for the generation of RDF. Since the beginning, I have been using RMLMapper and CARML in parallel because I think any given mapping should be processable by either of the two engines.

Now I've started looking at using RML functions. So far, I could handle quite a lot of issues with preprocessing, but as you write, this inhibits reuse. Also it weakens the declarative approach because the preprocessing is most likely procedural.
I understand that FnO aims at describing functions formally without being bound to a specific implementation. I guess this is inspired by a functional programming paradigm.

I understand that it is not the goal to a have a standard library interface (maybe something like the JSON-LD processor interface) that would have to be implemented by every engine but something more flexible.

But how would this work in practice?
Would I implement a function in Java and then register it in RMLmapper and CARML, respectively? What about RML engines that are not implemented with JVM technologies?

Thanks for your feedback!

Tobias

[dachafra]

@tobiasschweizer I'm going to move this to the forum, as it's more a discussion than an issue for the FNML spec. Hope that it will be fine for you.

[tobiasschweizer]

Yes, sure!

[DylanVanAssche]

I understand that FnO aims at describing functions formally without being bound to a specific implementation. I guess this is inspired by a functional programming paradigm.

FnO with RML + FNML exposes the function in an abstract way without depending on the implementation in terms of mapping rules. However, the engine still have to support of course the function in its implementation.

I understand that it is not the goal to a have a standard library interface (maybe something like the JSON-LD processor interface) that would have to be implemented by every engine but something more flexible.

There's a Function Hub of FnO which allows to find respectively implementations in programming languages of a given function: https://fno.io/hub/

It is not a standard library, but gives you an overview where you could find a certain function.
Engines could ask the Hub for a certain function and it gives back possible implementations of which the engine can pick.
However, I'm not aware of any engines actually supporting the Hub this far.

CC: @bjdmeest since he knows this stuff much better in detail.

[tobiasschweizer]

There's a Function Hub of FnO which allows to find respectively implementations in programming languages of a given function: https://fno.io/hub/

Ok, that looks interesting. Have you thought about defining some test cases that would make sure that different implementations of a function would behave the same way?

[DylanVanAssche]

Currently no, the Function Hub is described in this paper though:

The Function Hub : an implementation-independent read/write function description repository, ESWC 2019, Ben De Meester et al.

[tobiasschweizer]

I have been thinking about the ways functions are called in RML. Would it be feasible to call a function from within an rr:template? I am particularly thinking of GREL functions. GREL expressions could be called on a given field name and also chained.

So

rr:predicateObjectMap [
    rr:predicate schema:keywords ;
    rr:objectMap [
      a fnml:FunctionMap ;
      fnml:functionValue [
        rml:logicalSource <#LogicalSourceGrant> ;
        rr:subjectMap [
          rr:template "functionExec";
          rr:termType rr:BlankNode ;
          rr:class fno:Execution
        ] ;
        rr:predicateObjectMap [
          rr:predicate fno:executes ;
          rr:objectMap [
            rr:constant ex:splitFunction ;
          ]
        ],
        [
          rr:predicate ex:strParameterA ;
          rr:objectMap [ rml:reference "Keywords" ]
        ]
      ] ;
      rr:datatype xsd:string ;
    ]
  ] ;

could become something like

rr:predicateObjectMap [
    rr:predicate schema:keywords ;
    rr:objectMap [
       rr:template "{Keywords.split().trim()}" ;
       rr:datatype xsd:string
    ] ;

Leaving the problem of how to bind specific implementations to definitions aside for a moment, I think including function calls in templates would greatly enhance readability, especially when it comes to method chaining. I am not sure though what this would mean regarding the R2RML specs (compatibility).

[pmaria]

The community is moving towards simplifying the language for the current function approach with https://w3id.org/rml/fnml/spec

So the example that you posted will look something like this in RML:

rml:predicateObjectMap [
  rml:predicate schema:keywords ;
  rml:objectMap [
    rml:functionExecution [
      rml:function ex:splitFunction ;
      rml:input [
        rml:parameter ex:strParameterA ;
        rml:inputValueMap [
          rml:reference "name" ;
        ]
      ]
    ] ;
  ] ;
] ;

So it will already be less verbose. What do you think of this?

[tobiasschweizer]

I think that this is already more compact which enhances readability. However, I still think that chaining functions (using the return value of a function as the input for another function) will result in a nested construct that will ultimately be hard to read.
In fact, it reminds me a bit of the "callback hell" in JavaScript that was mitigated by the introduction of Promises (linear flow of control from a programmer's perspective).

I think the use of RML functions would greatly benefit from a more compact form of calling functions. I think it would be great if the dot notation could be used to call one or multiple functions, providing the expression before the dot as the function's first argument as in GREL (GREL is just an example, this pattern would work for any function library).

Rewriting example 6 from RML-FNML:

@prefix dbo: <http://dbpedia.org/ontology/> .
@prefix grel: <http://users.ugent.be/~bjdmeest/function/grel.ttl#> .
@prefix rml: <http://semweb.mmlab.be/ns/rml#> .
@prefix rr: <http://www.w3.org/ns/r2rml#> .

<#Person_Mapping>
    rml:logicalSource <#LogicalSource> ;
    rr:subjectMap <#SubjectMap> ;
    rr:predicateObjectMap <#NameMapping> .

<#NameMapping>
    rr:predicate dbo:title ;
    rr:objectMap [
        rml:reference "name.grel:stringReplace(' ', '-').grel:toUpperCase()"
    ] ;
    .

This should be fairly clear to read: first, grel:stringReplace is called on name, replacing whitespace chars with dashes and then the resulting string is converted to all upper case letters.

I admit that there are some things I haven't thought about in detail yet. Among these are parsing issues (as @pmaria has pointed out to me): How to distinguish the function calling part from the several reference formulations that can be used in RML? I think especially XPATH expressions could be tricky since they would already allow for function expressions such as text(). Also the namespace resolution (grel:) of functions could be a challenge.

However, I think the benefit would be that functions could be freely combined in a way that is known from many widely-used programming languages. If you think that could be useful, I could start thinking about the parsing part. Any support would be highly appreciated.

[dachafra]

Hi @tobiasschweizer,
Very interesting proposal, and I think that all users of functions within mappings want to simplify their definition. Indeed, the idea could be implemented in a more human-friendly serialization like YARRRML (e.g., we already admit inline functions, see here). We are leaving RML in RDF for machines ;-)

The example:

mappings:
  person:
    predicateobjects:
     - predicates: foaf:firstName
       objects:
        - function: ex:toLowerCase(input = $(firstname))

[tobiasschweizer]

Hi @dachafra,

Thanks for your feedback. I have actually tried YARRRML last year. While I see the advantage of a very compact way of writing a mapping, I had problems when dealing with the generated mapping in RDF (debugging etc.).

We are leaving RML in RDF for machines ;-)

Yes and no ;-) When I started using RML last year, I actually ran a mapping with two different RML engines, observing the differences which can be quite subtle.

Maybe it would be beneficial for me looking at the definitions of templates / reference formulations as this is where RDF and the actual serialisation (XML, CSV, JSON) "interface".

So I am asking myself how much of the function calls has to be expressed in RDF and/or can be delegated to template / reference formulation evaluation logic.

Have a good day,

Tobias

[dachafra]

Thanks for your feedback. I have actually tried YARRRML #17 (comment). While I see the advantage of a very compact way of writing a mapping, I had problems when dealing with the generated mapping in RDF (debugging etc.)

You can use YATTER (and you can also ask me for extensions, etc.) that gives you a readable RDF: https://github.com/oeg-upm/yatter (now it has been tested and updated and it's ready for users ;-))

So I am asking myself how much of the function calls has to be expressed in RDF and/or can be delegated to template / reference formulation evaluation logic.

The approach we followed in the CG with FNML and FnO is to have all aspects of functions semantically described, so we don't hide them in the templates/references and also not make them align with a specific programming language.