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

[Wendy Thomas]

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)
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)
3) Leave all other dates that whose types are specified by their 
containing element alone.




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