Repository navigation
Conversation
7 tasks
jdsika
marked this pull request as draft
September 14, 2026 11:19
Merged
4 tasks done
jdsika
force-pushed
the
feat/envited-x-pipeline
branch
2 times, most recently
from
October 14, 2026 12:54
980b7d6 to
b3021e5
Compare
Converter.to_collection walked an rdf:List chain checking only that each cell carries one rdf:first/rdf:rest pair and that the chain is acyclic. It did not check how many statements point into the chain. The @list form inlines the whole chain at a single reference and writes its cells nowhere else, so when a cell is referenced from more than one place each referring list rendered the shared cells again. The round trip then gained triples: _:tail rdf:first "b" ; rdf:rest rdf:nil . _:head rdf:first "a" ; rdf:rest _:tail . ex:s1 ex:p _:head . ex:s2 ex:p _:tail . # second reference into the chain serialized as two independent @list values, so the tail was emitted twice: 6 triples in, 8 out, not isomorphic. A head referenced twice was duplicated the same way: 4 in, 6 out. The Serialize RDF as JSON-LD Algorithm (JSON-LD 1.1 Processing Algorithms and API, section 8.4) only turns a chain into @list when every cell, the head included, is a blank node that is "referenced once", counted over the whole dataset. The converter now applies that condition. It counts blank-node references once per conversion, over every graph it writes, and a chain with a cell referenced more than once is written with explicit rdf:first/rdf:rest, which can express any arrangement of sharing. Counting across graphs also covers a cell that another named graph points at, whose reference was otherwise left dangling. add_to_node offered a term declared with "@container": "@list" for any object with an rdf:first, then iterated to_collection without checking for None. That already raised TypeError for a chain the converter refuses, such as one whose cell carries an extra property, and would have for every shared chain. The term is now chosen from to_collection's result instead. This is the defect RDFLib#3504 fixed in the Turtle and longturtle serializers; the JSON-LD converter has its own chain walk. Fixes RDFLib#3542.
jdsika
force-pushed
the
feat/envited-x-pipeline
branch
from
October 23, 2026 16:04
46f0890 to
be5ea8f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Integration branch. Tracking only, do not merge.
What this branch is
feat/envited-x-pipelineis upstreamRDFLib/rdflib@mainwith every contribution thisorganisation is still carrying cherry-picked on top, and nothing else. It is the branch to
check out when you need an rdflib that behaves the way our pipeline expects before
upstream has merged the relevant PRs.
It is rebased on upstream
main, never merged into. An empty cherry-pick list is the goalstate: it would mean upstream has merged everything, and the branch could be deleted.
Same convention as
ASCS-eV/linkml#14.What it currently carries
be5ea8fbThree of the four changes this branch used to carry are now merged upstream and have
been dropped from it:
#3546 (deterministic N-Triples via an opt-in
canonparameter), #3564 (SPARQLIN/NOT INvalue equality) and #3574 (relativeIRI resolution against a base without its fragment).
The branch is rebased onto upstream
mainat3c4501c2, so it is now a single commit,patch-identical to its upstream PR head, applying with no conflicts.
Last verified on this branch at
be5ea8fb, Python 3.12: black, ruff and mypy are clean forthe whole project, and the full test suite gives 8096 passed, 0 failed.
What consumes it
Nothing yet, deliberately.
asam-openx-standardspins releasedrdflib==7.6.0through
scripts/requirements.txt, anddiffable-rdfdepends on released rdflib too.That pin is the point: rdflib performs the final serialization of every generated OWL and
SHACL artifact, so a change here moves artifact bytes. Consuming this branch would mean
building from a fork, which the pipeline's reproducibility rules do not allow: the lock
records released versions precisely so a third party can obtain them.
The relationship is therefore one-directional. What lands upstream here eventually arrives
as a released rdflib that the pipeline can bump to, with regenerated artifacts in the same
change. The merged #3504 (the Turtle variant
of the RDFLib#3543 defect) is the precedent:
diffable-rdfhad to work around it until it wasreleased.
When a release contains RDFLib#3543,
diffable-rdf's sentinel testtest_rdflib_jsonld_serializer_does_not_preserve_shared_list_tailwill fail by design;that is the signal to retire the workaround.