Implementing the Common Education Data Standard Series – 5

Strategies for data leaders
Gary West

Introduction

Version 2 of the Common Education Data Standards (CEDS) [1] was released in January 2012.  CEDS components include the following:

  • Data Dictionary:  The data dictionary for CEDS contains about 750 data elements (in Version 2) that have been identified as essential for meeting the data goals of early learning agencies, SEAs, and institutions of higher education.  (Two-thirds of those elements address K-12 data needs.)  The data dictionary includes the definitions of the identified elements, the values that those elements may display, and other attributes that are required to provide context and meaning across the domains in which the elements would be used.  The data dictionary can be accessed at http://ceds.ed.gov/elements.aspx.
  • Logical Data Model:  A logical data model describes the relationships of the data elements within individual records that might be stored as part of datasets.  The relationship among data elements is important so users of the data can know which elements are related to which types of records.  Information about the data model can be found at http://ceds.ed.gov/dataModel.aspx.
  • Data Alignment Tool and Other Tools:  A Data Alignment Tool will help your SEA identify the elements within existing datasets and systems that align with the elements in CEDS 2.0.  Through the alignment tool, you can identify which of its existing data elements are perfectly “mapped” to CEDS 2.0 elements, which existing elements are not mapped to CEDS 2.0 elements, and which CEDS 2.0 elements do not exist in your existing datasets and systems.  The Data Alignment Tool requires a user ID and password.  SEA staff can register or login to the Data Alignment Tool at http://ceds.ed.gov/alignmentTool.aspx.
  • XML Schema:  An XML schema for CEDS was released in early Spring 2012, as well.  That schema describes the format in which the actual SEA data may be stored so that it can be imported into and used other types of databases, data systems, and applications.  The XML schema can be downloaded from http://ceds.ed.gov/data/xsd/ceds-v2-nds.xsd.  In addition, you can download SQL scripts may help build a normalized database for CEDS from http://ceds.ed.gov/dataModelNDS.aspx.

Version 3 of the Common Education Data Standards is currently being created, expanding on the existing Version 2, and is scheduled for release in January 2013.  Version 3 will include more elements that can be used to inform teaching and learning, connect to workforce datasets, and integrate elements from other education data standards and data models.

It is not necessary – nor advisable – to wait for the next release of CEDS to begin planning for implementation.  Immediate implementation of CEDS 2.0 will lay the foundation for future versions – and will create capacity for your state education agency (SEA) and your local districts to have a significant impact on the use of data (emphasis on “use”) and on the development of comprehensive software applications that inform teaching and learning, automate federal reporting, support your agency’s accountability flexibility, build meaningful research to guide education strategies and practices, and to inform all education stakeholders.


Click for larger image

Newer versions of the Common Education Data Standards, like Version 2, will not require that you modify your existing statewide longitudinal data system (SLDS) or other original datasets.  Newer versions will require only that you update your ETL [2] application to include new elements and appropriate values and that you add the appropriate elements to the record structures in your operational data store (ODS) [3].  CEDS is designed to offer an easy way to upgrade when new versions are released.  Please see Figure 1 for an example of the CEDS implementation strategy.  Figure 2 includes lists of the types of data that are needed to create a comprehensive data system to meet K-12 educational needs and shows that your SLDS is probably not the best way to bring these data together.

 

Background

CEDS is not something new for K-12 education.  The CEDS FAQ [4] provides information about the history behind CEDS and its links to existing data foundations.  The following information describes briefly the work that has gone on, through the efforts of many people around the country, to create implementable education data standards.


Click for larger image

Version 1 of the Common Education Data Standards was introduced in late 2010.  It included a small data dictionary that described some basic elements that were common to federal reporting requirements.  Because that first version was not comprehensive and did not include a logical data model, it was not implementable in any real way (that is, there was no way for you to create a physical set of data that would actually be “common” with anything else).  Shortly after the release of CEDS 1.0, work began to make the standards more comprehensive and to make them implementable:

 

  • The National Center for Education Statistics (NCES) [5] convened a new CEDS Stakeholder Group [6] to expand the original Technical Working Group that had facilitated the development of CEDS 1.0 [7]
  • The new CEDS Stakeholder Group set an ambitious timeline for the development and publication of CEDS 2.0 with a vastly expanded data dictionary and an accompanying logical data model.  Subsequent versions will be created and released with the same vigor and ambition; Version 3.0 is scheduled to be released in January 2013, with an expanded data dictionary, logical data model, and XML schema.
  • The CEDS Consortium [8] focused on action and products to address advocacy, communication, adoption, and implementation of CEDS 2.0.  That focus highlighted specific mechanisms through which SEAs can adopt and implement CEDS 2.0 voluntarily.  The Council of Chief State School Officers (CCSSO) [9] and the State Higher Education Executive Officers (SHEEO) [10] are the managing partners of the CEDS Consortium.
  • Draft 1 of CEDS 2.0 was released by the CEDS Stakeholder Group for public review and comment [11].
  • Draft 2 of CEDS 2.0 was released by the CEDS Stakeholder Group for public review and comment [12].

CEDS 2.0 was released by NCES and the CEDS Stakeholder Group in January 2012.

Over the last couple of years, there has been discussion (especially within the K-12 community) about standards, data models, and applications.  The Common Education Data Standards are the authoritative data standards for K-12 education (as well as early learning and postsecondary education).  In K-12, there are also “interoperability” standards (the School Interoperability Framework (SIF) [13] being the most commonly used), which define the way data are related across applications.  In postsecondary education, there is the Postsecondary Electronic Standards Council (PESC) [14], which defines the data used for higher education reporting, among other things. 

 

Extended data models may include all or part of the Common Education Data Standards in order to support specific applications, such as dashboards, learning maps, student information systems, and others.  Such extended data models are not, in and of themselves, data standards [15].

Strategies for K-12 Implementation of CEDS

When CEDS was first introduced, there was also much discussion about “adoption and implementation” – adoption has a meaning different from implementation.  As the discussions continued, it became clear that adoption is not a sufficient goal – if your state education agency is to benefit from CEDS, it must implement the standard in some operational way. 

You probably do not want to change the structures of your existing data systems.  Such changes have a tendency to “break” things – links within the data system are sometimes lost, important applications quit working as needed, and other bad things tend to happen.  Such changes cost a lot – and fixing the things that break can cost even more.

That might be the case for your SEA if you try to change your existing SLDS and other datasets so those can conform to CEDS.  At the same time, there is a real need for your SEA to consider voluntary implementation of the Common Education Data Standards in order to meet your data needs and to reduce the future costs of maintaining your data systems and applications.

Implementation of CEDS 2.0 in your SEA must:

  • Be voluntary, of course; you must see the value of CEDS to your future work and the future work of other educators in your state
  • Respect the investments you have already made in your data and information systems; you cannot afford to throw away your current systems and start over;
  • Meet your SEA’s comprehensive data needs for providing services to teachers, learners, and other stakeholders; you cannot afford to make changes now that must be changed again later when new data needs are identified; your changes must lay the foundations to support growth as your future data needs grow (as they will);
  • Provide data that can be used in collective and collaborative efforts with other SEAs and within your own districts; meeting the needs of mobile students and meaningful research requires that your data are portable and contain records that can be used to guide decision-making in real-time;
  • Create a data system that can reduce your agency’s costs while improving services to learners and other stakeholders; the implementation of CEDS in a significant number of SEAs will create economies of scale in the education data marketplace, resulting in savings, efficiencies, and capacities that have never existed before; and
  • Adapt to evolving and emerging data tools, strategies, and needs; the Common Education Data Standards will continue to evolve as educators’ data applications needs continue to evolve.

Click for larger image

Strategies for implementation must help your SEA build its capacity to meet its educational goals and to facilitate the appropriate collaboration with other SEAs, whenever needed and whenever appropriate.

The mechanism described in this section is an effective and efficient way to implement CEDS 2.0 to meet each SEA’s growing data needs and to build a foundation for the development of cost-effective educational applications to meet those needs.   Figure 3 illustrates the physical implementation of CEDS in your state education agency.

Currently, most states have built their statewide longitudinal data systems (SLDSs) without regard for CEDS; after all, the CEDS effort did not begin until after many SLDS projects had already been funded and implemented.  As a result, SLDSs do not provide a means of sharing data easily across SEAs or for informing applications to support individual SEA’s needs.

In addition, your SLDS probably does not contain all the data elements that are defined in CEDS 2.0 – although you may have other datasets – not directly connected with your SLDS – that contain many of the additional CEDS 2.0 elements.

With those factors in mind, the implementation mechanism described in this paper involves specific strategies for your SEA to implement CEDS 2.0 for the purpose of creating a comprehensive data and information system to meet your data needs.  In general, those strategies are:

  • Work with your districts to collect, at the SEA level, the CEDS 2.0 elements that are needed;
  • Build out your SLDS and other datasets that are needed to accommodate all the CEDS 2.0 elements;
  • Create an extract-transform-load (ETL) application that will pull data from your SEA’s data systems and will convert those data formats and values as defined by the CEDS 2.0 data dictionary and logical data model;
  • Transform your CEDS 2.0 formats into an XML [16] version of your data, based on the CEDS XML schema [17]; and
  • Load the transformed data into your operational data store (ODS). 

It is important to note that the strategy described in this paper results in a dataset – that is, a set of data values that have been collected, extracted, converted and placed as individual records in an operational data store.  It is important to note that this ODS does not result in a database or a data system – that is, there are no functional applications included with the resulting ODS.  The purpose of the ODS is to provide a commonly formatted set of data with comparable and equivalent data values in specific record formats that can be used by applications that are written to the record specifications [18].

It is possible that SEAs, collectively, will decide that the ODS should be or could be created in a format other than XML – such as SQL [19].  That collaborative and collective decision should be made, by you and your colleagues in other SEAs, prior to the creation of ETL applications so that the ETLs will know the format in which to load the data into your ODS – as well as the ODSs of your colleagues.

There are several reasons that this ETL mechanism is worth considering:

  • Building the ETL application will be cheaper than converting or modifying your existing SLDS and other data systems;
  • The use of CEDS 2.0 to define the data that come out of the ETL process (and are stored in your ODS) ensures that you have a dataset that will be compatible and comparable with other SEAs and with datasets in your districts; and
  • The creation of the ODS in your SEA and others ensures that applications written for use in another SEA can also be used in yours, if appropriate – meaning your SEA can take advantage of a marketplace with applications that work on your ODS as well as the ODSs in other SEAs.  (A later paper in this series will discuss that marketplace.) 

Click for larger image

The ETL application described above (and illustrated in Figure 4) will be unique for each SEA because each SEA’s SLDS and other datasets will be unique.  The purpose of the ETL application is to gather the SEA’s unique data elements and convert those elements to CEDS formats and values based on the CEDS data dictionary and logical data model; thus, the data that come out of the ETL process remains unique to the SEA but are in a format that is the same in every SEA.

Before that ETL process can be run, however, there are a few things that must be done:

  • Your SEA must collect the appropriate data elements from your districts and store those data in the SLDS and/or other accessible datasets; based on CEDS, you will probably need to add elements and records to what you already collect;
  • The appropriate elements in the SLDS and other datasets must be “mapped” to the CEDS 2.0 elements;
  • The appropriate ODS format must be agreed upon by all SEAs; this is a decision that must come from specific conversations among you and your colleagues in other SEAs; and
  • Your SEA must have a physical place (the ODS) in which to load the data that are extracted and transformed through the ETL application; your ODS can exist in your current network or in whatever secure cloud services you have; that decision is entirely yours.

 In its most basic form, the ETL application would include the following sequential functionality:

  1. Look into the SLDS and other datasets, find the data elements identified through the mapping process, and extract those elements and their values into a logical data store;
  2. Transform those elements into records that match CEDS formats and values – the result is a set (or sets) of records that align to the CEDS data model;
  3. Further transform those elements into an XML version of your datasets; and
  4. Load the XML data (or other agreed upon format) into your physical operational data store (your ODS).

In this basic ETL application (as illustrated in Figure 4), steps 1 and 2 would be unique for your SEA – because the SLDS (and other datasets) in your SEA is unique.  Both of those steps rely on the data dictionary and logical data model in CEDS 2.0 – first, to identify the elements to be extracted and, second, to know what those elements should be converted to (formats and values).

Steps 3 and 4 in this basic ETL application can be the same for each SEA – because the conversion to XML starts with the data that are already in CEDS 2.0 format.  The CEDS 2.0-to-XML part of the ETL application can be created once and shared with you and your colleagues in other SEAs.  It would then be integrated with your unique ETL component to automate the entire process.  (If a format other than XML is agreed upon by the SEAs, then substitute that format for XML in the above sentences.)

This mechanism for implementing CEDS 2.0 and creating a physical ODS through an ETL application offers various options to your SEA.  Assuming that XML would be the agreed upon format, some examples are:

(a)    Your SEA may choose not to include some elements in the data it collects from its districts.  That is possible and acceptable in the process and is entirely your SEA’s decision.  The ETL would simply create CEDS 2.0 elements and records and would leave those excluded elements with null values (that is, empty).  The output of Step 2 would include all the CEDS 2.0 elements and records, but some elements would have blank values if that were your SEA’s choice.  (The main point here is that the elements would exist in your ODS but would have blank values in your records.)
(b)   Your SEA may choose to transform its data into a format other than XML (for example, SQL) and store those data in a separate ODS (another dataset or database).  That would be acceptable – as long as that dataset or database could export the data in XML format to your CEDS-compatible ODS. 
(c)    All SEAs may collaboratively and collectively decide that XML is not an efficient storage strategy and may decide that the use of a relational database format (like SQL) may be more efficient and useable.  In that case, your ETL would not output XML; instead, your SEA’s ETL application would create an ODS that would align with the agreed-upon physical data model.

The main point in this section is that you have options in the process of creating your CEDS-compatible ODS.  Later papers in this series will describe the benefits of creating that ODS, including comprehensiveness, compatibility, comparability, economies of scale, collaborative research, an application marketplace, and more.

The K-12 Work to be Done

With the basic strategies for implementing CEDS 2.0 and beyond, your SEA and districts must consider the actual work to be done in preparation for implementation of the Common Education Data Standards.

CEDS implementation – full implementation – is defined by the physical creation of your operational data store (your ODS).  Alignment with the CEDS data dictionary and logical data model ensures successful implementation.

While the concept of implementing an ODS is reasonably straight-forward, there is also a good bit of work to be done in order to make it happen.  In the past, your SEA typically has collected only the data needed for federal reporting and for accountability – neither of which has the capacity to inform teaching and learning and both of which require significant manual labor, either in your districts, your SEA, or both. 

The work to implement CEDS begins with collecting comprehensive, complete, and correct data from your districts.  That may involve policy matters for which you may have to work with others within your SEA.  After collection of the appropriate data, then your work will involve initial storage, conversion, and updating your ODS.  As your ODS becomes important in services that inform teaching and learning, the data must be current as well as comprehensive, complete, and correct; thus, there will be work needed to automate data collection from your districts.

In general, your work to implement CEDS 2.0 and to create your ODS would look like the following (but, please keep in mind, that your working needs may be different from what I’ve listed here; the devil is in the details):

  • Make a statement of intent to implement CEDS 2.0 in your state.
    • Within your SEA, issue a brief statement that your agency will implement CEDS 2.0 and successive versions in order to meet its data needs.
    • Notify the your districts that CEDS 2.0 and successive versions have been adopted and will be implemented by your SEA.
    • Create the messaging for your efforts to collect and maintain more data elements based on the SEA’s goals (inform teaching and learning, automate federal reporting, support new accountability principles, and inform each state’s constituencies and communities, collaborative research, etc.) and to provide more services related to those goals.
  • Map your SEA’s existing data elements to the CEDS 2.0 data dictionary and logical data model.
    • Use the CEDS 2.0 tools or another resource to map current state-level dataset(s) to the standards.
    • Identify current elements that map directly to CEDS 2.0 (these can go on your “Mapped Elements” list).
    • Identify the other CEDS 2.0 elements that do not map directly to current elements in your datasets and systems (these elements can go on your “Missing Elements” list).
    • Identify current elements in your datasets and systems that do not map directly to CEDS 2.0 (these can go on your “Maybe-Later Elements” list).
    • Share the three lists with your districts and begin planning to collect the items on the “Missing Elements” list.
    • Work with districts to ensure that the “Missing Elements” can be collected with high-quality values.
    • Note:  With each new version of CEDS, this process will be repeated (albeit, on a much smaller scale than during the first implementation) in order to identify and collect newly defined elements; thus, a process that you can replicate and expand as new CEDS versions are released would seem desirable.
  • Collect the appropriate elements from your districts.
    • Develop a strategy for collecting the elements on the “Missing Elements” list as well as continuing to collect existing elements.
    • Redesign your SEA’s data collection tools and processes to include “Missing Elements” and to collect all the appropriate data elements daily (at a minimum).
    • There are two basic ways to store the “Missing Elements”:  (1) Modify your existing SLDS or (2) create new datasets that can be accessed by your ETL application.  (Your SEA may not want to modify its SLDS because doing so may “break” some of its existing applications.)
    • As appropriate, design and build the new dataset(s) or modify the SLDS so the “Missing Elements” have a place to land when those elements are collected from your districts.
    • Again:  With each new version of CEDS, this process will be repeated (albeit, on a much smaller scale than during the first implementation) in order to identify and collect newly defined elements; thus, building a process that can be replicated and expanded as new versions are released would seem desirable.
  • Develop the “upper” part of the ETL (extract and convert to CEDS 2.0).
    • Because the SLDS and other dataset formats are different from other SEAs’, the “upper” part of the ETL application will also be different from other SEAs’ ETLs; therefore, you must build your ETL application to cover parts 1 and 2 (see Figure 4).
    • Using the CEDS 2.0 data dictionary and logical data model, develop an application to extract the appropriate data elements and to convert those elements to CEDS 2.0-compatible records.
    • Your converted records would also include the appropriate values defined in the code sets (value sets) in the CEDS data dictionary.
    • The conversion would include all the elements defined in the CEDS 2.0 data dictionary – whether or not your SEA collects some of those values.  For elements that you might not collect from your districts, the element placeholders would still be part of the conversion to CEDS 2.0 formats and records would contain the appropriate null values (as defined in the code sets).  This is important because of the next step.
  • Implement the “lower” part of the ETL (convert to XML version and store in an ODS).
    • Because the “upper” part of the ETL application (see Figure 4) should contain exactly the same elements as defined in CEDS 2.0 – and because that would be the case in every SEA, including yours – the “lower” part of the ETL application can be developed once and, then, shared with every SEA.
    • The “lower” part of the ETL application will be developed collectively and collaboratively by all SEAs (possibly under contract with an agreed-upon developer) and shared.
    • The common “lower” part of the ETL application would be integrated with your “upper” part of the ETL so the entire ETL process is automated.
    • The “lower” part of the ETL application will look at the data created by your “upper” part, which will be in exact CEDS 2.0 format, and will convert those data into an XML version of your data.
    • The “lower” part of the ETL application must know about the location of your physical ODS; thus, it must contain a configuration routine that would allow you to provide the path to your ODS.
  • Load and store a physical copy of the XML version of your data into the physical ODS.
    • Within your SEA’s data network strategies, create the data store for the XML version of your data – that is, create your physical ODS to get the data from your ETL application.
    • Be sure the “lower” part of your ETL application knows the location of your physical ODS – whether it is located locally or in a “cloud” (based on your specifc strategies).
    • Your integrated and automated ETL application can then load the XML version into your ODS.
    • Note:  At that point, you have laid a solid foundation to meet the goals that have been outlined for providing services to districts, schools, educators, and learners – as well as laying the foundation from which applications can automate federal reporting, accountability, and other functionality that your education stakeholders want and need. 

The list above is a general description of the work that will be required if your SEA (voluntarily) implements CEDS and creates its ODS.  There are many ways that each piece of the work can be done and you and your team should look at all of options in planning and doing the work.  In those areas where collaboration and collective work make sense, you may want to facilitate that collaboration with your colleagues in other SEAs and with your colleagues in your districts.

Indicators of Successful CEDS Implementation

Successful implementation of CEDS can be measured by the successful population of your CEDS-aligned operational data store (see Figure 5).  The following list may be useful as a checklist of benchmarks to guide you to successful implementation:

  • Your SEA maps its SLDS and other datasets to the CEDS data dictionary and logical data model.
  • Your SEA communicates to districts that additional data elements and records may be collected at the SEA level.
  • Your SEA modifies its data collection tools and processes to collect the identified data elements.
  • Your SEA creates a data store or modifies its existing data stores to accept and store the newly collected elements and records.
  • Your SEA collects and stores the mapped elements based on policy and agreements with districts.
  • Your SEA creates the “upper” part of its ETL application, defined by the structure of its SLDS and other datasets and by the CEDS data dictionary and logical data model.
  • Your SEA, working with other SEAs, facilitates the creation of the “lower” part of the ETL process and shares it with all SEAs.
  • Your SEA integrates the “upper” and “lower” parts of the ETL application so that your whole ETL process is automated.
  • Your SEA creates your operational data store (its ODS) in which your XML version will be stored physically.  Your ODS can be located on your local network and in your secure cloud network, as appropriate.
  • Your SEA’s ETL process stores your data in your ODS.

Click for larger image

With the successful population of your ODS, which will contain data exactly formatted to the CEDS specifications, you will have built capacity to use your data in meaningful ways through applications and services that can inform teaching and learning, automate federal reporting and accountability, facilitate research, and change the way teaching and learning are done across your state. 

Now, applications can built to use those data to personalize learning.  Your SEA is ready to make it happen.

 

Strategies for Governance and Sustainability of CEDS

The implementation of CEDS, as described above, creates the capacity for your SEA to manage your own data within your own policies, processes, procedures, and practices.  Because your SEA can create automated processes in the collection, conversion, and storage of your data, those processes and related practices are easily sustainable.

There is a need to establish governance and sustainability strategies around the perpetual evolution of CEDS.  As K-12 education matures with regard to the use of data, measures of effectiveness, use of digital resources and strategies, expectations of real-time resources, and other emerging processes and products, the need for additional data elements and innovative ways of integrating data will require that CEDS mature, as well.

While NCES and the CEDS Stakeholder Group have responsibility for the content of CEDS, it is expected that your SEA, your colleagues in other SEAs, your districts, educators, other standards bodies, vendors, policymakers, and other stakeholders (like early learning and postsecondary entities) will make important contributions to the maturation of CEDS.

The process by which CEDS 2.0 (and, in early 2013, Version 3) was created can be used to maintain CEDS’ content and to facilitate extension of the CEDS data dictionary and logical data model as part of that maturation.  The facilitation of stakeholder groups that provide input from the field and an authoritative standards body, consisting of stakeholders, to review the input and recommendations is an essential part of maintaining and sustaining CEDS.  That facilitation is most likely a function of NCES and/or a body funded by NCES.

The authoritative standards body must have access to the technical expertise to maintain the standard and to resources to disseminate updates to the standard.  It must also have the content expertise to deal with large projects that create large numbers of new elements (for example, those elements related to the new assessment strategies being developed by the assessment consortia). 

Ultimately, the sustainability of CEDS will be based on the commitment of your SEA and others.  That commitment to populating your ODS creates the capacity for the creation and use of compelling applications that deliver compelling data and information to teachers and learners, as well as to the reporting and accountability processes in your districts and your agency. 

Conclusion

In your role as the data leader in your state education agency, you know your data and you know how those data can be used in many different ways.  Unfortunately, many of the educators you serve do not know the data and do not have access to the data to help make important decisions about individual learners.

CEDS provides the common vocabulary and language through which all educators and other education stakeholders can get involved in the decision making.

That’s the reason that implementation of CEDS is essential – data are not your business; education is your business.  And your data are an important set of tools needed to make your business successful.  Your mission (should we decide to accept it) is to do whatever is needed of you to provide those tools.  Education cannot be successful without you and your data – and CEDS provides the mechanism for creating that success.

Gary West [20]
May 2, 2012
garywwest2@gmail.com

Permission is granted to share this document with anyone, in print or electronic format, as long as the content is not changed in any way.

NOTE:  This series of papers is now available online at https://sites.google.com/site/CEDSimplementation.

 

Endnotes for Data Leader Strategies

[1] Official CEDS Website:  http://ceds.ed.gov.

[2] ETL:  The extract-transform-load process is referenced early in this paper and is described in more detail later in the paper.  See Figures 3, 4, and 5 for illustrations of the process.  While there is much technical online information about ETL, the linked Wikipedia article (http://en.wikipedia.org/wiki/Extract,_transform,_load) offers a comprehensive set of information that is pulled from many original sources.

[3] ODS: Please note that, in previous presentations and discussions, I have referred to the physical ODS created by the ETL process as “the Blue Box.”  The “Blue Box” terminology was my non-technical reference to the general concept of storing data in an operational data store (an ODS) so those data can be accessed and used by specific applications.  Beginning with this series of papers, I have dropped the “Blue Box” wording; as you have already seen, I have been using the more technical term “ODS” to describe and discuss the physical implementation of CEDS.

[4] CEDS Frequently Asked Questions (FAQs):  https://ceds.ed.gov/FAQ.aspx.  See the answer to the question, “What is the relationship between CEDS and the NCES Handbooks and the National Education Data Model (NEDM)?

[5] NCES (National Center for Education Statistics):  http://nces.ed.gov.

[6] NCES Stakeholder Group:  https://ceds.ed.gov/stakeHolderGroup.aspx.

[7] CEDS Version 1:  http://nces.ed.gov/programs/ceds/version1/data_elements.asp.

[8] CEDS Consortium:  http://ceds.ed.gov/consortium.aspx.

[9] CCSSO (Council of Chief State School Officers):  http://www.ccsso.org.

[10] SHEEO (State Higher Education Executive Officers):  http://www.sheeo.org.

[11] CEDS 2.0 Draft 1 Public Review and Comments:  http://ceds.ed.gov/pdf/comment-response-v2.pdf.

[12] CEDS 2.0 Draft 2 Public Review and Comments:  http://ceds.ed.gov/pdf/comment-response-v2.pdf.

[13] SIF (School Interoperability Framework):  www.sifinfo.org.

[14] PESC (Postsecondary Electronic Standards Council):  www.pesc.org.

[15] There has been much discussion about education data standards – and that discussion will (and should) continue.  I’ve expressed my view in this paper and as part of the broader conversation.  While the discussion has been interesting and has many complex components, there does come a time when mere conversation becomes paralyzing.  At some point, we who work in K-12 education must take action (either individually or collectively or both) and action is desperately needed in putting educational data to good use – not just for reporting and accountability but also for informing teaching and learning.  Implementation of the Common Education Data Standards gives K-12 education, and our colleagues in early learning and postsecondary education, the immediate capacity to do something that will have significant impact on education.  I will contend that the implementation of CEDS is an “educational” decision – not a “technical” decision – but that’s probably a whole other discussion.

[16] XML:  XML stands for “eXtensible Markup Language,” which is a “simple, very flexible text format … designed to meet the challenges of large-scale electronic publishing … playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere” (http://www.w3.org/XML/).  See more at the World Wide Web Consortium (W3C; http://www.w3.org/) and at Wikipedia (http://en.wikipedia.org/wiki/XML).  XML provides a way to store data in a standard format that can be read by computers and, then, used in comprehensive and sophisticated software applications.  Storing your data in XML format creates capacity for many applications to access and use those data to inform teaching and learning as well as meeting your reporting and accountability needs.

[17] CEDS XML Schema:  https://ceds.ed.gov/data/xsd/ceds-v2-nds.xsd.

[18] It is also important to note that the creation of your ODS completes the implementation of CEDS.  The development of of extended data systems, based on your ODS, and the development of applications to use the data in your ODS are NOT part of CEDS implementation.  Your ODS creates your SEA’s capacity to create or work with developers to create applications that use your data.  There are significant efficiencies and economies of scale that come from creating that capacity – by creating your ODS.

[19] SQL:  SQL stands for “Structured Query Language” and is a programming language for relational database management systems.  SQL is a standard managed by the American National Standards Institute (ANSI; www.ansi.org).  See more about SQL at http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+INCITS+135-1992+(R1998) and at http://en.wikipedia.org/wiki/SQL.

[20] I was high school math teacher for ten years, a federal projects coordinator for a small rural school district for nine years, a technology and data systems director for a moderately sized school district for more than nineteen years, the Chief Information Officer for the South Carolina Department of Education for more than three years, and the Strategic Initiatives Director for Information Systems and Research at the Council of Chief State School Officers in Washington DC for one year.  I have been emphasizing, since the beginning of time, the use of data to guide teaching and learning – not just the use of data to report what has already been taught and learned.  I believe strongly in the appropriate use of data to create personalized learning for everyone who is a stakeholder in our society and in our democracy.  The views expressed in this series of papers are mine and do not, necessarily, reflect the views of any past or future employers.  I do not receive any financial gain from writing or distributing these papers (that is, I am not paid to write or send these papers to you) and I do not envision that writing these papers will result in any financial gain on my part (and I don’t buy lottery tickets, either).