CONCRETE needs an information architecture that supports it's vision of dynamic, distributed, integrated information operations

[ClimbingAl]

Many initiatives that aim to be integrated (i.e. have integrated information operations) have fallen at the first hurdle by not having a consistent mechanism for representing existing and newly added information records. The CONCRETE opening gambit is to use "HQDM", or a suitably capable integration data model, in a foundational way. If this is done system-wide then a new, properly integrated, approach to information operations should be possible. Hwoever, doing this implies that other key architectural elements will be needed; it isn't just down to having a suitably capable data model, it needs to be useable within the CONCRETE system and by those who make use of it for their distributed information exchanges.

I have created some material to introduce how these architectural aspects can be addressed within CONCRETE.

Before making a pull request they are visible on a fork, on the hqdm_dev branch, here: https://github.com/ClimbingAl/CONCRETE/tree/hqdm_dev. Here's a link directly to the hqdm page and its sub-pages.

Ask questions if you are not sure of anything I have put in the edits or let me know if I have missed anything. Some of the key parts mentioned are novel and have never been implemented before.

[Chris-SimplexityAnalysis]

Adding to this issue - I agree with @ClimbingAl on this - to summarise the current challenge in even more high level terms:

1. Project Concrete is a promising approach to improve the data foundations of integrated information operations
2. At present, the materials could suggest the approach for its implementation have been determined and are being implemented (the nature of presenting outputs through github does implicitly (perhaps) suggest a degree of 'choice' has already been made and coding has already been started.

A slight concern with 2) is that this could present a degree of maturity for the idea and the approach that we're probably not at yet and hence comes back to Climbing Al's point, which to summarise mercilessly are (IMO) 'What the requirements that the approach proposed for Project concrete are addressing?'

Following a structured information requirements methodology to fulfil the architecture advocated by Climbing Al in his commits could be a useful, early exploratory activity to help get this work funded? The benefit of this would be it would help a) derisk the current work from being too focused on detailed technical implementation b) allow small (hopefully funded) activity to be conducted to better understand the requirements but also (potentially) scope and define scalable options for approach.

Again (without doing this) we're at risk slightly of putting in detailed technical options for a very big problem, that we haven't initially bounded (or at least tried to articulate in some ways)

As mentioned the IRM could be one method for doing this (https://github.com/Apollo-Protocol/information-requirement-methodology) likewise other top-level requirements methodologies like the BORO process could be used - with the clear goal of 'building an an agreed understanding of the problem Project Concrete is addressing'

Personally, I believe that addressing that goal will help articulate the mission to both the technical partners who can do the work, but crucially, bring on board high level decision makers who will need to understand the need of this if they are going to unlock funding...

[BigMassive]

Keeping this issue open to re-visit later - at any time.

After discussions - this website is at too early a stage of development to enable these information architecture comments to be addressed properly at present.

The material from @ClimbingAl will be used (with gratitude) to enhance the HQDM/4D ontology intro section, but will also be reflected in the wider site - where there are many other touch points.

@Chris-SimplexityAnalysis makes a reasonable additional observation about 'implementation having been determined before requirements are fully understood'. Agreed. However, this approach is considered necessary to overcome the chicken-and-egg issue. CONCRETE is, at any point in time, just a sketch to enable discussions about requirements. 'Spears' (or here, 'issues') are the most valuable commodity in this development.