[VOTE] restructure date-time value descriptions
Peter McCartney
peter.mccartney at asu.edu
Tue Nov 5 12:29:20 PST 2002
I'm going to vote approve because 1) i dont want to block the process and 2)
i failed to get my voter registration changed in time after moving so i want
to be able to vote on SOMETHING today.
However, if there are any other dissenters, then i would count my self among
them and will provide some alternates anyway:)
Its simply opaque to me why this datetime domain is put in ordinal versus
interval. we have users that treat this information as interval; we have
textbooks that describe this as interval. I think we make ourselves look
silly calling it ordinal. Since we've gone to the trouble of defining a
specialized structure to handle datetime outside of stmml, then why cant it
be a choice under interval where it makes intuitive sense? Or, why cant it
simply be a custom unit?
In this context, I do not see the feasibility of asking people to fill in
stmml compliant xml to define custom units. Without a way to relate my
custom units to types defined in the dictionary, how can i ever expect to
relate these to anything else? Who's to say i dont define a redundant
unitType and give it a different parentSI? how will i ever translate a
custom unit to one defined in the another dictionary?
With respect to dateTimeDomain, i think you are mixing physical with logical
again. if i have data stored in a dateTime container in some binary file
structure, the string representation of that data has nothing to do with
anything. I can request the data in any string representation you want. I
see no gain in understanding of the data by using the formatString element.
I DO see some advantage to indicating the precision (sorry, i cant think of
an alternate word!) of the measurement - that is, is it to the year, the
month, the day, the hour, etc. how do i describe the domain of a time field
that is not using the date portion? (internally, sql server represents 4:10
pm as 4:10 pm on jan 1 1980. or a time field that is ignoring the am/pm
portion?
While we have attribute.xsd open, i would also ask why don't we have numeric
domain as a possible option under ordinal? don't you think people will
complain about not being able to express a range of ranks as 1 through 5? I
know I will!!
Also, Im rather suprised by the radical changes in numericDomain. what's up
with the optional choices? and what happened to the ability to define
discontinous ranges? a much better (and less changed) model would be:
<numericDomain numberType=whole>
<range exclude=false>
<min>0</min>
<max>100</max>
</range>
<range exclude=true>
<min>1</min>
<max>49</max>
<range>
</numericDomain>
This defines a domain of 0, 50-100
is it clear that users won't confuse domain statements and the
missingValueCode entries?
the docs for the latter are clear but i havent looked to see if the inverse
is true.
I realize im probably lagging behind the process in the last couple of
weeks, but once again, I feel we're making extreme changes to something we
told everyone we were done with. I have more questions about how to fill in
data than have been answered by all this.
To say something positive,i do like the integration of units and domain
into measurement scale - im just worried about hanging our hats on things
like stmml and dateTimeDomain that seem very immature at this point.
Peter McCartney (peter.mccartney at asu.edu)
Center for Environmental Studies
Arizona State University
480-965-6791
> -----Original Message-----
> From: Matt Jones [mailto:jones at nceas.ucsb.edu]
> Sent: Tuesday, November 05, 2002 12:13 PM
> To: eml-dev
> Subject: [VOTE] restructure date-time value descriptions
>
>
> After our long discussions about date-time values, and Tim's
> excellent
> treatises on that subject and units, I think we are coalescing on the
> idea that date-time values are most appropriately modeled as ordinal
> values (the deeper underlying issues with measurementScale
> notwithstanding). Date-time values are ordered, but we seem to agree
> that one cannot do arithmetic calculations on them without
> parsing them
> and converting them to an interval scale such as "seconds since 1970".
>
> I have modified the eml-attribute.xsd file (yes, again!) to
> reflect this
> emerging concensus. You can see it in cvs at:
>
> http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/eml/em
> l-attribute.xsd?rev=1.93&content-type=text/plain
>
> Using this new schema, a date-time attribute is described in eml like
> this (taken from the eml-sample.xml file):
>
> <attribute id="att.2">
> <attributeName>year</attributeName>
> <attributeLabel>year</attributeLabel>
> <attributeDefinition>The year the data was collected
> </attributeDefinition>
> <storageType>gYear</storageType>
> <measurementScale>
> <ordinal>
> <dateTimeDomain id="dd.2">
> <formatString>YYYY</formatString>
> <minimum>1944</minimum>
> </dateTimeDomain>
> </ordinal>
> </measurementScale>
> </attribute>
>
> I would like to ask for a vote to determine this issue once
> and for all
> so we can release EML, especially as we were scheduled to release the
> final version of EML tomorrow! So, here it is:
>
> VOTE: The final release of EML should include the changes to
> representation of date-time values that were made in revision 1.93 of
> the eml-attribute.xsd file. This includes moving date-time value
> descriptions to the ordinal measurementScale, and moving the format
> string into the DateTimeDomain description.
>
> You should vote one of the following before the end of
> business Wednesday:
> Approve: I understand and agree with the date-time change proposal
> Neutral: I am neutral, or don't have a solution to propose
> Disapprove: I block this from occurring, and have a solution
> to propose
>
> If you vote Neutral or Disapprove, it would be great to get comments
> from you as to why (e.g., if you vote neutral just because
> you haven't
> been following the discussion, it would be good to know that), and
> proposed alternatives.
>
> Project member Vote
> --------------- ---------
> Tim Bergsma
> Chad Berkley
> David Blankman
> Matthew Brooke
> James Brunt
> Scott Chapal
> Corinna Gries
> Daniel Higgins
> Matthew Jones approve
> Chris Jones
> Peter McCartney
> Ken Ramsey
> Mark Schildhauer
>
> Thanks,
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20021105/fd17aa86/attachment.htm
More information about the Eml-dev
mailing list