78
15 DMS Metadata Provisioning
According to the OWS-9 RFQ Annex B, the following requirements have been identified for metadata provisioning:
Investigate, test, demonstrate, and document the inclusion of arbitrary header and metadata fields in messages exchanged between DMS and clientdispatcher
Store information within fields to support data synchronization Store information within fields to support validation
Store information within fields to support filtering Store information within fields to support prioritization
Store information within fields to support security Store information within fields to support authoritativeness
Store information within fields to support data link SLA provisioning
15.1 Scope of Work
Arbitrary inclusion of headers for messages exchanged between DMS and Client is achieved through the use of SOAP as the underlying protocol. This simplifies the
specification, for instance for reliable communications, as standardized mechanisms, i.e. WS-ReliableMessaging can be leveraged for use by the DMS.
15.1.1 Reliable Messaging Metadata
The WS-ReliableMessaging metadata are defined in the schema located at the following URI:
http:docs.oasis-open.orgws-rxwsrm200608wsrm-1.1-schema-200608.xsd Some message exchange examples following this schema is provided in Section 9.2.2.
15.1.2 Validation Metadata
Generation of metadata by the Validation Module occurs when a client has configured the Validation Module to flag non-valid messages before they are transmitted to the
client. The metadata is inserted into the SOAP message headers for interception by the client. Any example of the metadata date generated by the Validation Module is
provided below:
79 ValidFalseValid --- Non-valid message metadata tag
15.1.3 Provenance Metadata
The generation of provenance metadata by the Provenance Module follows the guidance of the ISO1911519139 standard. An example of the metadata generated by the
Provenance Module is given below:
ns2:LI_Lineage ns2:LI_ProcessStep id=PUBLISHER
... ns2:description
ns3:CharacterStringpublication of feature datans3:CharacterString
ns2:description ...
ns2:CI_ResponsibleParty ns2:organisationName
ns3:CharacterStringCOMSOFT GmbHns3:CharacterString
ns2:organisationName ...
ns2:LI_ProcessStep id=FILTER
ns2:description ...
ns2:CI_ResponsibleParty ns2:organisationName
ns3:CharacterStringHarrisCorporationns3:CharacterString ns2:organisationName
... ns2:description
... lt;-- Strip white space from all elements --gt;
lt;-- Copy the xmlover and perform further processing below lt;-- Remove allgml namespace nodes --gt;
lt;-- Remove all line breaks --gt; lt;-- Remove all self closing nodes--gt;
lt;-- Remove all empty nodes--gt;
15.1.4 Filtering Metadata
The DMS may proceed to the following actions that would require metadata provision: Extraction
Densification Provider selection
Extraction and Densification may imply feature modifications; therefore the metadata associated may belong to provenance metadata.
80 Regarding provider selection, the DMS shall be able to add metadata to the message,
stating the list of initial providers in concurrence and the provider that was eventually selected based on the client’s choices.
Those have not been implemented in OWS-9 and may could be considered for future work, if their relevance is confirmed.
16 AIXMWXXM Metadata Compliance
The AIXMWXXM Metadata Compliance is a requirement for the Provenance Tracking Module and the Operator Configuration Module. The provenance metadata generated by
the Provenance Tracking Module and the Operator Configuration Module must conform to ISO 19115 and ISO 19139 requirements which is in line with the metadata
representation of AIXM and WXXM. Developing the metadata generated by the Provenance Tracking Module and the Operator Configuration Module to be in line with
the AIXM and WXXM metadata profile currently under development will allow for compatibly.
17 Appendix: Systems Rules Model Analysis
This section details each of the systems rules models and the analysis behind each of the requirements outlined in the RFQ Section 10 Appendix. The basis of analysis is from an
FAA SWIM Harris NEMS perspective as well as a SESAR SWIM perspective. Harris services the FAA NAS SWIM program office through the deployment of the NAS
Enterprise Messaging Service NEMS. The NEMS is the implementation of the SWIM enterprise service within the NAS.
The SESAR SWIM perspective is represented by ATMOSPHERE and TriaGnoSys.
17.1 SRM 10.1 – Maintain Data Synchronization between Ground and Aircraft Users
