Repository navigation
Fix extra solution per entity in optional property branches - #184
Merged
karelklima merged 1 commit intoOct 13, 2026
Merged
Conversation
- Wrap the UNION of optional property branches in an OPTIONAL instead of starting it with an empty group - The empty group added a solution for every entity that has one of the optional properties, at every level of a nested schema - Update the expected quad count in the optional properties test
karelklima
approved these changes
Oct 13, 2026
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.
Follow-up to #183.
That PR starts the
UNIONof optional properties with an empty group, which keeps the solution for an entity that has none of them. The empty group also adds a solution for every entity that does have them, at each level of a nested schema. A store that does not deduplicateCONSTRUCToutput, such as QLever, sends the triples of each of those solutions again.With this change the
UNIONsits in anOPTIONALinstead:An entity with 3 values for one optional array and 3 for another now comes back as 3 + 3 = 6 solutions, where 2.10.0 gives 1 + 3 + 3 = 7. An entity with none still comes back as 1. A level with one optional property gets the same shape, which amounts to the plain
OPTIONALit had before #183.Measurements
I ran
findByIri()against the QLever endpoint of the Dataset Knowledge Graph, on its two largest VoID descriptions, with two schemas:Response size:
som-persons-in-musiciisg-kgsom-persons-in-musiciisg-kgThe last column is the 2.10.0 npm build with this change applied to it by hand, not a build of this branch. I compared the decoded entities whole, ignoring array order: they are identical in all three columns.
On the nested schema 2.10.0 was 48% and 41% larger than 2.7.2.
iisg-kgstays 7% above 2.7.2: where two optional properties on one level each have a single value, their sum (2 solutions) is higher than their product (1).An alternative that does not work
I first made only the first branch optional:
{ OPTIONAL { … } } UNION { … }. That group is evaluated without the bindings of?iri, so an entity with none of the optional properties is lost. Oniisg-kgthat dropped 1085 of the 3148 property partitions: the ones without a nested partition.Tests
The quad count in “Should not multiply the values of optional properties” goes from 34 to 28.