Add namespace_manager argument for n3 method on Paths

[mgberg]

Summary of changes

The n3 method on the Term class optionally takes a NamespaceManager as an argument which, if provided, is used to create a prefixed name instead of fully qualified URIs for URIRefs and typed Literals where applicable if an appropriate prefix has been bound for the relevant namespace. Path objects also have a n3 method to create N3/SPARQL compatible serializations for those objects which call the n3 method on the underlying URIRefs. However, Path.n3 did not have the argument for the NamespaceManager.

This PR simply adds the same optional NamespaceManager argument to the n3 method for Paths to be consistent with the n3 method on Terms and passes that NamespaceManager to any nested calls to n3 so it behaves as expected.

Checklist

• Checked that there aren't other open pull requests for
  the same change.
• Added tests for any changes that have a runtime impact.
• Checked that all tests and type checking passes.
• For changes that have a potential impact on users of this project:
  • Updated relevant documentation to avoid inaccuracies.
  • Considered adding additional documentation.
  • Considered adding an example in ./examples for new features.
  • Considered updating our changelog (CHANGELOG.md).
• Considered granting push permissions to the PR branch,
  so maintainers can fix minor issues and keep your PR up to date.

[aucampia]

@mgberg the PR looks pretty good, I made some minor changes to get validation to pass and to add some additional type hints:

• chore: add some more type hints and ignores corning-incorporated/rdflib#1

If you make PRs, it is better to make it from your personal account, that way we can push to your branch instead of needing to make PR to your branch.

[aucampia]

Change looks good to me, it makes sense to have the same signature for def n3() across all classes. I will merge before this weekend if there is no further feedback.

[mgberg]

If you make PRs, it is better to make it from your personal account, that way we can push to your branch instead of needing to make PR to your branch.

I believe that my organizational policy disallows that, but I'll double check on that. Thanks!

[aucampia]

I believe that my organizational policy disallows that, but I'll double check on that. Thanks!

It really is also up to you, I don't really mind either way, makes things a bit easier if we can push to your branch but it is not a requirement for PRs and if the PR does something valuable I don't mind making a PR to the PR branch to add fixes.