RDF Syntax Test Suites

[namedgraph]

I see that rdflib is passing the RDF Core Test Results. What about RDF Syntax Test Suites (Turtle family) though? I think they should be able to catch some of the Dataset-related problems.

[namedgraph]

OK it looks like the W3C edit included: https://github.com/RDFLib/rdflib/tree/main/test/data/suites/w3c
I don't get how they are passing though?

[ghost]

I think they should be able to catch some of the Dataset-related problems.
I don't get how they are passing though?

The issues pertaining to the RDFLib Dataset implementation aren't related to the parsing of RDF.

[aucampia]

• Rename `publicID` to `base_uri` or `base_iri` #2447

[ghost]

@gjhiggins if you or anyone else disagrees and think that the publicID should be used as the default graph ID in addition to the base URI for resolving relative URIs, as it was before #2406, please open an issue, so we can discuss reverting #2406. Otherwise, the behaviour you described here was wrong, and was a bug, and should not persist, and was correctly fixed.

I don't disagree as such, I just don't have a particularly detailed model and I'm not going to argue merely for the sake of arguing. You've identified a potential interaction between base URI for resolving relative URIs and the use of publicID for controlling the parsed destination of multi-graph source docs and I haven't had time to investigate and form a personal opinion other than that I can see a user might want to preserve any existing default graph content from "contamination" when parsing a multi-graph source doc and publicID seems to have been the way to do that thus far. But if there are negative consequences of (ab)using publicID (assuming it is an abuse) then avoiding those consequences would take priority.

[aucampia]

a user might want to preserve any existing default graph content from "contamination" when parsing a multi-graph source doc and publicID seems to have been the way to do that thus far.

For all non-default graphs, the behaviour of calling Dataset.parse() is that any triples from graph in the source with the same name gets added to the graph. Why should this be different for the default graph? Why for the default graph, instead of merging it, as we do for every other graph, we all of a sudden give it a name in contravention to the spec, and then randomly decide the name should be the same as the base URI for the document?

I don't see how this is possibly a positive consequence, and if someone wants it, they should explain why. I don't know of anyone who wants it, given the amount of issues we have had raised for this behaviour I think it is not really defensible.

If {Dataset,Graph}.parse updates the dataset or graph, it should do so consistently. If someone then does not want to update {Graph,Dataset}.parse, they should not call parse on a Graph or Dataset they don't want updated, and instead create a new Graph or Dataset, and call parse on that.

[aucampia]

@gjhiggins if the standard is things should behave the way they have behaved before, I don't really think there is much point in us making changes to RDFLib any longer, and it would be better to just say it is what it is and move on or start a different project from scratch.

[ghost]

@gjhiggins if the standard is things should behave the way they have behaved before

No, that's not what I believe but I'm obviously miscommunicating to markedly ill effect, to the extent that I'm actually being inadvertently disruptive. Time for me to stfu.

[namedgraph]

@gjhiggins what is your point exactly? Are you saying preserving the current behaviour is more important than standards compliance? Because the Dataset is not compliant in many ways, and @aucampia has used his time to identify and fix the issues.

Do you agree that rdflib should strive for 100% standards compliance? And that version 7 is a good way to improve it even if it means breaking changes (because they will not impact existing code)? If not, then I think it's best to fork this codebase into a different project that will work towards compliance, and leave rdflib behind as a legacy project. Having multiple projects wouldn't be great for the Python RDF community, but it also deserves to have a compliant library.