79447de7b01b9730c76a1101c970eb8b.ppt
- Количество слайдов: 107
A Proposal for a Reference Implementation of the WMO Core Metadata Profile based on ISO-19115/19139 by Jeremy Tandy, UK Met Office Jürgen Seib, Deutscher Wetterdienst Michael Burek, National Center for Atmospheric Research 3 rd May 2006 Page 1
A revised WMO Core Metadata Profile § WMO Core Metadata Profile … ISO 19115 compliant? (also note that the standard itself has undergone some revision: ISO 19115: 2003/Cor. 1: 2006) § Motivation § version 0. 2 is NOT compliant to ISO 19115 § XML schemas of version 0. 2 are ‘bespoke’ § UML model for WMO extensions does NOT exist Page 2
ISO 19115 compliance § WMO Core Profile v 0. 2 breaks the extension rules defined in ISO 19115 Annex C § § WMO encoding does not match ISO 19115 Changes to ISO 19115 (extensions) not in WMOgoverned namespace § Examples: § Cardinality restricted § Optional attributes removed § … and much worse … (DQ_Data. Quality) § Page 3 Further issues were noted in the WMO IPET-MI report prepared by Clemens Portele
A revised WMO Core Metadata Profile § Characteristics of WMO metadata documents § simple § human readable § (optionally) self-contained; i. e. the metadata record *should* be able to be expressed as a single document § multilingual § XML-validity should imply semantic correctness § ISO 19115 compliant ‘community profile’ Page 4
ISO 19115 - Extensions § How do we create an ISO 19115 compliant metadata profile? § § Guidance: § ISO 19115 Annex C: Metadata extensions and profiles § ISO 19115 Annex F: Metadata extension methodology In order to ensure interoperability beyond the community where the extensions are implemented: a) You must document the extension via the ‘extension metadata’ described in ISO 19115, and b) Add an iso. Type attribute to the class indicating which ISO 19115 class was sub-classed Page 5
ISO 19115 Clause C. 2: Types of extensions § adding a new metadata section § creating a new metadata code list to replace the domain of an existing metadata element that has “free text” listed as its domain value § creating new metadata code list elements (expanding a code list) § adding a new metadata element § adding a new metadata entity § imposing a more stringent obligation on an existing metadata element § imposing a more restrictive domain on an existing metadata element Page 6
ISO 19115 Clause C. 4: Rules for creating an extension § the name, definition or data type of an existing element can not be changed § a new element may include extended and existing metadata elements as components § metadata elements can be more stringent § domains can be more restrictive § the use of domain values can be restricted § code lists of type «Code. List» can be expanded § an extension shall not permit anything not allowed by the standard Page 7
Rules for creating a profile § check registered profiles § adhere to the rules for defining an extension § A profile shall include: § the core metadata § all mandatory metadata elements § all conditional metadata elements, if the dataset meets the condition § use UML diagrams to describe a profile § use your own namespace § publish the profile Page 8
WMO namespace § namespace: collection of names, identified by an URI reference § is needed for extensions § XML schemas of WMO extensions should reside in the http: //www. wmo. int/metadata/2006 namespace xmlns: wmo = “http: //www. wmo. int/metadata/2006” Page 9
So where do we go from WMO Core v 0. 2? 1. From the extension rules it’s clear that WMO Core v 0. 2 has problems 2. Furthermore, even *before* we extend ISO 19115 we need to identify an XML encoding of the content model § ISO 19115 is an ‘abstract specification’ … § IT specifies what information is required but not how to encode it § We developed our own XML encoding of ISO 19115 – as did many others § Interoperability is impaired by having numerous inconsistent encodings of ISO 19115 … Page 10
The ISO standard 19139 § XML schema implementation for ISO 19115 § provides a common specification for describing, validating and exchanging metadata § defines implementation guidelines for general-purpose metadata § includes XML schema implementations of other ISO 191 xx series (including ISO 19136 / GML) according to ISO 19118 ‘Geographic Information – Encoding’ F fulfils 99% of the needs for a WMO metadata standard Page 11
WMO metadata profile – key elements § Whilst ISO 19139 resolves a ‘large proportion’ (99%? ) of metadata-related concerns from the WMO community … there are still a number of outstanding elements worthy of discussion: 1. 2. 3. 4. 5. Time Internationalisation / multilingual support Codelists and keywords Service metadata Catalogues – incl. Feature Catalogues Page 12
The future? § § Whilst it is recommended that we adopt ISO 19139 as the ‘default’ encoding for WMO Core metadata … We must ensure that WMO Core is fit for purpose within the WMO community – § § § Page 13 where the existing ISO standard information models and encodings are not appropriate we should *adapt* them to our needs (e. g. ISO 19111 and parametric spatial referencing systems) The ISO standards are still in flux; so long as we *engage* with ISO/TC 211 we can adapt the standards to suit WMO This ‘profile’ is a *big* step forward, but it should not be considered a final version … it will continue to evolve
ISO 19118 Geographic Information - Encoding § ISO 19118 “Geographic information – Encoding” specifies rules for encoding geographic information … i. e. converting from the UML model to XML schema § ISO 19139 Clause 8 presents a good ‘summary’ in relation to encoding the ISO 19115 information model Page 14
ISO 19139 – Encoding summary (1) § Each UML class is encoded into 3 XML constructs: 1. XML Class Type (XCT) § describing the content (attributes) of the UML class 2. XML Class Global Element (XCGE) § ensuring the class has global visibility within the XML schema for ‘import’ etc. 3. XML Class Property Type § containment of a class is managed through the XML Class Property Type of it’s data type, enabling both “by Value” and “by Ref” implementations of content § Note: when an XCT is of xs: simple. Type, “by Ref” is not permitted Page 15
ISO 19139 – Encoding summary (2) § Naming conventions: § § § UML class XCT XCGE XCPT » Class 1_Type » Class 1_Property. Type Special case encodings: § § Abstract classes Inheritance and sub-classes Note: to achieve interoperability only ‘extension’ sub-classing (i. e. adding attributes) is permitted – restriction and multiple inheritance are not allowed § § § Page 16 Enumerations Codelists Unions
Polymorphism and substitution groups (1) § § § Polymorphism: the ability to assume different forms Example: [CI_Responsible. Party] » individual. Name [Character. String] could be specialized such that ‘name’ is compartmentalized into first and last names Polymorphism provides communities with a mechanism to better refine metadata to meet organizational need individual. Name is extended within a ‘community’ namespace … § whilst still utilizing ISO 19139 schemas (gmd namespace), and § still providing usable & understandable instance documents § Page 17 In OO, the specialized class “is a” type of the general class; e. g. a dog “is a” type of animal
Polymorphism and substitution groups (2) § § § The “is a” relationship implies semantic consistency & substitutability ISO 19118 *only* permits simple (extension-only) subclassing / specialization ISO 19139 allows polymorphism primarily though the _Property. Type encodings; e. g. gmd: PT_Free. Text_Property. Type is substituted for the more general gco: Character. String_Property. Type for multi-lingual support § Need to inform the XML parser of the substitution: a) via a substitution. Group directive in the schema, OR b) via a xsi: type directive in the instance document Page 18
GML pattern: by-value or by-reference (1) § GML properties are defined such that the ‘content’ can be referenced EITHER § § ‘by-value’ within the scope of the containing XML element, OR ‘by-ref’ (xlink) to an instance of the content residing elsewhere; either within the document or external
GML pattern: by-value or by-reference (2) § Example - from an “observations & measures” GML instance
GML pattern: object-type-object-type ‘striping’ object type object Page 22
Interoperability outside WMO community § § Users outside WMO community will (probably) NOT understand WMO extensions … Need to ‘remove’ them? ? ? Document with WMO extensions XSL Transformation Document without WMO extensions Page 23
Open Issues § § Worked examples & implementation test-bed Finalize extensions § which are required? Time, Service. Identification etc. § encode as ISO 19118 -compliant XML schema § ISO 19115 / 19139 have a multitude of options for describing information … which makes writing parsing applications complex § § Page 24 do we need to *restrict* WMO Core metadata? ISO/TC 211 & OGC community peer review
Thank you Page 25
Explanation of times for observations and simulations Encoding in ISO 19115 / 19139 metadata April 2006 © Crown copyright 2006 Page 27
Times relevant to a observations … a single observation … i (t ) Ti m e (t e iss ue im ev en t. T (Often referred to as “valid. Time” within GML schemas) e) Time at which the observation ‘event’ occurred (from om: Event) Observation Time at which the observation was published / issued … allowing for amendments to a previously published observation (we need to extend O&M for this) Time in the “real world” Default temporal reference system: ISO-8601 (Gregorian calendar) real time axis (t) event. Time encoded in ‘Observations & Measures’ as:
Time interval relative to the observation time for calculating accumulations, averages etc. time interval i (t ) e m Ti iss ue ev e nt Ti m e (t e) Times relevant to a observations … what about accumulations? … real time axis (t) An ‘instantaneous’ observation is conceptually simple; e. g. measuring temperature at a specific instant in time However, what about accumulations (or averages etc. ) … e. g. measuring a 3 -hr average temperature? We assert that you can’t evaluate the average until the end of the 3 -hr period. We assert that the time interval is a property of the measured phenomena (a 3 -hr average) & the event. Time (te) of observation occurs at the end of the time interval. © Crown copyright 2006 Page 31
Times relevant to a observations … what about maxima & minima? … Temperature fluctuation during time interval (t e) e im t. T ev en Related observation: temperature recorded at time instant Time instant at which the maximum temperature occurs during the time interval Primary observation: Maximum temperature recorded during time interval x real time axis (t) time interval The primary observation (in this example) is the maximum temperature during a time interval. The maximum temperature cannot be evaluated until the end of the time interval. We assert that the time interval is a property of the measured phenomena (a daily maximum) & the event. Time (te) time of observation occurs at the end of the time interval. In many cases, the exact instance when the maximum temperature occurred cannot be determined. However, automated weather stations now offer near-continuous measurement & can record the time instant that an event (i. e. the maximum temperature) occurred. We assert that the maximum temperature ‘event’ can be modelled as a related observation. © Crown copyright 2006 Page 32
) e (t e im en t. T ev co lle cti on Pe r iod Times relevant to a observations … what about collections of obs? … real time axis (t) collection. Period is the time interval bounding all discrete observations within the collection (note: this would probably be encoded as an element of the spatio -temporal bounding box for the collection) © Crown copyright 2006 Page 33
Which time values are needed in observation feature types? Time properties: event. Time (te) Time at which the observation event occurred Not valid: issue. Time (ti) time interval Time at which the observation was published … allowing for amendments (for calculating accumulations, averages, max/min etc. ) part of the ‘phenomenon’ definition collection. Period Time interval bounding all discrete observations within the collection (where appropriate) © Crown copyright 2006 Page 34
Time metadata in ISO 19115 (1) © Crown copyright 2006 Page 35
Time metadata in ISO 19115 (2) © Crown copyright 2006 Page 36
Encoding event. Time in ISO 19115 & ISO 19139 For a single observation, or a collection of observations with a common event. Time (te) … metadata [MD_Metadata] » identification. Info [MD_Data. Identification] » extent [EX_Extent] » temporal. Element [EX_Temporal. Extent] » extent [TM_Instant] © Crown copyright 2006
Encoding collection. Period in ISO 19115 & ISO 19139 For a collection of observations spanning multiple times, collection. Period … metadata [MD_Metadata] » identification. Info [MD_Data. Identification] » extent [EX_Extent] » temporal. Element [EX_Temporal. Extent] » extent [TM_Period] © Crown copyright 2006
Encoding issue. Time in ISO 19115 & ISO 19139 issue. Time … metadata [MD_Metadata] » date. Stamp [Date] metadata [MD_Metadata] » identification. Info [MD_Data. Identification] » citation [CI_Citation] » date [CI_Date] » date [Date] date. Type [CI_Date. Type. Code] edition [Character. String] {creation, publication, revision} edition. Date [Date] Problem: • date field only … • in meteorology we need to differentiate on smaller time scales • EITHER 1. extend metadata standard, OR 2. use ‘edition’ information to capture metadata information for amends etc.
Indeterminate times in GML – ISO 19136 Inexact temporal positions may be expressed using the optional indeterminate. Position attribute. This takes a value from an enumeration defined as follows:
Times relevant to a simulation … time in the real world … e i im t. T en ev (t ) e Ti m ue iss tio n cr ea da tu m Ti m e Ti (t m e c) (t (t e) Time at which the simulation was executed d) The ‘origin’ (datum) time used in the simulation Time of an ‘event’ that has been simulated … i. e. a ‘simulated’ observation Time at results of the simulation were published / issued x time axis (t) © Crown copyright 2006 Page 41
• the analysis is produced at the end of the assimilation period • the analysis. Time (ta) corresponds with the datum. Time (td) e) (t e im t. T ev en Consider a forecast … • the simulation is run to give a prediction from the datum. Time (td) to some arbitrary time in the future • however, the simulation begins earlier at the initialisation. Time (t 0)… allowing data to be assimilated into the simulation da an tum aly Tim sis e Ti (t m d) o e (t r a) Times relevant to a simulation … assimilation vs. prediction … x time axis (t) ini tia lis a tio n. T im e (t 0) assimilation period © Crown copyright 2006 Page 42
(t e im t. T ev en valid. Usage. Period may extend beyond the event. Time (te) us ag e Ex pir y. T im e e. P er iod d. U sa g va li rt. T e. S ta us ag da tu m Ti im m e e (t e) d) Times relevant to a simulation … usage periods … x time axis (t) valid. Usage. Period is the interval during which the results of the simulation should be used. Most often, simulation results do not have a valid usage period. However, we must include the concept as it is required for TAFs Whilst not obvious, the issue. Time (ti) and the start of the usage period do not need to coincide © Crown copyright 2006 Page 43
(t ) e) fin al. T im e f (t e im t. T Collection of discrete simulation result-sets that share the same Datum. Time ev en cti o lle co da tu m Ti m e (t d) n. P er iod A set of results from a simulation (a ‘model run’) End of the simulation … final. Time (tf) x time axis (t) © Crown copyright 2006 Page 44
simulation. Datum. Time (Td) The origin time for the simulation; e. g. T+0 e im t. T ev en Ti tu m Temporal coordinate reference system defined locally for the simulation using
Example encoding of a local temporal reference system Temporal coordinate reference system (hours since midnight UTC 9 th March 2006) encoded as:
Which time values are needed in simulation ‘metadata’? (at least for operational meteorology!) initialisation. Time (t 0) datum. Time (td) or analysis. Time (ta) creation. Time (tc) issue. Time (ti) ‘simulation’ metadata usage. Start. Time ‘publication’ metadata valid. Usage. Period usage. Expiry. Time event. Time (te) simulated. Time (Ts) primary metadata final. Time (tf) collection. Period © Crown copyright 2006 Page 47
Encoding primary time metadata in ISO 19115 & ISO 19139 (1) event. Time (te) simulated. Time (Ts) collection. Period Encode as for observations … except you *may* want to use two temporal extent definitions to describe time instants in both ‘Gregorian’ and ‘simulated’ reference frames © Crown copyright 2006
Encoding primary time metadata in ISO 19115 & ISO 19139 (2) event. Time (te) simulated. Time (Ts) Problem: 1. it *may* be difficult for parsers to differentiate between multiple temporal extents; e. g. when attempting to build an index on the content of the metadata record 2. there is no convenient placeholder for the local temporal reference system definition • • © Crown copyright 2006 it *may* be necessary to extend the ISO 19115 metadata standard to allow alternate time extents to be specified, along with their local reference system definition use a ‘similar’ pattern to expressing multi-lingual alternatives for character strings … Page 49
Encoding ‘publication’ time metadata in ISO 19115 & ISO 19139 usage. Start. Time creation. Time (tc) valid. Usage. Period issue. Time (ti) usage. Expiry. Time Encode as for observations metadata [MD_Metadata] » identification. Info [MD_Data. Identification] » citation [CI_Citation] » date [CI_Date] » date [Date] date. Type [CI_Date. Type. Code] edition [Character. String] {creation, publication, revision} edition. Date [Date] employing the CI_Date. Type. Code to describe the ‘type’ of the publication © Crown copyright 2006 Encode valid. Usage. Period as
Temporal usage constraints – extension required to ISO 19115? ISO 19115 defines constraint information; the metadata required for managing rights to information including restrictions on access and use. The metadata entity seems the most appropriate placeholder for temporal usage constraints … however, ISO 19115 only details: • MD_Legal. Constraints • MD_Security. Constraints To record temporal usage constraints in the metadata record, we will need to extend ISO 19115; e. g. WMO_Temporal. Usage. Constraints Question: is this type of metadata required in WMO core? © Crown copyright 2006 Page 53
Encoding ‘simulation’ time metadata in ISO 19115 & ISO 19139 initialisation. Time (t 0) datum. Time (td) or analysis. Time (ta) final. Time (tf) These metadata elements are artefacts of the numerical simulation itself. Furthermore, there are potentially many more metadata elements which *may* prove useful to discriminate between datasets (e. g. ensemble. ID) … ensemble. ID © Crown copyright 2006 The British Atmospheric Data Centre (BADC) are working on an ISO 19115 extension to define metadata about numerical simulations: http: //proj. badc. rl. ac. uk/ndg/wiki/Num. Sim Page 54
NDG Num. Sim extension Numerical Simulation Discovery Metadata (aka Num. Sim) The DIF describes datasets at the discovery level, but where simulations are involved, discovery metadata needs more information than is available in existing schema. A new schema which is being trialled at the BADC should be accessible to both DIF and ISO 19115 parent discovery schema, although at the moment it is rather standalone. … Proposal: WMO adopts Num. Sim as a formal mechanism for describing simulation metadata within WMO Core metadata profile. Prior to adoption, WMO should liaise with BADC to ensure the profile is fit for purpose and has been rigorously tested. © Crown copyright 2006 Page 55
Thank you © Crown copyright 2006 Page 56
Implementing codelists by Jeremy Tandy, UK Met Office Jürgen Seib, Deutscher Wetterdienst 3 rd May 2006 Page 57
Codelists § § § A permissible extension of ISO 19115 is that ‘free text’ content can be restricted by the use of a codelist Furthermore, existing codelists can be extended by adding more terms to the list Note that this is NOT possible with enumerations – an enumeration is NOT extensible § An «Enumeration» is implemented as an XML schema enumeration list § § A «Codelist» is implemented as a codelist catalogue file WMO Core profile v 0. 2 identified a small number of *new* code lists Page 58
ISO/TS 19139: 2005(E) – Clause 8. 5. 5 Codelist encodings (1) § § Page 59 A class that is stereotyped Code. List is an enumerated type like a class that is stereotyped Enumeration. The difference is that the <
ISO/TS 19139: 2005(E) – Clause 8. 5. 5 Codelist encodings (2) The last point is the crucial *implementation* issue … § Values of a codelist are NOT encoded in the schema (as is the case for an enumeration) § Codelist values are stored in some external register Issue: XML validation CANNOT verify codelist entries Page 60
Implementing code lists: alternative § define all WMO code lists of type «enumeration» § Issues: 1) Enumeration does not support multi-language 2) Codelists as enumerations is INFLEXIBLE … it does not permit extension (or local extension) … refer to complexity regarding BUFR 3) XML schema gives SYNTACTIC interoperability via XML schema validation … we need SEMANTIC interoperability via application-level parser Page 61
ISO 19139 Codelist schema Where codelists are referenced from within a metadata record, the following XML type is used:
Codelist implementation example – CI_Date. Type. Code (1) The XML global element corresponding to CI_Date. Type. Code:
Codelist implementation example – CI_Date. Type. Code (2)
WMO metadata profile codelist extensions § Page 65 WMO Core profile v 0. 2 identified a small number of *new* ‘code lists’: § WMO topic categories «enumeration» § WMO keywords «thesaurus» § WMO data frequency code «codelist» § WMO member countries «codelist»
Code lists: WMO topic categories § MD_Topic. Category. Code far too restrictive … § Create new WMO specialisation: WMO_Community. Topic. Category. Code (as proposed in WMO Core v 0. 2) Page 66
Example: WMO topic categories
SIMDAT: metadata directory structure (1) § SIMDAT (phase 1) employed WMO Core Metadata v 0. 2 §
Code lists: WMO keywords § MD_Keyword. Type. Code … § WMO Core v 0. 2 proposed a new WMO keyword list: WMO_Keyword. List (a VERY long list!) § WMO Core v 0. 2 expressed this as an enumeration … § Also put the actual keyword list *content* into the keyword *type* list (? ) Page 73
ISO 19139 keywords implementation § keyword … ‘free text’ field § type … from «MD_Keyword. Type. Code» codelist § classifies the type of keyword § does this codelist need extension? § thesaurus. Name … «CI_Citation» § identifies the ‘thesaurus’ that describes the permissible content of the keyword list § thesaurus. Name [CI_Citation] » identifier [MD_Identfier] » code [Character. String] can be used to express the URI of thesaurus / codelist … allowing linkage to URL or URN (alternative: substitute gmx: Anchor for gco: Character. String to reference the ‘thesaurus’) Page 74
WMO keyword – thesaurus implementation § Keyword thesaurus content (i. e. the list of keywords and their meanings) can be implemented as a) URN linkage to existing WMO code manuals urn: x-wmo: wmo. Manual: 306: synop ? ? ? (note: an application will need some additional, pre-defined context to dereference the URN) b) URL linkage to online catalogue; encoded according to the codelist catalogue pattern (see later) Page 75
Code lists: frequency values § MD_Maintenance. Frequency. Code too restrictive … § WMO Core v 0. 2 proposed an extended list: WMO_Data. Frequency. Code § expressed as an enumeration in WMO Core v 0. 2 Page 77
WMO_Data. Frequency. Code implementation § Standard codelist implementation … Global XML element …
WMO_Data. Frequency. Code example
Code lists: WMO member countries § The organisation responsible for various aspects of the metadata instance is defined thus: [CI_Citation] » cited. Responsible. Party [CI_Responsible. Party] » organisation. Name [Character. String] § WMO profile needs to formalise list of responsible organisations as the member countries of WMO_WMO-Member. Country. Code Page 81
WMO_WMO-Member. Country. Code implementation § Standard codelist implementation … Global XML element …
WMO_WMO-Member. Country. Code example
Member country list – alternative implementation § does not exist in WMO Metadata Profile v 0. 2 § should be implemented as an XML enumeration type
Member country list – alternative implementation
Thank you Page 86
Service metadata Encoding in ISO 19119 metadata May 2006 Page 87
Service metadata § WMO Core Profile key concern is describing *datasets* … Implication: § MD_Data. Identification is sufficient? § This is NOT the case … § § Where a dataset is described (i. e. via a WMO Core metadata record) you need to be able to identify the *service* by which you can *access* the data … Example: when a GISC ‘harvests’ metadata records from a DCPC (refer to plans for CBS Workshop demonstration Nov 2006) Page 88
Service metadata in ISO 19115 Page 89
ISO 19119: 2005 Geographic information - Services § § Page 90 Service metadata is described in ISO 19119 MD_Service. Identification is replaced with SV_Service. Identification The ISO standard discusses much more than simple *access* services … e. g. defining metadata constructs that can be used to describe service chaining Alternative service description standards (including WSDL) were deemed incomplete and insufficient
ISO 19119: 2005 UML model (1) Page 91
ISO 19119: 2005 UML model (2) Page 92
ISO 19119: 2005 – implementation (1) § § ISO 19119 seems to meet requirements But … 1. there is no ISO-ratified encoding (equivalent to ISO 19139) § although an incomplete (? ) ISO 19118 compliant XML encoding exists from OGC CSW initiative 2. there does not appear to be a place holder to reference pre -existing WSDL definitions § most implementation examples I have seen (OGC service offerings) have a WSDL definition in *parallel* to an ISO 19119 definition Page 93
ISO 19119: 2005 – implementation (2) § Best practice for WMO Core metadata? § § § Bind the service definition to the dataset via the operates. On relationship (via xlink reference) Set SV_Coupling. Type as ‘mixed’ Alternative ‘data access’ service binding? [MD_Distribution] » transfer. Options [MD_Digital. Transfer. Options] » on. Line [CI_Online. Resource] § Page 94 Extend CI_Online. Resource to hold SV_Service. Identification, wsdl: definition & default values / predefined queries?
ISO 19119: 2005 – implementation (3) § Incorporating WSDL service definitions? § Include *both* SV_Service. Identification and wsdl: definitions elements …
Default parameters / parameter ranges § § Page 96 SIMDAT (phase 1) implemented ‘bespoke’ service binding constructs ISO 19119 provides alternative implementation … Except for a mechanism for identifying “default” (fixed) values & ranges of values Extend ISO standard information model to cater for default values or range lists?
Thank you Page 97
Catalogues and registries by Jeremy Tandy, UK Met Office Jürgen Seib, Deutscher Wetterdienst 3 rd May 2006 Page 98
Feature catalogues § § § Current WMO Core best practice: dataset content identified via keywords Alternative: define content model as GML feature … a ‘feature type’ UK Met Office undertaking to develop GML feature types for meteorological information (http: //www. metoffice. gov. uk/informatics) § Page 99 Feature types are registered in a ‘feature catalogue’
Feature catalogue - implementation § § Best practice implementation for feature catalogues is ‘in flux’ ISO standards: § ISO 19110: Geographic information – Methodology for feature cataloguing (new work item) § ISO 19126: Geographic information – Profiles for feature data dictionary registers and feature catalogue registers § ISO 19135 Geographic Information – Procedures for registration of items of geographic information § Open Geospatial Consortium initiatives: § Page 100 MOTIIVE; INSPIRE-related project aiming to develop best practice methodology for implementing feature catalogues within registries
Supporting metadata § A key objective of IPET-MI is to define the schemas for WMO Core metadata … However, a number of resources are *external* to the metadata instances … § § § § § Page 101 Coordinate Reference System definitions Unit of Measure definitions Phenomena (parameter) definitions Codelists Keyword thesauri Feature catalogues Gazetteers Station lists
Registries and catalogues (1) § These ‘supporting’ metadata artefacts are registered in a *catalogue* or *registry* § § How do you implement a catalogue? § Page 102 Definition: a registry is a catalogue with *governance* Simple: § create an XML instance document containing the registered definitions & reference the content via hyperlinks § Issue: ‘brittle’ implementation – relies on fixed URLs … susceptible to ‘broken links’
Registries and catalogues (2) § § Page 103 Feature rich: § import the content into a *repository* and use a sophisticated registry to index the definitions, abstracting the *real* location of the documents, enabling the expression of rich content models and the traversal of associations between resources § Issue: complex implementation, limited reference implementations UK Met Office have undertaken to develop a registryrepository implementation based on OGC CSW and eb. RIM 3. 0; planned demonstration at CBS Workshop, Nov 2006
ISO 19139 catalogue implementation § 3 ‘concrete’ catalogue classes: 1. Coordinate Reference System 2. Unit of Measure 3. Codelist Page 104
ISO 19139 … codelist catalogue implementation § Page 105 Example: CT_Codelist. Catalogue
Codelist catalogue – XML encoding Also a ‘multi-lingual’ implementation available from ISO 19139 Page 106
Additional catalogues … CT_Centre. Catalogue Page 109 CT_Keyword. Catalogue CT_Station. Catalogue CT_Parameter. Catalogue
Volume A: observing stations § hierarchy: WMO region country § station name § station index number § latitude and longitude § elevation in metres § the elevation of the station (HP) § the elevation of the ground (H) or the official altitude of the aerodrome (HA) § pressure level in HPa § observation times § remarks Page 112
Catalogues: station catalogue Character. String (from Text) CT_Station. Catalogue <
Another UML model for stations WMO_Station 0. . * +station. Id +station. Name: Character. String +remarks[0. . 1]: Character. String <
Catalogues: station catalogue § Use
Catalogues: parameter catalogue CT_Parameter. Catalogue Meteorological. Element +name: Character. String +short. Name[0. . 1]: Generic. Name +unit. Of. Measure: Unit 1 +element 1. . * <
ISO 19112: 2003 - Geographic information — Spatial referencing by geographic identifiers Page 118
Gazetteer implementation – OGC 05 -035 (1) § § § Page 119 Within the OGC community there is a growing interest in the development of a common featurebased model for access to named features, often referred to as a gazetteer. OGC 05 -035 aims to implement a Gazetteer Service as a profile of the OGC Web Feature Service Gazetteer Service is a specialized profile of a Web Feature Service that specifies a minimum set of Feature. Types and operations required to support an instance of a gazetteer service
Gazetteer implementation – OGC 05 -035 (2) § By using the capabilities of a Web Feature Server, the Gazetteer Service as proposed here exposes the following interfaces to query location instances in a gazetteer database: § § Page 120 Get or Query features based on thesaurusspecific properties (broader term (BT), narrower term (NT), related term (RT) Retrieve properties of the gazetteer database, such as the location type class definitions and the spatial reference system definitions
Gazetteer implementation – interim § The Gazetteer Service (WFS-G) initiative has developed a set of ISO 19118 -compliant XML encodings for the ISO 19112 information model: § SI_Gazetteer «Feature. Type» § SI_Location. Instance «Feature. Type» § SI_Location. Type «Feature. Type» § … § § Recommendation: liaise with OGC regarding development of WFS-G Interim: use the ISO 19112 schema definitions to create a XML instance document for the gazetteer definitions & reference these via xlink from metadata instances § § Page 121 Simplementation Poor functionality (serving ONLY as a list)
Thank you Page 122


