The Scholar Snapp solution was updated for the 2018-2019 application cycle. The data model changes in the Snapp Profile (i.e., the applicant data exchanged by the Snapp Central API) were relatively light compared with previous updates. Most updates to the Snapp Profile data model were suggested by existing implementers. A few updates correct errors or typos in the standard.

The Snapp team heartily thanks all the implementers, technologists, and subject matter experts who provided input.

We welcome and accept feedback any time. If you are a current or prospective implementer of the Snapp Data Standard or the Snapp Central API and would like to provide input or be included in the next RFC period, please send a note to Governance@scholarsnapp.org with your contact information.

This documentation is a companion piece to What's New in the Snapp API v4.0, which describes the changes specific to the Snapp Central API.

Overview

The information that follows describes changes in the latest version of Scholar Snapp. 

The changes include:

Detail on each change follows.

Changes to the Snapp Data Standard

This section describes changes to the Snapp Data Standard, which defines the data payload representing an applicant's data.

Refine Gender, Gender Detail, and Orientation (SSDS-56)

Snapp previously contained three elements related to the notion of gender and gender identity. Based on community and partner feedback, we’ve updated the way in which we represent the notion of biological sex and gender identity.

Snapp has included gender identity information (i.e., information beyond a binary M/F choice) since its first version in 2008. For example, in v3.0, there was a distinction between biological sex and gender identity. For Berkeley, we have implemented several improvements.

In Snapp 4.0, we have elected to keep certain things the same. 

• Gender information is optional. The Snapp Profile treats gender information as optional. Accordingly, applicants are not required to enter gender or gender identity information when using the online Snapp Application form. The application's online help makes this clear. If gender identity data is present (e.g., if received from a partner requiring the information), students can remove that information from their profile.
• There is a simple, nullable gender field indicating the applicant's current biological sex. Most of our current scholarship providers use a binary Male / Female choice – and for many, the value is required. Similarly, many partners have indicated that they're addressing gender identity by providing options equivalent to "Male," "Female," and "Choose not to respond." So, we will continue to have the simple M/F/unspecified value to remain compatible with those scholarship providers.
• We provide support for the notion of gender identity with an approach that's both sensitive and practical. A common piece of advice when asking how to convey gender identity information is "Don't ask." However, given our history providing support and interest from current partners, we do provide support in the Berkeley version of Snapp. In addition, some scholarship programs are for the benefit of individuals with a specific gender identity, and our scholarship search feature can use this information to provide applicants with scholarship options for which they qualify.

Change Detail

In Snapp 4.0, we have made the following changes:

• The creation of a new Gender Identity element that combines the current Gender Detail and Orientation elements. Version 3.0 of Snapp separates biological gender values such as transsexual and transitioning from sexual orientation values such as gay and lesbian. Since those values are more typically found grouped into a single notion of identity, we have combined the values into a single "Gender Identity" element.
• The creation of a new, expansive Gender Identity enumeration. To date, we haven't found an authoritative standard that is reasonably inclusive of the values found represented by the LBGTQIA acronym and our partners. We've created an amalgam of values from various studies, sources such as the GLAAD Media Reference Guide, and the values in use by partners. 
• Support an explicit "Prefer Not to Answer" option. Rather than simply leave the Identity field optional, some applications and surveys offer a way for the applicant to indicate they would prefer not to answer. We are accommodating that – in addition to leaving the element optional.
• Use a "Prefer to Self-Identify (Other)" value for Gender Identity. Many surveys and applications asking about gender identity support a free-form text field. To support these partners, we have added a "Prefer to Self-Identify (Other)" value in the Gender Identity enumeration with an accompanying 100-character text field. Generally speaking,  "Prefer to Self-Identify" or similar inclusive language is used to indicate a free-form entry for this value. But, we include "Other" in the value text as a hint for technologists and analysts doing data mapping. This element is analogous to Facebook's "Custom" gender option. 

The following XSD snippet shows the list definition and enumeration items.

	...
	<xs:simpleType name="GenderIdentityList">
		<xs:annotation>
			<xs:documentation>The gender identity of a person</xs:documentation>
		</xs:annotation>
		<xs:restriction base="sds:ShortString">
			<xs:enumeration value="Asexual"/>
			<xs:enumeration value="Bisexual"/>
			<xs:enumeration value="Gay"/>
			<xs:enumeration value="Genderfluid"/>
			<xs:enumeration value="Genderqueer"/>
			<xs:enumeration value="Intersex"/>
			<xs:enumeration value="Lesbian"/>
			<xs:enumeration value="Non-binary"/>
			<xs:enumeration value="Nonconforming"/>
			<xs:enumeration value="Pansexual"/>
			<xs:enumeration value="Questioning"/>
			<xs:enumeration value="Straight"/>
			<xs:enumeration value="Straight Ally"/>
			<xs:enumeration value="Transgender, Female to Male"/>
			<xs:enumeration value="Transgender, Male to Female"/>
			<xs:enumeration value="Transitioning, Female to Male"/>
			<xs:enumeration value="Transitioning, Male to Female"/>
			<xs:enumeration value="Prefer Not to Answer"/>
			<xs:enumeration value="Prefer to Self-Identify (Other)"/>
		</xs:restriction>
	</xs:simpleType>
	...

Refine Class Type List Enumeration (SSDS-34)

The ClassTypeList (e.g., AP, IB, General) was established using the values from the Dell Scholars Program and other initial implementers as a guide. This improvement pegs the list to an external standard or norm.

• CEDS, for example, has a Course Level Characteristic enumeration. This has a number of values such as "Completion of requirement, but no units of value awarded" and "Career and technical education general course" that conceptually map to expected values, but from a style perspective are rather long.
• The Ed-Fi Data Standard has a conceptually similar enumeration but with more concise values than CEDS. The Ed-Fi Data Standard values "feel" more in-line with the rest of the Snapp idiom.

At this point, the Ed-Fi Data Standard looks like the external standard closest to the values relevant to Snapp partners.

Change Detail

The base enumeration in the Ed-Fi Data Standard appears closest to the intent and existing values in Snapp. We now align to that list of values, in the following manner:

• No existing Snapp values are modified (for backward compatibility).
• Existing Snapp values with a clear mapping to a different value in the Ed-Fi Data Standard are unchanged in the Snapp Profile (for backward compatibility).
• We have added values found in the Ed-Fi Data Standard for which a value does not already exist in Snapp. Additions follow the existing Snapp patterns for capitalization and abbreviation.
• We alphabetized the value list definition. 

The following XSD snippet shows the definition of the Class Type List in v4.0:

	...
	<xs:simpleType name="ClassTypeList">
		<xs:annotation>
			<xs:documentation>The type of student courses</xs:documentation>
		</xs:annotation>
		<xs:restriction base="sds:ShortString">
			<xs:enumeration value="Advanced"/> <!-- New -->
			<xs:enumeration value="AP"/>
			<xs:enumeration value="Career and technical education"/> <!-- New, equivalent to 'CTE' -->
			<xs:enumeration value="College-level"/> <!-- New -->
			<xs:enumeration value="Core subject"/> <!-- New -->
			<xs:enumeration value="Correspondence course"/> <!-- New -->
			<xs:enumeration value="Distance learning"/> <!-- New -->
			<xs:enumeration value="Dual enrollment"/>
			<xs:enumeration value="English language learner"/> <!-- New, equivalent to 'ELL' -->
			<xs:enumeration value="General"/> <!-- Existing, equivalent to 'Basic' -->
			<xs:enumeration value="Gifted and talented"/> <!-- New, equivalent to 'GTE' -->
			<xs:enumeration value="High school equivalent"/> <!-- New -->
			<xs:enumeration value="Honors"/>
			<xs:enumeration value="IB"/>
			<xs:enumeration value="Magnet"/> <!-- New -->
			<xs:enumeration value="Pre-AP"/>
			<xs:enumeration value="Pre-IB"/> <!-- New -->
			<xs:enumeration value="Remedial"/>
			<xs:enumeration value="Senior"/>
			<xs:enumeration value="Special education"/> <!-- Existing, maps to 'Students with disabilities' -->
			<xs:enumeration value="Untracked"/> <!-- New -->
			<xs:enumeration value="Other"/>
		</xs:restriction>
	</xs:simpleType>
	...

Add DACA Indication and Additional Citizenship Status Options (SSDS-59)

Some scholarship programs directly serve DREAMers and other individuals who have current or pending DACA status. The previous version of Snapp has citizenship values that plausibly apply, but no explicit indication of DACA status. This change adds a DACA indication to Snapp.

Other additions to Citizenship status were considered. For example, the federal Student Aid Report (SAR) has statuses not represented in Snapp, but likely meaningful to scholarship programs. 

Change Detail

We have added two DACA-specific values to the Citizenship Status List enumeration in Snapp:

• Current DACA Status
• Pending DACA Application

In addition, we have added the following SAR values to the same Citizenship Status List enumeration:

• Conditional Permanent Resident
• FAFSA-Eligible Non-Citizen
• Asylum-Seeker or Asylee
• Cuban or Haitian Entrant
• Humanitarian Parolee

Existing enumeration items from Snapp v3.0 will remain unchanged.

The following XSD snippet shows the definition of the Citizenship Status List in v4.0:

	...
	<xs:simpleType name="CitizenshipStatusList">
		<xs:annotation>
			<xs:documentation>The list of possible citizenship statuses</xs:documentation>
		</xs:annotation>
		<xs:restriction base="sds:ShortString">
			<xs:enumeration value="Asylum-Seeker or Asylee"/> <!-- New -->
			<xs:enumeration value="Conditional Permanent Resident"/> <!-- New -->
			<xs:enumeration value="Cuban or Haitian Entrant"/> <!-- New -->
			<xs:enumeration value="Current DACA Status"/> <!-- New -->
			<xs:enumeration value="FAFSA-Eligible Non-Citizen"/> <!-- New -->
			<xs:enumeration value="Humanitarian Parolee"/> <!-- New -->
			<xs:enumeration value="Non-U.S. Citizen"/>
			<xs:enumeration value="Pending DACA Application"/> <!-- New -->
			<xs:enumeration value="Refugee or Protected Person"/>
			<xs:enumeration value="Resident Alien or Permanent Resident"/>
			<xs:enumeration value="U.S. Citizen"/>
		</xs:restriction>
	</xs:simpleType>
	...

Clarify and Refine Armed Services Criteria (SSDS-61)

During internal development and testing of a scholarship search feature, the Snapp technical team discovered a few ambiguities in the Armed Forces Student Characteristics entity.

Ambiguity issues include:

• The service status (e.g., active duty, reserve duty, veteran) are independent of each other, and also not clearly tied to a service branch. This means there's not an unambiguous way indicate an applicant is a veteran of one service branch and currently on active duty in another.
• Reserve statuses are baked in to the service branch (e.g., "Army Reserve" is a distinct "service" from "Army"), which is not really accurate.

There are also a few housekeeping issues that have been fixed:

• The service branch is indicated by an element called "VeteranDesc", which is not correct since the element is used generically to indicate the service branch.
• The list of statuses has no way to indicate that an individual is retired.

Change Detail

We have made the following changes to the Armed Forces Student Characteristics entity:

• Refactoring existing Armed Forces Student Characteristics elements that represent service and status into a single entity indicating Service History. Elements affected by this reorganization include VeteranDesc (a 0-n enumeration), Veteran (a Boolean status), and Active Duty (another Boolean status).
• The history now contains a branch (e.g., Army, Navy), and a service status associated with that particular branch (e.g., Veteran, Active Duty). To maintain compatibility with existing semantics, we have implemented the service status as optional.
• The service status adds values of Retired and Reserve Duty.
• The various reserve branches (e.g., Army Reserve, Coast Guard Reserve) have been removed, and instead Reserve Duty service status now indicates that state of being.

• The "VeteranDesc" element has been renamed "MilitaryBranch."

The changes are applied both to the applicant entity and the analogous entity on Relative.

The following XML snippet shows the v3.0 and analogous v4.0 record for an applicant:

	<!-- OLD applicant armed forces elements in v3.0 -->
	...
	<ArmedForcesCharacteristics>
		<Veteran>true</Veteran>
		<VeteranDesc>Army</VeteranDesc>
		<POW>false</POW>
		<ChildOfPOWMIA>false</ChildOfPOWMIA>
		<GIBillEligible>false</GIBillEligible>
		<ActiveDuty>false</ActiveDuty>
	</ArmedForcesCharacteristics>
	...

	<!-- NEW applicant armed forces elements in v4.0 -->
	...
	<ArmedForcesCharacteristics>
		<StudentServiceRecord>
			<MilitaryBranch>Army</MilitaryBranch>
			<ArmedServiceStatus>Veteran</ArmedServiceStatus>
			<WarOrConflict>First Gulf War</WarOrConflict>
		</StudentServiceRecord>
		<ChildOfPOWMIA>false</ChildOfPOWMIA> <!-- Unchanged -->
		<GIBillEligible>false</GIBillEligible> <!-- Unchanged -->
	</ArmedForcesCharacteristics>
	...

The following XML snippet shows the v3.0 active duty flag and analogous v4.0 active duty indication for an applicant:

	<!-- OLD active duty flag in v3.0 -->
	...
	<ArmedForcesCharacteristics>
		...
		<ActiveDuty>true</ActiveDuty>
	</ArmedForcesCharacteristics>
	...

	<!-- NEW active duty indication in v4.0; for backward compatibility, branch not required (though recommended)  -->
	...
	<ArmedForcesCharacteristics>
		<StudentServiceRecord>
			<ArmedServiceStatus>Active Duty</ArmedServiceStatus>
		</StudentServiceRecord>
		...
	</ArmedForcesCharacteristics>
	...

Add Indicator for Current Grade Level (SSDS-65)

The previous v3.0 Snapp Profile had many fields related to current educational attainment such as the Education Level element, the Graduation Info entity, and so forth. However, there was no indicator for Current Grade Level, which is a fairly common and significant qualifying component for scholarship programs. This change addresses that gap.

Change Detail

This change adds a Current Grade Level enumeration to the Snapp Profile, and a new element was added to the Education Level complex type to hold the enumeration value. Additionally, the current Education Level element in the complex type was changed from required to optional.

The following XSD snippet shows the definition of the Current Grade Level List in v4.0:

	...
	<xs:simpleType name="CurrentGradeLevelList">
		<xs:annotation>
			<xs:documentation>The list of current grade levels for an applicant. Tracks to eligibility, so contains grade levels (e.g., High School Senior, College Freshman) plus a few options that indicate a situation or status (e.g., 5th Year College Undergraduate, On Academic Break).</xs:documentation>
		</xs:annotation>
		<xs:restriction base="sds:ShortString">
			<xs:enumeration value="High School Freshman"/>
			<xs:enumeration value="High School Sophomore"/>
			<xs:enumeration value="High School Junior"/>
			<xs:enumeration value="High School Senior"/>
			<xs:enumeration value="Community College Freshman"/>
			<xs:enumeration value="Community College Freshman - Attended College Previously"/>
			<xs:enumeration value="Community College Sophomore"/>
			<xs:enumeration value="College Freshman"/>
			<xs:enumeration value="College Freshman - Attended College Previously"/>
			<xs:enumeration value="College Sophomore"/>
			<xs:enumeration value="College Junior"/>
			<xs:enumeration value="College Senior"/>
			<xs:enumeration value="5th Year College Undergraduate"/>
			<xs:enumeration value="Nth Year College Undergraduate"/>
			<xs:enumeration value="Graduate Student"/>
			<xs:enumeration value="Doctoral Candidate"/>
			<xs:enumeration value="Postgraduate Medical School"/>
			<xs:enumeration value="Postgraduate Law School"/>
			<xs:enumeration value="Not Enrolled"/>
			<xs:enumeration value="On Academic Break"/>
		</xs:restriction>
	</xs:simpleType>
	...

These values are aligned with the Snapp Program Information data model. Some of the oddly specific entries (e.g., 5th Year College Undergraduate) are based on program eligibility requirements we've seen in the field.

Update List of College Readiness Programs (SSDS-66)

The previous v3.0 Snapp Profile already has a list of College Readiness Programs. This change simply updates the list of programs in the standard.

Change Detail

We reviewed lists used by our partners (e.g., the Dell Scholars Program) for updates and changes. We found a few updates and otherwise left existing program names in the enumeration unchanged.

The following XML snippet shows the College Readiness Program list in v4.0.

	...
	<xs:simpleType name="CollegeReadinessProgramList">
		<xs:annotation>
			<xs:documentation>The list of common college readiness programs</xs:documentation>
		</xs:annotation>
		<xs:restriction base="sds:ShortString">
			<xs:enumeration value="Alliance"/>
			<xs:enumeration value="AP Strategies"/>
			<xs:enumeration value="ASPIRE"/>
			<xs:enumeration value="AVID"/>
			<xs:enumeration value="Bottom Line"/>
			<xs:enumeration value="Breakthrough"/> <!-- New -->
			<xs:enumeration value="Breakthrough Austin"/>
			<xs:enumeration value="College Forward"/>
			<xs:enumeration value="College Possible"/>
			<xs:enumeration value="College Track"/>
			<xs:enumeration value="Cristo Rey Network"/>
			<xs:enumeration value="Fulfillment Fund"/>
			<xs:enumeration value="GEAR UP"/>
			<xs:enumeration value="Genesys Works"/>
			<xs:enumeration value="Green Dot"/>
			<xs:enumeration value="IDEA Academy"/>
			<xs:enumeration value="KIPP"/>
			<xs:enumeration value="KIPP Through College (KTC)"/> <!-- New -->
			<xs:enumeration value="Let's Get Ready"/>
			<xs:enumeration value="Mastery Charter Schools"/>
			<xs:enumeration value="NMSI"/>
			<xs:enumeration value="Noble Network"/>
			<xs:enumeration value="One Goal"/>
			<xs:enumeration value="Philadelphia Futures"/>
			<xs:enumeration value="Uncommon Schools"/>
			<xs:enumeration value="Uplift Education"/>
			<xs:enumeration value="Upward Bound"/>
			<xs:enumeration value="Upward Bound Math-Science"/>
			<xs:enumeration value="YES Prep"/>
			<xs:enumeration value="None"/>
			<xs:enumeration value="Other"/>
		</xs:restriction>
	</xs:simpleType>
	...

Changes In Progress or Coming Soon

This section describes changes to the Snapp solution that are expected sometime in the 2018-2019 scholarship application cycle.

Add Scholarship Application Eligibility Criteria (SSDS-58)

Most scholarships have one or more criteria defining who is eligible to receive the scholarship. Common criteria include current age, grades, test scores, affiliations (e.g., with a company or organization), and so forth. In Snapp v3.0, some of this information is not present (e.g., affiliation with a church or religious organization) and other information can be indirectly derived if a student has completed a thorough profile.

This change adds simple, direct representations of common scholarship eligibility criteria to Snapp.

Change Detail

Rather than "bolt on" eligibility criteria to the existing Snapp Profile Data Standard, we now have a new Snapp Eligibility Data Standard. This standard will convey a compact representation of common criteria – most of which could be derived from the more complex, data-rich entities in Snapp.

The criteria – including any identifying information – is optional, so sending systems can provide only the information of use to the receiving system.

Criteria for inclusion are:

• Academic eligibility (GPA, test scores, etc.)
• Activity eligibility (sports, hobbies, etc.)
• Affiliation eligibility (membership in clubs, churches, employee of organizations, relative of employee of organizations, etc.)
• Armed services eligibility (service branch, service status such as active duty or reservist or veteran, etc.)
• College readiness program participation (AVID, College Forward, KIPP, et al.)
• College preference
• Condition (mental or physical conditions, not necessarily disabilities)
• Current profession
• Current school
• Financial eligibility (FAFSA EFC, etc.)
• Location
• Field of study
• Grade level (current grade, such as graduating high school senior, second year of college, etc.)
• Interest criteria (general interest – distinct from activity, in that someone "interested" in golf is different from someone who plays golf)
• Situation (various life situations such as caregiver, homeless, teen parent; includes situations, such as living abroad, that are not generally perceived as negative.)

Changes Considered but Not Implemented

This section contains changes considered but not implemented in v4.0 based on feedback and further research.

Merge or Better Document Current Enrollments and Graduation Info (SSDS-44)

In Snapp, the Student.CurrentEnrollments element contains information about a student's present school, expected graduation date, for example., while the Student.GraduationInfo essentially contains past enrollment with a few additional details about the outcome such as GPA, actual graduation date, and so forth.

These are semantically distinct concepts, but the similarity between the two data structures can be confusing, especially because many applicants will have "current" enrollments that become graduation events during the course of a Scholarship application cycle.

This improvement provides a solution that combines the two without losing the distinction between events we expect to happen in the future and events that have already happened.

Change Detail

For the Berkeley (v4.0) generation of Snapp, we address this issue via improved documentation, and leave the Snapp Profile definitions of the Current Enrollment and Graduation Info entities as it is in v3.0.

We are using this nontechnical approach because we believe having a distinct historical entity (i.e., conveying data that will always be true, presuming data is correct) is useful when separate from a current status (i.e., conveying data that's expected to change).

Reinforcing the do-nothing option is that a drafting exercise resulted in an inelegant entity when combined. For example, a combined entity must make distinctions between expected graduation date and actual graduation date, attempted degree and awarded degree, and similar issues.

Documentation improvements are made:

• In annotations (e.g., in the Snapp Data Standard XSD)
• In online documentation for the relevant elements