[DDI-SRG] Discussion on BUG 114

[Wendy Thomas]

The decision was made in Dagstuhl that the link path between a physical 
instance and a logical record is as follows:

PhysicalInstance-->BaseRecordLayout-->PhysicalSegment-->LogicalRecord

I'm doing more work on this today and will make this clear....or clearer. 
PhysicalSegment is necessary to handle files with large numbers of ncubes 
in a single file. Not only can there be multiple segments, but parts of an 
ncube may fall in different segments due to its size. In the case of a 
complete single cube (for example when geography is described part of the 
cube and there is only the one "case"), the physicalsegment would be the 
cube entity stored as a string (single record), a multi record file with 
one of the dimensions providing the record identification by its value in 
the file (ncube_recordlayout or tabular_recordlayout).

Wendy


On Fri, 1 Feb 2008, Joachim Wackerow wrote:

> This looks like a very clean solution, which takes advantage from XML
> hierarchy/nesting.
>
> I have just a question regarding GrossRecordStructure in
> inline_ncube_recordlayout.
>
> While the GrossRecordStructure with LogicalRecordReference and
> PhysicalRecordSegment offers a great flexibility for the type of data
> order external to DDI, I still don't understand the sense of
> GrossRecordStructure in inline_ncube_recordlayout. The data is inline in
> inline_ncube_recordlayout, there is no GrossRecordStructure.
>
> Suggestion:
> The logical product can be referenced directly from RecordLayout (only
> in inline_ncube_recordlayout).
>
> RecordLayoutType
>    LogicalProductReference 1..1
>    NCubeInstance 1..n
>       ADD DefaultMeasureValue 1..n
>       DataItem 1..n
>         REMOVE NCubeInstanceReference  [*** see note below]
>         CHANGE MeasureValue to AlternateMeasureValue 0..n
>
>
> Question regarding ncube_recordlayout and tabular_ncube_recordlayout:
> Do I understand it right, that here LogicalRecordReference and
> PhysicalRecordSegment make sense for a complex order of ncubes in one file?
>
> Achim
>
> Wendy Thomas wrote:
>> This approach should be taken for ncube_recordlayout,
>> inline_ncube_recordlayout, and tabular_ncube_recordlayout
>>
>> On Thu, 31 Jan 2008, Wendy Thomas wrote:
>>
>>> To make this functional DataItem should be nested in NCubeInstance. With
>>> these two items as siblings, the advantage of a DefaultNCubeReference and
>>> DefaultMeasure is limited. While helpful for files containing single
>>> NCubes a large number of very large files contain multiple NCubes with
>>> their contents strung out in a single record. The need as expressed above
>>> is accurate, but the solution is only half-way there.
>>>
>>> Alternate suggestion is to
>>>
>>> RecordLayoutType
>>>    PhysicalRecordSegmentReference 1..1
>>>    NCubeInstance 1..n
>>>       ADD DefaultMeasureValue 1..n
>>>       DataItem 1..n
>>>         REMOVE NCubeInstanceReference  [*** see note below]
>>>         CHANGE MeasureValue to AlternateMeasureValue 0..n
>>>
>>>
>>>
>>> This means that a RecordLayout for NCubes would contain a reference to its
>>> PhysicalRecordSegment which provides the link back to the LogicalRecord
>>> description.
>>>
>>> Each NCube in the PhysicalRecordSegment is described as a unit,
>>> NCubeInstance.
>>> EAch NCube Instance would provide its MeasureValue (or MeasureValues in
>>> the case of data stored as an ordered array for each cell). The DataItems
>>> could override the MeasureValues (for example a cell with an alternate
>>> measure or perhaps containing an incomplete or misordered array)
>>>
>>> ***DataItem would not need to reference an alternate NCube as there would
>>> be no way to include a Cell that has no previously defined relationship to
>>> the NCube cells.
>>>
>>>
>>> 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
>
> _______________________________________________
> 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