add rml:UnsafeIRI and rml:UnsafeURI to ontology, shapes and spec

[bjdmeest]

Right now, termmaps with rml:template and termtype rml:IRI always does percent encoding and there is a note that non-encoded values can only be achieved using rml:reference and thus preprocessing is needed spec. Alternatively, a FnO string concatenation function could be used.

However, this turns out to be a very common case, e.g. creating a mailto: resource from an emailadres: you just want to be able to do rml:template "mailto:{mailadres}", but that doesn't work because the @ will be percent-encoded (see RMLio/rmlmapper-java#219 (comment) for a recent similar request).

Does it make sense to introduce a rml:templateUnsafe predicate or similar to have an easy-to-use construct for handling this common request? This does the same as rml:template, but never performs a reference value transforming function

[DylanVanAssche]

I would rather be in favor of rml:termType rml:UnsafeIRI then instead of introducing another template option. This would be in line with rml:URI idea of #50

[dachafra]

Similar as in #50. These are the required tasks:

• Spec change: define rml:UnsafeIRI and rml:UnsafeURI (@pmaria @andimou)
• Ontology change: add new rml:UnsafeIRI and rml:UnsafeURI (@anaigmo )
• SHACL change: allow rml:UnsafeIRI and rml:UnsafeURI as term type (@DylanVanAssche)
• Test cases (@DylanVanAssche)

[DylanVanAssche]

We should also have rml:UnsafeURI as we have rml:URI now.

[VladimirAlexiev]

Maybe related:
For a long time I wondered what's the purpose of xsd:anyURI (literal datatype).
I think the only benefit over a real URL is that it can accommodate invalid URLs.
So eg in our Crunchbase KG, we use it for things like website, linkedin, twitter, etc.