They are used as entity identifiers in an ontology.
We’re doing NLP and Robotics research and I’m writing a middleware to communicate between the different components. The project this is happening in is heavily focused around symbolic and explainable AI, so there is a lot of knowledge graph and ontology engineering involved. Basically all the components in the system communicate via the extension of a globally shared, append only, triple space, on which they can subscribe with queries.
We’ve decided to take a different path than the classical RDF and SemWeb route though, because frankly they are unsexy, over-engineered, and you encounter huge social barriers when trying to get people to use that stuff (understandably so).
We’ve therefore build our own knowledge graph system, tailored towards simplicity and minimalism, in the hope that this will make it easier to spread adoption within the project.
One of the fundamental components of our new system is using Observable for basically everything visual, because it allows researchers to not only quickly explore our reference implementation in a literate programming way, but it also makes it easy for them to contribute their own visualisations and enables pretty fast paced and reproducible science (at least that’s the long term goal ).
One of these uses for Observable is ontology engineering. Instead of having to boot up a tool like Protege (which ironically is also the only tool), researchers should be able to simply clone a Base Ontology Notebook, and continue experimenting from there. Using a literate programming style for their ontology, which not only gives good documentation but also makes it easy to scientifically publish the resulting work.
One problem we’ve encountered with RDF and it’s URI based naming scheme is that people interpret ontological concepts differently, and that sometimes the semantics of the concepts change a lot over time.
Both result in two parts of the system having a different understanding of the data which is not ideal. It also results in incompatibilities once you have systems of different generations collaborating.
So what we’ve decided to do (because hey UUID’s are cheap), is that whenever you publish a new version of your ontology, you don’t change the existing one, you simply append a new one with entirely new UUIDs.
The system will happily run with both ontologies at the same time, with the old components consuming and producing the old style data and the new stuff using the new concepts.
And this is why it would be great to be able to fixate values on publish. It would allow everyone visiting the notebook to get the up to date ontology, with compatible UUIDs, while enforcing a change of UUIDs whenever a change is made.