back to XmlBlob main page
Metadata references - a practical example
The example use case is from ISO19115 H.2.- Consider a geographic data provider generating vector mapping data for three Administrative areas(A, B and C). ... the metadata could be carried exclusively at Dataset Series level.
- After some time alternate vector mapping of Administrative area A becomes available. The metadata would then be extended for Administrative area A, to describe the new quality date values. These values would supersede those given for the Dataset series, but only for Administrative area A. The metadata for B and C would remain unchanged. This new metadata would be recorded at Dataset level.
- Eventually further data becomes available for Administrative area A, with a complete re-survey of the road network. Again this implies new metadata for the affected feature types. This metadata would be carried at Feature type level for Administrative area A. All other metadata relating to other feature types remains unaffected. Only the metadata for roads in Administrative area A is modified. This road metadata is recorded at Feature type level.
- An anomaly in the road survey is identified, in that all Overhead clearances for the Administrative area A have been surveyed to the nearest metre. These are re-surveyed to the nearest decimetre. This re-survey implies new metadata for the affected attribute type ‘Overhead Clearance’. All other metadata for Administrative area A remains unaffected. This ‘Overhead Clearance’ metadata is recorded at Attribute Type level.
- A new bridge is constructed in Administrative area A. This new data is reflected in the geographic data for Administrative area A, and new metadata is required to record this new feature. All other metadata for Administrative area A remains unaffected. This new feature metadata is recorded at Feature instance level.
- The overhead clearance attribute of the new bridge was wrongly recorded, and is modified. Again this new attribute requires new metadata to describe the modification. All other metadata for Administrative area A remains unaffected. This new attribute metadata is recorded at Attribute instance level.
step 1: initial vector mapping, all Areas
SELECT RegisterIsoMetadata( 'series', blob );We'll insert first an ISO Metadata document (scope: series). We'll imagine that this one is the first Metadata document to be inserted, so it will correspond to id=1.
INSERT INTO ISO_metadata_reference ( reference_scope, table_name, column_name, row_id_value, timestamp, md_file_id, md_parent_id ) VALUES ( 'table', 'bridges', 'undefined', -1, strftime( '%Y-%m-%dT%H:%M:%S', datetime( 'now' )), 1, 0 ); INSERT INTO ISO_metadata_reference ( reference_scope, table_name, column_name, row_id_value, timestamp, md_file_id, md_parent_id ) VALUES ( 'table', 'roads', 'undefined', -1, strftime( '%Y-%m-%dT%H:%M:%S', datetime( 'now' )), 1, 0 );Immediately after we'll insert the corresponding references for all vector layers (for simplicity we'll simply consider two table/layers: roads and bridges).
step 2: new vector mapping, Area A
SELECT RegisterIsoMetadata( 'dataset', blob );We'll insert a new ISO Metadata document (scope: dataset). This being the second Metadata document to be inserted, it will correspond to id=2.
Please note: this new metadata document extends the previous one only for Administrative Area A; both Area B and C still continue to be represented by the original document. So we'll define a parent/child relation hierarchically joining both documents.
INSERT INTO ISO_metadata_reference ( reference_scope, table_name, column_name, row_id_value, timestamp, md_file_id, md_parent_id ) VALUES ( 'table', 'bridges', 'undefined', -1, strftime( '%Y-%m-%dT%H:%M:%S', datetime( 'now' )), 2, 1 ); INSERT INTO ISO_metadata_reference ( reference_scope, table_name, column_name, row_id_value, timestamp, md_file_id, md_parent_id ) VALUES ( 'table', 'roads', 'undefined', -1, strftime( '%Y-%m-%dT%H:%M:%S', datetime( 'now' )), 2, 1 );Now we'll insert the corresponding references for the roads and bridges) tables.
step 3: complete re-survey of the road network, Area A
SELECT RegisterIsoMetadata( 'dataset', blob );We'll insert yet another ISO Metadata document (scope: dataset). This being the third Metadata document to be inserted, it will correspond to id=3.
In this case too the new metadata document will actually extend the previous one; and we'll define accordingly to this a parent/child relation hierarchically joining both documents.
INSERT INTO ISO_metadata_reference ( reference_scope, table_name, column_name, row_id_value, timestamp, md_file_id, md_parent_id ) VALUES ( 'table', 'roads', 'undefined', -1, strftime( '%Y-%m-%dT%H:%M:%S', datetime( 'now' )), 3, 2 );And we'll insert the corresponding reference for the roads table.
step 4: re-survey: overhead clearances, Area A
SELECT RegisterIsoMetadata( 'attributeType', blob );We'll insert yet another ISO Metadata document (scope: attributeType because a single column/attribute is affected, not the whole table/dataset). This being the fourth Metadata document to be inserted, it will correspond to id=4.
Yet again, we'll define a parent/child relation hierarchically joining this metadata document to the previous one.
INSERT INTO ISO_metadata_reference ( reference_scope, table_name, column_name, row_id_value, timestamp, md_file_id, md_parent_id ) VALUES ( 'column', 'roads', 'overhead_clearance', -1, strftime( '%Y-%m-%dT%H:%M:%S', datetime( 'now' )), 4, 3 );And we'll insert the corresponding reference for the roads.overhead_clearance column.
step 5: construction of a new bridge
SELECT RegisterIsoMetadata( 'feature', blob );We'll insert yet another ISO Metadata document (scope: feature because a single specific row is affected, not the whole table/dataset). This being the fifth Metadata document to be inserted, it will correspond to id=5.
Yet again, we'll define a parent/child relation hierarchically joining this metadata document to the latest one representing the whole bridges dataset, i.e. the one identified by id=2.
INSERT INTO ISO_metadata_reference ( reference_scope, table_name, column_name, row_id_value, timestamp, md_file_id, md_parent_id ) VALUES ( 'row/col', 'bridges', 'undefined', 1234, strftime( '%Y-%m-%dT%H:%M:%S', datetime( 'now' )), 5, 2 );And we'll insert the corresponding reference for the bridges table (we'll suppose that the newly inserted bridge will correspond to ROWID=1234).
step 6: modifying the overhead clearance for the new bridge
SELECT RegisterIsoMetadata( 'attribute', blob );We'll insert yet another ISO Metadata document (scope: attribute because a single specific row/column value is affected). This being the sixth Metadata document to be inserted, it will correspond to id=6.
Yet again, we'll define a parent/child relation hierarchically joining this metadata document to the previous one.
INSERT INTO ISO_metadata_reference ( reference_scope, table_name, column_name, row_id_value, timestamp, md_file_id, md_parent_id ) VALUES ( 'row/col', 'bridges', 'overahead_clearance', 1234, strftime( '%Y-%m-%dT%H:%M:%S', datetime( 'now' )), 6, 5 );Then we'll insert the corresponding metadata reference.
the ISO_metadata table
| id | md_scope | metadata | fileId | parentId |
|---|---|---|---|---|
| 0 | undefined | BLOB sz=4 UNKNOWN type | NULL | NULL |
| 1 | series | XmlBLOB-ISOmetadata | NULL | NULL |
| 2 | dataset | XmlBLOB-ISOmetadata | NULL | NULL |
| 3 | dataset | XmlBLOB-ISOmetadata | NULL | NULL |
| 4 | attributeType | XmlBLOB-ISOmetadata | NULL | NULL |
| 5 | feature | XmlBLOB-ISOmetadata | NULL | NULL |
| 6 | attribute | XmlBLOB-ISOmetadata | NULL | NULL |
the ISO_metadata_reference table
| reference_scope | table_name | column_name | row_id_value | timestamp | md_file_id | md_parent_id |
|---|---|---|---|---|---|---|
| table | bridges | undefined | -1 | 2013-02-07T15:29:05 | 1 | 0 |
| table | roads | undefined | -1 | 2013-02-07T15:29:06 | 1 | 0 |
| table | bridges | undefined | -1 | 2013-02-21T09:12:25 | 2 | 1 |
| table | roads | undefined | -1 | 2013-02-21T09:12:26 | 2 | 1 |
| table | roads | undefined | -1 | 2013-02-27T15:32:32 | 3 | 2 |
| column | roads | overhead_clearance | -1 | 2013-03-04T11:13:07 | 4 | 3 |
| row/col | bridges | undefined | 1234 | 2013-03-08T16:51:47 | 5 | 2 |
| row/col | bridges | overhead_clearance | 1234 | 2013-03-15T12:21:17 | 6 | 5 |
Please note: as you can easily see from this first example, you can represent all parent/child relationships just defining the appropriate numeric IDs accordingly to the intended hierarchy of XML Metadata documents.
Anyway a problem will become immediately evident; all relations are simply internal to the DBMS itself. Once the XML Documents will extracted outside the DBMS all them will immediately vanish (and would easily require a hard work in order to be thereafter reconstructed).
the ISO_metadata table (with explicit parent/child UUIDs)
| id | md_scope | metadata | fileId | parentId |
|---|---|---|---|---|
| 0 | undefined | BLOB sz=4 UNKNOWN type | NULL | NULL |
| 1 | series | XmlBLOB-ISOmetadata | 953c408a-4f56-45ae-88b2-ede53c5b9098 | NULL |
| 2 | dataset | XmlBLOB-ISOmetadata | 3144581b-725e-46a4-8ea3-077fc3ec5d99 | 953c408a-4f56-45ae-88b2-ede53c5b9098 |
| 3 | dataset | XmlBLOB-ISOmetadata | e20d9943-009f-4665-8d29-c7ee2a3a0f22 | 3144581b-725e-46a4-8ea3-077fc3ec5d99 |
| 4 | attributeType | XmlBLOB-ISOmetadata | 3848723f-87cd-4569-8b60-75a64f0acccc | e20d9943-009f-4665-8d29-c7ee2a3a0f22 |
| 5 | feature | XmlBLOB-ISOmetadata | dd467e4f-73b2-4c65-87e8-1cf565cc89e3 | 3144581b-725e-46a4-8ea3-077fc3ec5d99 |
| 6 | attribute | XmlBLOB-ISOmetadata | 673e43c9-6392-4b26-89ab-5f112c55bde3 | dd467e4f-73b2-4c65-87e8-1cf565cc89e3 |
The solution to the above mentioned issue is rather simple, and is implicit in ISO 199115 / 19139 specifications: you can directly set the appropriate values into the <gmd:fileIdentifier> and <gmd:parentIdentifier> XML tags. None of them is mandatory; anyway always inserting an explicit definition is a commonly adopted good practice: as is using UUIDs values.
SpatiaLite ISO Metadata implementation will help you in many ways to reach this goal.
back to XmlBlob main page