Metadata¶
Where change log is automatically generated dynamic information, meta data is user defined, user edited and more static information associated with entities.
Defining metadata properties¶
Defining the metadata properties is a task which involves users as well as system administrator. Each installation should agree on a common set of metadata properties.
At a technical level the metadata properties must be expressed as an XML schema. An example of a simple schema is:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="metadata" > <!--Root node -->
<xs:complexType>
<xs:sequence>
<xs:element name="identification" minOccurs="0" > <!--Category -->
<xs:complexType>
<xs:sequence>
<xs:element name="originator" type="xs:string" minOccurs="0" />
<xs:element name="publicationdate" type="xs:dateTime" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
It defines one property, identification, which is optional (minoccurs=0) and consists of two (also optional) values, originator and publicationdate. The first is a string, while the latter is a date-time.
Data types of properties in such a schema should be kept to standard types as defined by W3C.
A more elaborate sample is this - but still constructed following the line from above:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="metadata" >
<xs:complexType>
<xs:sequence>
<xs:element name="identification" minOccurs="0" >
<xs:complexType>
<xs:sequence>
<xs:element name="originator" type="xs:string" minOccurs="0" />
<xs:element name="publicationdate" type="xs:dateTime" minOccurs="0" />
<xs:element name="description" type="xs:string" minOccurs="0" />
<xs:element name="timeperiodofdata" minOccurs="0" >
<xs:complexType>
<xs:sequence>
<xs:element name="fromdate" type="xs:dateTime" minOccurs="0" />
<xs:element name="todate" type="xs:dateTime" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="progress" type="xs:string" minOccurs="0" />
<xs:element name="securityclassification" type="xs:string" minOccurs="0" />
<xs:element name="securityhandlingdescription" type="xs:string" minOccurs="0" />
<xs:element name="contactperson" type="xs:decimal" minOccurs="0" />
<xs:element name="contactorganization" type="xs:string" minOccurs="0" />
<xs:element name="contactemail" type="xs:string" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="dataquality" minOccurs="0" >
<xs:complexType>
<xs:sequence>
<xs:element name="logicalconsistencyreport" type="xs:string" minOccurs="0" />
<xs:element name="accuracyreport" type="xs:string" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="spatialreference" minOccurs="0" >
<xs:complexType>
<xs:sequence>
<xs:element name="geographiccoordinatesystemname" type="xs:string" minOccurs="0" />
<xs:element name="latituderesolution" type="xs:decimal" minOccurs="0" />
<xs:element name="longituderesolution" type="xs:decimal" minOccurs="0" />
<xs:element name="geographiccoordinateunits" type="xs:string" minOccurs="0" />
<xs:element name="unitofdatavalues" type="xs:decimal" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Note in addition to string and datetime als decimal types is used.
Configuring metadata properties¶
Bringing the defined the metadata properties into the Workbench is carried out via a "Metadata Schema Import" tool available in the Other Tools section of the Tools Explorer.
The tool takes two settings:
- The path and name of the xsd-file holding the schema to import.
- The Entity Type Name for which the schema shall be applied. This is selected from a drop-down listing the supported types.
Execution of the tool will validate the schema and eventually replace an existing schema for the entity type.
Displaying metadata properties¶
When an entity is selected in the UI and a schema is defined for the entity type and additional tab-page in the Properties dialog will appear showing the metadata.
Editing metadata properties¶
The same dialog used for displaying metadata can be used to modify the metadata. Updates are commited to the database immediately.
Translating metadata keys¶
It is possible to translate the metadata keys (the properties defined in the XSD file) to a readable format or to another language.
Currently this requires manual table updated in the database using the appropriate database management tool.
The tables to update are:
- language - which holds the language code and name (e.g. de-DE for German or en-US for US English)
Inserting can be accomplished by such a SQL statement:
INSERT INTO workspace1."language"(id, code, "name") VALUES ('7ea4af4b-d04c-4cd7-8b77-e9709b274d1c', 'en-US', 'English (United States)');
- translated key - which holds the reference to the language, the full XSD key and the translation.
This can insert a translation of Identification and its description:
`INSERT INTO workspace1.translated_key(id, language_id, "key","value") VALUES ('06D8C6FC-4E9A-4877-A570-2A00E419F5B6',
'7ea4af4b-d04c-4cd7-8b77-e9709b274d1c', '/metadata/identification', 'Identification');
INSERT INTO workspace1.translated_key(id, language_id, "key","value") VALUES ('60075350-2542-49FB-8989-044F534F0AFA',
'7ea4af4b-d04c-4cd7-8b77-e9709b274d1c', '/metadata/identification_description', 'Identification Category');