[DDI-SRG] recommended resolutions for open bugs
I-Lin Kuo
ikuoikuo at gmail.com
Mon Dec 17 12:00:16 EST 2007
I'm siding with Wendy on this one. Inheriting from an enclosing element
makes sense when the containing element is part of the context of the object
of interest, and the containment relation is a natural one, and the context
needs to be dragged along as the object of interest is moved. In this case,
I don't think that the containment of LifeCycleEvent by Archive is a
necessary fixed relationship. I can imagine cases where LifeCycleEvents are
moved around and rearranged, so I think it's better that they be as
self-contained as possible.
On Dec 17, 2007 10:30 AM, Wendy Thomas <wlt at pop.umn.edu> wrote:
> Pascal
>
> I think this is error prone. You are making an assumption that there will
> be standard software tools that will not only create these transportable
> copies but that will be aware that this information needs to be added when
> this takes place. I think that a large amount of activity will take place
> on home grown systems that subset or otherwise package data for delivery
> others and that this step will get lost in the shuffle. From experience I
> can say that to many local programmers, if its not something they'll have
> to deal with the consequences of then its not important to do.
>
> Wendy
>
>
> On Sat, 15 Dec 2007, Pascal Heus wrote:
>
> > Wendy:
> > There is no question that we need this element in the LifeCycleEvent,
> > just doesn't need to be mandatory (can default to the wrapping Archive
> > element's organization reference). Tools should take care of keeping
> > this consistent if you ever copy LifeCycleEvent elements from one
> > Archive to another.
> > *P
> >
> > Wendy Thomas wrote:
> >> Pascal,
> >>
> >> Thanks for the clarification. I must have been looking at the worng
> >> ArchiveOrganizationReference. I think...but will definately
> >> check...that the organizational reference in a LifeCycleEvent is there
> >> because this in information that may persist as a data file and/or
> >> metadata moves from Archive to Archive. For example the Census Bureau
> >> may be the originating Archive and entered specific LifeCycleEvents.
> >> Then it goes to Archive A which does some particular processing or
> >> updating based on corrections issued from the Census Bureau. Archive B
> >> then obtains a copy from Archive A and creates local copies in a
> >> different statistical package. At this point the LifeCycleEvents could
> >> contain events performed by three different Archives. At leass I
> >> believe this was the intention.
> >>
> >> Wendy
> >>
> >>
> >> On Fri, 14 Dec 2007, Pascal Heus wrote:
> >>
> >>> Wendy:
> >>> here are my comments logged in Mantis for bug #87
> >>> *P
> >>>
> >>> (1) The Archive element already has a mandatory ArchiveOrganization
> >>> with an ArchiveOrganizationReference. If the LIfeCycleEvent is in an
> >>> Archive, why do I need to repeat the organization for the event as it
> >>> will most likely be the archive itself?
> >>>
> >>> (2) I maintain that he name AgencyOrganizationReference is not
> >>> meaningful (what's an AgencyOrganization?). Suggest renaming to
> >>> EventOrganizationReference?
> >>>
> >>>
> >>> Wendy Thomas wrote:
> >>>> BUG 86
> >>>> Implement proposed solution
> >>>>
> >>>> BUG 87
> >>>> This is a very specific OrganizationReference as it is the
> >>>> OrganizationReference of the Archive. We have made that a required
> >>>> element as we now require the "Archive" creating the instance to
> >>>> identify itself.
> >>>> RECOMMENDED ACTION: Do not change.
> >>>>
> >>>> BUG 88
> >>>> Implement proposed solution
> >>>>
> >>>> BUG 89
> >>>> Implement proposed solution
> >>>>
> >>>> BUG 90
> >>>> Implement proposed solution
> >>>>
> >>>> BUG 91
> >>>> Implement proposed solution
> >>>>
> >>>> BUG 92
> >>>> Is this a final review item prior to publication??
> >>>>
> >>>> BUG 93
> >>>> Make DataSet a valid subsititution for BaseRecordLayout
> >>>>
> >>>> BUG 94
> >>>> Implement proposed solution
> >>>>
> >>>> BUG 95 & BUG 97
> >>>> Are you requiring people to create an external code list for things
> >>>> that might want a controlled vocabulary?? this seems overkill in
> >>>> places such as this where I just want to say its a paper instrument
> >>>> (xs:string) and now must provide a code list??
> >>>>
> >>>> BUG 98 & BUG 96
> >>>> We should probably look at this as an expanded DateType allow for a
> >>>> controlled vocabulary for a "frequency" attribute or element.
> >>>>
> >>>> BUG 100
> >>>> Take action stated
> >>>>
> >>>> 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
> >>
> >
> > _______________________________________________
> > 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
> _______________________________________________
> DDI-SRG mailing list
> DDI-SRG at icpsr.umich.edu
> http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg
>
--
I-Lin Kuo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.icpsr.umich.edu/pipermail/ddi-srg/attachments/20071217/6323bc0f/attachment.html
More information about the DDI-SRG
mailing list