GREL Expressions do not return calculated values "as is"

[AtesComp]

NOTE: The following objections relate to the fact that the RDF Mapping controls are in a Turtle (N3) format and that GREL generated IRI are expected to fit that format.

NOTE: The following examples have the complexity reduced for clarity.

GREL Issue

The GREL expressions in an RDF Mapping within OntoRefine return results that assumes string characteristics depending on the triple position: Subject, Predicate, Object. For Subject, Predicate, and IRI Object, it always assumes a fully qualified IRI and escapes the string for url, html, or xml (probably url).

For instance, calculating:
"ns:" + toString(row.record.index)
for an IRI produces "<ns%3A0>", i.e., it always adds a starting "<", and ending ">", and escapes the string.

Also, calculating:
"<" + "myURN://top#" + toString(row.record.index) + ">"
for an IRI produces "<%3CmyURN%3A//top#0%3E>"

Even calculating:
"myURN://top#" + toString(row.record.index)
for an IRI produces "<myURN%3A//top#0>" which is also erroneous (the ":" should not be escaped).

STOP IT! Why so overtly controlling? If the user has gone to the trouble of learning GREL, the mapper shouldn't assume it needs to process the result further. GREL has internal functions to perform such string escaping and does not require handholding, assumptions, and intervention by the mapper to force a transformation. It should gracefully allow the user to fail and, at best, only check if the string is a valid IRI (valid IRI is another issue). Since OntoRefine does not load directly into a repository (a user must create an RDF file or SPARQL query to insert), the process requires further modification to correct the output for suitable import.

Namespace Prefix Issue

Also, the mapper should not decide for a user when a namespace prefix (ns:) or a user defined URN (myURN:) is used. It might assume a prefix if the prefix is defined and a URN if not, but that is tenuous. In any event, it should give a user exactly the string the user calculated in all cases. Note strings such as "xyz:abc:mno" are valid IRI and may or may not include prefix elements.

Blank Node Issue

Additionally, this issue prevents the creation of Subject blank nodes when no suitable key is present and the record / row indices are not appropriate for Subject IRIs. Since Objects can generate blank nodes and subsequently be used as Subjects via nested triples, a "top level" blank node Subject should be supportable. Maybe a blank node "_:" namespace should be supported for direct blank node creation, just like for all other resource named nodes...no special control for "_:" is required.

For Predicate, a possible startsWith() check for "_:" might be a valid input error check.

Side Note: Record Index Issue

FYI: Other that blank nodes, this would not be much of an issues for these examples if the Record Index was supported as a Subject element. Record Index would be a nice reliable option as Record ID might not does not always distinguish records well. Row Index is always the global row index (not the local record row) which is probably best.