[DDI-SRG] Bug 127 Administrative Date: our comment

[Sanda Ionescu]

Wendy,
see below. 


Sanda Ionescu
ICPSR
University of Michigan
P.O. Box 1248
Ann Arbor, MI 48106

Phone, Fax: 734-615-7890 
-----Original Message-----
From: Wendy Thomas [mailto:wlt at pop.umn.edu] 
Sent: Tuesday, February 19, 2008 1:20 PM
To: Sanda Ionescu
Cc: ddi-srg at icpsr.umich.edu; Mary Vardigan
Subject: RE: Bug 127 Administrative Date: our comment

so to make sure I have this let me reiterate in a terser format.

1) Remove AdministrativeDate from Coverage leaving only the
ReferenceDate (this effectively removes AdministrativeDateCodeType and
AdminDateCodeType
entirely) -->>YES!!

2) Add an eventType to LifeCycle event allowing for a controlled
vocabulary (recommended vocabulary will contain many of the current
AdministrativeDate values as well as others) -->> THERE IS ACTUALLY AN
"EVENT TYPE" ELEMENT PRESENT RIGHT NOW - CHILD OF LIFECYCLE EVENT. I
thought we could just use it to contain a CV??? - with an additional
option of "Other", of course.

3) Leave all other dates that whose types are specified by their
containing element alone -->> YES!! 
(but, maybe you guys want to consider also adding dates to the
operations described in Processing Event?)




On Tue, 19 Feb 2008, Sanda Ionescu wrote:

>
> Hi, all.
>
> In response to Wendy's description of the issue, and her comments 
> below, here's what we think should happen with Administrative Date:
>
> - Remove Admin. Date from Coverage entirely:
>
> --Coverage reflects the *scope* of the data (time, geography that data

> refer TO..)
>
> -- Define Admin. Date as any date pertaining to the *management* of 
> the data collection - any operations involved in creating, processing,

> analyzing the data, etc.
>
> -All of these "administrative" or "data management" operations may be 
> represented as Life Cycle Events.
>
> -- HOWEVER,  some events have entries of their own in DDI 3.0 
> specifying the type of event: i.e. production, copyright, software 
> use, processing (in ProcessingEvent). All of these, for which there is

> a specific entry, should also have their own Dates (no need to change 
> the element name to "administrative date" - just date should suffice)
>
> -Life cycle events entries should cover other events for which there 
> are no specific entries in DDI 3. A controlled vocabulary should be 
> attached to (or recommended for) EVENT TYPE, NOT DATE!  DDI-CV working

> group can put together a recommendation. This new CV would build on 
> the current admin.date types.
>
> -Then, each of the lifecycle events, should also have its own date 
> (which they actually do right now -so no change would be needed here.)

> No need, again, to call these dates "administrative".
>
> Thanks for addressing this.
>
> Sanda and Mary.
>
>
> Sanda Ionescu
> ICPSR
> University of Michigan
> P.O. Box 1248
> Ann Arbor, MI 48106
>
> Phone, Fax: 734-615-7890
> -----Original Message-----
> From: Wendy Thomas [mailto:wlt at pop.umn.edu]
> Sent: Sunday, February 17, 2008 5:27 PM
> To: ddi-srg at icpsr.umich.edu
> Cc: Sanda Ionescu; Mary Vardigan
> Subject: Bug 127 Administrative Date
>
> AGENDA ITEM for Thursday TIC
> This information has also been uploaded to Mantis. Please read this 
> and comment prior to Thursdays discussion. Please copy all 
> inidividuals to make sure Sanda and Mary stay informed and involved in
this discussion.
>
> Wendy
>
>
> BUG 127 AdministrativeDate Discussion
>
>
> AdministrativeDate is currently used only in TemporalCoverage 
> TemporalCoverage defines the "Description of the temporal coverage of 
> the data described in a particular DDI module."
> TemporalCoverage consists of 2 elements both of type=DateType 
> including the AdministrativeDate and ReferenceDate ReferenceDate 
> contains the The time period to which the data refer. This item 
> reflects "the time period covered by the data, not dates in the life 
> cycle of a study or collection."
> AdminstrativeDate contains "Listing of pertinent coverage dates by 
> type."
> AdminDateCodeType
>   Types of allowable dates.
>     "DataProcessing" = Date when data was processed.
>     "PilotDate" = Dates of a pilot study.
>     "TrainingDate" = Dates of training (interviewer or enumerator 
> training, data processing training, etc.)
>     "EventDate" = Date of a specific event related to the study.
>     "DesignDate" = Date of the study design.
>     "PostAnalysisDate" = Date of post-collection analysis.
>     "PublicationDate" = Date of Publication.
>     "DepositDate" = Date when data and/or documentation were deposited

> in an archive or library.
>     "ReleaseDate" = Date of data release.
>     "ProductionDate" = Date of data or metadata production.
>     "HarvestingDate" = Date of data harvesting.
>     "CollectionDate" = Date of data collection.
>     "ReportingDate" = The reporting date of the data
>     "VersionDate" = Date of specific version.
>     "CopyrightDate" = Copyright date.
>     "SoftwareDate" = Version date of software.
>
> When initially created this list was supposed to address all types of 
> administrative dates under the supposition they would all occur in 
> TemporalCoverage. This is no longer the case.
>
>
>
> Citation
>  Has PublicationDate type=DateType
>  Has Copyright Date type=DateType
> LifeCycleEvents
>  Provides for date of Event
>  Does not currently provide a controlled vocabulary for type of event
>
> Recommendation has been made to remove AdministrativeDate from 
> TemporalCoverage and move it to LifeCycle thereby providing a type 
> coded date option to the current date element in LifeCycleEvent.
>
>
>
> DCType substitutionGroups for dc:date
>    "created"
>    "valid"
>    "available"
>    "issued"
>    "modified"
>    "dateAccepted"
>    "dateCopyrighted"
>    "dateSubmitted"
>
> These appear to map to the following AdminDateCodeType
>    "created" = ProductionDate
>    "valid" ??
>    "available" = ReleaseDate [internal embargo date]
>    "issued" = ReleaseDate
>    "modified" = VersionDate
>    "dateAccepted" = DepositDate
>    "dateCopyrighted" = CopyrightDate
>    "dateSubmitted" = DepositDate
>
>
> DDI appears to have multiple ways to reflect various activities.
>
> Citation contains specific copyright and publication dates 
> TemporalCoverage contains ReferenceDate which seems to also be covered

> by "ReportingDate"
> SoftwareDate is contained in all references to or listings of software

> CollectionDate is part of DataCollection Versionable/Maintainable all 
> have VersionDate Labels contain a validForDate DataCollectionEvent 
> contains a DataCollectionFrequency which can be a simple data, range, 
> cycle DataSource has an origin statement including a citation and 
> therefore publication date for the data source if not collected from a

> population
>
> QUESTIONS:
>
> Should all or some of the Administrative Dates be removed from 
> Temporal Coverage?
> Processing Operations in DataCollection do not have dates, should they

> or are they treated as LifeCycleEvents?
> What dates belong in LifeCycleEvents?
> What dates belong in TemporalCoverage? Consider that Total temporal 
> coverage is declared for the study unit and that other parts (logical 
> product, data collection, physical data structures can constrain 
> temporal coverage to a subset of the study units) How much of what is 
> defined withing the XML should be repeated in the LifeCycleEvent list?
> Is use of AdministrativeDate the best way to provide an optional type 
> code for LifeCycleEvent?
>
>
>
>
>
> 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
>

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