STMML units and date/time values
Peter Murray-Rust
pm286 at cam.ac.uk
Fri Oct 18 14:11:30 PDT 2002
At 09:29 18/10/2002 -0800, Matt Jones wrote:
>Peter,
>
>Again, thanks for your reply. Unfortunately, I don't think I conveyed my
>fundamental problem.
>
>I completely understand how to specify values that are in units derived
>from the fundamental SI unit of time (second), such as minute, hour,
>etc. However, attributes that represent calendar dates are a different beast.
>
>In the case I was describing, the value is not directly derived from the
>SI unit second, but rather generally represents both a statement of
>elapsed time (e.g., seconds since the start of the calendar) and some
>implied knowledge of when that calendar starts and how long its units
>were. It is also expressed in units which are not of constant duration
>across the calendar (e.g., each month in a year contains a different
>number of seconds, and the same month across years can contain different
>numbers of seconds). Thus, for "date" or "datetime" values there is a lot
>of implied information about the calendar: 2002-10-10 17:34:45 represents
>an elapsed time since the start of the calendar that is calculated by:
> ((2002*averageSecondsPerYearThrough2002) +
> (10*averageSecondsPerMonthThroughOctober) +
> (10*secondsPerDay) + 17*60*60 + 34*60 + 45).
>Note that we can't use averageSecondsPerYear because that is affected by
>leap years in weird ways, and we can't use averageSecondsPerMonth because
>that differs between the first ten months and all twelve months. Luckily,
>I think days, hour, and minutes are all constant durations, even though
>month and year are not.
>I know this to be a very difficult area and have deliberately kept out of
>it. The first place I would look would be the Java documentation for
>Calendar class:
public abstract class Calendar
extends Object
implements Serializable, Cloneable
Calendar is an abstract base class for converting between a Date object and
a set of integer fields such as YEAR, MONTH, DAY, HOUR, and so on. (A Date
object represents a specific instant in time with millisecond precision.
See Date for information about the Date class.)
Subclasses of Calendar interpret a Date according to the rules of a
specific calendar system. The platform provides one concrete subclass of
Calendar: GregorianCalendar. Future subclasses could represent the various
types of lunar calendars in use in many parts of the world.
Like other locale-sensitive classes, Calendar provides a class method,
getInstance, for getting a generally useful object of this type. Calendar's
getInstance method returns a Calendar object whose time fields have been
initialized with the current date and time:
Calendar rightNow = Calendar.getInstance();
A Calendar object can produce all the time field values needed to implement
the date-time formatting for a particular language and calendar style (for
example, Japanese-Gregorian, Japanese-Traditional). Calendar defines the
range of values returned by certain fields, as well as their meaning. For
example, the first month of the year has value MONTH == JANUARY for all
calendars. Other values are defined by the concrete subclass, such as ERA
and YEAR. See individual field documentation and subclass documentation for
details.
I would expect that it is possible to calculate differences between dates
in seconds using the Java classes. (I have seen criticism of their
navigability, but believe them to be sound.) Thus if two datetimes are
given it should be possible to compute the delta in seconds precisely.
I think that second should be unique. minutes and hours are probably strict
multiples. I think days, months and years are fragile as they may relate to
solar or siderial with significant error. For this I would consult the NIST
website.
>OK, so, the question is:
> What is the unit for a scalar date-time value like "2002-10-10 17:34:45"?
I don't think it has units - it has a dataType of xsd:dateTime
>How can this unit be defined in STMML? How is this unit related to the
>fundamental SI unit of second?
>
Something like
<myScalar title="start event" dataType="xsd:dateTime">2002-10-10
17:34:45</myScalar>
<myScalar title="end event" dataType="xsd:dateTime">2002-10-10
18:34:45</myScalar>
should be consistent with
<scalar dataType="xsd:decimal" title="duration of event"
units="unit:s">3600</scalar>
There is a difference between scales and absolute values. Thus for
temperature 0degC = 273.15K (BTW I mistyped this in the paper - please
correct). But heat capacity is energy/temperature difference so 11kJ/K =
1 kJ/C
>I'm pretty confused about this. Thanks for the help.
So am I but this has helped.
P.
>Matt
>
>Peter Murray-Rust wrote:
>>At 15:04 17/10/2002 -0800, Matt Jones wrote:
>>
>>>Peter,
>>>
>>>Thanks for the followup earlier on STMML and its use in our Ecological
>>>Metadata Language. We've run into another issue. Lots of ecological
>>>data include attributes with date, time, or date-time values. These are
>>>obviously numeric expressions of elapsed time on an implied calendar
>>>scale (e.g., Gregorian). How can we define an STMML unit for such an
>>>attribute?
>>>
>>>Example data
>>>
>>>Year Date Time DateTime
>>>---- ---------- -------- -------------------
>>>1999 10-10-2002 17:34:45 10-10-2002 17:34:45
>>>2002 03-04-1943 07:54:00 01-02-2003 08:34:22
>>>
>>>Also, how would such a unit relate to the use of an STMML "dataType" of
>>>type "xsd:gYear" or "xsd:gDate"? What is an STMML dataType in relation
>>>to the domain of an attribute and its precision?
>>Excellent question! I haven't actually hacked this in software so this is
>>a first pass... There are two separate approaches for time.
>>STMML allows users to define scalar dataTypes to which they can attach
>>scientific units. The scientific units are based on the SI system. We
>>are working closely with NIST and CODATA in this area and will adopt
>>their approach whenever it is formalized. So for simple chemists who
>>measure things in "seconds" or "days" it is straightforward. Example:
>><scalar dictRef="mydict:halflife" units="units:year" title="plutonium
>>halflife">25000</scalar>
>>would be OK.
>>** We already have a demo application of conversion between units using
>>XSL which we can send to you along with our growing dictionary. ***
>>The W3C deliberately did not introduce units into Schemas. IMO this was a
>>pity, but... However they did introduce dataTypes, and for Time - based
>>on ISO8601 - this implies units.
>>http://www.w3.org/TR/NOTE-datetime
>>expounded in
>>http://www.cl.cam.ac.uk/~mgk25/iso-time.html
>>So you could also define your own scalar by:
>><scalar dataType="xsd:gYear" title="moon landing">1969</scala>
>>You could then validate it using W3 Schema tools.
>>I think Time is the only W3C data type with implied units.
>>The advantage of this is it is standard. But you would have to write your
>>own software (probably) to do conversions. XML is also closely related to
>>Java and it is almost certain that Java tools will convert reliably from
>>ISO8601. But the actual implementation is hard to navigate through.
>>
>>>For example, if I specify that an attribute "X" measured on an
>>>"interval" scale has a domain with a minimum value of 0 and a maximum
>>>value of 10 in units of "meter" with a precision of "0.5 meter" then I
>>>know pretty much everything I need to analyze it. Can you map the STMML
>>>terminology (e.g. dataType, unit) onto this example? That would be
>>>extremely useful to me.
>>
>><scalar title="The universal X" dictRef="mydict:x123" min="3.22"
>>max="4.22" errorBasis="range" units="unitdict:met01"
>>dataType="nonNegativeNumber" >3.72</scalar>
>>Will record the data but only the lower constraints. We would define the
>>constraints either in a dictionary or a schema (we hope to use the
>>dictionary as the primary definition because schemas are so horrible).
>>In a schema you would have to write something like:
>><xsd:simpleType name="xValueType" id="st.xValueType">
>> <xsd:annotation>
>> <xsd:documentation>
>> <div class="description">An X Type</div>
>> </xsd:documentation>
>> </xsd:annotation>
>> <xsd:restriction base="xsd:decimal">
>> <xsd:minInclusive value="0.0"/>
>> <xsd:maxInclusive value="10.0"/>
>> </xsd:restriction>
>></xsd:simpleType>
>>
>>This is horrible to most sentient humans (Henry and I spend our evening
>>hacking this sort of stuff) so we want to put it in the dictionaries. The
>>initial design of dictionaries didn't cater for data types so we want to
>>develop something like:
>>In a dictionary we might expect:
>><entry id="xxx">
>> ...An X object ...
>> <dataType extends="xsd:decimal" min="0" max="10" />
>>and then autogenerate the stuff above. It's high priority but not yet
>>hacked. I will send you a copy of our latest demo - I won't post it here
>>because the list is copied in and we haven't yet published it...
>>If this makes sense and you have units you can add to the dictionary that
>>would be exciting :-) We hope to post this on sourceforge shortly...
>>
>>P.
>>
>>>Thanks for the help,
>>>Matt
>>>
>>>--
>>>*******************************************************************
>>>Matt Jones jones at nceas.ucsb.edu
>>>http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
>>>National Center for Ecological Analysis and Synthesis (NCEAS)
>>>
>>>Interested in ecological informatics? http://www.ecoinformatics.org
>>>*******************************************************************
>>
>>_______________________________________________
>>eml-dev mailing list
>>eml-dev at ecoinformatics.org
>>http://www.ecoinformatics.org/mailman/listinfo/eml-dev
>
>
>
>--
>*******************************************************************
>Matt Jones jones at nceas.ucsb.edu
>http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
>National Center for Ecological Analysis and Synthesis (NCEAS)
>
>Interested in ecological informatics? http://www.ecoinformatics.org
>*******************************************************************
More information about the Eml-dev
mailing list