RML-FNML: user-defined functions for RDF mapping
RML is a spec describing how you can transform heterogeneous formats (CSV, SQL, XLS…) to RDF. It’s elegant for the simple cases, this column becomes this predicate, that field becomes that URI. Pure declaration, no code. But RML has a blind spot, and it’s a big one: real data is never that clean. So, you need ETL before you can use RML. Of course, the semantic people don’t want to define a spec for ETL so they came up with one for user-defined functions (UDF) inside RML. Welcome the new RML-FNML specs 📣. It describes external functions in the same way to LLMs get callables via JSON function specs. Except that RML-FNML looks horribly complicated. The more academia define new standards the more I see how little they ever talk to businesses and understand real-word data projects.
RML-FNML lets you declare functions (inputs, outputs, even nested compositions) as first-class mapping rules, using the same vocabulary you use for the rest of the mapping. Transformation logic stops living in a disconnected script and becomes part of the graph specification itself. Provenance, auditability, reuse all inherited for free. Although, function inheritance, really? 🤔
Morph-KGC is a python package (which overlaps with my post yesterday on YARRRML) ships a working RML-FNML implementation with Python UDFs called directly from RML rules, built-in GREL-style functions out of the box, and YARRRML support. At least YARRRML makes it human-readable.
The RML-FNML spec itself reads like it was written for compiler theorists (or fans of Rube Goldberg machines), not knowledge engineers. Function-as-execution-map, parameter bindings, nested rml:input structures, the formalism is dense. But strip away the ontology-blah and the idea is simple: separate what a transformation does from how it’s implemented and keep both inside the mapping (just like tool definitions fed to LLMs).
- RML-FNML: https://kg-construct.github.io/rml-fnml/spec/docs
- Morph-KGC: https://morph-kgc.readthedocs.io