Robert Best: Maybe the injector could also allow the creation of new node and edge types in addition to new properties... This would allow the injector to start as a blank slate. matrix 
Though, I also think intentionally constraining ourselves to a particular schema that we use in common with others also seems useful. I'm also interested in creating Wiki sites who's sole purpose is to represent and describe a schema... So when one schema refers to a person for example, I could click into the wiki for that schema and find out what exactly is meant by that word, or any of the other one-word types and relations
~
One of Frank Lloyd Wright's Organic Architecture principles, this seems to prefigure the fractal concept of "scale symmetry", one of the most striking and beautiful aspects of Systems As Living Things.
In any case, I feel that Composite Pattern, being a generative pattern, is capable of grasping the temporal aspects of changing structure of objects. An object realized through some Composite Pattern can be thought of as a point-in-time view. The structural evolution (Schema Evolution) of such an object can be traced by the Composite Pattern. There may be cases when a structural change in the object requires the Composite Pattern itself to change ie it requires creation of new types of components.
~
Angela Bonifati, Peter Furniss, Alastair Green, Russ Harmer, Eugenia Oshurko, and Hannes Voigt. 2019. Schema Validation and Evolution for Graph Databases. In Conceptual Modeling. Springer International Publishing, Cham, 448–456.
BONIFATI, Angela, FURNISS, Peter, GREEN, Alastair, HARMER, Russ, OSHURKO, Eugenia and VOIGT, Hannes, 2019. Schema Validation and Evolution for Graph Databases. In: LAENDER, Alberto H. F., PERNICI, Barbara, LIM, Ee-Peng and DE OLIVEIRA, José Palazzo M. (eds.), Conceptual Modeling. Cham: Springer International Publishing. 2019. p. 448–456. Lecture Notes in Computer Science. ISBN 978-3-030-33223-5. DOI 10.1007/978-3-030-33223-5_37.
> Despite the maturity of commercial graph databases, little consensus has been reached so far on the standardization of data definition languages (DDLs) for property graphs (PG). Discussion on the characteristics of PG schemas is ongoing in many standardization and community groups. Although some basic aspects of a schema are already present in most commercial graph databases, full support is missing allowing to constraint property graphs with more or less flexibility.
The schemas that (property) graph database systems typically provide are descriptive in the sense that they only reflect the data: the schema can be changed simply by manipulating the data instance directly with no particular restrictions on any such manipulations. The flexibility that this entails is generally perceived as a valuable characteristic, particularly in the earlier stages of application development, and especially in conjunction with the now ubiquitous agile software development method. A system that allows for the structure of graph elements to be manipulated and refactored freely, as the understanding and modelling of an application’s universe evolves, greatly simplifies the development process in its early stages.
As applications mature, however, a gradual shift in priorities occurs. As a concept becomes more stable, well-established, and central in our data model, we must treat it with increasing caution when considering further modifications. The demand for restrictive schema manipulation policies further increases when an application goes into production since data becomes precious and misshaped data can have large financial consequences. By this stage, traditional prescriptive schemas are the more appropriate choice.
**Note**: Evolution, *Schema Evolution* in the context of Wardley Mapping.
DOT FROM lambda-browsing