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

[Wendy Thomas]

Based on the exchange below the following will be put forward as a 
recommended action for BUG 127:

NOTE: EventType is already a CodeValueType which is the structure 
that allows for either a string OR a declared controlled vocabulary.

In Reusable:

DELETE   TemporalCoverageType/AdministrativeDate
DELETE   AdminDateCodeType   [not used except in above deleted item]

REVIEW: DataCollection/ProcessingEvent/ContolOperation and Cleaning 
Operation [both of type OperationType] QUESTION: should we add optional 
date here. It would seem that these provide information on how certain 
operations are done and who does them. A date could reflect completion or 
period of the activity. However, it seems like this might more 
appropriately be listed as an event in LifeCycleInformation and the date 
attached there. It is the application of the process to particular 
materials that is the datable event, not the process itself.
      IF the decision is to link the date to the process description itself
      THEN add Date 0..1 to DataCollection/OperationType
      ELSE no additional action required here.

Wendy

On Tue, 19 Feb 2008, Sanda Ionescu wrote:

> 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
>
> _______________________________________________
> DDI-SRG mailing list
> DDI-SRG at icpsr.umich.edu
> http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg
>

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