search

kg-construct / rml-fnml

RML-FNML: Transformation functions within RML
https://w3id.org/rml/fnml/spec
Creative Commons Attribution 4.0 International
6 stars 2 forks source link

fnml:ReturnMap #12

Closed samiscoding closed 1 year ago

samiscoding commented 1 year ago

I noticed that in defining the fnml:ReturnMap and fnml:Input we're following a double standard. We're defining the fnml:Input based on both abstract definition in FnO (i.e., parameter) and the practical level (i.e., the reference to the value in the real data source), while, in the case of fnml:ReturnMap we only define based on the abstract level (i.e., we're not allowing the definition of the return value in the real data source). Maybe I'm missing something, otherwise, I think we need to modify the definition of fnml:ReturnMap. Lert me know if you want me to pull request with the modification :)

bjdmeest commented 1 year ago

Hmmm, I don't think I fully understand, because I don't understand why you would want to define the return value in the real data source. If you can define the return value in the real data source, you don't need a function anymore, or what am I missing? Maybe a pull request makes sense to understand the full context?

samiscoding commented 1 year ago

Allowing users to define the name of the output (a field in any type of data source) could increase the reusability of the output without calling the function repeatedly, but I see your points that since the output is connected to the execution, this may not be useful. Unless we can use it when it comes to applying Fields. I guess we can open this issue later once we proceed with Fields if necessary :)