Metadata references
Not logged in

back to XmlBlob main page

Metadata references - a practical example

The example use case is from ISO19115 H.2.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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

idmd_scopemetadatafileIdparentId
0undefinedBLOB sz=4 UNKNOWN typeNULLNULL
1series XmlBLOB-ISOmetadataNULLNULL
2dataset XmlBLOB-ISOmetadataNULLNULL
3dataset XmlBLOB-ISOmetadataNULLNULL
4attributeType XmlBLOB-ISOmetadataNULLNULL
5feature XmlBLOB-ISOmetadataNULLNULL
6attribute XmlBLOB-ISOmetadataNULLNULL

the ISO_metadata_reference table

reference_scopetable_namecolumn_namerow_id_valuetimestampmd_file_idmd_parent_id
tablebridgesundefined-12013-02-07T15:29:0510
tableroadsundefined-12013-02-07T15:29:0610
tablebridgesundefined-12013-02-21T09:12:2521
tableroadsundefined-12013-02-21T09:12:2621
tableroadsundefined-12013-02-27T15:32:3232
columnroadsoverhead_clearance-12013-03-04T11:13:0743
row/colbridgesundefined12342013-03-08T16:51:4752
row/colbridgesoverhead_clearance12342013-03-15T12:21:1765

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)

idmd_scopemetadatafileIdparentId
0undefinedBLOB sz=4 UNKNOWN typeNULLNULL
1series XmlBLOB-ISOmetadata953c408a-4f56-45ae-88b2-ede53c5b9098NULL
2dataset XmlBLOB-ISOmetadata3144581b-725e-46a4-8ea3-077fc3ec5d99953c408a-4f56-45ae-88b2-ede53c5b9098
3dataset XmlBLOB-ISOmetadatae20d9943-009f-4665-8d29-c7ee2a3a0f223144581b-725e-46a4-8ea3-077fc3ec5d99
4attributeType XmlBLOB-ISOmetadata3848723f-87cd-4569-8b60-75a64f0acccce20d9943-009f-4665-8d29-c7ee2a3a0f22
5feature XmlBLOB-ISOmetadatadd467e4f-73b2-4c65-87e8-1cf565cc89e33144581b-725e-46a4-8ea3-077fc3ec5d99
6attribute XmlBLOB-ISOmetadata673e43c9-6392-4b26-89ab-5f112c55bde3dd467e4f-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