Hi Holger, let me add some details We are using GraphQL queries, maintained client-side, because the clients are familiar with GraphQL but not with SPARQL, so we are trying to avoid using SPARQL if possible
We also have a workaround for the time being: just before using the 'update' mutation, we 'get' the state of the graph. We can pull the URI of the BNode, and combine 'deleteValue' with the 'updateX' mutation. (Would you have any other pure-GraphQL ideas?) In principle, we are using the BNode to implement a structured Datatype, and/or consider the underlying property as a datatypeproperty. With a 'value' type, one normally always sets all the elements, and deleting the BNode to replace it, vs reusing the existing, would be the same. Do you think something like this could be feasible? Thank you! Davide On Wednesday, October 15, 2025 at 9:23:42 PM UTC-5 Holger Knublauch wrote: > Hi Michael, > > Thanks for the details. I first thought it was a SPARQL-based mutation, > but you’re using updateXY. > > I checked the source code and don’t see that we have special intelligence > to handle blank nodes here. > > One tricky bit is that it is unclear if these updates should modify the > already existing blank node or rather create a new one. If it’s supposed to > create a new one then that would need to have all values for the > properties, while an incremental update would only require the replacement > values. > > So I am afraid this clean-up is not supported with the GraphQL update > operation. It will always just create a new blank node. > > The alternative would be to formulate these updates as SPARQL > INSERT/DELETE and then either use the SPARQL endpoint or the sparql field > in GraphQL mutations. > > Is this an option for you, or do you have specific reasons for using > GraphQL here? > > Holger > > > On Oct 16, 2025, at 02:39, Michael Panzer <[email protected]> wrote: > > Sure, this is the full mutation, but we reproduced this with just the > bnode update. > > > mutation updateExpressionById( > $uri: ID!, > $primaryId:String!, > $versionTag:String!, > $catalogedOn: String!, > $createdOn: String!, > $name: String!, > $internalName: String!, > $state: ID!, > $contentModel: ID!, > $clientTag: String!, > $tagType: ID!) { > outcome: updateExpression (input:{ > uri:$uri > internalName: $internalName > primaryId: $primaryId > versionTag: $versionTag > name:{ > string:$name > lang:"en-US" > } > state: { > uri: $state > } > contentModel: { > uri: $contentModel > } > versionCode: { > code:$clientTag > tagType: {uri: $tagType} > } > catalogedOn: $catalogedOn > createdOn: $createdOn > }), > report{ > addedCount > diff > conforms > results{ > message > severity > constraintComponentName > pathLabel > focusNode{ > uri > } > sourceShape { > uri > } > } > } > commit(strict: true) > } > > But it's really an UPDATE mutation where you have a URI, a property, and a > BNode object. If you call it twice with 2 different values for the BNode, > the first call creates the graphlet > > URI <prop> _BNode(val1) > > the second call updates the property > > URI <prop> _BNode(val2) > > but does not delete _BNode(val1) from the graph in the process > > On Tuesday, October 14, 2025 at 7:15:02 PM UTC-5 Holger Knublauch wrote: > >> Hi Michael, >> >> can you share the UPDATE that you are running here? It’s difficult to >> analyze with the currently provided details. >> >> Regards, >> Holger >> >> >> On Oct 15, 2025, at 07:10, Michael Panzer <[email protected]> wrote: >> >> When updating a blank node through a GraphQL mutation, the following >> happens: >> >> <image.png> >> It seems that the blank node get deleted, the updated blank node gets >> committed, but then also the old blank node either survives or gets >> rewritten into the triple store as an orphan. >> >> Is that something that might be a bug in the GraphQL engine in TopBraid >> or do we need to add some garbage collection cleanup to manually delete >> these every time a blank node value gets updated? >> >> -- >> The topics of this mailing list include TopBraid EDG and related >> technologies such as SHACL. >> To post to this group, send email to [email protected] >> --- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Suite Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/topbraid-users/ae40a76b-90f3-469b-906a-3548fd5558a5n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/topbraid-users/ae40a76b-90f3-469b-906a-3548fd5558a5n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> <image.png> >> >> >> > -- > The topics of this mailing list include TopBraid EDG and related > technologies such as SHACL. > To post to this group, send email to [email protected] > --- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion visit > https://groups.google.com/d/msgid/topbraid-users/fc384333-4856-4eea-902a-63ce4ac227ben%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/fc384333-4856-4eea-902a-63ce4ac227ben%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- The topics of this mailing list include TopBraid EDG and related technologies such as SHACL. To post to this group, send email to [email protected] --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/topbraid-users/4cb1c82b-4db1-4b5b-acdf-2817c3ba1774n%40googlegroups.com.
