INSPIRE Data Specifications What s new? What s next?

Transcription

1 INSPIRE Data Specifications What s new? What s next? Michael Lutz INSPIRE Conference 25 th June 2013, Firenze Serving society Stimulating innovation Supporting legislation

2 What s new?

3 Key pillars of data interoperability Conceptual data models Encoding Harmonised vocabularies Registers spatial objects and their properties and relationships for 34 data themes cross-domain harmonization based on a common modelling framework managed in a common UML repository GML application schemas as standard encoding conceptual models independent of concrete encodings also possible to derive other encodings (e.g. based on RDF) to overcome interoperability issues caused by free-text and/or multilingual content allow more specific terms from local vocabularies in addition to the harmonized terms provide unique and persistent identifiers for resources allow their consistent management and versioning items can be made unique and referred to unambiguously

4 Coverages Describe characteristics of realworld phenomena that vary over space and/or time, e.g. temperature, elevation, land cover, imagery Contain sets of such values, each associated with one of the elements in a spatial and/or temporal domain Typical spatial domains are point sets (e.g. sensor locations) and grids (e.g. orthoimages, elevation models), etc.

5 Coverages Used in several Annex II+III themes, e.g. AC-MF, OF, ER, EL, NZ, OI, LU, LC Only used where they are an established and accepted practice in the thematic community Common coverage model includes rectified grid coverages referenceable grid coverages time series (covered by reference to WaterML) Encoding rules for TIFF (EL, OI) and jpeg2000 (OI) Ongoing discussions on extending D2.7 Encoding Guidelines for coverage encodings

6 INSPIRE O&M Guidelines ISO provides a generic framework, but there are many ways of utilizing the core structures Guidelines for the use of O&M and SWE-related standards in INSPIRE (D2.9) Determine requirements for O&M within INSPIRE Provide recommendations for using O&M in INSPIRE Ensure that O&M is used consistently within INSPIRE O&M used in several themes, e.g. GE, OF, AC-MF, EF, SO class Figure 2: Observation Core +thegf_featuretype 1 +carrierofcharacteristics 0..* «metaclass» GF_FeatureType «instanceof» «FeatureTyp... GFI_Feature «metaclass» GF_PropertyType {root} «FeatureType» OM_Process «FeatureType» +featureofinterest Domain OM_Observation + phenomenontime :TM_Object +propertyvalueprovider + resulttime :TM_Instant 0..* + validtime :TM_Period [0..1] + resultquality :DQ_Element [0..*] + parameter :NamedValue [0..*] 1 1 Phenomenon +observedproperty 1 +procedure ProcessUsed +generatedobservation 0..* Metadata MD_Metadata +metadata 0..1 constraints {observedproperty shall be a phenomenon associated with the feature of interest} {procedure shall be suitable for observedproperty} {result type shall be suitable for observedproperty} {a parameter.name shall not appear more than once} Range 0..* +relatedobservation 0..* «DataType» NamedValue + name :GenericName + value :Any +result «type» Any {root} Observ ationcontext + role :GenericName

7 INSPIRE O&M Guidelines General introduction of O&M concepts O&M design patterns by feature of interest / type of result INSPIRE-specific model extensions observable properties processes specialised observations observation references Annex: Harmonising the delivery of gridded data as observation results class Trajectory Observation TrajectoryObservation - sequential measurements along a curve. Each point has time, location, value. From WaterML «FeatureType» CVT_DiscreteTimeInstantCoverage observation::om_observation «Type» Timeseries::Timeseries + temporalextent :TM_Period constraints {temporalextent = domainextent (renamed)} +collection 0..* +point 1..* CVT_TimeInstantValuePair «DataType» «FeatureType» Timeseries::AnnotatedTimeValuePair coverageobservation:: OM_DiscreteCoverageObservation + geometry :TM_Position + value :Record constraints {geometry renamed time} {increasing in time} «FeatureType» Sampling Coverage Observation:: SamplingCov erageobserv ation observedproperty shall be consistent with result.rangetype featureofinterest.shap e shall be consistent with spatial components of result.domain phenomenontime shall be consistent with temporal component of result.domain «datatype» TimeLocationValueTriple + location :GM_Position «featuretype» TrajectoryObservation result must be a TimeSeries /* result must be a TimeSeries */ inv: self.result.ocliskindof(timeseries) result.point must be TimeLocationValueTriple /* each point in the result must be a TimeLocationValueTriple */ inv: self.result.point.ocliskindof(timelocationvaluetriple) featureofinterest must be a SF_SamplingCurve /*featureofinterest must be a SF_SamplingPoint*/ phenomenontime must be a TM_Period /* phenomenontime must be a TM_Period */ inv: self.phenomenontime.ocliskindof(tm_period)

8 Additional models Base types for referring to documents and legal acts thematic identifiers Common base model for activity complexes used in AF, PF, US Zoned geographical grid Maritime units and boundaries

9 Encoding Encoding guidelines (D2.7) updated during Annex II+III development Minor changes in the encoding rule references to code list values association classes New informative annex on implementation of identifiers using URIs in INSPIRE FAQ: Several projects developing RDF vocabularies based on INSPIRE data models

10 Code lists Code lists for spatial data already exist and should be reused in INSPIRE (wherever possible) Key principle: Extensibility Code lists are extensible where no agreed code lists or classifications exist in the domain code lists or classifications in a specific domain are subject to frequent changes (e.g. addition of values) code lists in a specific domain are hierarchical Extensibility gives data providers the possibility to use more specific (national or local) values

11 Code lists in the IRs 4 types of INSPIRE code lists according to extensibility a) not extensible only values included in IRs are allowed b) narrower extensible values included in IRs and narrower values are allowed c) freely extensible values included in IRs and any other values are allowed d) empty any values are allowed For code lists of types (b), (c) and (d), additional values have to be published in a register TG may include additional proposed values that will be published in the INSPIRE code list register

12 Registers EC will provide central registries for INSPIRE resources First prototype published on Joinup & registers: code lists, themes, application schemas browsing and accessing register content Formats: HTML, XML, Atom, JSON and RDF/SKOS Multilingual content (based on IR content) Features considered for future releases additional registers: Feature Concept Dictionary, Glossary access through a SPARQL endpoint. adding querying facilities Open to external contributions

13 Feedback

14 Key pillars of data interoperability Conceptual data models Encoding Harmonised vocabularies Registers spatial objects and their properties and relationships for 34 data themes cross-domain harmonization based on a common modelling framework managed in a common UML D2.5: repository Generic Conceptual Model GML application schemas as standard encoding conceptual models independent of concrete encodings also possible to derive other encodings (e.g. to overcome interoperability issues caused by free-text and/or multilingual content allow more specific terms from local vocabularies in addition to the harmonized terms provide unique and persistent identifiers for resources described in INSPIRE Conceptual Framework documents D2.6:Methodology based on RDF) for Specification Development D2.7: Guidelines for Encoding D2.9: O&M Guidelines allow their consistent management and versioning items can be made unique and referred to unambiguously D2.10.3: Common data models

15 What s next?

16 INSPIRE maintenance & implementation framework Moving into the implementation phase Important to preserve the investment and the wealth of knowledge Main principles Maintain participatory approach Based on implementation experience Cross-cutting coherence Commission Expert Group on INSPIRE Implementation and Maintenance (MIG) Continuity of expertise pool of experts

17 Overview NCPs nominate representatives EC EEA NL ET UK PL PT... Commission expert group on INSPIRE maintenance and implementation (MIG)

18 Overview INSPIRE stakeholders nominate experts Registers Communication NCPs nominate representatives NS M&R DS DSS MD EC EEA NL ET Pool of experts UK PL PT... Commission expert group on INSPIRE maintenance and implementation (MIG)

19 Overview INSPIRE stakeholders nominate experts Registers Communication NCPs nominate representatives EC EEA NL ET set up & select experts DSS M&R MD NS DS Pool of experts Sub-group (e.g. for a dedicated maintenance task) UK PL PT... Commission expert group on INSPIRE maintenance and implementation (MIG)

20 MIG Tasks Exchange of experience and good practice related to the implementation of the INSPIRE Directive and IRs Identify and give advice about the priority issues to be addressed in the maintenance of the INSPIRE Directive, IRs and/or TG documents Identify issues related to INSPIRE implementation and advise the Commission on how to address them Prepare and regularly update the rolling work programme to be agreed by the INSPIRE Committee and the Commission

21 Pool of experts Call for participation published on 21 June Registration will be open from 8 July Tasks Ad-hoc input to discussions related to INSPIRE implementation Help answering questions related to implementation Share implementation experiences Promote INSPIRE-related activities Participate in sub-groups set up by the MIG to address specific maintenance or implementation tasks based on M&I work programme sub-groups to be disbanded once tasks is completed ToR to be defined by the MIG

22 Thank you Questions?

23 Conceptual data models Encoding Harmonised vocabularies Registers spatial objects and their properties and relationships for 34 data themes cross-domain harmonization based on a common modelling framework managed in a common UML repository GML application schemas as standard encoding conceptual models independent of concrete encodings also possible to derive other encodings (e.g. based on RDF) to overcome interoperability issues caused by free-text and/or multilingual content allow more specific terms from local vocabularies in addition to the harmonized terms provide unique and persistent identifiers for resources allow their consistent management and versioning items can be made unique and referred to unambiguously

24 Conceptual data models Encoding Harmonised vocabularies Registers spatial objects and their properties and relationships for 34 data themes cross-domain harmonization based on a common modelling framework managed in a common UML repository GML application schemas as standard encoding conceptual models independent of concrete encodings also possible to derive other encodings (e.g. based on RDF) to overcome interoperability issues caused by free-text and/or multilingual content allow more specific terms from local vocabularies in addition to the harmonized terms provide unique and persistent identifiers for resources allow their consistent management and versioning items can be made unique and referred to unambiguously

25 Conceptual data models Encoding Harmonised vocabularies Registers spatial objects and their properties and relationships for 34 data themes cross-domain harmonization based on a common modelling framework managed in a common UML repository GML application schemas as standard encoding conceptual models independent of concrete encodings also possible to derive other encodings (e.g. based on RDF) to overcome interoperability issues caused by free-text and/or multilingual content allow more specific terms from local vocabularies in addition to the harmonized terms provide unique and persistent identifiers for resources allow their consistent management and versioning items can be made unique and referred to unambiguously

26 Conceptual data models Encoding Harmonised vocabularies Registers spatial objects and their properties and relationships for 34 data themes cross-domain harmonization based on a common modelling framework managed in a common UML repository GML application schemas as standard encoding conceptual models independent of concrete encodings also possible to derive other encodings (e.g. based on RDF) to overcome interoperability issues caused by free-text and/or multilingual content allow more specific terms from local vocabularies in addition to the harmonized terms provide unique and persistent identifiers for resources allow their consistent management and versioning items can be made unique and referred to unambiguously