[DDI-SRG] Bug 127 Administrative Date: our comment
Sanda Ionescu
sandai at umich.edu
Tue Feb 19 12:56:44 EST 2008
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
More information about the DDI-SRG
mailing list