S e n s o r M o d e l
L a n g u a g e O G C
0 7 - 0 0 0
9 SWE Common XML Encoding and Examples
Informative
The normative definition for SensorML is provided by the schema presented in Appendices A SensorML and B SWE Common. The following informative section
provides additional information on the SWE Common encoding through the use of XML instance “snippets” and examples.
9.1 Encoding principles
The SensorML models presented in the previous section, are encoded as XML Schema documents. It is envisioned that XML instance documents will be created for each
process, component, and system based upon the framework and rules provided by the XML Schema. The current schema provides concrete elements for creating instance
documents for processes, sensor components, and sensor systems and does not require the development of application schemas for various process or component types.
If it proves desirable to further restrict the schema for particular process or component types, then this can be achieved using derivation by restriction in XML Schema, by
restricting the current XML Schema using Schematron rules, or through a combination of both.
9.1.1 XML Encoding Conventions
The http:www.opengis.netsensorML namespace is used for fundamental core SensorML elements that can be applicable for a wide range of sensors. As they are
developed, common process and component types can be approved by OGC or particular user communities and can utilize the http:www.opengis.netsml-x namespace.
This document also defines schema for components used throughout the SWE framework. These are referred to as SWE Common components and are defined within
the http:www.opengis.netswe namespace.
The SensorML schema also utilizes components from two external XML schemas: Geography Markup Language GML, version 3.1.1, http:www.opengis.netgml
Intelligence Community Information Security Marking, v2, urn:us:gov:ic:ism:v2 The “rules” used to encode the SensorML models into an XML Schema are similar to
those used in GML. SensorML uses the concept that there are “Objects” and that these Objects have “properties” or “associations” that take other Objects or basic data types
e.g., string, decimal, etc. as their values. While this convention occasionally results in deeper nesting of elements, it provides explicit association between Objects and is
comparable to conventions utilized in the Resource Description Framework and the Semantic Web. SensorML follows the following lexical conventions:
• Objects are instantiated as XML elements with a conceptually meaningful name in UpperCamelCase
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
66
S e n s o r M o d e l
L a n g u a g e O G C
0 7 - 0 0 0
• Properties are instantiated as XML elements whose name is in lowerCamelCase • Abstract elements start with an underscore e.g. _Process while element types
start with the word “Abstract” e.g. AbstractProcessType • Names of XML types are in UpperCamelCase ending in the word “Type”
As in GML, most properties and Objects in the UML diagrams are encoded as elements within the XML Schema. Only a few properties, such as IDs, xlink associations,
definitions, and reference frames, are encoded as attributes within an element. Most properties that are encoded as attributes with SensorML support some form of URI links
to other Objects, dictionary entries, or online references.
9.1.2 ID, URI, and Linkable Properties
As in GML, SensorML makes extensive use of XLink components to support hypertext referencing in XML. This allows one to reuse Objects that are either internal or external
to the instance document, and allows these objects to perhaps have different associations or roles within one or more documents. This is supported by extensive use of the id
attribute taking an xs:ID as its value within Objects, and utilizing the GML attribute group, gml:AssociationGroup, within property elements.
In properties that support XLink components, one can usually choose to define that property value inline, as in:
contact xlink:arcrole
= expert
ResponsibleParty id
= JohnDoe
…. ResponsibleParty
contact
Or one can reference an object within the same document:
contact xlink:href
= JohnDoe
xlink:arcrole =
expert
or an object within an external document:
contact xlink:href
= http:www.myCom.compersonel.xmlJohnDoe
xlink:arcrole =
expert
Typically, XLink references will be specified as URLs or as URNs that can be easily resolved through registries. In all cases above, the xlink:arcrole attribute was utilized to
define the particular role of the contact with regard to this object.
In addition to these cases, many other attributes in SensorML are encoded to take anyURI as their value. SensorML is designed with the concept that there exist dictionaries or
registries for definitive specification of various terms. We anticipate such definitions for phenomenon, for various community specific sensor and process properties, and for
searchable terms to be used within identifiers and classifiers. Such dictionaries and registries are crucial to the goal of interoperability both within and between different
sensor and processing communities. In most cases, these definitions should be specified
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
67
S e n s o r M o d e l
L a n g u a g e O G C
0 7 - 0 0 0
in SensorML documents as resolvable URNs, while XLink references will be either URLs or URNs.
9.2 SWE Common Data
