[SensorML] SweCommon: Time

Johannes Echterhoff echterhoff at uni-muenster.de
Mon Jun 25 09:17:54 EDT 2007


Hi.

Thanks for the clarification. I was worried about the many meanings that 
the usage of the various XML schema datatypes, especially xs:time and 
xs:date, would have for a swe:Time value. Your explanations help to 
better understand how one should read a swe:Time.

> (1) xs:time and xs:date would be used in the case where date and time of day
> are given in two separate fields of a dataset. xs:dateTime only works if
> both are given in the same field... I know that's not exactly the meaning
> intended by W3C XMLSchema for xs:date and xs:time but what else can we do?
> Create our own type?
>   
That is alright for me - as long as everybody would read a swe:Time in 
this way. E.g., if a dataset contained a swe:Time expressing a time (of 
day), one should read it simply as the time of day without the 
additional meaning (from W3C Schema) that it recurs every day - unless 
this is implied by the definition of the swe:Time. "At which time (of 
the day) did Mount St. Helens erupt?" "08:32" - and not "08:32 every 
day". Including the definition that it recurs every day: "At which time 
of the day is a train leaving for Paris during the whole week?" "During 
the whole week? At 10:15." ... hope I got that right. :-)
> (2) xs:double is needed to specify a delay after an epoch specified by the
> referenceFrame or referenceTime (itself an ISO8601 dateTime).
>   
Good - a clear definition. Hope that nobody tweaks it to use it as a 
duration.
> (3) Any type of time interval should be supported by TimeRange right now. We
> haven't added support for ISO duration notation (ex. P1D) because we feel it
> is just as easy to use a Quantity with the appropriate unit... We may want
> to add support for that later...
Well, I hope that this works. It is not as easy as the ISO notation but 
let us see how easy / difficult it turns out to be in the end.

I agree with Mike that we need a best practices page for the usage of a 
swe:Time in different cases - that also applies to other elements of 
SweCommon as well. Maybe a wiki can help for gathering such examples? 
Maybe the OGC can provide such a platform (if it has not already) 
because it would be useful for other specs and encodings as well. Or do 
you think the OGC Forum is sufficient for that?

Best regards,
    Johannes



Mike Botts schrieb:
> Johannes.
>
> Swe:Time is perhaps a little more complicated than it could be due to having
> overloaded so much flexibility into the one element (this was an occasional
> discussion between Alex and I during development of SensorML). However, the
> needs for the different ways of expressing time are definitely needed. In
> fact, that was verified in a meeting that I attended this week when a
> particular standards body realized that their Time model did not support
> many of the needed use cases.
>
> There is definitely a need to specify a time past an epoch ... e.g. seconds
> past mission start, seconds pasts scan start time, or even seconds past
> 1972-01-01T00:00.0Z which is sometimes referred to as "Julian time" (not to
> be confused with Julian Date) or seconds past 1970-01-01T00:00.0Z, sometimes
> referred to as "Unix time".
>
> We probably could have gotten away with only having xs:dateTime and not the
> additional xs:date and xs:time if, as Alex mentioned, we didn't use the SWE
> Common data types to specify data packets. Many data sets and sensor outputs
> that we have dealt with tend to output date and time as separate tokens in a
> tuple or they only output one or the other. So, we allow any of these to be
> specified.
>
> Then on top of that we have the indeterminate times that we have found that
> we need, particularly for time ranges from some dateTime to the present.
>
> All that being said, we really need to get out some examples of how one
> would specify different times for different cases. That would help establish
> not only a better understanding, but also a best practices so that people
> don't come up with several combinations that mean the same thing.
>
> Thanks.
> Mike Botts
>
> --------------------------------------------------------
> Mike Botts, Ph.D.                   mike.botts at uah.edu
> Principal Research Scientist          http://vast.uah.edu
> NSSTC                                          
> University of Alabama in Huntsville (256) 961-7760
> Huntsville, AL 35899 USA            (256) 652-0165 cell
> --------------------------------------------------------
>  
>
> -----Original Message-----
> From: sensorml-bounces+mike.botts=uah.edu at opengeospatial.org
> [mailto:sensorml-bounces+mike.botts=uah.edu at opengeospatial.org] On Behalf Of
> Alexandre Robin
> Sent: Friday, June 22, 2007 10:00 AM
> To: echterhoff at uni-muenster.de; sensorml at opengeospatial.org
> Subject: Re: [SensorML] SweCommon: Time
>
> Hi Johannes,
>
> The reason why all these different choices are still in there is to be able
> to support a maximum of cases.
>
> (1) xs:time and xs:date would be used in the case where date and time of day
> are given in two separate fields of a dataset. xs:dateTime only works if
> both are given in the same field... I know that's not exactly the meaning
> intended by W3C XMLSchema for xs:date and xs:time but what else can we do?
> Create our own type?
>
> (2) xs:double is needed to specify a delay after an epoch specified by the
> referenceFrame or referenceTime (itself an ISO8601 dateTime).
>
> (3) Any type of time interval should be supported by TimeRange right now. We
> haven't added support for ISO duration notation (ex. P1D) because we feel it
> is just as easy to use a Quantity with the appropriate unit... We may want
> to add support for that later...
>
> The ultimate thing that would tell you what the time really represent is the
> definition attribute anyway, just like any other simpleType we use in SWE
> Common... 
>
> Of course if that seems really too hard to support in a client, we can
> discuss and limit the possibilities. For instance (1) may not really be
> needed since it MAY always be possible to reformat a dataset and merge date
> and time in the same field... But right now I am reluctant to enforce
> that...
>
> Cheers,
>
> --------------------------------------------
> Alexandre Robin
> Research Scientist
> National Space Science and Technology Center
> (256) 961 7978
>
>
>
>   
>> -----Original Message-----
>> From: sensorml-bounces+robin=nsstc.uah.edu at opengeospatial.org
>> [mailto:sensorml-bounces+robin=nsstc.uah.edu at opengeospatial.org] On 
>> Behalf Of Johannes Echterhoff
>> Sent: Thursday, June 21, 2007 9:27 AM
>> To: sensorml at opengeospatial.org
>> Subject: [SensorML] SweCommon: Time
>>
>> Hi.
>>
>> I have a question concerning the possible meanings of swe:Time. Such 
>> an element can have four different representations: a string (before, 
>> after, now or unknown from gml:TimeIndeterminateValueType), a double, 
>> xs:data, xs:time or xs:dateTime.
>>
>> The meaning of each of the possible representations is quite different:
>>
>>     * gml:TimeIndeterminateValueType does not provide a specific time
>>       instance but rather an indeterminate value (as the name says)
>>     * The double value would always have to be computed with respect to
>>       the given referenceFrame. This could result in a time instance but
>>       could also be a duration or recurring time depending on the
>>       reference frame, or am I missing something?
>>     * xs:date defines a duration (one-day long) at a specific date (e.g.
>>       2007-06-07).
>>     * xs:time represents an instant of time that recurs every day.
>>     * xs:dateTime finally represents a specific instance of time.
>>
>> My question is: was it intended to allow all of these different 
>> meanings for the swe:Time element? I thought that swe:Time would 
>> represent an instance of time in the end, but now I am no longer sure
>>     
> about that.
>   
>> Best regards,
>>     Johannes
>>
>> --
>> Johannes Echterhoff
>> Institute for Geoinformatics (IfGI), University of Muenster, Germany 
>> Robert-Koch-Str. 26-28, D - 48149 Muenster
>>
>> Fon: +49 (0)251 83 39761
>> Fax: +49 (0)251 83 39763
>>
>> IfGI-site: http://ifgi.uni-muenster.de/
>>
>> _______________________________________________
>> SensorML mailing list
>> SensorML at opengeospatial.org
>> https://mail.opengeospatial.org/mailman/listinfo/sensorml
>>     
>
> _______________________________________________
> SensorML mailing list
> SensorML at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/sensorml
>
>   


More information about the SensorML mailing list