# Security and Ownership in User-Defined Data Meshes
## 4 A Framework for Supporting the Transfer of Ownership in Data Meshes
### Semantically Enriched Creation of Data Lake Architecture and Data Mesh Products  
A metadata mechanism is of paramount importance for a DL as it functions as its organizational backbone, offering a systematic and detailed catalog of the diverse datasets hosted within the DL. Without such a metadata mechanism, a DL will gradually be transformed into a data swamp. In essence, a metadata mechanism provides data owners with a vital insight into the type and context of the stored information by capturing important details about the origin, structure, relationships, and usage of data. By providing this information, navigating and mapping raw data become feasible, making data searching, retrieval, and management easier and more efficient. The SDB is a metadata enrichment mechanism that identifies and characterizes a candidate source before it becomes member of a DL [10]. The framework described in [10] integrates blueprint ontologies with the 5 Vs big data features, namely Volume, Velocity, Variety, Veracity, and Value, to support data processing (storage and retrieval) in DLs organized in a pond architecture. The latter structures a DL in several distinct data ponds, each of which holds or refers to a certain type of data according to the pond design. Depending on the type of data (structured, semi-structured, unstructured), each pond has a unique data processing and storage method. When extracting data from the DL, this built-in pond architecture is quite useful as it supports quick and easy access to the storage space. As previously mentioned, a dedicated blueprint is developed to describe each data source that stores data in the DL. Specifically, the blueprint of a source consists of two interconnected blueprints, as shown in Figure 4, the stable and the dynamic blueprint [10]. The former is static and describes the name and type of the source, the type of data it produces, as well as the value, velocity, variety, and veracity of the data source pushed in the DL. The latter is a dynamic blueprint which involves attributes that are not stable over time and essentially characterizes volatile properties such as the volume of data, the last source update, and keywords characterizing the source. The dynamic blueprint is updated every time data sources produce new real-time or batch data, or its description through keywords may be modified. In essence, the metadata description--SDB is provided in Terse Triple Language (TTL) using the Resource Description Framework (RDF), which is a well-known framework for describing resources on the Web. The metadata mechanism contains TTL descriptions for all the sources included in the DL. In essence, TTL is a serialization format that provides a concise and human-readable way to represent RDF data, making it easier for both machines and humans to work with semantic information on the Web. RDF represents information as triples, which consist of subject-predicate-object statements. The resource being described is the subject, the property or attribute is the predicate, and another resource or value is the object. An example of a triple may be _ex:variety \"unstructured\"_, which means that the subject is the source, the predicate is \"variety\" and the object is the value \"unstructured\". Our framework supports the categorization of data into three pillars: structured, semi-structured, and unstructured. This classification allows for the flexible inclusion of diverse datasets that transcend the constraints of data representation through meticulous metadata recording and semantic enrichment. By introducing stable and dynamic blueprints, the framework captures the essence of data variety, thereby ensuring independence from specific representations and underscoring its adaptability and robustness across varying datasets, marking a significant stride in modern data analytics. Let us assume that a user requests access to specific sources producing data and storing it to the DL. In this case, a dedicated SPARQL query is formed and executed in the DL.