Consider evolving or removing Period from data model

The Period entity and pattern have under-performed.  Period does provide an effective way to segment out optional dates in some cases, but it's interaction with the data model key system drives complexity for vendors and others required to submit data.

Consider the following case, which came up in the TEA project. (This code sample is written in MetaEd for convenience but I want to reinforce that MetaEd is not an official language of Ed-Fi standards)

Association Student additions

   common StudentCensusBlockGroupSet

   is required

   ... 

Common Type StudentCensusBlockGroupSet      

    shared string StudentCensusBlockGroup

        documentation "The value of the block group."

        is part of identity

    common Period

       documentation "The period for which the value was effective."

             is required collection

The issue here is that submitting Periods like this is awkward: a SIS has to organize these into a history for each value (creating additional SIS business logic). Much simpler is:

Association Student additions

    common StudentCensusBlockGroupSet

        ... 

Common Type StudentCensusBlockGroup

     shared string StudentCensusBlockGroupValue

        documentation "The value of the block group."

        is part of identity

    date BeginDate

        documentation "The effective date."

        is part of identity

    date EndDate

        documentation "The date at which the value was not effective."

        is optional

We showed a SIS provider these two models and received this feedback:

However, from a general perspective, student data that is tracked historically is usually stored in a child table that references back to a student or student enrollment.  Records in the table usually include one or more related values (e.g. Learning Modality), a required start date and an optional end date.  This corresponds to the second model.

Using the first model for e.g. Learning Modality, would mean that if a student were Virtual for Aug-Sep, then On Campus Oct-Dec, then Virtual Jan-Feb and On Campus Mar-May, the SIS database would have four records, but these would be published as two parent records, each with two child periods.

Using the second model would mean that four records would be published, pretty much directly from the source system.

While there is a degree of elegance to the first model, I think the second will typically be easier to work with.