Test cases for query languages wrt iterator/reference behavior?

[mielvds]

RML mappers can interpret the query language in ql:referenceFormulation differently like here SDM-TIB/SDM-RDFizer#48. This support is only slightly covered by the test cases.

It might be helpful to zoom into some of the common ones (eg. ql:JSONPath, ql:XPath, ...), especially with respect to iterator/reference behavior. These could be put in separate test groups and reports per QL to not cause confusion with RML support. Happy to contribute btw

[andimou]

that's indeed towards the direction we are thinking as well.

We are considering of separating the Logical Source descriptions from the rest of the RML specification.
We'll keep you in the loop ;)

Unfortunately the behavior of ql:JSONPath, ql:XPath are highly affected by how the underlying libraries implement the corresponding spec (besides human errors). See these references:
https://github.com/RMLio/rmlmapper-java/#xml-file-parsing-performance
RMLio/rmlmapper-java#63

Do you have @mielvds any concrete thoughts you already want to share?

[mielvds]

that's indeed towards the direction we are thinking as well.

We are considering of separating the Logical Source descriptions from the rest of the RML specification.
We'll keep you in the loop ;)

Cool! That seems like the most maintainable indeed.

Unfortunately the behavior of ql:JSONPath, ql:XPath are highly affected by how the underlying libraries implement the corresponding spec (besides human errors). See these references:
https://github.com/RMLio/rmlmapper-java/#xml-file-parsing-performance
RMLio/rmlmapper-java#63

Yeah and we shouldn't be writing their unittests. Just some basic test cases that can identify if an underlying library is no good.

Do you have @mielvds any concrete thoughts you already want to share?

For RML, the main (and only?) concern is how the path in rml:iterator translates to the iterator output and consequently, to what value the path in rml:reference/ rr:template translates to. Could this be abstracted from the query language somehow?

Maybe test cases that focus on iterator-reference combinations would be enough, such as

rml:iterator "$.[*]" + rml:reference "city.name" = ['Amsterdam', 'Brussels', 'Berlin', 'London']

[andimou]

Yeah and we shouldn't be writing their unittests. Just some basic test cases that can identify if an underlying library is no good.

regarding this, we discussed during the last consortium meeting that we should cluster and abstract the test cases. So I'd imagine that a certain part of test cases may refer to references to input test cases. Feel free to join the discussions ;)

Could this be abstracted from the query language somehow?

Do you have a suggestion for this?

Are you aware of the solution proposed by ShExML?
https://github.com/herminiogg/ShExML
Is what you're thinking towards this direction?

[mielvds]

Yeah and we shouldn't be writing their unittests. Just some basic test cases that can identify if an underlying library is no good.

regarding this, we discussed during the last consortium meeting that we should cluster and abstract the test cases. So I'd imagine that a certain part of test cases may refer to references to input test cases. Feel free to join the discussions ;)

I know, I am trying to get more involved :)

Could this be abstracted from the query language somehow?

Do you have a suggestion for this?

Not really no tbh. It's hard to do because RML is oblivious to what the path expression actually resolves to. The best option is probably to test iterator-reference combinations per QL.

Are you aware of the solution proposed by ShExML?
https://github.com/herminiogg/ShExML
Is what you're thinking towards this direction?

I don't think so. Isn't this simply another mapping language? (Looks interesting though)