There is an bug with using a dash in graphql, which is prevents you from refering to any prefix or URI that contains a - . For example, the Human(iri: ex_Alice) you mentioned will throw a syntax error if you have Human(iri: ex_Alice-smith) or Human(iri: ex-test_Alice) .
Section "2.1.9 Names" of the graphql spec limits names to alpha numeric and underscore, with two leading underscores reserved for introspection (in the current version of the spec, previous versions didn't have this leading underscore restriction). If you have RDF properties with dashes in them, they would unfortunately have to be converted (either with reasoning such as with Stardog Rules) or materialize (e.g. with a insert/where), or updated in virtual graph mappings for virtualized data to convert them to underscores. Checking the spec, I don't actually see dash being called out anywhere else. I'll have to look into if there's any rationale behind omitting it. Please let us know if one of the above workaround strategies doesn't work for you and we can investigate other options.
Thanks for answering! I didn't know dashes were not allowed.
The solutions you propose would work, but they are far from ideal given the extra computation or triples. But more importantly: this would change identifiers, which is would cause havoc along the line. I'll give it some more thought though.
That said, I believe the root of the problem is that Stardog insists in making URIs into an Enum (which even requires knowledge on the server-side defined prefixes).
They could be a string (or a custom scalar if you please) Human(iri: "http://example.org/Alice-smith") or maybe Human(iri: "ex_Alice-smith"), because you know the ID type is an IRI and you can cast them. Granted, this leaves room for invalid URIs, but that's also the case in the current approach. If a string doesn't cast to a URI, simply throw a Syntax error to the client. Also, this is more in line with the query results. If I would query Human { iri }, Stardog would return { iri: "ex_Alice" }, which is ultimately a string value.
We indeed allow strings in some places where an IRI should be specified, e.g. when the named graph IRIs are specified for the query inside @config. I take your point that this might be done for the built-in iri field. But you cannot do the same for fields so if you have a property with a dash or any other characters illegal in GraphQL you will need to fall back to defining aliases withe run the schema or as part of the query @config as explained here.
Best,
Evren