- Metamodels as a Piece of the Pie
- Remembering the Objective
- Storing Metadata
- Accessing Metadata
- Metamodel and Metadata Relationships
- Sample Metamodels
This chapter is from the book
This chapter is from the book
This chapter is from the book
Remembering the Objective
Why are we designing and implementing a metadata solution? Often, participants forget the main objective. Despite this seemingly myopic vision, "solutions" do result, but they are not always geared to original purpose. A continued naïveté almost always reflects in the metadata requirements themselves. It is essential to realize that a standalone metamodel will not serve metadata objectives if it becomes the only implemented component of a metadata solution.
How will the metamodels be populated? Will they be populated at all? How will the metamodels serve as access points for the metadata beneficiaries? How will metadata remain up to date? What relationship will the metadata suppliers, often tools, have with the metamodel contents?
Reviewing the 5 Questions
Although the 5 Questions1 focus on data and its qualities, they are transferred easily to the metadata arena. When we review them, it is clear that the metamodel in and of itself will not handle the objectives of any metadata solution.
What metadata do we have? Although a metamodel depicts the scope of metadata coverage, the traversal of the model is often quite clumsy and inefficient for most metadata beneficiaries. Therefore, to answer the question, a directory or high-level categorization of the metamodel contents is often an additional requirement.
What does it mean? How did we come up with the instance values of metadata? What does "Data Element Definition" really mean? Is it the definition according to one set of users, or is it a definition that has been sanctified as corporate? Where can we find out how this value was obtained? Do we define metadata, or just metadata instances?
Where is it? The location of the metamodel contents has not been discussed yet. This is a crucial component of all metadata solutions and depends on many architectural factors.
How did it get there? How and when was the metadata created? Why was it created and stored in its current location? This information is always of great significance to the metadata beneficiaries and often implies levels of credibility that are not necessarily documented.
How do I get it (Go get it for me!)? Last, but certainly not least, access to the validated and organized metadata must not be forgotten. If all this work goes into designing and creating a metadata solution, it should be available to all metadata beneficiaries—they are tools, users, applications, or repositories.
We address each of these questions in this chapter and validate our definition of metadata solution.