How to handle and/or report IRI values of `sh:annotationProperty` that would lead to invalid SPARQL variable?

[ajnelson-nist]

One of those niche corner cases: http://example.org/☃ (snowman, code point U+2603) is a valid IRI (RFC 3987, Section 2.2, grammar rule ucschar). ☃ cannot be a SPARQL variable name (SPARQL grammar rule VARNAME). Do we need to leave a reminder here of SPARQL's VARNAME grammar rule? If someone does try some unicode IRI---probably not an emoji , but perhaps there would be non-Latin use cases---and it wouldn't work in SPARQL, should we specify that it's the SHACL processor's responsibility to catch this at shapes graph load-time; or, instead warn the shapes graph authors that incompatible IRIs would likely be reported by the SPARQL engine (i.e., SHACL delegating to SPARQL)? Note the latter case leaves the shapes graph users scratching their heads if the shapes graph authors don't see the warning.

Originally posted by @ajnelson-nist in #330 (comment)

[afs]

cannot be a SPARQL variable name

The text you commented on says "localName". Sometimes the only localname possible is empty string. http://example.org/ for example. "☃" isn't legal as local name.

There are other characters in iunreserved that can't be SPARQL variables in ASCII "-" / "." / "_" / "~"

non-Latin use cases

VARNAME includes PN_CHARS_U which covers the relevant parts of all unicode codepoints.

[HolgerKnublauch]

There are other conditions related to SPARQL processing that SHACL engines cannot easily verify beforehand without running the query. I would leave this corner case unhandled and let it fail if invalid var names are produced.

So I suggest closing this ticket.