refactor: RDF, documentation and briefing pack for RC2

[afizzycola]

All changes listed below cover:

1. RDF serialisation
2. markdown documentation
3. Briefing pack

Added

• Extent class as the root of the individuals hierarchy, allowing for individuals that are not necessarily spatiotemporal. This makes explicit IES-Top's commitment to Extensionalism, upon which Four-Dimensionalism is subsequently built, and moves IES-Top closer to David Lewis' principle of plenitude, under which "the worlds are many and varied" and may differ fundamentally from our own — including worlds in which "totally different laws govern the doings of alien particles with alien properties". SpacetimeExtent is now a subclass of Extent
• WorldboundExtent and TransworldExtent classes. In RC1 these distinctions were represented through class definitions; they are now explicit classes in their own right
• RegularSpacetimeExtent class as a subclass of SpacetimeExtent, providing the foundation for updates to IES-Core in relation to spatial objects, relative spaces and coordinate systems. Note: in practice, virtually all usage of IES relate to regular spacetime extents
• World class as the superclass of the existing Universe class, allowing for worlds irrespective of whether they are spacetime worlds or not
• connected and disconnected relations
• SHACL validation file for for all classes and properties

Changed

• Renamed SpatiotemporalExtent to SpacetimeExtent. This makes clearer that, at this level, we are talking about "chunks" of spacetime (in a spacetime world), aligns the terminology with the foundational spacetime literature originating with Minkowski and Einstein, and provides a shorter and cleaner term in the RDF implementation
• Refined the pattern for continuous and intermittent states, giving it a standard mereotopological foundation based on self-connection and self-disconnection, itself built on the newly introduced connected and disconnected relations

Still to do before release (upcoming PRs)

• Re-introduce to the RDF serialisation: Object- and DataType- Properties
• Update Change Log

[github-actions]

Required repository documentation checks passed

All required repository documentation checks passed in this run.

Total Files	Passed	Failed	Score
11	11	0	100%

Results from commit 4939b68, view the full job summary for detailed results.

♻️ This comment has been updated with latest results.

[jamrce]

@afizzycola - I've just ran a diff across rc1 and rc2 and have found some of the ID's do not align to where you've renamed classes between versions. This may not be of significance whilst still in RCs, but if you could fix for anyone resolving on these IDs for class name changes as users would expect the dcterms:identifier to be a oblique ID mechanism that could be relied upon. I've not exhausting checked everything, but if other classes have been renamed they may have the same problem.

# rc1
ies_top:SpatiotemporalExtent dcterms:identifier "{DCB3F671-0FA3-4de6-B037-A011C432A087}" . 

RC2 briefing pack states that: "The class SpatiotemporalExtent has been renamed to SpacetimeExtent."

# rc2 - a fresh ID for SpacetimeExtent.
ies_top:SpacetimeExtent dcterms:identifier "{77BB5948-C5BF-4cc2-B6DC-B7FFE413ADF5}" .

# the resolved rc2 class of where the rc1 ies_top:SpatiotemporalExtent now resolves to instead
ies_top:RegularSpacetimeExtent dcterms:identifier "{DCB3F671-0FA3-4de6-B037-A011C432A087}" . 

[afizzycola]

@afizzycola - I've just ran a diff across rc1 and rc2 and have found some of the ID's do not align to where you've renamed classes between versions. This may not be of significance whilst still in RCs, but if you could fix for anyone resolving on these IDs for class name changes as users would expect the dcterms:identifier to be a oblique ID mechanism that could be relied upon. I've not exhausting checked everything, but if other classes have been renamed they may have the same problem.

# rc1
ies_top:SpatiotemporalExtent dcterms:identifier "{DCB3F671-0FA3-4de6-B037-A011C432A087}" . 

RC2 briefing pack states that: "The class SpatiotemporalExtent has been renamed to SpacetimeExtent."

# rc2 - a fresh ID for SpacetimeExtent.
ies_top:SpacetimeExtent dcterms:identifier "{77BB5948-C5BF-4cc2-B6DC-B7FFE413ADF5}" .

# the resolved rc2 class of where the rc1 ies_top:SpatiotemporalExtent now resolves to instead
ies_top:RegularSpacetimeExtent dcterms:identifier "{DCB3F671-0FA3-4de6-B037-A011C432A087}" . 

This example is fine: a SpatiotemporalExtent was always a an extent in regular spacetime (where we do most of the work) i.e. RegularSpacetimeExtent. There might be the odd mismatch but I am going to say considering these are RC, I think breaking changes in this regard need to be expected.

[jamrce]

This example is fine: a SpatiotemporalExtent was always a an extent in regular spacetime (where we do most of the work) i.e. RegularSpacetimeExtent. There might be the odd mismatch but I am going to say considering these are RC, I think breaking changes in this regard need to be expected.

Agreed, I was mostly raising for awareness for others who find the same issue.

On your logic, I've just seen the same for the Disjoint sets and a previous SetOfDisjointSpatiotemporalExtents is now not always a SetOfDisjointExtents. Still no change required.
RC1: ies_top:SetOfDisjointSpatiotemporalExtents dcterms:identifier "{2733C396-A001-42fb-945F-B4F26E120B33}" .
RC2: ies_top:SetOfDisjointExtents dcterms:identifier "{2733C396-A001-42fb-945F-B4F26E120B33}" .

[chrispartridge1091]

Looks okay.

[nigel81562]

Comments addressed - all looks okay now