[SensorML] standard sensornames ?

Mike Botts mike.botts at uah.edu
Tue Jul 8 13:38:01 EDT 2008


Hi Arliss.

 

I agree with you in part. Profiles will ultimately be important if we wish
to have common descriptions for particular sensor and process types.
However, with SensorML we purposely decided not to take the complete design
philosophy of GML, which is to provide a base schema for Feature (which
essentially has nothing in it) and then provide the components that one add
to a feature description. In essence, with GML, you can’t really have a
usable GML Feature description without first creating an “application
schema” for each type of feature. You do this in GML by starting with a
base and through derivation by extension you add properties, by creating
property elements that you give a specific name (e.g. “centerline” or
“population”) and you have it take a particular GML Object as its property
value (e.g. gml:LineSegment, gml:Curve). 

 

With SensorML, we provide the same generality of the base schema, except in
SensorML, one can build a sensor or process description without first
creating an application schema. In fact, one may never have to create an
application schema nor profile in SensorML if they don’t find it useful for
improving interoperability or consistency in descriptions. Furthermore, in
SensorML and unlike GML, the property element names don’t change (i.e. an
input is always found under the “input” element although it can get a
human readable name using the required “name” attribute). A slight
difference perhaps, but one that we feel is important for software to be
built around the standard. Also, in SensorML, the real significance of an
Object (e.g. DataRecord, Quantity, etc) is provided by the “definition”
attribute which should be a reference to a dictionary entry somewhere.
Currently, we are beginning to build these as Semantic dictionaries in
OWL/RDF so that one can now and in the future begin to map relationships
between these terms in order to support higher meaning. I suppose in GML, if
element names and objects are explicitly given semantic meaning, this would
be supported in the annotation for a property within the application schema.

 

Both approaches (GML and SWE) have merit and both introduce some
complications … there’s no way around some complexity if you’re creating
a schema that will be general enough for a wide range of features, sensors,
or processes. Nor are they two approaches necessarily contradictory
(SensorML is after all an Application Schema of GML … albeit a very general
one which can be further restricted). However, the different design
philosophies do perhaps suggest different approaches to schema profiling,
software parsing, and usage of the information by software.

 

By the way, I think this discussion is healthy because we want to find the
right balance for supporting a very wide range of objects, while improving
interoperability, and enabling software to be able to understand what it’s
looking at and what it can and should do with the information at hand. As
you know, this is no small order. We’re all looking for the right, magic
solution for this and within the SensorML team, we are certainly open to
improvements.

 

One of the fallouts of the SensorML approach is that profiling in SensorML
needs to be process of restricting the schema, whereas in GML this is
accomplished by extending the base Feature schema. As far as profiling by
restriction, we like many others, have found that XML Schema is very
challenging when it comes to derivation by restriction. One must create new
elements for any minor restriction and each of these new elements must
typically be given a new name. Also, although I won’t go into details here,
XML Schema is still limited as one gets to finer grained profiling (e.g.
defining rules that apply to an attribute and an element or wanting to
define an attribute to have a particular value without changing the name of
the attribute, etc.). The GML community has looked at augmenting XML Schema
using Schematron, an approach they we have also experimented with and which
we still feel has merit. However, we have also been looking at getting
deeper into using RelaxNG for finer-grained profiling in SensorML and have
found this to work nicely (not perfect, but nice, simple, and very
flexible). 

 

Although we don’t currently have the SensorML/SWE Common RelaxNG schema
available on the public website, we will soon be making those available
along with some SensorML profiles (including the CSM models that you are
interested in). The European Space Agency and SPOT image have also been
working on some RelaxNG profiles to ultimately be used for all of their
satellite sensor descriptions. We will also very soon be releasing a beta
version of a SensorML Editor that can utilize these RelaxNG profiles for
creating particular process or sensor system instances (and later for
defining the profiles themselves).

 

I was also planning on discussing in this email how the “sml:method”
property in SensorML is there to explicitly allow one to define how one can
use or interpret the meaning of at least the input, output, and parameter
properties of a process, but I’ll save that for later discussion.

 

In closing, let me say that this comparison between GML and SensorML is in
no way a criticism of GML, but truly an exploration of the different
approaches. With you coming primarily with significant experience in
profiling GML, I felt it was important to discuss in some detail the slight
differences in design and ultimate utilization.

 

Thanks.

Mike Botts

 

********************************

Dr. Mike Botts

Principal Research Scientist

University of Alabama in Huntsville

 

mike.botts at uah.edu

work: +01-256-961-7760

cell: +01-256-652-0165

********************************

 

From: sensorml-bounces+mike.botts=nsstc.uah.edu at lists.opengeospatial.org
[mailto:sensorml-bounces+mike.botts=nsstc.uah.edu at lists.opengeospatial.org]
On Behalf Of Whiteside, Arliss E (US SSA)
Sent: Friday, July 04, 2008 8:26 PM
To: gsnmlxs; sensorml
Subject: Re: [SensorML] standard sensornames ?

 

I agree that the ProcessModel and similar elements in SensorML allow
including a huge number of component elements and attributes, and the XML
schemas provide very little information on when to include or omit each
element and attribute.  This makes the XML schemas essentially impossible to
apply (with or without interoperability), without the definition of some
profiles for some practical applications.  A few examples are available, but
examples are never complete enough to be sufficient application guidance.

Arliss
  

  _____  

From: sensorml-bounces+arliss.whiteside=baesystems.com at lists.opengeospatial.
org
[mailto:sensorml-bounces+arliss.whiteside=baesystems.com at lists.opengeospatia
l.org] On Behalf Of gsnmlxs
Sent: Tuesday, July 01, 2008 9:21 AM
To: sensorml
Subject: Re: [SensorML] standard sensornames ?

 

Hi all,

 

I have similar question. The schema contains a lot of fileds some of which
(mainly come from GML) may not be necessary in most of cases. I am wondering
if there is a standard specification on what information items are necessary
or optional. Otherwise I think it is still difficult for the interoperation.
Let me know your great ideas!

 

Best wishes,

  _____  

Pine

2008-07-01

  _____  

From: Aadit Shrestha

At: 2008-07-01 09:19:01

To: sensorml at lists.opengeospatial.org

CC: 

Subject: [SensorML] standard sensornames ?

 

Dear all,
Are there any standard methods to write sensornames and phenomenons?
For Example if I want to write 'Soil Moisture Sensor', how do I write it?
'Soil_Moisture' or 'SoilMoisture' or 'SM' or 'S M Sensor' etc
Is there a standardized list of how sensornames and phenomenon names should
be written? ... So that they are unique and distinguished globally?
Thanks and regards,
Aadit

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 14406 bytes
Desc: not available
Url : http://lists.opengeospatial.org/pipermail/sensorml/attachments/20080708/dfb38b98/attachment.bin 


More information about the SensorML mailing list