The NSPA Scholarship Program Data Standard specification is operational in a few solutions, but the standard itself is still considered a draft. This section outlines the changes in v1.0e, which is expected to be the final draft of the specification before the first formal release.

The NSPA and Dell Foundation teams thank all the NSPA Members, implementers, technologists, and subject matter experts who provided input and contributions. If you have feedback on the proposed changes, contact ndelmuro@scholarshipproviders.org. If you or your organization are interested in contributing ideas or changes to the overall NSPA Data Standard, consider participating in the NSPA Data Standards Initiative.

Overview

The information that follows describes the changes proposed for the next version of the NSPA Scholarship Program data model.

The changes include:

Detail on each change follows.

Major Changes & Additions to the Data Model

The structure and contents of the NSPA Scholarship Program Data Standard is defined by its data model. This section describes the more notable changes to the data model.

Add a Metadata Entity (SPDS-24/DATA-15)

Add a new Metadata entity to the Scholarship Program entity. The high-level organizing principle is that these values are usually not directly entered. The values are typically those that are automatically updated (such as a Last Modified On value) or are values that are calculated (such as a general “Type of Program”) or looked up and provided for convenience (such as an entire hierarchy for coded hierarchical values). 

In practice, systems will automatically maintain or populate these values. These values will typically be read-only to most data consumers and API clients.

Change Detail

The proposed change adds a new Metadata entity, with new elements to convey the following information: 

• True metadata such as "Record last modified date" (which is distinct from the "Last Verified Date" element indicating a human has reviewed the record for accuracy). 

• Categorizations (e.g., shorthand program types such as "First-Generation" or "STEM" that are often tightly bound to one or more specific eligibility criteria). 

• The full path of hierarchical eligibility criteria codings (e.g., a program with an Activity of "Downhill Skiing" might have a "full path" entry of "Activity > Sports > Skiing > Downhill Skiing"). 

• Created By. An element named CreatedBy defined as a short string. The organization that initiated the record. By convention, the organization initiating this record in the NSPA Exchange ecosystem, but may contain agreed-upon values for any data exchange scenario.

• Created On. An element named CreatedOn defined as a datetime. The creation date for the record. If a CreatedBy value is present, should indicate the date the record was created in the originating system. Most date-related elements in the standard are just that: date-only data fields. This element and the following Last Modified On element are defined as date + time to support data update use cases where the precise time that an event happened on the record is important.

• Last Modified On. An element named LastModifiedOn defined as a datetime.

• Lists. An element named Lists defined as an array or short string values. Lists on which the program appears (e.g., “Programs for Hispanic Americans” or “Weirdly Specific Programs” or “Programs for Families of Armed Servicemembers“). Common list names and definitions are maintained by the NSPA, but this field may be used for ad-hoc purposes to support information exchange.

• Eligibility Criteria Hierarchies. An element named EligibilityCriteriaHierarchies defined as an array of medium-length string values.

In addition, the following element has been refactored from the scholarship program record to the new Metadata entity:

• Program Categories. This element was bolted on to the main program detail in v1.0d, but conveys information that’s best thought of as metadata. With the addition of the Metadata entity, we’ve refactored the ProgramCategories array to the Metadata entity.

An example XML snippet follows, with the new Metadata entity starting on line 2:

Add Unforeseen Event or Disaster Element (SPDS-49/DATA-24)

In the not-too-distant past, the U.S. scholarship space has offered programs for students affected by major events, often natural disasters. (Perhaps there is a program for $1,000,000+ lottery winners. If so, we're not aware of it.) Examples include 9/11, Hurricanes Katrina and Harvey, Covid-19, and others. This addition would allow a coded way to identify funding (or other programmatic support) for scholars who have been impacted by recent events.

Change Detail

Proposed changes include:

• Add an UnforeseenEvent criteria, allowing for a selection from a list of events. Allow an “Other” value and Include an UnforeseenEventOther element, to support exchange of data related to very recent event.

• Create and publish a new NSPA List of Unforeseen Events. An initial draft list is published on this site here. This will be a “living” list, initially populated with relatively recent events and disasters for which there are scholarships and financial aid.

The Event eligibility criteria is illustrated in JSON data snippet shown below on lines 9 and 10, showing a program for the benefit of the fictional Hurricane Steve.

Add Elements for "Scam" and "Requires Application Fee" (DATA-29) (New 3/14)

NSPA has a few types of programs that it wishes to have in the database, but (generally) should not be shared in any data service.

Current examples include "Scams" (which would be used for a blacklist) and "Application Fee" (i.e., programs that charge applicants to apply, which the NSPA community feels strongly is not awesome), “Insecure Application” (i.e., for online applications that are not secure, or applications that require scholars to email Social Security Numbers or similar).

Note that we should take care about the nomenclature. Not all concerning characteristics are necessarily scams or even unambiguously negative in all contexts. And definitive declarations like "IsScam" should have alternatives that simply indicate areas of concern.

This change will flesh out the list of concerning characteristics, and model elements. The main "priority" elements are the "Application Fee," which came up in Q3-2020 as useful, and an unambiguous “Scam” indicator which has been on the data model to-do list since 2019.

Change Detail

Proposed changes include:

• Add an optional NoteworthyApplicationCharacteristics entity to contain various issues that raise some level of concern.

• Add a RequiresApplicationFee boolean and an ApplicationFeeAmount decimal.

• Add a HasNewMembershipOrAccountRequirement boolean. Indicator for whether the application requires a new membership or new account to apply. Specifically does not apply to membership requirements that typically already exist, such as a club or membership with local organization.

• Add a new ApplicationAppearsInsecure boolean. Indicates that an online application is not sent over an encrypted connection, or a downloadable form with personal information must be sent via email with no provisions for data protection, or similar security and privacy issues.

• Add a LegitimacyConcern entity, containing a boolean HasLegitimacyConcerns flag, an LegitimacyConcernType array of possible concerns (e.g., No Contact Information, No Evidence of Past Winners), and a LegitimacyConcernNotes text element to provide any details.

The NoteworthyApplicationCharacteristics eligibility criteria is illustrated in JSON data snippet shown below on lines 8 through 21, showing a program with many, many questionable characteristics.

Usage Notes

• The NoteworthyApplicationCharacteristics entity is optional. Note that some implementers may choose never to emit or exchange records that have such “Noteworthy” characteristics. (For example, the NSPA Exchange intends to record questionable applications and programs for its own tracking and reporting — but would generally not share any programs with legitimacy concerns through its data services.)

• Some elements are not necessarily “bad” or problematic for all parties. For example ApplicationAppearsInsecure indicates that an applicant’s data is not safe — but that doesn’t necessarily indicate nefarious intent. Similarly, an application fee could (hypothetically) be associated with a legitimate program, but it’s a classic hallmark of an application to be avoided so it’s included with these elements.

Improve Support for International Programs (SPDS-52/DATA-27) (Updated 6/1)

Many key partners have programs spanning the U.S. and Canada. This issue represents the work to (a) improve international support generally, and (b) add specific support for the Canadian scholarship system.

Examples include adding citizenship statuses applicable in Canada, standardized test scores & grading systems, currency, and more. Practically speaking, a transition to full internationalization requires a phased approach because it typically affects how many elements are expressed. So this work may include a roadmap for a phased implementation approach.

Change Detail

Several changes are proposed in the latest draft.

1. The first change is simply a refinement to the definition of an existing data element. The Country value in the Location Eligibility Criteria will define the country context. Implementers (such as the NSPA Exchange) who maintain data systems that cross borders will include a country value (primarily, e.g., “US”, “CA”), on every record to ensure the context is clear, and that programs for the benefit of scholars in that country are easily found, segmented, and so forth.

2. Added an EICode element to the existing School entity to contain the 4-digit code (e.g., AJAF, GPAB, LUAA) assigned to designated educational institutions. See the excellent documentation on Canada.ca here for a full definition and the current list of designated EIs.

3. Refactored the CitizenshipStatuses eligibility criteria. Changed the data model from an enumeration based on USCitizenshipStatusValueList (which was, you may have guessed, U.S.-specific) into a text string. Defined the list of expected values by reference to a new Citizenship Status List. Removed the orphaned USCitizenshipStatusValueList enumeration from the schema.

4. This change mirrors the Citizenship Status change noted above, technically. Refactored the AcademicEligibility criteria from a U.S.-centric enumeration into a text string. Defined the list of expected values by reference to a new Academic Criteria List. Removed the orphaned AcademicEligibilityCriteriaList.

Add Study Abroad Support (SPDS-55/DATA-30) (Updated 5/21)

This change will improve support for study-abroad programs, and programs explicitly for international students. (“Abroad,” generally speaking, is currently defined as “programs available to or explicitly serving residents of countries other than the program provider’s country.”)

In v1.0d, the standard has a general "study abroad" indicator, but otherwise it’s not apparent which programs are explicitly “for” students who wish to study abroad. This change will start with a deliberate review, and will suggest improvements to more clearly indicate scholarships for the study-abroad crowd.

Feedback also suggests that structured support would be useful for international students seeking U.S. opportunities. We do have, for example, a Non-U.S. Citizen value in the Citizenship Eligibility Criteria, but this doesn't clearly indicate programs for students who may not already be in North America.

As noted, the standard has some support for these proposed cases. The goal is to allow for a specific lens on these opportunities to support these specific, but large, student populations.

Change Detail

The core changes include:

• Create a new Eligibility Criteria named StudyAbroad.

• The Study Abroad contains one or more StudyAbroadDestination entities to indicate the host or destination country for the program, along with a state or province, county, and city, if applicable.

This change resulted in a light refactoring:

• The new Study Abroad Destination is identical in structure to the current Eligibility Location in that it will indicate a country along with a state or province, county, and city.

• Since this is identical to the current Eligibility Location structure, we refactored EligibilityLocation into a new, general-purpose Location criteria, and used that for both the previous Location Criteria and the new Study Abroad Destination criteria.

The code snippet below shows an example usage as JSON data. In this example, the destination country (the UK) is indicated in the StudyAbroadDestination. Note that the Location criteria in this example is also present, which indicates that the program is designed to serve students in the United States.

Usage Notes

• The destination or host country is indicated in the Study Abroad Destination. The specific country of origin requirements — if any — are indicated in the Location Eligibility Criteria.

• The Study Abroad indicator is reserved for truly international studies. It is not intended for use to, for example, indicate programs in another state within the same country.

• The Study Abroad Destination should always contain a country. Optionally, it may contain a state or province, county, and city, if the program has a specific location within a country.

• If the program is for a particular institution in the destination country, then the Study Abroad Destination can be assumed to share the specific county or city in which the institution resides, semantically speaking. However, data exchange implementers may opt to simply list the country and provide additional location details with the institution or institutions associated with the program.

Improve Future Enrollment Intentions, Current School Enrollment, and Alumni Support (SPDS-3/DATA-2) (Updated 5/5)

The current approach to encoding relevant school and graduation requirements need refinement.

Specific issues with the current v1.0d draft standard include:

• In the eligibility criteria, the field named “College Attendance Criteria” would imply that a student is already attending a school. However, the definition (and current implementation in the NSPA Exchange) actually means “future college intentions” or “future plans.”

• Also in the eligibility criteria, the Graduation Status is a mix of requirement concepts like “graduating high school senior” (i.e., a future graduation) and “alumnus” (i.e., a past graduation).

• There’s no way to indicate that a student has a degree in a particular field of study.

• There’s no way to indicate that a student has a degree from a particular institution.

• In the Graduation Status list itself, some statuses are in-progress statuses (primarily, e.g., "Graduating High School Senior"). However, this is semantically equivalent to having a current grade of "High School Senior." We want to avoid this kind of duplicate meaning where possible, and so may want to remove the "Graduating High School Senior" from the Graduation Status List.

This change is a global update to clarify the purpose of existing elements, clean up or remove the clunky “Graduation Status” list, and improve the support for Alumni requirements.

Change Detail

• Clarify the meaning of the current College Attendance Criteria by renaming it CollegePlans. Update inline documentation.

• Refactor the current Graduation Status Criteria to focus on Alumni support thusly:

  • Clarify the meaning of the current Graduation Status Criteria entity by renaming it GraduationCriteria.

  • Rename the general School entity in the Graduation Status Criteria to AlmaMater as a further way to make the “past graduation” meaning obvious.

  • Remove the clunky GraduationStatusList and replace it with the DegreeList, which provides a straightforward way to note if applicants are required to have a particular degree.

  • Add a FieldOfStudy element to indicate that a degree in a particular field of study are required for applicant eligibility.

  • All elements are optional, all may contain multiple criteria, and all may be used singularly or in combination. For example, one can indicate solely that an applicant must have graduated from a school, or only that the student have a particular degree, or that a student must have graduated from a particular school, with a particular degree, in a particular field of study.

• Rename the DegreeSeekingCriteriaList definition to DegreeList to reflect its multipurpose use as a simple list of degrees.

• Remove the GraduationStatusList, which is unused after the above changes.

The newly reorganized Graduation eligibility criteria is the most significant change. The following JSON snippet shows example data for a Graduation eligibility criteria that leverages all available data elements:

In the example above, applicants are eligible if they:

1. Have a Bachelor’s Degree

2. In English and Writing OR Film and Video Studies (i.e., the indicated CIP Codes)

3. From U.C. Santa Cruz in sunny California

While most programs have a single set of simple graduation criteria, the standard does allow for multiple sets. So, one can encode eligibility requirements for a particular degree from a particular school and a wholly separate degree from a different school.

Consider Adding Element to Indicate a Program is Part of a List (DATA-38)

The current data standard has multiple ways to categorize programs, including the Eligibility Criteria and the Program Category. However, there's no current way to simply make a list of programs with a natural-language definition, or where human judgment is involved (e.g., “Unusual Scholarships” or "Scholarships for High School Students in California" or "Opportunities for Hispanic Americans" or "Essay Contests" or similar).

This change would add an element to indicate that a program is a member of a list. The NSPA would publish its defined set of lists and definitions. Where applicable, the NSPA would map membership in a list to the data points that indicate membership in the list.

The list would be flexible, allowing implementers to establish lists of their own. However, the spec would recommend that implementers use the NSPA-defined values where a conceptual match was present.

Change Detail

• This change was implemented in the new Metadata entity.

• See also DATA-15, which contains an example data snippet showing use.

Improvements to Logo File Treatment, Including Content Delivery Network Support (SPDS-57/DATA-32)

Version 1.0d of the NSPA Scholarship Program Data Standard allows for a small logo file to be included in the record (using Base 64 encoding).

The inclusion of the logo file is convenient for file-based transfer scenarios, but the increase in record size can cause performance issues for integration scenarios and API usage. Implementers have suggested that a URL reference would be useful — and would allow for API integrations to leverage a high-speed content delivery network suitable for image content.

In addition, the current File Name element serves as a proxy for the file type (e.g., the ".png" in "Organization-Logo-File.png" serving as the primary hint that the logo is in PNG format). A more common pattern is to specify the file type using an enumeration or a MIME Type.

This item will consider these improvements (and will evaluate other opportunities) for v1.0e.

Change Detail

Proposed changes include:

• Add a LogoURL element. Content delivery network URLs can be long, so this is an sps:MediumString, which allows for a generous 512 characters.

• Add a MIMEType element. This would allow for an explicit statement of file type such as “image/png”. By convention, file types (and thus the related MIME types) in the standard are limited to image/png, image/jpg, image/gif. But, the schema puts no technical limitation on the images conveyed, so data exchange implementers can use additional types by mutual agreement.

• Organize all Logo-related elements into a new Object/Complex Type called Logo. Elsewhere in the design, we gather related elements into a single entity, and these additions indicate a similar pattern would keep the structure clean.

The following JSON data file snippets illustrate the previous version (lines 8 & 9) and the proposed update (lines 21–26).

Additions to NSPA Code Lists (SPDS-53/DATA-28)

In version 1.0d, many Eligibility Criteria enumerations were changed to a more flexible code list. These include: 

• Activity 

• Affiliation Entity 

• College Readiness Program 

• Demographic Criteria

• Interest 

• Miscellaneous 

• Profession 

• Situation 

• Unforeseen Event (New in v1.0e)

We expect to add values to most of these lists based on observed data in field use. For this version, we intend to minimize changes or deletions, instead marking items as deprecated and removing in v2.0 of the specification.

Changed List Detail

Activity Entity

Proposed changes to the Activity List can be found here. The changes are primarily additions and suggested deprecations.

Affiliation Entity

Proposed changes to the Affiliation Entity are listed here. A general overview of the proposed changes:

• Added General Organization Types. In v1.0d, the Affiliation Entity was strictly limited to named organizations (i.e., proper nouns). In practice, we found many programs serve students directly or indirectly affiliated with an entire class of organization, such as programs for participants in any fire cadet program. The proposed Affiliation Entity list adds several general organization types.

• Added Missing Entities. Field work revealed several missing organizations to the list, related additions proposed.

New List Detail

Academic Criteria (New in v1.0e)

Previous versions of the standard had an enumeration baked in to the Standard for Academic Criteria. In v1.0e, the U.S.-centric list was ported to a flexible Academic Criteria list containing both U.S. and Canadian values, with metadata identifying the applicable context(s) for each entry. The current draft list is here.

Citizenship Status (New in v1.0e)

Previous versions of the standard had an enumeration baked in to the Standard for U.S. Citizenship Statuses. In v1.0e, the U.S.-centric list was ported to a flexible Citizenship Status list containing both U.S. and Canadian values, with metadata identifying the applicable context(s) for each entry. The current draft list is here.

Legitimacy Concern (New in v1.0e)

The v1.0e data model adds an entity to track legitimacy concerns with a program. This new list indicates specific reasons for concern. The initial list is based on classic characteristics of concern (e.g., no contact information, no evidence of past winners, bogus program sponsor organizations). But, we expect to refine this list over time. The current draft list is here.

Unforeseen Event (New in v1.0e)

The v1.0e data model adds an eligibility criteria related to events, usually a natural disaster or other unfortunate happening. Semantically, the list of Events is driven by real-world occurrences, so this list is expected to change over time. The NSPA will populate the list with relatively recent events to set the hierarchy and general structure. The current draft list is here.

Add Automatic Application and Automatic Award Indicators (DATA-19 & DATA 20) (New 4/14)

In field use, adopters of the standard have run across a few programs with “automatic” criteria, which have some importance to data exchange use cases.

The first is a set of programs for which students are automatically enrolled (i.e., that do not require students to apply). An indicator for this type of program would be useful because these programs would typically not be presented to students in scholarship listing, searching, and matching systems. By definition, students need not apply.

The second is a set of programs for which all eligible applicants are automatically awarded a scholarship or benefit. An indicator for this type of program would be useful because any eligible student should be encouraged to apply. This may be a useful piece of information for, say, search ranking algorithms that positively weighted programs where a scholar was most likely to win an award.

Change Detail

Proposed changes include:

• Add an optional IsAutomaticApplication Boolean flag to indicate programs for which students need not apply to be considered.

• Add an optional IsAutomaticAward Boolean flag to indicate programs for which all qualifying students are awarded a scholarship.

Usage Notes

• Both elements are optional. For both elements, receiving systems can treat a missing value as the equivalent of false. These types of programs are currently rare enough in observed data that an explicit false is not necessary.

• The Is Automatic Award flag does not mean anyone who applies is awarded without verification, of course. This flag should be assumed to mean that any eligible applicant will receive an award only after the program staff verify an applicant’s eligibility.

Minor Changes to the Data Model

This section describes relatively minor changes to the NSPA Scholarship Program data model.

Allow Multiple CIP Codes per Major in Field of Study Eligibility Criteria (DATA-40) (New 5/19)

Our current v1.0d data model has a "Fields of Study" eligibility criteria to indicate a scholar’s major or academic focus. In addition to a natural-language expression of the field of study (e.g., “Journalism”), the eligibility criteria allows entry of a CIP code (e.g., “9.0401“).

This update is proposed because our current data model allows only one CIP Code per major — but our Field of Study value list allows for multiple CIP codes to align with a single Field of Study. This change will make it easier for students and the NSPA Data Team to use human-friendly names for fields of study, even when those friendly names encompass multiple CIP codes.

As an aside, this would also allow for use to wide fields of study, for example, "STEM" and have all related CIP codes populate from metadata.

The following XML data snippet shows an example of a major with multiple CIP Codes:

Refactor Program Organization Name into Program Organization Entity (SPDS-50/DATA-25) (Updated 5/23)

Field implementation of v1.0d revealed something that wasn't unexpected: having "typed" Associated Organizations made it odd to have a different (and looser) structure for the Program Organization. 

Notes from the field: 

Program Organization is pretty much the same as Associated Organizations in that it also has Type and Role. I liked that fact that we are giving a reference ID to the organization (in the same spirit as giving reference id to Program Name). I already have a database table where we add Program organization. Associated organizations will also be added in the same table.

This change will refactor the Program Organization Name into a Program Organization entity containing the same properties as those already found in the Associated Organization.

Change Detail

Proposed changes would include:

• Rename ProgramOrganizationName to ProgramOrganization. Instead of ProgramOrganizationName being a Short String, it now becomes an object of the “Organization” type. This will enforce that ProgramOrganization now has a Reference ID (whereas currently only Associated Organizations have a Reference ID). This also adds a OrganizationType and OrganizationRole. 

• Add a “Program Sponsor” value to the OrganizationRole value list.

• On a completely trivial note: the new Program Organization entity was moved below the ProgramReferenceId element to group it with the Additional Associated Organizations.

The JSON snippet below illustrates the Program Organization:

Add Organization ID to Organization (SPDS-51/DATA-26) (Updated 5/23)

The NSPA Exchange already assigns a GUID to each unique organization, which is used internally to assist with data consistency and searching. Some prospective field implementers have suggested that it would be useful for NSPA to expose its unique IDs as a number analogous to the NCES or CEEB codes. This field would carry that value. 

Note that a GUID may not be suitable as an external reference. So, we may implement the element allowing for a GUID/UUID, but transition to a human-friendly, NSPA-issued, unique code over time (similar to the CEEB code, but, one hopes, easier to find and navigate).

One clarifying point: The Organization (née AssociatedOrganization) Entity already has an Organization Reference ID, but that indicates an organization's own ID for the program record. In other words, this ID is maintained and used by data providers to identify a program. Consider an Organization ID Type, which would allow for CEEB, NCES, NSPA, or other externally valid reference values.

Change Detail

• See also DATA-25.

• The refactoring of ProgramOrganizationName from a string into an Organization entity (in DATA-25) adds a GUID “for free,” since it was already part of the Organization definition.

• For v1.0e, we’re simply going to let the Organization Reference ID GUID fill the Organization ID role. In the NSPA Exchange context, this will be a unique ID — but implementers may elect to use their own Organization ID in data exchange scenarios.

• We’ll continue to solicit input from the field regarding the usefulness of a “friendly” ID administered by the NSPA.

Consider Adding Country of Residence Support (DATA-36)

This addition would add a Country of Residence eligibility element, which would fill a semantic gap between the current Citizenship Status and Location elements, indicating country of origin for international students.

This should be considered in the context of any other international support planned for the current revision cycle.

Change Detail

• This was addressed with a nontechnical change. The data model already supports a Location criteria with a country element. As part of the general improvements for international support in v1.0e, we’re clarifying that the existing Country element should be populated to indicate the context in which a program is valid.

• See also DATA-30, which elaborates on this change.

Consider Refining Support for Additional GPA Scales in Academic Eligibility (DATA-37)

The current version of the standard supports a minimum GPA (and maximum GPA) in the Academic Eligibility entity. By definition, the value is encoded on a 4.0 scale.

The real world, of course, contains a multitude of scales and indications. In the U.S., that minimally includes:

• A letter scale (e.g., A, A-, B+, B, B-, C, etc.)

• A 1–100, or percent-scale, grade

• A 5.0, or weighted, scale

• A 4.5, or honors, scale

...and more.

International support will require support for additional systems, with support for Canadian programs being the current priority.

This entry represents the work to consider options and formalize additional support.

The current data standard usage documentation suggests referencing the conversion on the How to Convert Your GPA to a 4.0 Scale article on the College Board site. That conversion method is used by the NSPA data team when coding data in its system, and multiple implementers have pointed to the same resource as their method. At least in the near-term, it may be worth considering an expansive, standardized set of conversions (as opposed to what would be an elaborate coding scheme, with multiple data types and a fixed set of enumerated scale types).

Change Detail

The proposed change for this version is technically simple: continue to normalize input into a U.S. 4.0 scale, but establish a robust, standardized mapping to other scales.

• The NSPA will publish a set of conversion tables and methods (a draft of which is here).

• NSPA will use the conversions for its own uses (such as the NSPA Exchange).

• Adopters will be encouraged to use the same conversions in data exchanges using the standard. (To be clear, adopters will continue to use whatever method best suits their use cases within their own systems. The recommendation will solely apply to exchanging data between systems using this standard.)

Consider Adding an “Amount Varies Up To…” Indicator (SPDS-37/DATA-18)

Back in the halcyon days of Q4-2019, we ran across several programs listing an amount in the form "Varies up to $10,000" or semantic equivalent. The Freda Gray Charitable Fund at The Pittsburgh Foundation (https://pittsburghfoundation.org/scholarship/1958) is a good example.

The current data model supports a single-value award amount, and a minimum-maximum range. And, by convention, leaving both the minimum and maximum award amounts blank semantically means “the amount varies.” But, the standard has no structured way of indicating an "up to" amount.

We’ve considered workarounds such as entering a $0 or $1 amount a minimum and advising implementers about how to handle that in display. But, this approach seems actively misleading and likely error-prone, so we’re proposing a structured indicator for this purpose.

Add Support for U.S. Nationals in Citizenship (SPDS-6/DATA-5)

The term "U.S. national" is used by UNCF (United Negro College Fund). A large percentage of their programs are open to people who are a "U.S. citizen, U.S. national or permanent resident." Generally, the term U.S. national also includes U.S. citizens, but in this context, it also refers to noncitizen U.S. nationals from American Samoa and Micronesia, a population served by UNCF. The categorization is generally useful, so it’s a proposed addition to the list of U.S. Citizenship eligibility criteria.

Change Detail

The proposed change is simple:

• Add the value “U.S. National” to the new NSPA Citizenship Status list as an option for programs in the U.S. context.

Add and Improve Values in Degree Seeking Criteria List (DATA-9, DATA-34) (Updated 4/25)

The current Degree Seeking enumeration indicates the degree or credential toward which applicants will be working. The current list starts with postsecondary experiences such as Professional Certification, and has postsecondary degree values such as Bachelor's Degree.

Some scholarships are available for High School graduation. Consider adding High School, GED, and professional certificates in a future revision.

As a side benefit: the Scholar Snapp Profile standard to which the NSPA Scholarship Program Standard aligns has a value for High School in its analogous "Degree Being Sought" enumeration. This will keep the two standards in synch.

Change Detail

The following additions are proposed to the Degree Seeking Criteria List:

• Add a High School item.

• Add a GED item.

• Add a Professional Badge item.

• Add a Professional Certification item.

• Add a Professional Micro-credential item.

The following change is proposed to the Degree Criteria List:

• Change the former “Associate’s Degree” item to Associate Degree.

The following annotated listing shows the proposed list in toto:

Support Maximum GPA and Maximum Class Rank Percentage (DATA-11) (New 4/25)

The current Program Info standard only allows encoding for Minimum GPA, and minimum amounts for other academic criteria. We originally left out the companion "Maximum" values because maximums were applied to few criteria, few programs, and made public for even fewer.

However, in practice, we are seeing examples in the field with published maximum GPA amounts. A few have been firm requirements, while others are an expressed preference.

This proposed change will add selected maximum amounts to academic criteria.

Change Detail

The following additions are proposed to the Academic Eligibility Criteria List enumeration:

• Add a MaximumGPA item.

• Add a MaximumClassRankPercentage item.

Usage Notes

• Both values should only be added to the Eligibility Criteria if a maximum value is a requirement to apply. When the Maximum value is phrased as the upper boundary of a preferred range, it should be entered as a Preference Criteria.

Consider a Refactor or Rename of Locations in XSD (SPDS-1/DATA-1)

The "Locations" entity in the XSD is odd: it's at the root level of the Schema, but allows multiple values.

In JSON, the syntax for multiple locations makes sense, because each {"State":"...", "Country":"..."} pair is its own object in the Locations array:

But in XML, each <Locations> element is at the same level, not in a containing element:

It “feels” like the element name should be singular <Location> or there should be a <Locations> element with individual <Location> elements inside. Though it complicates the schema slightly, we’re leaning toward the latter.

Consider Allowing Affiliation Entity Names Longer Than 100 Characters (SPDS-58/DATA-33)

In real-world use, we've seen scholarship-related organization names that exceed 100 characters, e.g., "United Association of Journeymen and Apprentices of the Plumbing and Pipe Fitting Industry of the United States and Canada Local 344" and similar.

Rather than arbitrarily truncate or abbreviate long names, consider changing the Affiliation Entity string length from a Short String (100 characters) to a Medium String (512 characters).

Presuming we make this change, the Affiliation Entity Other string length would also be increased to a Medium String.

The change is illustrated on lines 10 and 16 in the following XSD listing:

Element & Entity Name Improvements (SPDS-8/DATA-7)

A minor element name change was made as part of v1.0e.

Change Detail

Proposed changes would include:

• Change AgeRestrictionEligibility back to its intended name AgeEligibility. This change came from a minor coding error in the production system for v1.0d.

We originally noted a fix to GraduationStatusCriteria, but that was no longer relevant given the element was removed/refactored as part of DATA-2.

General Changes & Improvements

Consider Developing a Flat-File Representation of the Standard (SPDS-56/DATA-31)

The current technical representations of the NSPA Scholarship Program data model are in XML and JSON, which are suitable for machine-to-machine transfer and have robust tools available for developer use.

However, use-cases are emerging where humans are in the data exchange pipeline (e.g., program staff who keep data natively in Excel, exports from existing systems that are massaged by humans, and so forth).

This work would create a new flat-file model and technical expression for the Data Standard. Key considerations include:

• Full coverage of the data model allowing all the flexibility of XML and JSON is not practical. For example, 1-N repeating elements are difficult to represent in a columnar way. But, our sense is that most core data elements and a reasonable subset of eligibility criteria coding is both possible to represent in a flat file and potentially useful.

• We assume a mapping between the full data model and the flat-file representation will be a required part of the specification for this to be practical.

• If the flat-file has significant uptake in the field, ancillary technical support would be useful. For example, an XSLT or other executable means of transforming data to and from flat-file to XML or JSON would be useful.

• The NSPA Member Site can import data as a flat-file with ~12 columns — and even that limited spec has been useful for internal data teams and external groups supplying data.

• Expressions for CSV, tab-delimited, and Excel may be useful. In conversation, we most often hear “Excel.”

Changes On Hold Pending Further Input

Google Maps Platform & Geolocation for Location Eligibility (SPDS-28/DATA-17)

This change is on hold pending further input. Because it is optional and additive, the change is still a candidate for the final release of v1.0.

Google Maps Platform (https://developers.google.com/maps/documentation/javascript/basics ) and its associated data services have a complete toolkit for looking up and representing locations. Notable for the NSPA Exchange data model, the services define the sometimes nebulous locations expressed in eligibility criteria (e.g., “for scholars in the Bay Area”), and provides international support. We’re considering if and how to integrate the Maps Platform services with the Exchange data model.

Note that the Google place ID is exempt from caching restrictions that apply to most other location services data provided by Google. In fact, Google publishes advice on saving the place ID in client applications here. We intend to follow the published advice, which notes:

• The place ID provided by Google is a string of text characters (e.g., the San Francisco Bay Area in California is encoded as ChIJtdeIpqODhYARqR9GV4QbiYw).

• Google explicitly notes that there is no defined maximum length to the place ID. We’ve seen examples around 700 characters long, so we’ll use a compatible string type of adequate length.

• Although the place ID is generally stable, it can change or become obsolete over time. Implementers should note that Google recommends refreshing stored place IDs annually. Google provides an ID refresh endpoint, but also recommends that implementers store the raw information used to produce the ID in case an ID misses its refresh window.

Google provides free services to retrieve place IDs, and to refresh place IDs. This means that implementers creating and maintaining records (such as the NSPA Exchange) can do so at a minimal cost. However, some use cases for implementers may come with a cost. For example, testing a scholarship applicant’s address to see whether it is within a particular Google place ID would be a paid use.

Change Detail

Notes on the proposed changes:

• The data model may only require minor modifications, likely a simple element to store a Google place ID and perhaps a search result.

• The real magic will be in the matching and filtering by scholarship services that can use a Google Location ID to determine eligibility.

Reviewers have noted that this improvement would benefit from a specific definition how this would work before committing to add the element, and a reference implementation once the improvement is added (e.g., showing the process to test a set of encoded programs against a student’s address or place of residence).

Add a Unique Code Element to Published Value Lists (SPDS-20/DATA-20)

This change is on hold pending further input. Because it is primarily a change to metadata, and would be optional in the data model, the change is still a candidate for the final release of v1.0.

The NSPA Scholarship Program Data Standard v1.0d replaced many enumerations with values defined by an NSPA-published list (e.g., an Activity List containing values such as “Football” and “Choir”). The implementation treats each text item as a necessarily unique value.

However, creating a value list using meaningful text has the usual attendant problems over time: one can't correct spelling errors without having an unambiguous reference to the previous value being corrected, and so forth. This proposed change would add an unambiguous code for every enumeration value defined by an NSPA-published list. The data model would likely offer an optional element to contain the code value.