N3 parsing of local names with special characters

[acassaignemondeca]

Hello,

the goal of this commit is to improve the handling of local names with special characters. I modified the implementation of the "qname" function in accordance to https://github.com/RDFLib/rdflib/blob/master/rdflib/plugins/parsers/notation3.py (function "qname").

Also to align with https://github.com/RDFLib/rdflib/blob/master/rdflib/plugins/parsers/notation3.py:

• in _notQNameChars I removed . and %
• I created _notKeywordsChars (= _notQNameChars + "." )
• outside of qname function and to handle the side effect of changing _notQNameChars by _notKeywordsChars I replaced all occurrences of _notQNameChars by _notKeywordsChars.
• I verified that "%" was not a concern in these cases. I could do that everywhere except for the "tok" function where the logic is not in notation3.py so I added back the "%" case. I don't know if this logic is useful ?

I tested the modification with rdflib-evaluation. No regression and tests succeeding are up from 193 to 211 (out of 298). (Tests attached to this pull request).

Best regards,
Arnaud

spec-rdflib-ntriples-patch.txt
spec-rdflib-ntriples-reference.txt
spec-rdflib-turtle-patch.txt
spec-rdflib-turtle-reference.txt

[angelo-v]

Thanks for your contribution. I cannot say much about it contentwise and leave that up to @timbl .

From a quality perspective it is good to see more tests passing. I did not know rdflib-evaluation before. Could we include it in github actions? Nevertheless the code changes a lot and I would like to see this covered by unit tests as well. Those tests would also serve as a documentation of the changes so that it is easier to grasp how the code actually behaves.

[TallTed]

Suggested change

	part of a notation3 serializer.
	part of a Notation3 serializer.

[angelo-v]

Thanks for your contribution. I cannot say much about it contentwise and leave that up to @timbl .

From a quality perspective it is good to see more tests passing. I did not know rdflib-evaluation before. Could we include it in github actions? Nevertheless the code changes a lot and I would like to see this covered by unit tests as well. Those tests would also serve as a documentation of the changes so that it is easier to grasp how the code actually behaves.