[DDI-ADG] time spreadsheet

[Katherine McNeill-Harman]

Couple of comments about the new version of the date spreadsheet:

- Wendy's explanation of calendar makes sense and I think we should keep it 
in.  However, in ultimate implementation I'm we might also consider it as 
an attribute of the other dates (i.e. if the original date was according to 
the Jewish calendar, not sure if it'd then be translated into Gregorian 
calendar and be repeated).

- R.e. security, it seems like the main differences between that and 
embargo are 1) it can apply at the variable level and 2) it can apply 
differently to different groups.  And it seems like it has two parts, both 
a release date and the category of users to which it applies (I guess the 
latter is an attribute).  So it seems like we should keep it, although I 
wonder if it could be combined into the same element as the embargo, maybe 
something like access restrictions, that could contain both dates and 
categories of people?

- In this spreadsheet, should we have it written down explicitly at the top 
that all dates will be in ISO format?  Just to have it officially written 
somewhere.

- I'm noticing that none of the TemporalCoverage or AdministrativeDates 
dates are required.  Is there any that we feel like we could require, e.g. 
reference?  Conversely, they are all listed as potentially going up to 
N.  Is this also what we want?  Some items could repeat if they can apply 
to different variables or values (e.g. ReferenceDate), but some other 
things I think would only happen one time per file (e.g. publication date).

- PublicationDate appears both in TemporalCoverage and 
AdministrativeDates.  Was this repeat deliberate?  If not, I guess we could 
keep it in AdministrativeDates.

- I'm not entirely clear on a couple of things about DateType.  First, is 
it a sub-element or attribute of those other dates?  Also, I see the 
attempt to distinguish single dates vs. date ranges, but I'm a little 
confused as to how it works.  If there's a single date they fill out only 
Date? But then Start Group seems to be a required element, so they'd also 
have to put the single date as the start/end date?

- Small notes on frequency: 1) I imagine we'd want Occurrence to be 
0..1.  And do we need to we say in the note that it's a reusable class on 
its own (i.e. that it can be applied at the variable level)?

Kate

At 03:03 PM 8/17/2005 -0500, Wendy Thomas wrote:
>Don't know...lets see how it shakes out. Does it make sense to have all
>the dates in one place except for the geography? I guess I thought that
>the date in Geography was a reference to the date(s).
>
>wendy
>
>
>On Wed, 17 Aug 2005, J Gager wrote:
>
> > I purposefully omitted Geography, as we included a Date in the Geography
> > structure.  Is there an issue with that?
> >
> > -----Original Message-----
> > From: ddi-adg-bounces at icpsr.umich.edu
> > [mailto:ddi-adg-bounces at icpsr.umich.edu] On Behalf Of Wendy Thomas
> > Sent: Wednesday, August 17, 2005 3:45 PM
> > To: ddi-adg at icpsr.umich.edu
> > Subject: [DDI-ADG] time spreadsheet
> >
> >
> > Need to include "geographic time" in the list. This can be different
> > than the data time stamp. Aggregate data is often retabulated for new
> > goegraphies such as congressional districts (ex. 2000 data for 2002
> > congressional district geography).
> >
> > Calender date: This was provided in order to allow for alternative
> > calender systems particularly if relevant to the data. This is
> > hypothetical but if I were collecting data related to a specific date in
> > the Jewish Calender I need to know that date. This is particularly true
> > if I were collecting over a number of years or months as the
> > relationships between the Jewish Calender and Georgian calender shift
> > and you'd never see the relationship if using only the Georgian
> > calender.
> >
> > While this seems a bit of a stretch, we have frequently discussed the
> > ability to use DDI for historical data derived from historical
> > administrative records...kept in the calender of the time and place.
> >
> > SECURITY: version 2.0 4.3.4, 4.4.6
> >
> > security?    (ATT == ID, xml-lang, source, date)
> >
> > <!-- 4.3.4 Security (security)
> > -->
> > <!--
> > -->
> > <!-- Provides information regarding levels of access to the variable,
> >       e.g., public, subscriber, need to know. The ISO standard for
> >       dates (YYYY-MM-DD) is recommended for use with the date
> >       attribute.
> > -->
> >
> > <!ELEMENT security   (#PCDATA | %a.phrase; | %e.form;)*
> > >
> > <!ATTLIST security
> >      %a.global;
> >      %a.date;
> > >
> >
> >
> >
> >
> > Wendy L. Thomas                          Phone: +1 612.624.4389
> > Data Access Core Director             Fax:   +1 612.626.8375
> > Minnesota Population Center              Email: wlt at pop.umn.edu
> > University of Minnesota
> > 50 Willey Hall
> > 225 19th Avenue South
> > Minneapolis, MN 55455
> >
> > _______________________________________________
> > DDI-ADG mailing list
> > DDI-ADG at icpsr.umich.edu
> > http://www.icpsr.umich.edu/mailman/listinfo/ddi-adg
> >
> >
> > _______________________________________________
> > DDI-ADG mailing list
> > DDI-ADG at icpsr.umich.edu
> > http://www.icpsr.umich.edu/mailman/listinfo/ddi-adg
> >
>
>Wendy L. Thomas                          Phone: +1 612.624.4389
>Data Access Core Director               Fax:   +1 612.626.8375
>Minnesota Population Center              Email: wlt at pop.umn.edu
>University of Minnesota
>50 Willey Hall
>225 19th Avenue South
>Minneapolis, MN 55455
>
>_______________________________________________
>DDI-ADG mailing list
>DDI-ADG at icpsr.umich.edu
>http://www.icpsr.umich.edu/mailman/listinfo/ddi-adg

___________________________________________
Katherine McNeill-Harman
Data Services Librarian
Dewey Library for Management and Social Sciences
Massachusetts Institute of Technology
77 Massachusetts Avenue, E53-100
Cambridge, MA 02139
mcneillh at mit.edu
617-253-0787