| Warning |
|---|
Update 11 Feb 2019 - this was a proposed design whose implementation ended up being different than documented here. Please reference the DDF docs for details on configurations for Metacard Types, Attributes and Validation Rulesets. |
DDF provides the ability to use multiple different types of metacards depending on the data types being ingested into the catalog. Out of the box, DDF provides basic metacards that can handle some common data types. However, as new data types are ingested into the catalog, it makes sense to define new metacard types that reflect the attributes specific to the new data type.
...
- Validating that metacard data is complete and compliant on ingest
- Indexing metacard attributes for optimized searching
- Validating results from other systems before caching/aggregating
- Displaying metacards for editing
- Discovering which fields of the metacard should be displayed
- Validating individual attributes of a metacard upon user entry
- Transforming metacards into requested response formats
...
Metacard Validation
DDF validates metacards at various points throughout the system. Metacards can be validated as a whole – i.e. every attribute in the metacard is validated successfully, or individual attributes of the metacard may be validated – i.e. from the UI as the user is entering data into a metacard editor.
...
Metacard validation involves validating each attribute of the metacard. In order to perform that validation, the validator must know how to perform that validation. It must know the type of data being validated and what constraints that data must meet in order to be considered valid. Some examples of various types of data and potential constraints that could be applied include:
Data Type | Potential constraints |
|---|---|
Integer or Long | Allowable range (0..100, -180..180) |
Float | Allowable range (0.0-1.0) |
XML | Schema validation (xml schema definition) Schematron ruleset validation (ruleset file) |
Enumerations | List of allowable values (“Red,Green,Blue”, “SiteA,SiteB,SiteC”) |
String | Length ( <= 80 characters) Pattern matching (email address, telephone numbers, IDs) |
...
Normalized Metacards
In order to be truly useful in the enterprise, where users search for information across multiple systems, metacards from each system need to represent common information in a common manner. Data representing a common data type, e.g. file size, should all be represented in the same manner (bytes vs. kilobytes vs. megabytes, etc.). In other words, the data in each metacard should be represented in a normalized fashion.
...
In addition to the name of an attribute and its base type there are several characteristics of an attribute that the catalog used for processing those attributes. These additional characteristics are specified as part of the attribute definition and are described below:
| Name | Description |
|---|---|
| multiValued | The attribute can contain more than one value |
| indexed | Indicates whether or not this attribute should be indexed by the catalog and participate in query evaluations. Some attributes may only want to be stored and not indexed. |
| stored | Indicates whether or not the catalog must store the value of this attribute. Some attributes may only need to be indexed and not stored. |
| tokenized | Indicates whether or not this attribute should be tokenized, i.e. remove stopwords, before storing or indexing the resulting values. |
Example Metacard Definition
...