![[photo-1545987796-200677ee1011.jpg]] Photo by [Alina Grubnyak](https://unsplash.com/ko/@alinnnaaaa?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/KuyqQNhT7rE?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) We already discussed MetaSystem structure of ecosystems (in [[How to structure MetaSystem]] article), consisting from Entities and Connections and now is the time to put some data inside :) In the next couple of sections we will describe MetaData syntax and how to universally identify metadata in specific example. MetaData are dynamically structured in dependency of various MetaSystems and can hold unlimited depth and granularity of attributes. Graphical representation of MetaData describing Megastructure is depicted below illustrating systems with their boundaries, entities, attributes and their values connected via MetaConnections. ![[Pasted image 20230709113320.png|Figure 1: MetaData Structure]] Metadata Syntax is derived from logical representation of Metadata Structure and covers all MetaSystem components and their attributes. Let's dive in into the description of MetaData Syntax language. MetaData syntax is structured in dependency of MetaSystem encapsulation, so it’s dynamic structure, fully dependent of particular MetaSystem and described by attributes and their content. ![[Pasted image 20230709113403.png|Figure 2: MetaData syntax]] Each encapsulation is uniquely identified by “Connection ID” and semantically identified by “Semantic ID”. Each “Connection ID” (graphically represented below identification line ) is loosely coupled with referenced “Semantic ID” (graphically represented above the line). Every Connection (relation or system) contains 2 or more entities (or connections / systems). Each entity is uniquely identified by “Entity ID” and semantically identified by “Semantic ID”. The Entity ID is graphically represented inside the entity (inside the circle) and is loosely coupled with referenced “Semantic ID” (graphically represented above the entity). Each connection or entity can have 1 or more attributes. Each attribute is referenced by semantic ID and could be recursive referenced within encapsulated structure of attributes. ## Semantics and Importance of Semantic ID Semantics (from Greek: **sēmantiká**) is the study of meaning, which focuses on the relation between signifiers, such as words, phrases, signs, and symbols, and what they stand for - their **denotata**. In computer science, the term semantics refers to the meaning of languages, as opposed to their form (syntax). Terms such as semantic network and semantic data model are used to describe particular types of data models characterized by the use of directed graphs in which the **vertices** denote concepts or entities in the world, and the **arcs** denote relationships between them. (Source: Wikipedia) Semantic ID is universal identifier for each object type (Ecosystem, System, Entity, Connection, Attribute). This ID is referenced from Semantic Master Index and can use multiple federated indexes (Open Metadata Sets via OWL/RDF) or Indexed list of all objects (The "SPHERES" distributed semantic ontology) ![[Pasted image 20230709113440.png|Figure 3:Semantic ID example "Racing Team"]] Let's take a look at the semantic example “Racing Team”, which shows simple MetaSystem of 2 essential entities: - Entity “CAR” , uniquely identified as Entity ID “001” semantically identified as Semantic ID [6662495], further described by attribute: - “Model”, semantically identified as Semantic ID [93103601] with Content “Corvette”. The “Corvette” model could be also identified by semantic ID with attribute “Trim” and as a content could be “ZR-1” or Z06” - Examples of Next attributes are: model Year, color - Entity “Human” , uniquely identified as Entity ID “002” semantically identified as Semantic ID [2261099], further described by attribute: - “Role”, semantically identified as Semantic ID [3333652] with Content “Driver”. The “Driver” role could be also identified by semantic ID with attribute “Name” and as a content have his real name (i.e. “John Armstrong”) - Examples of next attributes are: gender, nationality, age These 2 entities are connected together (orange connection link) by inclusive relationship (1:1), and together are representing mandatory requirement for “Racing Team”. In other words we have to have at least one (Human:Car) connection, otherwise we can’t make Racing Team. Racing Team can have more than one (Human:Car) connections (this applies to principle of dynamic structure of MetaSystem), which means one racing team can have more racing cars with assigned drivers. However (Human:Car) connection is static – it’s the minimum what has to be described by entity attributes (uniquely identified by Entity IDs). Our example of “Racing Team” MetaSystem is on the highest level of detail identified by unique Connection ID (1001) and semantically referenced by Semantic ID [0002578]. This means, in real world case scenario we will have more racing teams, they will have different unique Connection IDs (i.e. 1002), but exactly same Semantic ID. We defined one attribute of our Connection: - Attribute “Factory” semantically identified as Semantic ID [8933652] with content “Chevrolet”. This indicates that this instance of “Racing Team” is owned by Chevrolet Factory Team. Another instance of Racing Team could be owned by Dodge and so on. - We could define additional attributes of this connection (MetaSystem) , such as “Coach”, “Budget”, “Schedule” and more. As we already indicated above, our “Racing Team” MetaSystem is identified by Connection ID. Someone might ask a simple (and reasonable) question: "Why we are not using Entity ID instead of Connection ID?". The reason is simple; Connection always contains 2 or more entities (Mandatory requirement). Each Entity could potentially contain other entities too, but we don’t care about that level of detail in our model, therefore we don’t have to generate/translate/integrate our MetaSystem with lower level entities than we intend to do. Fundamentally, connection means – we care in our design/architecture what’s inside that particular system/entity. --- Next question could be: "Why we care about entities (components) about this particular entity?". Here are some of the possible answers: - We want/have to define relationships inside - There are multiple instances of entities inside with different ratios (1:N, N:N, 1:1) - The Entities (components) inside needs to be defined for integration purposes (outside of this Ecosystem model). This is basically pointing at requirement to define interface (API in IT). ## Related to [[MetaX - The Definition]]