AQD IPR pilot study programme on e-reporting

Transcription

1 AQD IPR pilot study programme on e-reporting Annual Assessments data flows and progress on UTD & AQ zones 5 th pilot meeting Copenhagen May 2012

2 Agenda Morning Pilot country experiences & discussion e-reporting code list & management e-reporting schema updates &management The INSPIRE e-reporting data model Overview & wrap up Afternoon Discussions as needed and travel plans allow

3 Code lists to support e-reporting Current practise Managed locally in the AQD schema We acknowledge this is not best practice It is an interim measure Local schemas are out of date Future management Managed centrally with other Eionet code lists URL New schema repository in SKOS

4 What is SKOS? Simple Knowledge Organization System (SKOS), a common data model for sharing and linking code list systems via the Web. Using SKOS, concepts can be identified using URIs labelled with text strings in one or more natural languages assigned notations (codes) documented with various types of notes linked to other concepts and organized into informal hierarchies and association networks aggregated into concept schemes grouped into labelled and/or ordered collections mapped to concepts in other schemes

5 Current code list implementation Requires updating Code lists becomes out of date very quickly Pilot Countries ETC/ ACM IPR Guidance Codelists New data flows Communication of updates needs management & documenting to trace requirements We need input from pilot countries on content modifications & updates

6 Code list management going forward Will be managed by EEA and ETC/ACM Out of date code lists limit/slow schema testing, updates soon please Core categories to review Ø Measurement methods Ø Sampling methods Ø Analytical techniques Ø Validity codes Ø Verification codes Ø Emissions sources Contributions from pilot countries a necessity

7 Code list management going forward Split Guidance updated code list available now & posted to the AQ portal shortly Is a AQ portal page for code list management updates required? How should we mange updates going forward? As new data flows come on line for test in 2012 the code list discussion will expand.

8 The AQD e-reporting schema Initial testing arising from 4 th pilot meeting raised schema queries 1. Is the this simplified AQD data model configuration a requirement of INSPIRE Answer from the INSPIRE drafting team was Yes, it has been constructed to accommodate cross (environment) domain requirements as presented to the INSPIRE EMF data specifications group AQ featured highly in the group compiling the EMF data specifications

9 The AQD e-reporting schema 2. Would / will alternative AQD data model architectures be compliant with INSPIRE data specifications? Answer from the INSPIRE drafting team was No. Question to the group arising from this is, can we live with this? What are the pilot group s main issues as of today?? Data model content?? Data model architecture?? Mapping of native (local) datasets to the AQD schema?? ETL issues with populating the data model?? Hierarchy / relationships within the data model?? Verification of the populated datasets

10 The AQD e-reporting schema 3. The AQD.xsd found at referenced namespaces as follows at line 3 xmlns:aqd=" targetnamespace=" These were interim references introduced by the schema compilers. Even so persistence in the XSD does not enable global referencing of schemas from Eionet online resources and prevented validation. The references have been substituted in the beta release (version 3.1) found at Version 3.1 is under evaluation by ETC/ACM and EEA Further updates to be introduced to this beta version

11 The AQD e-reporting schema 4. Queries arising whilst validating the XML deliveries against the AQD.xsd. Though no problems are obvious in XMLSpy, Python xsd validators will accept the xml. Questions arising:? Why insist that OM_Observation have to be within gml:featuremember when it is not part of the schema?? Why use GML when there is no exchange of spatial information - no coordinates?? Why does the schema refer to GML 3.2 where FeatureCollection and FeatureMember is deprecated?

12 The AQD e-reporting schema 4. Queries arising whilst validating the XML deliveries against the AQD.xsd. Though no problems are obvious in XMLSpy, Python xsd validators will accept the xml. Questions arising: OM_Observation is part of the schema and is also a GML feature. In order to provide multiple observations in one XML doc (or one service request) we need some sort of container, currently we are using gml:featuremember. Agree that in GML 3.2 this has been deprecated, an AQ_Collection should be derived using AbstractFeatureMemberType in the final schema. The version we are working with is out of date & much will require changing to meet the details of GML3.2.1 and INSPIRE e.g. the INSPIRE ReportingUnit is now also deprecated also Article 26 of the AQD requests provision of data via INSPIRE. A great deal of dat is spatial, so INSPIRE makes a lot of sense. What wouldn't make sense to my understanding would be to provide the spatial and measurement stuff via INSPIRE (i.e. GML), and then provide Assessmemt Regime and Attainment via a different standard.

13 The AQD e-reporting schema 4. Shouldn t we build one XSD file for each report type to describe the format of the report expected? Well, I can see the direction of this enquiry & it was my preference for a while but in terms of managing changes to the schema, no. Everything required for reporting is included in the schema. Perhaps the documentation & supporting information id not adequate yet, granted. 5. How are relationships between XML data blocks / elements represented without hierarchy in the XML. Using Xpointer to traverse xlink:href signposts to other parts of a document or other parts of an different document. <ef:observedproperty xlink:href="pm10"/> <ef:procedure xlink:href="process_1"/> < ef:featureofinterest xlink:href="samplingfeature_1"/>

14 Any Questions?