Cannot build a top level PossibleWorld

[Fabalab]

Describe the bug
Every possible_world inherits from state and, therefore, must be part of a possible_world. To break the recursion, (ie. for a top-level possible_world) a self reference is needed. However, this is not possible using the builder classes supplied in hqdm-canonical. Should there be an extra, partOfOwnPossibleWorld() method on the PossibleWorldBuilder class that allows you to make this self-referential relationship?

To Reproduce
Steps to reproduce the behavior:
Run the following code:

final IRI topLevelWorldIri = new IRI(HQDM.HQDM, "Top_Level_World");
final PossibleWorldBuilder topLevelWorldBuilder = new PossibleWorldBuilder(topLevelWorldIri);
final PossibleWorld topLevelWorld = topLevelWorldBuilder.build();

It will return the following error:

Exception in thread "main" uk.gov.gchq.magmacore.hqdm.exception.HqdmException: Property Not Set: part_of_possible_world
	at uk.gov.gchq.magmacore.hqdm.rdfbuilders.PossibleWorldBuilder.build(PossibleWorldBuilder.java:268)
	at main.Program.main(Program.java:20)

[ClimbingAl]

Yes, this is expected and known behaviour. You can call this a paradox in the original HQDM model. The possible world is a subtype of spatio_temporal_extent. The catch that you have discovered is that the supertype spatio_temporal_extent has a mandatory relationship part__of_possible_world that requires any (and all) represented material item (i.e. a distinct 'chunk' of spacetime) to be part of a larger material extent. This makes trivial sense for things that have parts (the head and handle of a hammer are each parts of a hammer).

The challenges arise when things being represented using Magma Core are aggregated together in some maximal way. possible_world is one example of this - "an individual that is a complete spatio-temporal history of some possible world.". Aside from philosophical debates about such things, there is practical value in being able to aggregate representations (MC data objects) of 'real'-world things together so that they don't get confused/merged/grouped with others unintentionally. This feature also allows different possible representations of the same / competing situations that are represented as data.

Rather than changing the MC code to address this (which is possible, but probably worth trying the following first) is to generate the seed possible_worlds manually. This is straightforward.

Example possible world created by generating the underlying triples

Example possible world being generated manually, but as a an object

Treat a single root model as a constant

Each of these approaches is manual, but is a quick way to create what is needed to satisfy the MagmaCore builders and hasn't caused many practical issues so far AFAIK. If it becomes a problem for you then we can carry on discussing it here and could lead to changes to MC itself if the case is solid.

[twalmsley]

Hi @Fabalab @ClimbingAl , I was going to answer this yesterday but was too busy. The examples from @ClimbingAl are all good, but here are my thoughts as well.

I didn't want to update the builder for possible world to refer to itself because this would end up being the default and people wouldn't then think about the problem, so I'm glad to see that you have looked into it! Another alternative I considered earlier was to have a well-known IRI defined in the library for a possible world that represents our world, the world outside any computer system, to act as the root of all possible worlds within any computer system. The 'universal possible world' could then be supplied when using the builder. It's something to think about but in the meantime any of the alternatives above will do.