Closed IanEmmons closed 2 years ago
Hi!
Thanks for reaching out! Do you have a reproducible example with RML rules and some sample data to better understand this issue? Thanks!
My examples are quite involved with many external dependencies, and therefore difficult to pass along. However, if you take any working example with an XML source, choose an rml:reference in it, and wrap that XPath expression with the normalize-space Path function, you will reproduce the problem.
I can now reproduce it and have a fix ready. Will be available in the next release!
Thanks for your report!
Thanks, that will reduce the number of FNO function calls I need to make in my RML files.
When translating an XML file, rml:reference properties in the RML have values that are XPath expressions. If such an XPath expression results in a node or a node-set, all is well. The mapper uses XPath's inherent ability to convert a node-set into a string and then uses that string in the RDF output. However, if the XPath result is of type string, the mapper fails because it is expecting a node-set. This is easily reproduced by wrapping an XPath expression in a string function, like so:
It would be helpful if the mapper would handle a string result as well as a node-set, because the functions available in XPath are fairly rich and can in many cases sidestep the need for RML function calls.