Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Artifact ID:	b410618e47bc449dbc8ebd05e8a3a1ca745d1de1
Page Name:	Metadata references
Date:	2013-03-18 17:46:14
Original User:	sandro
Parent:	6efda6c7f7784f8d8abb985580cb68610863ab7f (diff)

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

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