STMML units and date/time values
Matt Jones
jones at nceas.ucsb.edu
Fri Oct 18 10:29:24 PDT 2002
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.
OK, so, the question is:
What is the unit for a scalar date-time value like "2002-10-10
17:34:45"? How can this unit be defined in STMML? How is this unit
related to the fundamental SI unit of second?
I'm pretty confused about this. Thanks for the help.
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