Error on "Change working graph > define a new one"
Thomas Francart
--
linked data | domain ontologies | knowledge graphs
blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart
tel : +33 (0)6.71.11.25.97
stel...@uniroma2.it
Dear Thomas,
I was going to point you, wrt your previous email, exactly to this, but I see you already figured it out :-)
Specifically for this, thanks as usual for the very clear references. Unfortunately, I’m unable to replicate the issue.
I can provide more details about what I did, to help both of us checking whether there is any difference:
- I performed the test on VB 14.0, as you reported, as admin.
- Following your scenario, I created two projects: A and B. Both projects were configured this way: model:OWL, lexmodel:SKOS-XL, local RDF4J (if I got what you meant by “local”), native storage.
- I added a couple of classes to project A then, from project B, imported A’s data, using “import from local project” (here local just means that the project is on the same instance of VB).
- Then, I switched graph, selecting the graph corresponding to data from project A (same baseuri of A). I went then to class test:SubClassA (which was editable, given the switch) and added the skos:definition you see in the picture below. Pls notice that the picture shows it in yellow again as I switched back to the main graph of project B in the meanwhile.
Is there any difference from what you did that might suggest there’s still a bug? Conversely, you can quickly try my test and see if you can replicate the successful performance of those actions or whether even with that, it fails.
Back to your original email in [1] (and summarizing for any interested reader), as you can imagine, the data from project A (again, in reference to your scenario) needs to be copied into project B. Had we kept a “live” reference between projects, we should have devised a way to adopt federated queries as an alternative for all non-federated ones, also with all risks associated with federations. So, whenever A is updated, its imported mirror in B needs to be updated as well. However, we felt this was not only an understandable limitation, but also a good approach as, for instance, in a dataProject importing ontologyProject (where the ontology is also in evolution) it makes sense to import an ontology and keep it stable, until developers of the ontology in the ontologyProject reach a stable version and the developers of the dataProject want to update to the new vocabulary (taking also necessary actions for reconciling data with the new model where necessary). The functionality for updating the data from the linked project (based on additional metadata that is not in the dataset, which only keeps the owl:import statement) allows then for easily keep everything updated without deleting and reapplying the import each time.
However, if there’s no need to keep the projects separated, also a solution based only on graph switching can be applied. Currently, we did not implement a way to assign graphs to different users/groups (as we did, for instance, for concept schemes in the multischeme management) so the project separation is recommended in case of different users working on the different artefacts.
Putting the two things together, as the solution with separated projects & import is creating a copy, it is obviously possible to combine the two together as in the example above (with the due caveat that an update of the import from the linked project will obviously reset everything to the new version of the imported project, deleting any local change that has been done on its copy stored in the different graph of the importing project).
Just a marginal note on the graph switching: from the next version, it will be possible to assign different baseuris to the data stored in each graph so that each time the graph is switched, also the baseuri adopted for new resources changes.
Kind Regards,
Armando
Da: vocben...@googlegroups.com <vocben...@googlegroups.com> Per conto di Thomas Francart
Inviato: giovedì 12 febbraio 2026 09:21
A: vocbench-user <vocben...@googlegroups.com>
Oggetto: [vocbench-user] Error on "Change working graph > define a new one"
Hello
With respect to my tests on how to handle the situation described at [1], I am trying to play with different working graphs in the same project.
If I try to do Global Data Management > Change working graph > Define a new one, and enter a new graph URI and click on OK, it does not work and I get the following error in the console:
The project is a local one, model OWL, lexicalisation SKOS-XL. Vocbench version 14.0.0.
--
Thomas Francart - SPARNA
linked data | domain ontologies | knowledge graphs
blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart
tel : +33 (0)6.71.11.25.97
--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vocbench-user/CAPugn7VpBArqbZDtuWAzi98q6fTt2_hcjDxksVV-Hgm7KuNXxQ%40mail.gmail.com.
Thomas Francart
Dear Thomas,
I was going to point you, wrt your previous email, exactly to this, but I see you already figured it out :-)
Specifically for this, thanks as usual for the very clear references. Unfortunately, I’m unable to replicate the issue.
I can provide more details about what I did, to help both of us checking whether there is any difference:
- I performed the test on VB 14.0, as you reported, as admin.
- Following your scenario, I created two projects: A and B. Both projects were configured this way: model:OWL, lexmodel:SKOS-XL, local RDF4J (if I got what you meant by “local”), native storage.
- I added a couple of classes to project A then, from project B, imported A’s data, using “import from local project” (here local just means that the project is on the same instance of VB).
- Then, I switched graph, selecting the graph corresponding to data from project A (same baseuri of A). I went then to class test:SubClassA (which was editable, given the switch) and added the skos:definition you see in the picture below. Pls notice that the picture shows it in yellow again as I switched back to the main graph of project B in the meanwhile.
Is there any difference from what you did that might suggest there’s still a bug? Conversely, you can quickly try my test and see if you can replicate the successful performance of those actions or whether even with that, it fails.
stel...@uniroma2.it
Hi Thomas!
Thanks for the explanation. On the bug on graph creation, my fault, it was pretty clear from your initial email and I overlooked it.
About the edit part, I now realize what you want; initially when you mentioned that you wanted to edit, I thought you wanted to intervene on their same graph where the resource is stored (as in remotely accessing the other project’s data and modifying it), that’s why I also clarified about the “reset” at each regeneration, but I thought it was specifically required for minor corrections, in order to get them in advance, while the original dataset that is imported is being finalized in the other project.
Ok, about the bug on graph creation, I’m aware of it and it’s been solved long time ago; it was simply that the graph was created but not stored temporarily client side. As graphs are dynamically generated by checking the fourth element of quadruples, if one generates a graph and then adds nothing, the next time the panel is reopened, it won’t be shown because, technically, that graph doesn’t exist. After the fix, the graph is stored temporarily client side and included in the list dynamically retrieved from the server so that it persists even before data is factually added to it. Unfortunately, the fix was released right after 14.0 and then it has been sleeping waiting for 15.0 to be released. We will come very soon with a 15.1 (15.0 was internal) and it will contain the fix.
About what you ask: that’s not a bug but an explicit policy (bound to a linked data principle) we applied. Basically, the idea is that if a named graph represents an external source (e.g. an imported ontology), it is in that external source that you need to edit the resource that belongs to it, according to the principle that each publisher is responsible for the resources they edit and publish.
However, considering that:
- One thing is LOD publication, other thing is the technical exploitation of named graphs, which you can use as tools for doing lot of stuff, before their content is published (and possibly arranged differently).
- What you ask for is substantially a monotonical edit: according to your request, you wouldn’t change the original source (e.g. data triples in proj A and imported in proj B); only add further descriptions to its resources in the working graph of the importing project (e.g. proj B). This is something I didn’t get from your original email
we could add an option for performing such operations, even though I would be cautious with that. I’ve seen too many weird things out there, such as datasets distributed with entire pieces of other datasets copied within them, with no trace of the fact that those are actually pieces of another dataset/vocabulary and I fear the consequences of freeing so much power.
On the long term, maybe an option that enables such operation at project level; maybe even a defined user capability for doing it, could be the ideal way to accompany such operation.
Such setting is more on the safe side, so that expert users like you who know what they are doing can perform such “hacks”, while the default setting maintains a more conservative approach.
On the short term, with your current VB, you can do the following (again, most probably you already figured that out, but it could be of interest for other readers) :
You mentioned you are probably working alone or close to on your dataset, so you have high permissions (admin or PM); then you can:
- place an INSERT DATA that just writes a definition triple (i.e. a triple with rdf:type as predicate) for the resource you want to add triples to. A rdf:type definition is enough for considering a resource as a local resource and be able to edit it. The following is an example for the screenshot resource I put in my previous email
INSERT DATA {
graph http://example.b/test {
http://example.a/test#SubClassA a owl:Class
}
}
note that you can even conveniently store it as a parameterized SPARQL UPDATE, with a parameter bound to the UI’s class chooser so that each time you want to modify an imported resource it suffices to do this operation with a couple of clicks, without editing SPARQL
- you can now edit the resource.
As you may notice, there are still parts that are yellow, this is because we only copied in the working graph the rdf:type triple, which acts as a sort of declaration of the resource.
The UI won’t allow you to modify the values existing only in the imported graph (and you will miss some shortcuts such as “add new value”, which spares you from choosing again the same property) but you still have 100% editing capabilities through the “+” buttons that are all active now.
Kind Regards,
Armando
Da: vocben...@googlegroups.com <vocben...@googlegroups.com> Per conto di Thomas Francart
Inviato: giovedì 12 febbraio 2026 15:35
A: stel...@uniroma2.it
Cc: vocbench-user <vocben...@googlegroups.com>
Oggetto: Re: [vocbench-user] Error on "Change working graph > define a new one"
To view this discussion visit https://groups.google.com/d/msgid/vocbench-user/CAPugn7Vgwg0LcH%2B8K%2BD3MdXkjN7TgU75jKKfS3rxwBjvmNbQFA%40mail.gmail.com.
Thomas Francart
About what you ask: that’s not a bug but an explicit policy (bound to a linked data principle) we applied. Basically, the idea is that if a named graph represents an external source (e.g. an imported ontology), it is in that external source that you need to edit the resource that belongs to it, according to the principle that each publisher is responsible for the resources they edit and publish.
- yes, each publisher is responsible for the resources they edit and publish, and no one should temper with/remove whatever was published...
- ... but, it should remain possible to state extra information about imported resources
However, considering that:
- One thing is LOD publication, other thing is the technical exploitation of named graphs, which you can use as tools for doing lot of stuff, before their content is published (and possibly arranged differently).
- What you ask for is substantially a monotonical edit: according to your request, you wouldn’t change the original source (e.g. data triples in proj A and imported in proj B); only add further descriptions to its resources in the working graph of the importing project (e.g. proj B). This is something I didn’t get from your original email
we could add an option for performing such operations, even though I would be cautious with that. I’ve seen too many weird things out there, such as datasets distributed with entire pieces of other datasets copied within them, with no trace of the fact that those are actually pieces of another dataset/vocabulary and I fear the consequences of freeing so much power.
On the long term, maybe an option that enables such operation at project level; maybe even a defined user capability for doing it, could be the ideal way to accompany such operation.
Such setting is more on the safe side, so that expert users like you who know what they are doing can perform such “hacks”, while the default setting maintains a more conservative approach.
On the short term, with your current VB, you can do the following (again, most probably you already figured that out, but it could be of interest for other readers) :
You mentioned you are probably working alone or close to on your dataset, so you have high permissions (admin or PM); then you can:
- place an INSERT DATA that just writes a definition triple (i.e. a triple with rdf:type as predicate) for the resource you want to add triples to. A rdf:type definition is enough for considering a resource as a local resource and be able to edit it. The following is an example for the screenshot resource I put in my previous email
INSERT DATA {graph http://example.b/test {
http://example.a/test#SubClassA a owl:Class
}
}
note that you can even conveniently store it as a parameterized SPARQL UPDATE, with a parameter bound to the UI’s class chooser so that each time you want to modify an imported resource it suffices to do this operation with a couple of clicks, without editing SPARQL
- you can now edit the resource.
As you may notice, there are still parts that are yellow, this is because we only copied in the working graph the rdf:type triple, which acts as a sort of declaration of the resource.
The UI won’t allow you to modify the values existing only in the imported graph (and you will miss some shortcuts such as “add new value”, which spares you from choosing again the same property) but you still have 100% editing capabilities through the “+” buttons that are all active now.
