How small or big can a Statistical Program be?

[michaeladenk]

Related to the previous issue. Consider again the existing data acquisition exercise with a few gaps (missing values?) being identified and then being collected with a different instrument (in our case: "harvest existing data") and via a different mode (e.g. "web scraping"). Calling this additional (auxiliary) data acquisition a new "statistical program" seems a bit disproportionate to me, but maybe it's just the wording. Maybe the BusinessCase could also initiate an Activity (i.e. sth. at a lower level than Program)? This also depends on how we define those different levels.

[victory1805]

At the moment the StatisticalProject is defined as a (possibly repeated) time bound activity. A Program can have many Projects and currently the model does not state that there can be only one Project for a time period. So, this could be handled within the same Program by another (Data Acquisition) Project. Clearly the two Projects may be combined for the next phase but this is also handled as it is a different Project (with a different time bounding)

[brucefraser]

I think I am aligned with the above comment. A single statistical project can have multiple aquisition projects, each of which can have multiple instruments. I think it would be possible to say the scenario illustrated is a single acquisition project with multiple instruments but it seems much neater to say we have 2 aquisition projects within the one statistical project. Especially as within another issue I suggest an acquisiton project need not necesarily have an instrument attached to it (eg for transactional data)

[victory1805]

The link between Acquisition Activity and Data Collection/Instrument etc. has not yet been made on the model. I think it would be neater if one Acquisition Activity results in (zero or) one data collection using one Instrument type which may be administered via many Data Sources. The Project can have many activities so the Poject could do web scraping, questionnaires, mining admin registers etc.

[adamstatsnz]

I think this is one of the key iussues we have to get right. I think that we must consider how 'bitty' the nformation may end up if we impose the constraint that one acquistion project has one instrument. I wouldn't like to suggest that the individualk and household questionnaires part of Census are in different projects! I'd prefer a model where an acquistion project could have multiple instruments to cope with these situations and we clearly define an acquistion project around collection for a particular purpose at a particular time.

[victory1805]

The Acquisition Project can have many Acquisition Activities. The suggestion is that each activity is related to just one instrument. So, the Census is a Project with multiple Activities. One is Household, another is Individual. However, it doesn't have to be like this. We should not impose rules if there is no reason for it. But a good reason could be that that the Activity is a good place to link information that is related to the activity and not to the instruments etc. I think that maybe the Acquisition Activity is like the Data Collection in DDI. But we will see.

[brucefraser]

In this case ... do we need both Acquisition Activity and Instrument? Acquisition Activity seems to serve the role of Instrument, plus it would contain information when there is no explicit Instrument

[victory1805]

I suggest this be closed as the model has changed. I have posted a new issue to discuss terminology of Program/Profile/Project/Activity

[michaeladenk]

I wouldn't want to close this as it collects many arguments. The new item with the comment from the external feedback seems a bit different to me. But if we continue discussion there we can still close this one. On the content: Bruce's last question makes the connection to the instrument component of the model. I don't think that activity and instrument are equivalent. I thought that a questionnaire is an instrument, and a "report form" (a template used to collect tabular data) is an instrument, and ... what else? An acquisition activity uses an instrument (or multiple instruments?). Maybe you are right, Chris, and we should continue these different issues based on the current version of the model in a new thread (or multiple threads).

[brucefraser]

My comment could be re-phrased as "If we have an Instrument object then why do we need an Acquisition Activity object", ie what information would Acquisition Activity hold, and could this information just be incorporated as extra characteristics within the Instrument object.

Certainly the Instrument object would have to be generic enough to cover a request for administrative data or statistical aggregates - but rather than create a new object for this can it be incorporated into the Instrument object in some way?

When I tried thinking about inputs and outputs by GSBPM phase for my IGOE spreadsheet (on the wiki), I identified the following inputs to the collect phase:

Data collection questions, modules and instruments Provider induction/approach materials Frame / Population specification Sample design (specification) Fully configured workflows Training materials and documentation Paradata/MI processes

So these are the objects I think - plus extensions/analogues to cover administrative data collection and other scenarios. What is an Acquisition Activity object? Does it just hold pointers to all these other objects?

It just highlights that we need to define the objects and get at least a rough idea of the characteristics contained within each object, then we are better placed to discuss their relationships and how they look within a UML diagram.

[adamstatsnz]

My definition of an instrument would just be the tool that is used to gather the dasta without the surrounding information. I would think that you nwould want to be able to use the same questionnaire but potentially change the sample design etc.?

[brucefraser]

I agree - I have the same defintion of Instrument. My list above identifies 7 (or more) objects, I'm not suggesting all this information is contained in an Instrument object.

[michaeladenk]

Should be reviewed when finalizing the Instrument part of the model.