-
Notifications
You must be signed in to change notification settings - Fork 555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It is possible to create invalid RDF with rdflib #895
Comments
@nicholascar Is this issue still open? I'm thinking to solve this issue by adding assert statements in the the add function. |
Adding `assert` statements in production code is no good idea. They do not work if optimization is enabled. https://docs.python.org/3/reference/simple_stmts.html
|
Maybe this is also a cool feature to use the RDF lib to work with generalised RDF (sorry can't find the reference now on my mobile, but see also https://www.w3.org/2001/sw/wiki/Literals_as_Subjects). However, the serializers should only create output valid for the respective format.
|
There isn't a good way to catch issues like this at runtime without taking a performance hit. If this is implemented in rdflib core, then maybe it could be as an One solution to these kinds of issues is a static type system. I'm not sure if python's type annotations would help here, but the might be a minimally obtrusive way to add this functionality for those who want it. |
My feeling is maybe this should be caught at serialisation time, like we do with non rdf/xml serialisable URIs etc. |
@prince17080 obviously still open! Sorry, we didn't get to handle this for 5.0.0. @gromgull not sure this should only be handles "on the way out" at serlialization time. I think this really should be handled "on the way in" at creation, my general feeling being, if the spec (RDF) doesn't allow something, we shouldn't allow it in the Python We don't tolerate this:
So we shouldn't tolerate:
Unless there's some very good code speed reason etc. that prevents us from not tolerating it.
Clearly we have a bunch of them in there already... |
But there is also a note:
In SPARQL 1.1, Literals are allowed in the subject position. https://www.w3.org/TR/sparql11-query/#construct JSON-LD says:
They also put up a note:
As a conclusion we don't need to support it, but we can. As it is currently possible, whhat is a good reason to remove it from the Graph, if we can also ensure it for the serializers.
Maybe we should see if we can remove them in the future. |
@nicholascar @white-gecko @tgbugs So, I guess the conclusion from the above discussion can be adding a new function |
@prince17080 indeed there is the suggestion to introduce Not sure I would use it much though - like @tgbugs I check my entries to a |
There's check_statement in util. A wrapper would be nothing more than a call to check_statement. |
Thanks @oohlaf, really useful tip! |
I close this issue now. Maybe someone finds a place for the hint of @oohlaf in the documentation or someone should ask and answer it on https://stackoverflow.com/questions/tagged/rdflib . |
I was able to successfully create the following RDF graph:
It is serialised into Turtle as follows:
And according to the RDFLib code it is a valid triple. However, according to the RDF specification it is not:
And indeed when the output Turtle is validated with the W3C validator, it produces this error:
Hence, this bit in the README file is also incorrect:
I think this issue deserves a further discussion, and please let me know if I can fix this and raise a PR.
The text was updated successfully, but these errors were encountered: