Cop
Figure 4 — Data types contained in Contents package
The details of each class contained in the package will be explained in the following subclauses.
7.2.1 AbstractContents
Each SWE service usually defines a Contents section, which provides metadata about the resources managed by the service. The AbstractContents can host a list of offerings –
subclasses of AbstractOffering see clause 7.2.2.
The AbstractContents acts as the property provider for the AbstractOffering see clauses 7.2.2 and 22.
Specifications like SOS and SPS can derive from AbstractContents and thereby add properties that are specific to their service domain. They may also specify that such
properties are included in the property inheritance mechanism for their offerings.
ht © 2011 Open Geospatial Consortium.
15
yrig
16
Copyright © 2011 Open Geospatial Consortium.
Requirement http:www.opengis.netspecSWES2.0reqcontentsAbstractContentsproperties
REQ 2. The AbstractContents type shall include the properties
according to Table 7.
Table 7 — Properties in the AbstractContents type
Name Definition
Data type and values Multiplicity and
use
procedureDesc riptionFormat
identifier of a specific proceduresensor description
format FormatCode
see section 10.2.2 Zero to many
optional observableProp
erty Pointer to a property that can
be observed by a procedure, not necessarily a property
that has already been observed.
GFI_PropertyType
a
see ISODIS 19156 Zero or more
optional
relatedFeature feature that is directly or
indirectly observedobservable by a
procedure; can be any feature of which the service provider
thinks the procedure can make valuable observations
for FeatureRelationship
see clause 9.2.4 Zero or more
optional
offering contains metadata about a
proceduresensor hosted by the service
AbstractOffering see clause 7.2.2
Zero or more optional
a Note: the primary use of this property is to provide a pointeridentifier – see clause 16.3.1 for further details
7.2.2 AbstractOffering
An AbstractOffering contains metadata about a proceduresensor hosted by the service. This includes a pointer to the procedure together with a list of formats supported by the
offering for describing the procedure, properties that can be observed by the procedure and related features. These features can be any feature that the service provider thinks the
procedure can make valuable observations for.
A service may create more than one offering for the same procedure, so that a 1:n n ≥1
relationship between procedures and offerings exists. This functionality supports use cases in which the service provider wants to structure offerings according to certain
criteria e.g. to segregate the observable properties. However, the recommended way of structuring the offerings is to have exactly one offering per procedure.
Copyright © 2011 Open Geospatial Consortium.
17 Requirement
http:www.opengis.netspecSWES2.0reqcontentsAbstractOfferingprocedureDescriptionFormatHomogeneity
REQ 3. If multiple offerings exist for the same procedure, then the
procedureDescriptionFormat property of these offerings shall have the same values to ensure consistency when retrieving the
description of a procedure via DescribeSensor see clause 11.
Properties to store information like a local offering identifier or metadata are automatically added to the content model of AbstractOffering because it is an object type
see clause 24.
Requirement
http:www.opengis.netspecSWES2.0reqcontentsAbstractOfferingidentifierUniqueness
REQ 4. A service shall assign an identifier value to each of its offerings
that is unique for each offering contained in the contents section of the Capabilities.
Specifications like SOS and SPS can derive from AbstractOffering and thereby add properties that are specific to their service domain. They may also specify that such
properties are included in the property inheritance mechanism for their offerings.
Requirement http:www.opengis.netspecSWES2.0reqcontentsAbstractOfferingproperties
REQ 5. An AbstractOffering shall include the properties according to
Table 8.
18
Copyright © 2011 Open Geospatial Consortium.
Table 8 — Properties in the AbstractOffering data type
Name Definition Data type and
values Multiplicity
and use
procedure Pointer to the proceduresensor
associated with this offering. OM_Process
a
see ISODIS 19156 One
mandatory procedureDescr
iptionFormat identifier of a specific
proceduresensor description format
FormatCode see section 10.2.2
Zero to many optional
observableProp erty
Pointer to a property that can be observed by the procedure, not
necessarily a property that has already been observed.
GFI_PropertyType
a
see ISODIS 19156 Zero or more
optional relatedFeature
feature that is directly or indirectly observedobservable
by the procedure; can be any feature which the service
provider thinks the procedure can make valuable observations
for FeatureRelationship
see clause 9.2.4 Zero or more
optional
a Note: the primary use of this property is to provide a pointeridentifier – see clause 16.3.1 for further details
The AbstractOffering represents an inheritor of the properties contained in the AbstractContents which has the role of property provider; see clause 22 for further
details on the property inheritance mechanism.
Requirement
http:www.opengis.netspecSWES2.0reqcontentsAbstractOfferingpropertiesInheritance
REQ 6. The AbstractOffering shall inherit the properties defined in the
content model of AbstractOffering according to Table 9.
Table 9 — Inheritance of AbstractOffering properties from AbstractContents
Property Number Inheritance
Category
procedure
1
no procedureDescriptionFormat
1..
replace observableProperty
1..
replace relatedFeature
0..
replace
Copyright © 2011 Open Geospatial Consortium.
19 Thus, even though the UML model and resulting schema encoding define the
observableProperty and procedureDescriptionFormat properties as optional, they are mandatory in each offering. In other words, each offering has to include at least one value
for these two properties after the property inheritance mechanism was applied.
20
Copyright © 2011 Open Geospatial Consortium.
8 Notification
8.1 Introduction
