prefixes with '.' break loading triples

[lalewis1]

If Prez returns turtle with any Prefix declarations like

PREFIX my.pre: <http://my.prefix.com/>

Then an error is shown

likely this is an n3 issue?

[recalcitrantsupplant]

I think it is n3, the spec is pretty permissive. There's a few open parse issues: https://github.com/rdfjs/N3.js/issues?q=is%3Aissue+is%3Aopen+parse+

Perhaps we're better to send ntriples from the API or attempt to generate nicer prefixes - I suspect the problematic ones are mostly auto generated. Thoughts?

[lalewis1]

Whatever is easier. However, would we be concerned about the extra package size from ntriples? Assuming that it would be larger as the syntax is more verbose.

[recalcitrantsupplant]

I think it's automatically compressed/decompressed and the payload sizes are pretty trivial

[recalcitrantsupplant]

I've added code to prevent inclusion of "special" characters in generated curies in Prez, it may prevent the issue. Would still recommend specifying nice prefixes.

RDFLib/prez#284 (comment)

[nicholascar]

Please send Turtle, not n-triples, from the API. It is nice to be able, very occasionally, to look at the data as a human and n-triples basically makes this impossible

[recalcitrantsupplant]

no worries - I'm making changes to "clean up" i.e. valid not not nice, and also ensure the auto generated prefixes are valid (Lawson pointed out they shouldn't start with [0-9]).

Normal disclaimers:

• the n3 parser should ultimately be fixed
• users should specify the prefixes they want; prefix generation isn't deterministic. Clashes in auto generated prefixes are likely where the dataset has similar namespaces. If further data is added to the triplestore, the order in which namespaces are read in for prefix generation may change, meaning the prefix previously generated for a namespace may change.

[lalewis1]

validation implemented in RDFLib/prez#284. Tested locally and it fixes this issue. closing as resolved.