SIF AssociationCCSSO

News & Updates

"The NEDM project has been very helpful in the ongoing expansion of the eScholar Complete Data Warehouse. By leveraging the work of the NEDM in finding commonality among education data attributes across disparate systems and organizations, we are able to more quickly deliver broadly applicable enhancements."
-Shawn Bay
 Founder/CEO, eScholar LLC

“What I’ve found helpful about working with NEDM is that it provides us with a starting point for our work to expand our data system. In New Jersey, we have multiple, fragmented data collections that grew over the years as independent entities. Our challenge is to build out our SLDS to incorporate what we’ve been collecting but also focus on what we may not have been collecting. NEDM is a fabulous tool to help us establish our priorities for which data elements and collections should be incorporated first and also to provide the more global guidance of what the data values and formats should be for each new data element.”
-Bari Anhalt Erlichson PhD
 Director Office of Research and Evaluation, New Jersey Department of Education

FAQ Page

The following is a list of some frequently asked questions regarding the Education Data Model.

Are the naming conventions used in this data model generally accepted in fields outside of education?

Naming of classes, entities, and attributes in the Data Model was influenced by the well documented and accepted ISO/EEC 11179 standards. For example, the Data Model hierarchy has the following properties:

  • Unique Names
  • Many items follow the multi-part naming convention, i.e., [Object] [Qualifier] Property RepresentationTerm.
  • A classification framework in which items can be located using dot notation such as classname.classname.entity.attribute.

Also, class names begin with a capital letter and contain no spaces; entity and relationship names begin with a lower-case letter, followed by camel case, with no spaces; attribute names contain spaces and are capitalized. For example, Person and Client are classes, libraryPatron is an entity, and Library Patron Name is an attribute.

Couldn't some items be an entity and attribute at the same time?

Yes. For example, a person listed in a discipline incident could have a victim attribute or a perpetrator attribute. Or, we could model the role of victim as an entity. In this case, this is essentially the relationship between a discipline incident and a victim. Attributes of this entity might include injuries sustained and the victim’s description of the incident. The data model strives to reflect consistent decisions with respect to such issues.

Why not just use Entity Relationship (ER) diagrams or a (UML) object diagram?

These types of diagrams are used to represent logical or physical models. The Education Data Model is a conceptual map (ontology) with the addition of attribute detail that cannot be represented using ER diagrams or UML object diagrams.

How specific are the entities? When do we stop creating classes based on different types and create an entity?

In creating the taxonomy, a number of questions arise concerning the scope and depth of the taxonomy. For example, where do we draw the line between classes and entities? Is ‘Science teacher’ an entity in the class of teachers? Or is teacher an entity and the ‘subject taught’ a characteristic (attribute) of teachers? Is a ‘warehouse’ a type of building (e.g., a coded value in a code set for building type)? Or is a warehouse a separate entity in a class of buildings?

A subjective criterion for creating a lower level entity might be that characteristics of the lower level item must be significantly different from the parent item. Another view might be that characteristics of the child item must be a significant addition to the parent characteristics. So teacher is a type of person but is a child of the class of persons because the characteristics for teachers are significant addition to the person attributes. In order to clarify the distinction between a class and an entity these guidelines were used in developing the Model:

Entity

  • An entity may represent a Class (not an instance) in an Object-Oriented (OO) design. The word ‘class’ has a different meaning in OO design than in the Data Model.
  • An entity should fit as part of the collection of entities that make up a class.
  • The entities in a class do not make up the complete set of possible entities for the class. In reality, there are an infinite number of possible entities for each class.

Class

  • Classes represent concepts.
  • Subclasses make up the complete set with their class. For example, Area and Location make up the complete set of Places in the Data Model.

Why is the entity name written as one word?

Spaces in class, entity, and relationship names are illegal in the ontology language we are using. Camel case is used to improve readability. The convention is that class names are camel case with the first letter upper case. Entity and relationship names are camel case with the first letter lower case.

How can I tell if the definitions in the “description” are from the NCES Handbooks Online? Are they all from the Handbooks?

Entity descriptions that are from the Handbook start with “From Handbooks Online:”. Not all of the descriptions in the Data Model are included in the Handbooks because the Data Model entity may be at a more detailed or general level than an Handbook item, or the Data Model entity may be describing a relationship which the NCES Handbooks Online does not.

I came across an entity without any relationships (or one with only one relationship and others with many relationships), why is this?

All entities have at least one inherent relationship: the relationship or membership in its class. Only some of the infinite number of possible relationships are represented in the Data Model. One intended use of the Data Model is for users to take the model and add the relationships that are relevant to their particular use of the Data Model. Also, the Data Model contents are a work in progress so not all of the widely accepted relationships among the entites have been collected and entered into the Model.

Some entities have many attributes and some have only one, why is this?

See also the answer to the question above. The Data Model is meant to be a reflection of current practice, not a definitive design. All of the relevant attributes for each entity have not yet been collected from the field.

How can I provide comments to the data model for future updates?

A another website is available that serves as the Data Model development website: http://nces.sifinfo.org/datamodel. This site is used for collecting community input on the data model and will have Data Model tools that are under development and not yet available on the official website.

In the Conceptual Modeling Software section, why did you pick the two software packages?

The two software packages (Protege and SWOOP) were chosen because they are free of charge and they are two of the most widely used open source software packages in this area. There are many more commercial software packages to choose from as well. Although these two software packages are free of charge, it may take some time for a user to install and understand how to use the software compared to a commercial software package.