Upload
ethan-dobson
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
Page 1
A Proposal for a Reference Implementation of the WMO Core Metadata Profile based on
ISO-19115/19139
3rd May 2006
byJeremy Tandy, UK Met Office
Jürgen Seib, Deutscher WetterdienstMichael Burek, National Center for Atmospheric Research
Page 2
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 19115XML schemas of version 0.2 are ‘bespoke’ UML model for WMO extensions does NOT exist
Page 3
ISO 19115 compliance
WMO Core Profile v0.2 breaks the extension rules defined in ISO19115 Annex C
WMO encoding does not match ISO 19115 Changes to ISO 19115 (extensions) not in WMO-
governed namespace Examples:
Cardinality restricted Optional attributes removed … and much worse … (DQ_DataQuality)
Further issues were noted in the WMO IPET-MI report prepared by Clemens Portele
Page 4
A revised WMO Core Metadata Profile
Characteristics of WMO metadata documentssimplehuman readable (optionally) self-contained; i.e. the metadata record
*should* be able to be expressed as a single document
multilingualXML-validity should imply semantic correctness ISO 19115 compliant ‘community profile’
Page 5
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 isoType attribute to the class indicating which ISO 19115 class was sub-classed
Page 6
ISO 19115 Clause C.2: Types of extensions
adding a new metadata sectioncreating 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 elementadding 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 7
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 restrictedcode lists of type «CodeList» can be expandedan extension shall not permit anything not allowed by
the standard
Page 8
Rules for creating a profile
check registered profilesadhere to the rules for defining an extensionA 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 9
WMO namespace
namespace: collection of names, identified by an URI reference
is needed for extensionsXML schemas of WMO extensions should reside in the http://www.wmo.int/metadata/2006 namespace
xmlns:wmo = “http://www.wmo.int/metadata/2006”
Page 10
So where do we go from WMO Core v0.2?
1. From the extension rules it’s clear that WMO Core v0.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 11
The ISO standard 19139
XML schema implementation for ISO 19115provides a common specification for describing,
validating and exchanging metadatadefines implementation guidelines for general-purpose
metadata includes XML schema implementations of other ISO
191xx series (including ISO 19136 / GML) according to ISO 19118 ‘Geographic Information – Encoding’
fulfils 99% of the needs for a WMO metadata standard
Page 12
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. Time2. Internationalisation / multilingual support3. Codelists and keywords4. Service metadata5. Catalogues – incl. Feature Catalogues
Page 13
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 –
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
Page 14
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 15
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:simpleType, “by Ref” is not permitted
Page 16
ISO 19139 – Encoding summary (2)
Naming conventions: UML class » Class1 XCT » Class1_Type XCGE » Class1 XCPT » Class1_PropertyType
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
Enumerations Codelists Unions
Page 17
Polymorphism and substitution groups (1)
Polymorphism: the ability to assume different forms Example:
[CI_ResponsibleParty] » individualName [CharacterString] 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
individualName is extended within a ‘community’ namespace … whilst still utilizing ISO 19139 schemas (gmd namespace), and still providing usable & understandable instance documents
In OO, the specialized class “is a” type of the general class; e.g. a dog “is a” type of animal
Page 18
Polymorphism and substitution groups (2)
The “is a” relationship implies semantic consistency & substitutability
ISO 19118 *only* permits simple (extension-only) sub-classing / specialization
ISO 19139 allows polymorphism primarily though the _PropertyType encodings; e.g.
gmd:PT_FreeText_PropertyType is substituted for the more general gco:CharacterString_PropertyType for multi-lingual support
Need to inform the XML parser of the substitution:
a) via a substitutionGroup directive in the schema, OR
b) via a xsi:type directive in the instance document
Page 19
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
<xs:attributeGroup name="ObjectReference"> <xs:attributeGroup ref="xlink:simpleLink"/> <xs:attribute name="uuidref" type="xs:string"/></xs:attributeGroup>
<xs:attribute name="nilReason" type="gml:NullType"/>
<xs:complexType name="ObjectReference_PropertyType"> <xs:sequence/> <xs:attributeGroup ref="gco:ObjectReference"/> <xs:attribute ref="gco:nilReason"/></xs:complexType>
Page 20
GML pattern: by-value or by-reference (2)
Example - from an “observations & measures” GML instance
<om:location xlink:href="#ot2p"/>
<om:observedProperty xlink:href="urn:x-ogc:def:phenomenon:OGC:Species"/>
<om:featureOfInterest>
<om:Station gml:id="ot2s">
<gml:name>8903</gml:name>
<om:position>
…
</om:position>
</om:Station>
</om:featureOfInterest>
by-reference
by-value
Page 21
«xlink» semantics
<attributeGroup name="simpleLink"> <attribute name="type" type="string" fixed="simple"
form="qualified"/> <attribute ref="xlink:href" use="optional"/> <attribute ref="xlink:role" use="optional"/> <attribute ref="xlink:arcrole" use="optional"/> <attribute ref="xlink:title" use="optional"/> <attribute ref="xlink:show" use="optional"/> <attribute ref="xlink:actuate" use="optional"/></attributeGroup>
How should parsers interpret xlink? XML validation will *only* check the grammar of the xlink
statement xlink has ‘deferred binding’ semantics …
Page 22
GML pattern: object-type-object-type ‘striping’
object
object
object
object
type
type
type
type
object
object
object
object
<om:location xlink:href="#ot2p"/>
<om:observedProperty xlink:href="urn:x-ogc:def:phenomenon:OGC:Species"/>
<om:featureOfInterest>
<om:Station gml:id="ot2s">
<gml:name>8903</gml:name>
<om:position>
<gml:Point gml:id="ot2p">
<gml:pos srsName="urn:x-ogc:def:crs:EPSG:6.3:62836405">
-30.7025065 134.1997256
</gml:pos>
</gml:Point>
</om:position>
</om:Station>
</om:featureOfInterest>
Page 23
Interoperability outside WMO community
Document withoutWMO extensions
Document withWMO extensions
XSL Transformation
Users outside WMO community will (probably) NOT understand WMO extensions …
Need to ‘remove’ them???
Page 24
Open Issues
Worked examples & implementation test-bed Finalize extensions
which are required? Time, ServiceIdentification 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
do we need to *restrict* WMO Core metadata? ISO/TC 211 & OGC community peer review
Page 25
Thank you
© Crown copyright 2006 Page 27
Explanation of times for observations and simulations
Encoding in ISO 19115 / 19139 metadata
April 2006
© Crown copyright 2006 Page 30
Times relevant to a observations… a single observation …
even
tTim
e (t e
)eventTime encoded in ‘Observations & Measures’ as:
<om:Observation gml:id="obsTest1">…<om:time>
<gml:TimeInstant gml:id="ot1t"><gml:timePosition>2005-01-11T16:22:25.00</gml:timePosition>
</gml:TimeInstant></om:time>…
</om:Observation>
eventTime encoded in ‘Observations & Measures’ as:
<om:Observation gml:id="obsTest1">…<om:time>
<gml:TimeInstant gml:id="ot1t"><gml:timePosition>2005-01-11T16:22:25.00</gml:timePosition>
</gml:TimeInstant></om:time>…
</om:Observation>
Time at which the observation ‘event’ occurred (from om:Event)
(Often referred to as “validTime” within GML schemas)
issu
eTim
e (t i)
Time at which the observation was published / issued …
allowing for amendments to a previously published observation(we need to extend O&M for this)
real time axis (t)
Time in the “real world”Default temporal reference system:
ISO-8601 (Gregorian calendar)
ObservationObservation
© Crown copyright 2006 Page 31
Times relevant to a observations… what about accumulations? …
even
tTim
e (t e
)
time interval
Time interval relative to the observation time for calculating accumulations, averages etc.
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 eventTime (te) of observation occurs at the end of the time interval.
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 eventTime (te) of observation occurs at the end of the time interval.
issu
eTim
e (t i)
real time axis (t)
© Crown copyright 2006 Page 32
Times relevant to a observations… what about maxima & minima? …
even
tTim
e (t e
)
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 eventTime (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.
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 eventTime (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.
real time axis (t)
xTemperature fluctuation during time interval
Time instant at which the maximum temperature occurs
during the time intervalRelated observation:
temperature recorded at time instant
Related observation:temperature recorded at
time instant Primary observation:Maximum temperature
recorded during time interval
Primary observation:Maximum temperature
recorded during time interval
© Crown copyright 2006 Page 33
Times relevant to a observations… what about collections of obs? …
even
tTim
e (t e
)
collectionPeriod 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)
collectionPeriod 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)
colle
ctio
nPer
iod
real time axis (t)
© Crown copyright 2006 Page 34
Which time values are needed in observation feature types?
eventTime (te)Time at which the observation
event occurred
time interval(for calculating accumulations,
averages, max/min etc.)
part of the ‘phenomenon’ definition
Not valid:
collectionPeriodTime interval bounding all
discrete observations within the collection
(where appropriate)
Time properties:
issueTime (ti)Time at which the observation was published … allowing for
amendments
© Crown copyright 2006 Page 35
cd Time properties
Metadata entity set information::MD_Metadata
+ characterSet: MD_CharacterSetCode = "utf8"+ contact: CI_ResponsibleParty+ dataSet: CharacterString+ dateStamp: Date+ fi leIdentifier: CharacterString+ hierarchyLevel: MD_ScopeCode = "dataset"+ hierarchyLevelName: CharacterString+ language: CharacterString+ metadataStandardName: CharacterString+ metadataStandardVersion: CharacterString+ parentIdentifier: CharacterString
«Abstract»Identification information::
MD_Identification
+ abstract: CharacterString+ citation: CI_Citation+ credit: CharacterString+ pointOfContact: CI_ResponsibleParty+ purpose: CharacterString+ status: MD_ProgressCode
«DataObject»Citation and responsible party information::
CI_Citation
+ alternateTitle: CharacterString+ citedResponsibleParty: CI_ResponsibleParty+ collectiveTitle: CharacterString+ date: CI_Date+ edition: CharacterString+ editionDate: Date+ identifier: MD_Identifier+ ISBN: CharacterString+ ISSN: CharacterString+ otherCitationDetails: CharacterString+ presentationForm: CI_PresentationFormCode+ series: CI_Series+ title: CharacterString
«DataObject»Citation and responsible party
information::CI_Date
+ date: Date+ dateType: CI_DateTypeCode
«CodeList»Citation and responsible
party information::CI_DateTypeCode
+ creation+ publication+ revision
Identification information::MD_DataIdentification
+ characterSet: MD_CharacterSetCode = "utf8"+ environmentDescription: CharacterString+ extent: EX_Extent+ language: CharacterString+ spatialRepresentationType: MD_SpatialRepresentationTypeCode+ spatialResolution: MD_Resolution+ supplementalInformation: CharacterString+ topicCategory: MD_TopicCategoryCode
Extent information::EX_TemporalExtent
+ extent: TM_Primitive
«DataObject»Extent information::EX_Extent
+ description: CharacterString
+temporalElement 0..*
+identificationInfo 1..*
Time metadata in ISO 19115 (1)
© Crown copyright 2006 Page 36
cd TM_Primitiv e
Temporal Objects::
TM_Primitiv e
Temporal Objects::TM_Instant
Temporal Objects::TM_Period
Temporal Objects::TM_GeometricPrimitiv e
+end
1
+endedBy
0..*
+begin
1
+begunBy
0..*
Time metadata in ISO 19115 (2)
© Crown copyright 2006 Page 37
Encoding eventTime in ISO 19115 & ISO 19139
For a single observation, or a collection of observations with a common eventTime (te) …
metadata [MD_Metadata] »
identificationInfo [MD_DataIdentification] »
extent [EX_Extent] »
temporalElement [EX_TemporalExtent] »
extent [TM_Instant]
For a single observation, or a collection of observations with a common eventTime (te) …
metadata [MD_Metadata] »
identificationInfo [MD_DataIdentification] »
extent [EX_Extent] »
temporalElement [EX_TemporalExtent] »
extent [TM_Instant]
<MD_Metadata> <identificationInfo> <MD_DataIdentification> <extent> <EX_Extent> <temporalElement> <EX_TemporalExtent> <extent> <gml:TimeInstant> <gml:timePosition> 2005-01-11T16:22:25.00 </gml:timePosition> </gml:TimeInstant> </extent> </EX_TemporalExtent> </temporalElement> </EX_Extent> </extent> </MD_DataIdentification> </identificationInfo></MD_Metadata>
<MD_Metadata> <identificationInfo> <MD_DataIdentification> <extent> <EX_Extent> <temporalElement> <EX_TemporalExtent> <extent> <gml:TimeInstant> <gml:timePosition> 2005-01-11T16:22:25.00 </gml:timePosition> </gml:TimeInstant> </extent> </EX_TemporalExtent> </temporalElement> </EX_Extent> </extent> </MD_DataIdentification> </identificationInfo></MD_Metadata>
© Crown copyright 2006 Page 38
Encoding collectionPeriod in ISO 19115 & ISO 19139
For a collection of observations spanning multiple times, collectionPeriod …
metadata [MD_Metadata] » identificationInfo [MD_DataIdentification] » extent [EX_Extent] » temporalElement [EX_TemporalExtent] » extent [TM_Period]
For a collection of observations spanning multiple times, collectionPeriod …
metadata [MD_Metadata] » identificationInfo [MD_DataIdentification] » extent [EX_Extent] » temporalElement [EX_TemporalExtent] » extent [TM_Period]
<MD_Metadata> <identificationInfo> <MD_DataIdentification> <extent> <EX_Extent> <temporalElement> <EX_TemporalExtent> <extent> <gml:TimePeriod> <gml:beginPosition> 2006-01-11T16:22:25.00 </gml:beginPosition> <gml:endPosition> 2006-01-12T16:22:25.00 </gml:endPosition> </gml:TimePeriod> </extent> </EX_TemporalExtent> </temporalElement> </EX_Extent> </extent> </MD_DataIdentification> </identificationInfo></MD_Metadata>
<MD_Metadata> <identificationInfo> <MD_DataIdentification> <extent> <EX_Extent> <temporalElement> <EX_TemporalExtent> <extent> <gml:TimePeriod> <gml:beginPosition> 2006-01-11T16:22:25.00 </gml:beginPosition> <gml:endPosition> 2006-01-12T16:22:25.00 </gml:endPosition> </gml:TimePeriod> </extent> </EX_TemporalExtent> </temporalElement> </EX_Extent> </extent> </MD_DataIdentification> </identificationInfo></MD_Metadata>
© Crown copyright 2006 Page 39
Encoding issueTime in ISO 19115 & ISO 19139
issueTime …
metadata [MD_Metadata] » dateStamp [Date]
metadata [MD_Metadata] » identificationInfo [MD_DataIdentification] » citation [CI_Citation] » date [CI_Date] » date [Date] dateType [CI_DateTypeCode] edition [CharacterString] {creation, publication, revision} editionDate [Date]
Problem:• date field only …• in meteorology we need to differentiate on smaller
time scales• EITHER 1. extend metadata standard, OR2. use ‘edition’ information to capture metadata
information for amends etc.
issueTime …
metadata [MD_Metadata] » dateStamp [Date]
metadata [MD_Metadata] » identificationInfo [MD_DataIdentification] » citation [CI_Citation] » date [CI_Date] » date [Date] dateType [CI_DateTypeCode] edition [CharacterString] {creation, publication, revision} editionDate [Date]
Problem:• date field only …• in meteorology we need to differentiate on smaller
time scales• EITHER 1. extend metadata standard, OR2. use ‘edition’ information to capture metadata
information for amends etc.
<MD_Metadata>
<dateStamp> <gco:Date>2006-02-20</gco:Date> </dateStamp>
<identificationInfo> <MD_DataIdentification> <citation> <CI_Citation> <date> <CI_Date> <date> <gco:Date>1993-01-01</gco:Date> </date> <dateType> <CI_DateTypeCode codeList="codeList.xml?CI_DateTypeCode" codeListValue="creation">creation</CI_DateTypeCode> </dateType> </CI_Date> </date> </CI_Citation> </citation> </MD_DataIdentification> </identificationInfo>
</MD_Metadata>
<MD_Metadata>
<dateStamp> <gco:Date>2006-02-20</gco:Date> </dateStamp>
<identificationInfo> <MD_DataIdentification> <citation> <CI_Citation> <date> <CI_Date> <date> <gco:Date>1993-01-01</gco:Date> </date> <dateType> <CI_DateTypeCode codeList="codeList.xml?CI_DateTypeCode" codeListValue="creation">creation</CI_DateTypeCode> </dateType> </CI_Date> </date> </CI_Citation> </citation> </MD_DataIdentification> </identificationInfo>
</MD_Metadata>
© Crown copyright 2006 Page 40
Indeterminate times in GML – ISO 19136
Inexact temporal positions may be expressed using the optional indeterminatePosition attribute. Thistakes a value from an enumeration defined as follows:
<simpleType name="TimeIndeterminateValueType"><restriction base="string">
<enumeration value="after"/><enumeration value="before"/><enumeration value="now"/><enumeration value="unknown"/>
</restriction></simpleType>
These values are interpreted as follows: “unknown” indicates that no specific value for temporal position is provided. “now” indicates that the specified value shall be replaced with the current temporal position whenever the value is accessed. “before” indicates that the actual temporal position is unknown, but it is known to be before the specified value. “after” indicates that the actual temporal position is unknown, but it is known to be after the specifiedvalue.
<gml:TimeInstant> <gml:timePosition indeterminatePosition="now"/></gml:TimeInstant>
<gml:TimeInstant> <gml:timePosition indeterminatePosition="now"/></gml:TimeInstant>
© Crown copyright 2006 Page 41
Times relevant to a simulation… time in the real world …
crea
tionT
ime
(t c)
Time at which the simulation was executed
issu
eTim
e (t i)
Time at results of the simulation were
published / issued
time axis (t)
Time of an ‘event’ that has been simulated …
i.e. a ‘simulated’ observation
datu
mTi
me
(t d)
The ‘origin’ (datum) time used in the
simulation
even
tTim
e (t e
)
x
© Crown copyright 2006 Page 42
Times relevant to a simulation… assimilation vs. prediction …
time axis (t)
datu
mTi
me
(t d) o
r
anal
ysis
Tim
e (t a
)
initi
alis
atio
nTim
e (t 0
)
assimilationperiod
Consider a forecast …
• the simulation is run to give a prediction from the datumTime (td) to some arbitrary time in the future
• however, the simulation begins earlier at the initialisationTime (t0)… allowing data to be assimilated into the simulation
• the analysis is produced at the end of the assimilation period
• the analysisTime (ta) corresponds with the datumTime (td)
Consider a forecast …
• the simulation is run to give a prediction from the datumTime (td) to some arbitrary time in the future
• however, the simulation begins earlier at the initialisationTime (t0)… allowing data to be assimilated into the simulation
• the analysis is produced at the end of the assimilation period
• the analysisTime (ta) corresponds with the datumTime (td)
even
tTim
e (t e
)
x
© Crown copyright 2006 Page 43
Times relevant to a simulation… usage periods …
time axis (t)
datu
mTi
me
(t d)
usag
eSta
rtTim
e
usag
eExp
iryTi
me
valid
Usa
gePe
riod
validUsagePeriod 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 issueTime (ti) and the start of the usage period do not need to coincide
validUsagePeriod 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 issueTime (ti) and the start of the usage period do not need to coincide
even
tTim
e (t e
)
validUsagePeriod may extend beyond the eventTime (te)
x
© Crown copyright 2006 Page 44
x
A set of results from a simulation (a ‘model run’)
time axis (t)
datu
mTi
me
(t d)
Collection of discrete simulation result-sets that share the same
DatumTime
even
tTim
e (t e
)fin
alTi
me
(t f)
End of the simulation …
finalTime (tf)colle
ctio
nPer
iod
© Crown copyright 2006 Page 45
Times relevant to a simulation … the axes of time for simulations …
real time axis (t)
simulationtime axis (T)
datu
mTi
me
(t d)
simulationDatumTime (Td)
simulationTime (Ts)
Example: T+60
The origin time for the simulation; e.g. T+0
even
tTim
e (t e
)
simulation time (T) is ‘projected’ onto real time (t) … although this is not always straightforward with 360-day
calendars for climate models!
simulation time (T) is ‘projected’ onto real time (t) … although this is not always straightforward with 360-day
calendars for climate models!
Time in the “real world”Default temporal reference system:
ISO-8601 (Gregorian calendar)
Time in the “real world”Default temporal reference system:
ISO-8601 (Gregorian calendar)
Time in the “conceptual world” of the numerical simulation
Temporal coordinate reference system defined locally for the
simulation using <gml:TimeCoordinateSystem>
Time in the “conceptual world” of the numerical simulation
Temporal coordinate reference system defined locally for the
simulation using <gml:TimeCoordinateSystem>
© Crown copyright 2006 Page 46
Example encoding of a local temporal reference system
Temporal coordinate reference system (hours since midnight UTC 9 th March 2006) encoded as:
<gml:TimeCoordinateSystem gml:id=“simTRS1"><gml:description>Number of hours since midnight UTC, 9th March 2006</gml:description><gml:name>Simulation time axis</gml:name><gml:domainOfValidity>global</gml:domainOfValidity><gml:origin>2006-03-09T00:00:00.00</gml:origin><gml:interval>H</gml:interval>
</gml:TimeCoordinateSystem>
Temporal coordinate reference system (hours since midnight UTC 9 th March 2006) encoded as:
<gml:TimeCoordinateSystem gml:id=“simTRS1"><gml:description>Number of hours since midnight UTC, 9th March 2006</gml:description><gml:name>Simulation time axis</gml:name><gml:domainOfValidity>global</gml:domainOfValidity><gml:origin>2006-03-09T00:00:00.00</gml:origin><gml:interval>H</gml:interval>
</gml:TimeCoordinateSystem>
Time instant “T+60” (relating to local temporal reference system) encoded as:
<gml:TimeInstant><gml:timePosition frame=“#simTRS1">60</gml:timePosition>
</gml:TimeInstant>
Time instant “T+60” (relating to local temporal reference system) encoded as:
<gml:TimeInstant><gml:timePosition frame=“#simTRS1">60</gml:timePosition>
</gml:TimeInstant>
© Crown copyright 2006 Page 47
Which time values are needed in simulation ‘metadata’?(at least for operational meteorology!)
datumTime (td) oranalysisTime (ta)
eventTime (te)
creationTime (tc)
issueTime (ti)
validUsagePeriod
usageStartTime
usageExpiryTime
initialisationTime (t0)
finalTime (tf)
‘publication’ metadata
‘publication’ metadata
primarymetadataprimary
metadata
‘simulation’metadata
‘simulation’metadata
collectionPeriod
simulatedTime (Ts)
© Crown copyright 2006 Page 48
Encoding primary time metadata in ISO 19115 & ISO 19139 (1)
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
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
eventTime (te)
collectionPeriod
simulatedTime (Ts)
<EX_Extent> <temporalElement> <EX_TemporalExtent> <extent> <gml:TimeInstant> <gml:timePosition> 2005-01-11T16:22:25.00 </gml:timePosition> </gml:TimeInstant> </extent> </EX_TemporalExtent> </temporalElement> <temporalElement> <EX_TemporalExtent> <extent> <gml:TimeInstant> <gml:timePosition frame=“#simTRS1"> 60 </gml:timePosition> </gml:TimeInstant> </extent> </EX_TemporalExtent> </temporalElement> </EX_Extent>
<EX_Extent> <temporalElement> <EX_TemporalExtent> <extent> <gml:TimeInstant> <gml:timePosition> 2005-01-11T16:22:25.00 </gml:timePosition> </gml:TimeInstant> </extent> </EX_TemporalExtent> </temporalElement> <temporalElement> <EX_TemporalExtent> <extent> <gml:TimeInstant> <gml:timePosition frame=“#simTRS1"> 60 </gml:timePosition> </gml:TimeInstant> </extent> </EX_TemporalExtent> </temporalElement> </EX_Extent>
© Crown copyright 2006 Page 49
Encoding primary time metadata in ISO 19115 & ISO 19139 (2)
eventTime (te)
simulatedTime (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
• 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 …
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
• 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 …
cd Alternativ e temporal extent
Extent information::EX_TemporalExtent
+ extent: TM_Primitive
WMO_TemporalExtent WMO_LocalisedTemporalExtent
+ localReferenceSystem: TimeCoordinateSystem+alternateExtents
1..*1
© Crown copyright 2006 Page 52
Encoding ‘publication’ time metadata in ISO 19115 & ISO 19139
Encode as for observations
metadata [MD_Metadata] » identificationInfo [MD_DataIdentification] » citation [CI_Citation] » date [CI_Date] » date [Date] dateType [CI_DateTypeCode] edition [CharacterString] {creation, publication, revision} editionDate [Date]
employing the CI_DateTypeCode to describe the ‘type’ of the publication
Encode as for observations
metadata [MD_Metadata] » identificationInfo [MD_DataIdentification] » citation [CI_Citation] » date [CI_Date] » date [Date] dateType [CI_DateTypeCode] edition [CharacterString] {creation, publication, revision} editionDate [Date]
employing the CI_DateTypeCode to describe the ‘type’ of the publication
creationTime (tc)
issueTime (ti)
validUsagePeriod
usageStartTime
usageExpiryTime
Encode validUsagePeriod as <gml:TimePeriod>
<validUsagePeriod> <gml:TimePeriod> <gml:beginPosition> 2006-01-11T16:22:25.00 </gml:beginPosition> <gml:endPosition> 2006-01-12T16:22:25.00 </gml:endPosition> </gml:TimePeriod> </validUsagePeriod>
Encode validUsagePeriod as <gml:TimePeriod>
<validUsagePeriod> <gml:TimePeriod> <gml:beginPosition> 2006-01-11T16:22:25.00 </gml:beginPosition> <gml:endPosition> 2006-01-12T16:22:25.00 </gml:endPosition> </gml:TimePeriod> </validUsagePeriod>
© Crown copyright 2006 Page 53
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_LegalConstraints
• MD_SecurityConstraints cd Constraint classes
MD_Constraints
+ useLimitation: CharacterString
MD_LegalConstraints
+ accessConstraints: MD_RestrictionCode+ otherConstraints: CharacterString+ useConstraints: MD_RestrictionCode
MD_SecurityConstraints
+ classification: MD_ClassificationCode+ classificationSystem: CharacterString+ handlingDescription: CharacterString+ userNote: CharacterString
Metadata entity set information::MD_Metadata
+metadataConstraints 0..*
To record temporal usage constraints in the metadata record, we will need to extend ISO 19115; e.g.
WMO_TemporalUsageConstraints
Question: is this type of metadata required in WMO core?
© Crown copyright 2006 Page 54
Encoding ‘simulation’ time metadata in ISO 19115 & ISO 19139
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. ensembleID)
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/NumSim
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. ensembleID)
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/NumSim
datumTime (td) oranalysisTime (ta)
…
initialisationTime (t0)
finalTime (tf)
ensembleID
© Crown copyright 2006 Page 55
NDG NumSim extension
Numerical Simulation Discovery Metadata (aka NumSim)
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 ISO19115 parent discovery schema, although at the moment it is rather standalone.
…
Proposal: WMO adopts NumSim as a formal mechanism for describing simulation metadata within WMO Core metadata profile. Prior to adoption, WMO should liaise with BADC to ensure the the profile is fit for purpose and has been rigorously tested.
© Crown copyright 2006 Page 56
Thank you
Page 57
Implementing codelists
3rd May 2006
byJeremy Tandy, UK Met Office
Jürgen Seib, Deutscher Wetterdienst
Page 58
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 v0.2 identified a small number of *new*
code lists
Page 59
ISO/TS 19139:2005(E) – Clause 8.5.5Codelist encodings (1)
A class that is stereotyped CodeList is an enumerated type like a class that is stereotyped Enumeration.
The difference is that the <<CodeList>> class is extensible.
All <<CodeList>> classes defined in ISO 19115, Annex B, are described in tables with three columns: Name, DomainCode and Definition.
Codelists and their associated definitions are controlled in a register. ISO 19115, Annex B contains the content of a register or registers that could be created that is well understood by software.
Page 60
ISO/TS 19139:2005(E) – Clause 8.5.5Codelist 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 61
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 62
ISO 19139 Codelist schema
Where codelists are referenced from within a metadata record, the following XML type is used:
<xs:complexType name="CodeListValue_Type"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="codeList" type="xs:anyURI" use="required"/> <xs:attribute name="codeListValue" type="xs:anyURI“ use="required"/> <xs:attribute name="codeSpace" type="xs:anyURI" use="optional"/> </xs:extension> </xs:simpleContent></xs:complexType>
Example instance values:
codeList = http://www.tc211.org/ISO19139/resources/codeList.xml#CI_DateTypeCodecodeListValue="creation"
Page 63
Codelist implementation example – CI_DateTypeCode (1)
The XML global element corresponding to CI_DateTypeCode:<xs:element name="CI_DateTypeCode" type="gco:CodeListValue_Type"substitutionGroup="gco:CharacterString"/>
The XML PropertyType corresponding to CI_DateTypeCode:<xs:complexType name="CI_DateTypeCode_PropertyType"> <xs:sequence> <xs:element ref="gmd:CI_DateTypeCode" minOccurs=”0”/> </xs:sequence> <xs:attribute ref="gco:nilReason"/></xs:complexType>
cd CD
«CodeList»CI_DateTypeCode
+ creation+ publication+ revision
Page 64
Codelist implementation example – CI_DateTypeCode (2)
<CI_Date> <date> <gco:Date>1993-01-01</gco:Date> </date> <dateType> <CI_DateTypeCode codeList="./resources/codeList.xml#CI_DateTypeCode" codeListValue="publication">publication</CI_DateTypeCode> </dateType></CI_Date>
… implementation of codelist registers will be discussed later …
cd CD
«CodeList»CI_DateTypeCode
+ creation+ publication+ revision
Page 65
WMO metadata profile codelist extensions
WMO Core profile v0.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»
Page 66
Code lists: WMO topic categories
MD_TopicCategoryCode far too restrictive …
Create new WMO specialisation:
WMO_CommunityTopicCategoryCode
(as proposed in WMO Core v0.2)
cd topic category
«Enumeration»Identification information::MD_TopicCategoryCode
+ biota+ boundaries+ climatologyMeteorologyAtmosphere+ economy+ elevation+ environment+ farming+ geoscientificInformation+ health+ imageryBaseMapsEarthCover+ inlandWaters+ intell igenceMilitary+ location+ oceans+ planningCadastre+ society+ structure+ transportation+ util i tiesCommunication
«Enumeration»WMO_CommunityTopicCategoryCode
+ actinometry: + aerology: + agricultureMeteorology: + airplaneObservation: + airPollution: + climatology: + glaciology: + hydrology: + landHydrology: + landMeteorologyClimate: + landPollution: + landWaterPollution: + marineAerology: + marineMeteorology: + meteorology: + observationPlatform: + oceanography: + pollution: + rocketSounding: + satell iteObservation: + seaPollution: + synopticMeteorology: + waterPollution: + weatherForecasts: + weatherObservations:
Page 67
WMO topic categories - schema
<xs:simpleType name=“WMO_CommunityTopicCategoryCode_Type"> <xs:restriction base="xs:string"> … <xs:enumeration value=“weatherObservations"/> … </xs:restriction></xs:simpleType>
<xs:element name=“WMO_CommunityTopicCategoryCode" type=“wmo:WMO_CommunityTopicCategoryCode_Type" substitutionGroup=“gmd:MD_TopicCategoryCode_PropertyType"/>
<xs:complexType name=“WMO_CommunityTopicCategoryCode_PropertyType"> <xs:sequence>
<xs:element ref=“wmo:WMO_CommunityTopicCategoryCode" minOccurs="0"/> </xs:sequence> <xs:attribute ref="gco:nilReason"/></xs:complexType>
Page 68
Example: WMO topic categories
<MD_Metadata>...... <topicCategory> <MD_TopicCategoryCode> climatologyMeteorologyAtmosphere </MD_TopicCategoryCode> </topicCategory> <topicCategory xsi:type=“wmo:WMO_CommunityTopicCategoryCode_PropertyType”> <WMO_CommunityTopicCategoryCode> weatherObservation </WMO_CommunityTopicCategoryCode> </topicCategory>.......</MD_Metadata>
(This part *may* not be required)
Page 69
SIMDAT: metadata directory structure (1)
SIMDAT (phase 1) employed WMO Core Metadata v0.2 <topicCategory> was ‘misused’ to hold a ‘directory structure’ for the metadata
instance …
Example:
<topicCategory>
NWP Outputs > ECMWF > 40 years reanalysis
</topicCategory>
This implementation is NOT ISO 19115 compliant
Proposal:
Use MD_DataIdentification » supplementalInformation as a placeholder for the ‘directory’
Page 73
Code lists: WMO keywords
MD_KeywordTypeCode … WMO Core v0.2 proposed a new WMO
keyword list:
WMO_KeywordList
(a VERY long list!)
WMO Core v0.2 expressed this as an enumeration …
Also put the actual keyword list *content* into the keyword *type* list (?)
cd keywords
«CodeList»Identification information::
MD_KeywordTypeCode
+ discipline+ place+ stratum+ temporal+ theme
Identification information::MD_Keywords
+ keyword: CharacterString+ thesaurusName: CI_Citation+ type: MD_KeywordTypeCode
Page 74
ISO 19139 keywords implementation
keyword … ‘free text’ field
type … from «MD_KeywordTypeCode» codelist
classifies the type of keyword does this codelist need extension?
thesaurusName … «CI_Citation»
identifies the ‘thesaurus’ that describes the permissible content of the keyword list
thesaurusName [CI_Citation] »
identifier [MD_Identfier] »
code [CharacterString]
can be used to express the URI of the thesaurus / codelist … allowing linkage to URL or URN
(alternative: substitute gmx:Anchor for gco:CharacterString to reference the ‘thesaurus’)
cd keywords
«CodeList»Identification information::
MD_KeywordTypeCode
+ discipline+ place+ stratum+ temporal+ theme
Identification information::MD_Keywords
+ keyword: CharacterString+ thesaurusName: CI_Citation+ type: MD_KeywordTypeCode
Page 75
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 manualsurn:x-wmo:wmoManual: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 77
Code lists: frequency values
MD_MaintenanceFrequencyCode too restrictive …
WMO Core v0.2 proposed an extended list:
WMO_DataFrequencyCode
expressed as an enumeration in WMO Core v0.2
cd frequency v alues
«CodeList»WMO_DataFrequencyCode
+ 1-minute: + 10-daily: + 10-minute: + 12-hourly: + 15-minute: + 3-hourly: + 30-minute: + 5-minute: + 6-hourly: + 8-hourly: + annually: + biannually: + continuous: + daily: + decadally: + fortnightly: + hourly: + irregularly: + monthly: + quarterly: + weekly:
«CodeList»Maintenance information::
MD_MaintenanceFrequencyCode
+ annually+ asNeeded+ biannually+ continual+ daily+ fortnightly+ irregular+ monthly+ notPlanned+ quarterly+ unknown+ weekly
Page 78
WMO_DataFrequencyCode implementation
Standard codelist implementation …
Global XML element …
<xs:element name=“WMO_DataFrequencyCode" type="gco:CodeListValue_Type"
substitutionGroup="gco:CharacterString"/>
XML PropertyType …
<xs:complexType name=“WMO_DataFrequencyCode_PropertyType"> <xs:sequence> <xs:element ref=“wmo:WMO_DataFrequencyCode" minOccurs=”0”/> </xs:sequence> <xs:attribute ref="gco:nilReason"/></xs:complexType>
Page 79
WMO_DataFrequencyCode example
<MD_MaintenanceInformation>
…
<maintenanceAndUpdateFrequency xsi:type=“wmo:WMO_DataFrequencyCode_PropertyType”>
<wmo:WMO_DataFrequencyCode codeList="codeList.xml?WMO_DataFrequencyCode" codeListValue="daily">daily</wmo:WMO_DataFrequencyCode>
</maintenanceAndUpdateFrequency>
...
</MD_MaintenanceInformation>
Page 81
Code lists: WMO member countries
The organisation responsible for various aspects of the metadata instance is defined thus:
[CI_Citation] »
citedResponsibleParty [CI_ResponsibleParty] »
organisationName [CharacterString]
WMO profile needs to formalise list of responsible organisations as the member countries of WMO
WMO_WMO-MemberCountryCode
Page 82
WMO_WMO-MemberCountryCode implementation
Standard codelist implementation …
Global XML element …<xs:element name=“WMO_WMO-MemberCountryCode"
type="gco:CodeListValue_Type"substitutionGroup="gco:CharacterString"/>
XML PropertyType …<xs:complexType name=“WMO_WMO-MemberCountryCode_PropertyType"> <xs:sequence> <xs:element ref=“wmo:WMO_WMO-MemberCountryCode“ minOccurs=”0”/> </xs:sequence> <xs:attribute ref="gco:nilReason"/></xs:complexType>
Page 83
WMO_WMO-MemberCountryCode example
<CI_Citation> … <citedResponsibleParty> <CI_ResponsibleParty> <organisationName> <wmo:WMO_WMO-MemberCountryCode codeList="codeList.xml?
WMO_WMO-MemberCountryCode" codeListValue="Deutscher Wetterdienst">Deutscher Wetterdienst
</wmo:WMO_WMO-MemberCountryCode> </organisationName> </CI_ResponsibleParty> </citedResponsibleParty> ...</CI_Citation>
Page 84
Member country list – alternative implementation
does not exist in WMO Metadata Profile v0.2should be implemented as an XML enumeration type
<xs:simpleType name="WMO_MemberCountriesCodeType"> <xs:restriction base="xs:string"> <xs:enumeration value=”France"/> <xs:enumeration value=”Germany"/> ....... </xs:restriction></xs:simpleType>
<xs:element name="Country” type="wmo:WMO_MemberCountriesCodeType” substitutionGroup="gmd:Country"/>
Page 85
Member country list – alternative implementation
<MD_Meatadata>...... <locale> <PT_Locale> <languageCode/> <country> <wmo:Country>Germany</wmo:Country> </country> <characterEncoding> .......</MD_Metadata>
Page 86
Thank you
Page 87
Service metadata
Encoding in ISO 19119 metadata
May 2006
Page 88
Service metadata
WMO Core Profile key concern is describing *datasets* …
Implication:
MD_DataIdentification 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 89
Service metadata in ISO 19115
cd serv ice metadata
Metadata entity set information::MD_Metadata
«Abstract»Identification information::
MD_Identification
Identification information::MD_DataIdentification
Identification information::
MD_Serv iceIdentification
+identificationInfo 1..*
Page 90
ISO 19119:2005 Geographic information - Services
Service metadata is described in ISO 19119 MD_ServiceIdentification is replaced with
SV_ServiceIdentification 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
Page 91
ISO 19119:2005 UML model (1)cd Figure 2 - Serv ice metadata class diagram
«Abstract»Identification information::
MD_Identification
+ abstract: CharacterString+ citation: CI_Citation+ credit: CharacterString+ pointOfContact: CI_ResponsibleParty+ purpose: CharacterString+ status: MD_ProgressCode
Identification information::MD_DataIdentification
+ characterSet: MD_CharacterSetCode = "utf8"+ environmentDescription: CharacterString+ extent: EX_Extent+ language: CharacterString+ spatialRepresentationType: MD_SpatialRepresentationTypeCode+ spatialResolution: MD_Resolution+ supplementalInformation: CharacterString [0..1]+ topicCategory: MD_TopicCategoryCode
«CodeList»DCPList
+ COM: + CORBA: + JAVA: + SQL: + WebServices: + XML:
«CodeList»SV_CouplingType
+ light: + loose: + mixed:
«enumeration»SV_ParameterDirection
+ in: + in/out: + out:
SV_Serv iceIdentification
+ accessProperties: MD_StandardOrderProcess [0..1]+ coupledResource: SV_CoupledResource [0..*]+ couplingType: SV_CouplingType+ extent: EX_Extent [0..*]+ restrictions: MD_Constraints [0..1]+ serviceType: GenericName+ serviceTypeVersion: CharacterString [0..*]
SV_OperationMetadata
+ connectionPoint: CI_OnlineResource [1..*]+ DCP: DCPList [1..*]+ invocationName: CharacterString [0..1]+ name: MemberName+ operationDescription: CharacterString [0..1]+ operationName: CharacterString
SV_CoupledResource
+ identifier: CharacterString+ operationName: CharacterString
SV_OperationChainMetadata
+ description: CharacterString [0..1]+ name: CharacterString
«DataType»SV_Parameter
+ description: CharacterString [0..1]+ direction: SV_ParameterDirection [0..1]+ optionality: CharacterString = "Mandatory"+ repeatabil ity: Boolean
«Metaclass»Type
+valueType
+parameters 1
+operation
+operation 1..* {ordered}
Chaining Metadata
+dependsOn
Dependencies
+containsOperations
+operatesOn
Page 92
ISO 19119:2005 UML model (2)
cd serv ice binding classes
MD_Identification
SV_Serv iceIdentification
+ accessProperties: MD_StandardOrderProcess [0..1]+ coupledResource: SV_CoupledResource [0..*]+ couplingType: SV_CouplingType+ extent: EX_Extent [0..*]+ restrictions: MD_Constraints [0..1]+ serviceType: GenericName+ serviceTypeVersion: CharacterString [0..*]
SV_CoupledResource
+ identifier: CharacterString+ operationName: CharacterString
SV_OperationChainMetadata
+ description: CharacterString [0..1]+ name: CharacterString
SV_OperationMetadata
+ connectionPoint: CI_OnlineResource [1..*]+ DCP: DCPList [1..*]+ invocationName: CharacterString [0..1]+ name: MemberName+ operationDescription: CharacterString [0..1]+ operationName: CharacterString
«CodeList»DCPList
+ COM: + CORBA: + JAVA: + SQL: + WebServices: + XML:
«CodeList»SV_CouplingType
+ light: + loose: + mixed:
«DataType»SV_Parameter
+ description: CharacterString [0..1]+ direction: SV_ParameterDirection [0..1]+ optionality: CharacterString = "Mandatory"+ repeatabil ity: Boolean
«Metaclass»Type
«enumeration»SV_ParameterDirection
+ in: + in/out: + out:
+operation 1..* {ordered}
Chaining Metadata
+dependsOn
Dependencies
+containsOperations
+parameters 1+operation
+valueType
Page 93
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 94
ISO 19119:2005 – implementation (2)
Best practice for WMO Core metadata? Bind the service definition to the dataset via the operatesOn
relationship (via xlink reference) Set SV_CouplingType as ‘mixed’
Alternative ‘data access’ service binding?
[MD_Distribution] »
transferOptions [MD_DigitalTransferOptions] »
onLine [CI_OnlineResource]
Extend CI_OnlineResource to hold SV_ServiceIdentification, wsdl:definition & default values / predefined queries?
Page 95
ISO 19119:2005 – implementation (3)
Incorporating WSDL service definitions?
Include *both* SV_ServiceIdentification and wsdl:definitions elements …
<MD_Metadata> … <identificationInfo> <MD_DataIdentification>…</MD_DataIdentification> </identificationInfo> <identificationInfo> <SV_ServiceIdentification>…</SV_ServiceIdentification> </identificationInfo> <identificationInfo xsi:type=“wsdl:definitions?”> <types>…</types> <message>…</message> <portType> <operation>…</operation> </portType> <binding>…</binding> <service>…</service> </identificationInfo> …</MD_Metadata>
Page 96
Default parameters / parameter ranges
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?
<location>int.ecmwf.mars</location><request> <class>e4</class> <levtype>sfc</levtype> <database>marser</database> <grid>2/2</grid></request><variables> <date type=“date”> <startDate>1980-01-01</startDate> <endDate>1990-12-31</endDate> </date> <time title=“Base time” multiple=“1”
type=“enum”> <value>0000</value> <value>1200</value> </time></variables>
Page 97
Thank you
Page 98
Catalogues and registries
3rd May 2006
byJeremy Tandy, UK Met Office
Jürgen Seib, Deutscher Wetterdienst
Page 99
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)
Feature types are registered in a ‘feature catalogue’
cd feature catalogues
Metadata entity set information::MD_Metadata
«Abstract»Content information::MD_ContentInformation
Content information::MD_FeatureCatalogueDescription
+ complianceCode: Boolean+ featureCatalogueCitation: CI_Citation+ featureTypes: GenericName+ includedWithDataset: Boolean+ language: CharacterString
+contentInfo 0..*
Page 100
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:
MOTIIVE; INSPIRE-related project aiming to develop best practice methodology for implementing feature catalogues within registries
Page 101
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 …
Coordinate Reference System definitions Unit of Measure definitions Phenomena (parameter) definitions Codelists Keyword thesauri Feature catalogues Gazetteers Station lists
Page 102
Registries and catalogues (1)
These ‘supporting’ metadata artefacts are registered in a *catalogue* or *registry*
Definition: a registry is a catalogue with *governance*
How do you implement a catalogue?
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’
Page 103
Registries and catalogues (2)
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 registry-repository implementation based on OGC CSW and ebRIM 3.0; planned demonstration at CBS Workshop, Nov 2006
Page 104
ISO 19139 catalogue implementation
3 ‘concrete’ catalogue classes:
1. Coordinate Reference System
2. Unit of Measure
3. Codelistcd Figure 10 - Catalogues
«Abstract»CT_Catalogue
+ characterSet: MD_CharacterSetCode [0..1]+ fieldOfApplication: CharacterString [0..*]+ language: CharacterString [0..1]+ locale: PT_Locale [0..*]+ name: CharacterString+ scope: CharacterString [1..*]+ versionDate: Date+ versionNumber: CharacterString
CT_CrsCatalogue CT_UomCatalogue CT_CodelistCatalogue
Page 105
ISO 19139 … codelist catalogue implementation
Example: CT_CodelistCatalogue
cd Figure 13 - Codelist Catalogue
CT_Catalogue
CT_CodelistCatalogue
CT_Codelist
«Abstract»CT_Item
+ definition: CharacterString+ description: CharacterString [0..1]+ identifier: GenericName+ name: GenericName [0..*]
CT_CodelistValue+codeEntry
1..*1
+codeListItem 1..*1
Page 106
Codelist catalogue – XML encoding
cd Figure 69 - Codelist items - XML implementation
«Abstract»CT_Item
+ definition: CharacterString+ description: CharacterString [0..1]+ identifier: GenericName+ name: GenericName [0..*]
CT_Codelist
CT_CodelistValue
AbstractGML
«ObjectType»dictionary::Definition
+ remarks: string [0..1]
«ObjectType»dictionary::Dictionary
«xs:element»gmx:
CodeDefinition
«xs:element»gmx:
CodelistDictionary
+codeEntry
1..*
1
+codeEntry
1..*
«XCGE»
«XCGE»
«XCGE»
Also a ‘multi-lingual’ implementation available from ISO 19139
Page 109
Additional catalogues …
CT_KeywordCatalogue CT_StationCatalogueCT_CentreCatalogue CT_ParameterCatalogue
Page 112
Volume A: observing stations
hierarchy: WMO region countrystation namestation index number latitude and longitudeelevation 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 HPaobservation times remarks
Page 113
Catalogues: station catalogue
CharacterString(from Text)
GlobalStationId
+code: IntStationCode
LocalStationId
+code: GenericName
<<Enumeration>>IntStationCode
+WMO+ICAO
MeteorologicalCentre(from WMO namespace)
+owner
CT_StationCatalogue
1..* +station
WMO_Station+stationName: CharacterString+country: CharacterString+wmoRegion: integer+latitude[0..1]: Decimal+longitude[0..1]: Decimal+elevationHP[0..1]: double+elevationH[0..1]: double+elevationHA[0..1]: double+pressureLevel[0..1]:integer+remarks[0..1]: CharacterString
0..*+stationId
<<Abstract>>StationId
Product
+productID: GenericName+timePerid[0..1]: TM_Period+accessRights[0..1]: MD_Constraints+quality[0..1]: DQ_DataQuality
0..*+product
CI_Contact(from Metadata CI package)
0.. 1+stationContact
Page 114
Another UML model for stations
0..*+stationId
<<Abstract>>StationId
WMO_Station
+stationName: CharacterString+remarks[0..1]: CharacterString
CI_Contact(from Metadata CI package)
0.. 1+stationContact
LandSurfaceStation
+country: CharacterString+wmoRegion: integer+latitude[0..1]: Decimal+longitude[0..1]: Decimal+elevationHP[0..1]: double+elevationH[0..1]: double+elevationHA[0..1]: double+pressureLevel[0..1]:integer
0..*+product
Product(from WMO namespace)
Ship(from WMO namespace)
Airplane(from WMO namespace)
Buoys(from WMO namespace)
RadiosondeStation(from WMO namespace)
Page 115
Catalogues: station catalogue
Use <gmx:Anchor> to reference a station<geographicElement>
<EX_GeographicDescription>
<geographicIdentifier>
<MD_Identifier>
<code>
<gmx:Anchor xlink:href=“station.xml#2667”>
Köln-Bonn</gmx:Anchor>
</code>
</MD_Identifier>
</geograhicIdentifier>
</EX_GeographicDescription>
</geographicElement>
Page 116
Catalogues: parameter catalogue
1..* +parameter
CT_ParameterCatalogue
MeteorologicalParameter
+name: CharacterString+shortName[0..1]: GenericName+frequency: duration
1 +element
MeteorologicalElement
+name: CharacterString+shortName[0..1]: GenericName+unitOfMeasure: Unit
Aggregation
+function: AggregationCode+interval: duration
0..1 +subAggregation
0..1+aggregation
<<Enumeration>>AggregationCode
+minimum+maximum+mean+average+sum
Also see • NASA’s ‘SWEET’ ontology, and• Observations & Measure phenomena dictionary
Page 118
ISO 19112:2003 - Geographic information — Spatial referencing by geographic identifiers
cd Gazeteer
Gazetteer::SI_Gazetteer{root,leaf}
+ name: RS_Identifier+ scope[0..1]: CharacterString+ territoryOfUse: EX_GeographicExtent+ custodian: + coordinate_system[0..1]: SC_CRS+ isGlobal: Boolean+ acceptableClassList: Set<TypeName> = {Any}
ReferenceSystem by Identifier::SI_LocationType{root,leaf}
+ name: RS_Identifier+ theme: CharacterString+ identifier: CharacterString+ definition: CharacterString+ owner: + territoryOfUse: EX_GeographicExtent
positions must be recorded if the geographic identifier contains insufficient information to identify location
Gazetteer::SI_LocationInstance{root,leaf}
+ geographicIdentifier: CharacterString+ alterrnativeGeographicIdentifier[0..*]: CharacterString+ geographicExtent[0..1]: EX_GeographicExtent+ temporalExtent[0..1]: EX_TemporalExtent+ administrator: + position[0..1]: GM_Point
ReferenceSystem by Identifier::SI_SpatialReferenceSystemUsingGeographicIdentifiers
{leaf}
+ theme: CharacterString+ overallOwner: + territoryOfUse: EX_GeographicExtent
1..*+locationType1..*+locationTypes
0..*+referenceSystem
+child 0..*
+parent 0..*
1..*+comprises
1..*+gazetteer
+parent 0..*
+child 0..*
1
+locationType
Page 119
Gazetteer implementation – OGC 05-035 (1)
Within the OGC community there is a growing interest in the development of a common feature-based 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 FeatureTypes and operations required to support an instance of a gazetteer service
Page 120
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:
Get or Query features based on thesaurus-specific 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
Page 121
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 «FeatureType»
SI_LocationInstance «FeatureType»
SI_LocationType «FeatureType»
…
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
Simple implementation
Poor functionality (serving ONLY as a list)
Page 122
Thank you