1EdTech OneRoster 1.2 CSV Binding: Japan K-12/Schools Profile

Final Release
Spec Version 1.0

Final Release

Document Version:	1.0
Date Issued:	March 1st, 2026
Status:	This document is made available for adoption by the public community at large.
This version:	https://www.imsglobal.org/spec/orcsvjp/v1p0/
Latest version:	https://www.imsglobal.org/spec/orcsvjp/latest/
Errata:	https://www.imsglobal.org/spec/orcsvjp/v1p0/errata/

IPR and Distribution Notice

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights webpage: https://www.1edtech.org/sites/default/files/media/docs/2023/imsipr_policyFinal.pdf .

The following participating organizations have made explicit license commitments to this specification:

Org name	Date election made	Necessary claims	Type
CASIO COMPUTER CO., LTD	November 6, 2025	No	RF RAND (Required & Optional Elements)
UCHIDA YOKO CO., LTD	November 13, 2025	No	RF RAND (Required & Optional Elements)
DIGITAL KNOWLEDGE EDTECH LAB, INC	January 5, 2026	No	RF RAND (Required & Optional Elements)
TOKYO SHOSEKI CO., LTD	February 25, 2026	No	RF RAND (Required & Optional Elements)

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: https://www.1edtech.org/standards/specification-license.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Public contributions, comments and questions should be directed to support@1edtech.org .

Trademark information: https://www.1edtech.org/about/legal

Abstract

The OneRoster® (OR) standard addresses the exchange of student data (primarily about people, courses, enrollments and grades) between different educational systems for the specific needs of K-12. The primary use-cases are: the exchange of data between a Student Information System (SIS) and Learning Management System (LMS), and the rostering of learning tools [OR-OVIEW-12].

A format for CSV file based exchange of the data has been defined. CSV files are typically exchanged between the school and the vendor to populate the roster information needed to gain access to learning tools, portals and learning environments. This specification defines how the relevant information is to be stored in a set of CSV files. This set of CSV files is exchanged as a zip file (it also contains a manifest.csv file that describes the associated data CSV files). The specification DOES NOT define how the zip file is moved from system to system.

This DOCUMENT presents the Japan K-12/Schools Profile of the OneRoster 1.2.1 CSV Binding [OR-CSV-12]. Creation of this document has been facilitated by 1EdTech Japan Society. The key change in this profile of the base specification is the sole focus on Rostering information i.e. support for the exchange of information about resources and gradebooks has been removed. This is a standalone document i.e. it is self contained and includes best practices and the conformance and certification requirements specific to this Profile.

This Section is NORMATIVE.

The set of changes made to the base specification [OR-CSV-12] by the Japan K-12/Schools Profile are:

For the various CSV files the following extensions have been made:
- classes.csv file
  - metadata.jp.specialNeeds (optional) - an enumeration used to denote if this is a special needs class
- enrollments.csv file
  - metadata.jp.shussekiNo (optional) - used to denote the student's attendance number in the associated class
  - metadata.jp.publicFlg (optional) - used to denote public or private
- users.csv file
  - metadata.jp.kanaGivenName (optional) - Hiragana, katakana, half-width, etc. are accepted for the given name
  - metadata.jp.kanaFamilyName (optional) - Hiragana, katakana, half-width, etc. are accepted for the family name
  - metadata.jp.kanaMiddleName (optional) - Hiragana, katakana, half-width, etc. are accepted for the middle name
  - metadata.jp.homeClass (optional) - sourcedId of the home/main class for students with special needs
  - metadata.jp.kanaPreferredFamilyName (optional) - Hiragana, katakana, half-width, etc. are accepted for the preferred family name
  - metadata.jp.kanaPreferredGivenName (optional) - Hiragana, katakana, half-width, etc. are accepted for the preferred given name
  - metadata.jp.kanaPreferredMiddleName (optional) - Hiragana, katakana, half-width, etc. are accepted for the preferred middle name
The following properties have been changed:
- The values for several properties in the manifest.csv have been fixed
- The value for the courseCode property in the courses.csv have been fixed as an empty string
- Values from the dictionary [APPLIC-CODE] are to be used for the values of the subjects and subjectCodes properties
- Several properties in the demographics.csv have been prohibited
- Rules for setting the value of the primary property in the enrollments.csv have been defined
- Vocabularies for several properties in the orgs.csv have been identified
- The vocabulary for the role property in the roles.csv has been extended
Support for the exchange of resource information has been removed. Therefore support for the exchange of the following CSV files has been removed:
- Support for the exchange of the information in the resources.csv file has been removed
- Support for the exchange of the information in the classResources.csv file has been removed
- Support for the exchange of the information in the courseResources.csv file has been removed
- Support for the exchange of the information in the userResources.csv file has been removed

Support for the exchange of gradebook information has been removed. Therefore support for the exchange of the following CSV files has been removed:
- Support for the exchange of the information in the categories.csv file has been removed
- Support for the exchange of the information in the lineItems.csv file has been removed
- Support for the exchange of the information in the lineItemLearningObjectiveIds.csv file has been removed
- Support for the exchange of the information in the lineItemScoreScales.csv file has been removed
- Support for the exchange of the information in the results.csv file has been removed
- Support for the exchange of the information in the resultLearningObjectiveIds.csv file has been removed
- Support for the exchange of the information in the resultScoreScales.csv file has been removed
- Support for the exchange of the information in the scoreScales.csv file has been removed

The details for these data model changes are provided in Section 4.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in [RFC2119].

An implementation of this specification that fails to implement a MUST/REQUIRED/SHALL requirement or fails to abide by a MUST NOT/SHALL NOT prohibition is considered nonconformant. SHOULD/SHOULD NOT/RECOMMENDED statements constitute a best practice. Ignoring a best practice does not violate conformance but a decision to disregard such guidance should be carefully considered. MAY/OPTIONAL statements indicate that implementers are entirely free to choose whether or not to implement the option.

The structure of the rest of this document is:

An outline description of the structure of the rest of this document.
2. ROSTERING IN K-12/SCHOOLS IN JAPAN	An explanation of how the teaching and learning processes in Japanese schools can be supported using this Profile.
3. CSV OVERVIEW	An overview of the structure of the CSV binding for OneRoster 1.2.
4. CSV FORMAT	The detailed format for the data in the CSV files for OneRoster 1.2.
5. EXTENDING THE CSV BINDING	How proprietary data properties may be added so that compatibility can be maintained with systems that do not support these extensions.
6. BEST PRACTICES	The best practices that should be adopted when using this Profile.
7. CONFORMANCE & CERTIFICATION	The set of conformance requirements that MUST be fulfilled to be awarded certification for this Profile.
APPENDIX A – THE FILE DEPENDENCY MATRIX	An explanation of the file dependencies when exchanging bulk processing based CSV files.
APPENDIX B – REVISION HISTORY	History of the various published versions of this document. This includes details of the changes made with respect to the previously published version.
APPENDIX C – REFERENCES	The details of the set of documents cited within this document.
APPENDIX D – LIST OF CONTRIBUTORS	The people who were responsible for the creation of this document.

API: Application Programming Interface
APPLIC: The Association for Promotion of Public Local Information and Communication
BOM: Beginning of Message
CSV: Comma Separated Values
FTP: File Transfer Protocol
GUID: Globally Unique Identifier
IETF: Internet Engineering Task Force
LDAP: Lightweight Directory Access Protocol
LMS: Learning Management System
LOR: Learning Object Repository
LTI: Learning Tools Interoperability
MEXT: Ministry of Education, Culture, Sports, Science and Technology
PII: Personal Identifiable Information
RFC: Request For Comment
SIS: Student Information System
UTF: Unicode Transformation Format
UUID: Universally Unique Identifier

This Section is NOT NORMATIVE.

The School Education Act serves as the foundation of the school education system in Japan. According to this Act, the Minister of Education, Culture, Sports, Science and Technology (MEXT) determines the curriculum from kindergarten to high school. Specific content is defined in the Regulations for Enforcement, while detailed curriculum standards are outlined in the National Curriculum Standard for each educational level. At the local level, the Act on the Organization and Operation of Local Educational Administration stipulates that the board of education manages and executes matters related to curriculum, textbooks, and other educational materials for schools under their jurisdiction. The municipal board of education is required to create a registry of school-age children and students based on the basic resident register, which is used to manage student enrollment in public elementary and junior high schools.

Primary and secondary education in Japan, both public and private, spans from 1st to 12th grade. Elementary school lasts 6 years, junior high school 3 years, and high school 3 years, forming the 6-3-3 system, with elementary and junior high school being compulsory education. The academic year begins in April and ends in March of the following year. 80% of schools divide the academic year into three terms: the first term from April to July, the second from September to December, and the third from January to March. Between terms, there are extended breaks: approximately 40 days of summer vacation, 2 weeks of winter break, and spring break. Term lengths are determined by local governments to ensure necessary instructional hours, with some schools adopting a two-semester system.

In many elementary and junior high schools, the Gakkyu (学級) functions not only as a learning group for subject studies but also as a life experience group that creates a basic living environment and desirable human relationships essential for school life. Therefore, this specification intentionally distinguishes between Gakkyu and class, the latter referring to a simple learning group. In elementary schools, the homeroom teacher is responsible for classroom management and can teach all subjects, though there is an increasing number of subject-specific teachers similar to those in junior high schools. Unlike elementary and junior high schools which are part of compulsory education, high schools have many course systems, with many high schools offering multiple courses. This diversity serves not only general education but also vocational education in fields such as technology, commerce, agriculture, home economics, nursing, fisheries, welfare, and information technology.

This specification applies to elementary education and lower secondary education subject to compulsory education, specifically targeting public elementary and junior high schools, which account for more than 90% of such institutions. Many aspects defined by law, such as the start and end dates of the school year, class organization, and courses can be configured using OneRoster. In addition, many of the roles and names of users necessary for implementing education can also be configured. However, the following items cannot be set with the current OneRoster and require extensions:

The Regulations for Enforcement of the School Education Act require the creation of attendance records.
The School Education Act stipulates special needs education, and it is necessary to specify classes that require special support.
It must be possible to set disclosure permissions for each user registered in a class.
It must be possible to assign attendance numbers to each student.
In Japan, names are generally expressed in kanji, but kanji cannot determine the pronunciation. For example, the kanji name "杉谷裕子" can be read as "Sugitani Yuko" as well as "Sugiya Hiroko." Therefore, it is necessary to set the reading of the name.

Additionally, the following issues exist regarding optional settings:

School names, board of education names, grade levels, subject names, and subject codes need to be included in the specifications according to the codes established by MEXT or APPLIC.
In Japan, demographics-related information such as race or country of origin is not required, so it is necessary to specify that these are not used.
Items that are optional in OneRoster need to be set to specified values according to Japanese circumstances. For example, enabledUser in users.csv is {true|false}, but in Japanese usage, it should be set to true.

The OneRoster Japan Profile adds a new column called "Profile Annotation" to the tables explaining the data model of each CSV file shown in the OneRoster CSV Binding specification. This column records annotations regarding considerations for use in Japan. Examples of annotations include instructions on how to specify the title in courses.csv for Japanese elementary and junior high schools that do not adopt a course system, and directions to reference MEXT codes or APPLIC codes for grades and subjects in courses.csv and classes.csv.

Additionally, newly required columns are added according to the metadata extension method, as shown in Figure 1:

In 'users.csv', when specifying givenName, familyName, and middleName in kanji, their readings and display names are supplemented in either katakana or hiragana.
In 'classes.csv', a flag for Special Needs Class is added.
In 'enrollments.csv', disclosure settings for student information and attendance numbers are added.

This Section is NORMATIVE.

Many districts currently provide student information to tool providers and LMS/LOR vendors as .csv formatted files. For those districts that must continue to use CSV files to exchange roster information with vendors, the format defined in the Tables in Section 4 should be used: this format corresponds to the data models in the OneRoster 1.2 Rostering [OR-ROS-SM-12] document. Districts can choose to upload class rosters by preparing up to eleven (11) files in CSV format outlined in this document. The rosters could be available for both import and export. A summary of the set of files is given in Table 3.1.

Table 3.1 A summary of the list of files that may be present as part of a OneRoster CSV-based data exchange for the Japan K-12/Schools Profile.
CSV File Name	Required	Description
manifest.csv	Yes	A control file. The manifest contains the OR version (set as 1.2 for this release of the standard) and the list of files that are supplied in this data set.
academicSessions.csv	No	A data file. The academic sessions data model content.
classes.csv	No	A data file. The classes data model content.
courses.csv	No	A data file. The courses data model content.
demographics.csv	No	A data file. The demographics data model content. Data model revised in v1.2.
enrollments.csv	No	A data file. The enrollments data model content.
orgs.csv	No	A data file. The orgs data model content.
roles.csv	No	A data file. The mapping between roles, orgs and accounts data models content.
userProfiles.csv	No	A data file. The userProfiles data model content.
users.csv	No	A data file. The users data model content.

KEY:

CSV File Name – the name of the CSV file;
Required – denotes whether or not the CSV file MUST be supplied (Yes or No);
Description – a statement of the content in the file.

When data is exchanged there will be 1-10 CSV files. An exchange MUST include the manifest.csv file. The case of when only the manifest.csv is supplied is used to denote that no updates occurred. At most, 10 CSV files are exchanged i.e. there MUST NOT be more than one of each of the data CSV files. When the set of files are for bulk processing they must be semantically consistent i.e. every object referenced in a file must also be defined in either the same, or one of the other files in the zip package (see Appendix A for more details on this set of file dependencies).

For V1.0 of the Japan K-12/Schools Profile the CSV files will be exchanged as a zip file. The encompassed files must be at the root level i.e. they MUST NOT be contained within an enclosing directory. There is NO constraint on the name of the zip file but it must have a file extension of ‘zip’. The compression MUST conform to [RFC1951].

The existence and management of a record is controlled via the bulk and delta processing options. A record can be in four possible states:

'No Record' – the record has not been created or it did exist but the system has deleted the record and it cannot be recovered with the previously assigned sourcedId;
'Record[-]' – the record has been created and assigned a sourcedId but it has not yet been activated;
'Record[Active]' – the record status has been set to 'active';
'Record[ToBeDeleted]' – the record status has been set to 'tobedeleted'.

For each state there are four possible types of transition events:

B[-] – a bulk transfer has occurred and an existing record (one with a sourcedId) does not appear in those files;
B[S] – a bulk transfer has occurred and the record occurs in the new file set;
D[A] – a delta transfer has occurred and the record status is set as 'active';
D[D] – a delta transfer has occurred and the record status is set as 'tobedeleted'.

The 'System Deletes the Record' transition is only possible when the record is in the state of 'Record[ToBeDeleted]'. For this transition the system deletes the record (the length of time between this deletion action and the record being set as 'tobedeleted' is implementation dependent).

The state diagram for the creation and management of a record in a service provider is shown in Figure 2.

State diagram for the CSV bulk/delta modes interaction. — Figure 2 – State diagram for the management of records using bulk/delta processing at the service provider.

A OneRoster Service Consumer could issue a 'HTTP GET' request for the record in each of these four states. When such a read request is made the request will result in the following payloads:

'No Record' – in the case of a single record request a 404 response will be returned;
'Record[-]' – the record will be returned with an empty 'status' field and an empty 'dateLastModified' field;
'Record[Active]' – the record will be returned with a 'status' field value of 'active' and the 'dateLastModified' field set to the time the record was last changed;
'Record[ToBeDeleted]' – the record will be returned with a 'status' field value of 'tobedeleted' and the 'dateLastModified' field set to the time the record was last changed.

This Section is NORMATIVE.

The file format for each of the data files is a Comma Separated Values (CSV) format as specified in [RFC4180] with the extra restriction that carriage-returns are not permitted within a field. Fields containing commas and double-quotes must be enclosed in double-quotes. If double-quotes are used to enclose a field, then a double-quote appearing inside the field must be escaped by preceding it with another double-quote.

The character set code has the following specifications:

Japanese character sets supported as defined in JIS X 0213 [JIS-X-0213]
Character code supported as defined in ISO/IEC 10646 [ISO/IEC10646]
The CSV files must be UTF-8 encoded [RFC3629]
BOM (Byte Order Mark) prefixes MUST NOT be present

Other key points are:

All header names and content values within the CSV file are case-sensitive. Incorrect case will result in conformance failure and should be logged as a detected error;
The Header row for each file is required;
The Header fields for a file must be supplied in the same order as defined in the tables below. If metadata extension fields are used, then they must be added to the right of the defined data fields in the specification, as the last set of columns. This ensures that the sequence of the defined data fields remains fixed irrespective of the presence or not of metadata fields;
Header field names must be uniquely named within a file;
Files that contain no data rows are NOT permitted;
For ALL fields that are optional and which have a defined enumeration token set, then the value of NULL/blank (i.e. a blank value "") is permitted to denote that NO data is supplied;
The support of ALL string-based data-types requires that a maximum length of at least 255 must be supported by implementations. If string lengths of greater than 255 are used then system may lose some part of the string without failing conformance.

When mapping from the data model [OR-ROS-SM-12], [OR-RES-SM-12], [OR-GBK-SM-12] to the equivalent column headers the following special rules have been applied:

When referencing an object in the data model (using the data-type GUIDRef) the name has been extended using SourcedId e.g. org to orgSourcedId;
When referring to a set of objects in the data model maps to a comma separated list, enclosed in quotation marks, under the corresponding column header (as per [RFC4180]);
The references to resources in the Class and Course data models have NOT been mapped.

CSV import/export is envisaged to work in one of two ways, bulk and delta:

In BULK processing, the CSV files MUST NOT contain values in the dateLastModified and status fields. That is to say, for each row, there will be no data for either of these fields. Importing Systems MUST view this incoming data as the reference version of all data. That is to say, if records that were previously imported do not appear in this bulk csv file, then the importing system should internally mark those records as tobedeleted with the dateLastModified value set to the time of the bulk files import processing. If said records subsequently appear in a future bulk file, then those records should be updated and made active. When a set of Bulk files are created they must be semantically complete i.e. every object referenced by another object MUST also be defined in the corresponding source CSV file and included with the manifest.csv file;
In DELTA processing, the incoming CSV file MUST contain values in the dateLastModified and status fields. That is to say, each row in the CSV file should include data describing that (the row) data was last modified and its status. Importing systems must view this incoming delta file as changes to the reference data, and should make the appropriate changes, deletions and insertions of the new data.

The key to the CSV description tables listed in Subsections 4.2 to 4.20 is:

Field Header – the name for the Column Header;
Required – denotes if data must be present. The meanings for this field are:-
- 'Yes' for fields which are always required
- 'Yes for Delta' for fields which must be populated for Delta processing, and which must be blank for Bulk processing
- 'No' for fields which do not require to have values;
PII Sensitive - to identify properties that contain Personal Identifiable Information. The permitted values are:
- 'Yes' for contains PII sensitive data
- 'Identifier' the identifier for an individual
- 'Credential' secure access to information
- 'No' for does not contain PII sensitive data;
Format – the data-type for the data:-
- 'GUID' denotes some form of globally unique identifier (this must be less than 256 characters). This is not restricted to the 128 bit UUID format but MUST contain ONLY the characters '0-1 | a-Z | A-Z | . | - | _ | / | @' (the '|' character is being used as a separator in the expression)
- 'GUID Reference' denotes the GUID of an object defined in some other CSV data file (this is limited to the same set of characters as per a 'GUID')
- 'UUID Reference' denotes the UUID of the referenced object (this must be a valid 128 bit UUID)
- 'List of GUID Reference' denotes a comma-delimited list of GUID References of objects defined in another CSV data file
- 'ID' denotes an identifier defined outside of the OneRoster specification, e.g. identifiers generated by vendors for their resources in the Resources data-set
- 'String' denotes a sequence of characters that should follow the description. Generally this is aimed to be human-readable e.g. "Science Lesson"
- 'List of Strings' denotes a sequence of Strings. The individual strings within the list must not contain commas, and the list is a comma separated list e.g. "1,2,3". If a List of Strings contains more than one element, then it must be double-quote encapsulated
- 'Enumeration' denotes a fixed set of values that will be referred to in the description. In the case of fields which are not required, an empty field denotes no value
- 'Enumeration List' denotes a list of Enumerations. The list is comma separated e.g. "teacher,student,aide"
- 'Float' denotes a floating point number
- 'DateTime' denotes a timestamp format. DateTimes MUST be expressed in W3C profile of ISO 8601 [ISO8601] (it MUST be of the format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ) and MUST contain the UTC timezone e.g. "2012-04-23T18:25:43.511Z"
- 'Date' denotes a date format. Dates MUST be expressed using ISO 8601 format [ISO8601], more commonly formatted as "YYYY-MM-DD" e.g. "2002-04-23"
- 'Year' denotes a date format of year only. Years MUST be expressed using ISO 8601 format [ISO8601], more commonly formatted as "YYYY" e.g. "2002";
Example/Description – an example of the expected data, and a brief statement of the nature of the content
Profile Annotation - statement of the changes made in this profile with respect to the property. It is in this column that any changes to data-type and/or multiplicity will be identified.

NOTE: The manifest file will consist of just two columns with the headers propertyName and value. Each row will contain a single property/value pair. The list of supported property/value pairs is described in Table 4.1.

Table 4.1 - Format for the contents of the 'manifest.csv' file.
Property Name (One per row)	Required	Format	Value Description	Profile Annotation
manifest.version	Yes	String	The version of the manifest. For an initial value this must be “1.0”.
oneroster.version	Yes	String	The OneRoster version supported by this file set.	MUST be set as `1.2_JP`.
file.academicSessions	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.
file.categories	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.classes	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.
file.classResources	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.courses	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.
file.courseResources	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.demographics	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.
file.enrollments	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.
file.lineItemLearningObjectiveIds	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.lineItems	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.lineItemScoreScales*	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.orgs	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.
file.resources	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.resultLearningObjectiveIds	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.results	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.resultScoreScales	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.roles	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.
file.scoreScales	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.userProfiles	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.
file.userResources	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.	MUST be set as `absent`.
file.users	Yes	Enumeration	Permitted values of: { absent \| bulk \| delta }.
source.systemName	No	String	The name for the system producing the set of files.
source.systemCode	No	String	Identification code for the system producing the set of files.

In the enumerations in Table 4.1 the interpretations for each permitted value are:

'absent' – the CSV file is not supplied;
'bulk' – the CSV file contains only bulk data;
'delta' – the CSV file contains only delta data.

These processing mode hints should be consistent with the data held within the accompanying CSV files but in cases of conflict the values in the data CSV files must take precedence.

This file represents the AcademicSessions data-set from the OneRoster Rostering specification.

The academicSessions.csv file format and contents.
Column Field Header	Required	PII Sensitive	Format	Description	Profile Annotation
sourcedId	Yes	No	GUID	Unique ID for the academicSession.
status	Yes for Delta	No	Enumeration	Permitted values for Delta mode: { active \| tobedeleted }. This MUST NOT be used for the Bulk mode.	"tobedeleted" applies to previous year data or deleted data. "active" applies to other than the above.
dateLastModified	Yes for Delta	No	DateTime	The date that this record was last modified. [ISO8601] format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ MUST be used. This MUST NOT be used for the Bulk mode.	Examples: "The date and time when the CSV was output".
title	Yes	No	String	Name or title of the academic session.	Set "the target four-digit school year" + "年度" for which the processing is executed.
type	Yes	No	Enumeration	Permitted values of: { gradingPeriod \| semester \| schoolYear \| term } This vocabulary may be extended.	Fixed: "schoolYear" (only handles school year data).
startDate	Yes	No	Date	Inclusive end date for the academic session. ISO 8601 format [ISO8601].	Fixed: Start date of the target year Example: 2024-04-01.
endDate	Yes	No	Date	Exclusive end date for the academic session. ISO 8601 format [ISO8601].	Fixed: End date of the target year Example: 2025-03-31.
parentSourcedId	No	No	GUID Reference.	SourcedId of the parent of this academic session.
schoolYear	Yes	No	Year	The school year for which the academic session contributes. This year should be that in which the school year ends (Format is: YYYY).

The dependencies of this file on other files when supporting bulk processing are:

Other academicSessions could be referenced in the SAME file through the parentSourcedId attribute. Therefore, for semantic consistency there are NO dependencies on OTHER files.

Support for this Data Model removed in this Profile.

This file represents the Categories data-set from the OneRoster Gradebook specification [OR-GBK-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

This file represents the Classes data-set from the OneRoster Rostering specification.

The classes.csv file format and contents.
Column Field Header	Required	PII Sensitive	Format	Description	Profile Annotation
sourcedId	Yes	No	GUID	Unique ID for the class.
status	Yes for Delta	No	Enumeration	Permitted values for Delta mode: { active \| tobedeleted }. This MUST NOT be used for the Bulk mode.	"tobedeleted" applies to previous year data or deleted data. "active" applies to other than the above.
dateLastModified	Yes for Delta	No	DateTime	The date that this record was last modified. [ISO8601] format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ MUST be used. This MUST NOT be used for the Bulk mode.	Examples: "The date and time when the CSV was output".
title	Yes	No	String	Name of this class.	Example: The official names are assumed to be "1年1組", special needs class "あおぞら組", etc.
grades	No	No	List of Strings	Grade(s) for which the class is attended. The permitted vocabulary should be agreed as part of the definition of the usage of this specification.	Code "Grade" defined in APPLIC [APPLIC-CODE] Also, for compulsory education schools, secondary education schools, etc.
courseSourcedId	Yes	No	GUID Reference	SourcedId of the course of which this class is an instance.	[Course.SourcedId] for the target year in the target organization.
classCode	No	No	String	Human readable code used to help identify this class.	An empty string ("") is acceptable, but if the SIS holds a code to identify the class, it is preferable to output it. Example: Replace both "1年1組" and "1年A組" with a common code such as 0101.
classType	Yes	No	Enumeration	The permitted values are: { homeroom \| scheduled } This vocabulary may be extended.	"homeroom" apples for student classes. "scheduled" applies for class units by proficiency level, club/committee information.
location	No	No	String	Human readable description of where the class is physically located.
schoolSourcedId	Yes	No	GUID Reference.	SourcedId of the Org that teaches this class of OrgType 'school'.	Org.SourcedId of the target organization.
termSourcedIds	Yes	No	List of GUID References.	SourcedIds of the terms (the academicSessions) in which the class is taught.	AcademicSession.SourcedId for the target year.
subjects	No	No	List of Strings	Subject name(s) in human readable form. If the 'subjectCodes' attribute is present then the subjects and subjectCodes lists must have the same length and have order significance. The permitted vocabulary should be agreed as part of the definition of the usage of this specification. If the value of the "Course Title" contains commas, then those commas must be removed.	When specifying a subject, use the code content of the "Subject" code defined in APPLIC [APPLIC-CODE]. For subjects not defined in APPLIC, use any string. If the subject name is determined in the MEXT's Educational Data Standard, the reference will be changed.
subjectCodes	No	No	List of Strings	Subject codes(s) in machine readable form. If more than one subject code is needed, use double quotes, and separate with commas (per [RFC4180]). If the 'subjects' attribute is present the two lists must have the same length and have order significance. The permitted vocabulary should be agreed as part of the definition of the usage of this specification.	When specifying a subject, use the code content of the "Subject" code defined in APPLIC [APPLIC-CODE]. For subjects with undefined subject codes, do not enter the item itself. If subject codes are defined in the MEXT's Education Data Standards, the reference will be changed.
periods	No	No	List of Strings	The time slots in the day that the class will be given. If more than one period is needed, use double quotes, and separate with commas (per [RFC4180]). Examples: 1; “1,3,5”
metadata.jp.specialNeeds	No	No	Enumeration	Added for Japan Profile	A special needs class:"true" Otherwise: "false"

The dependencies of this file on other files when supporting bulk processing are:

This requires a reference to the associated terms (academicSessions) using the termSourcedIds attribute. This produces a dependency on the academicSessions.csv;
This requires a reference to the associated course (course) using the courseSourcedId attribute. This produces a dependency on the courses.csv;
This requires a reference to the associated school (org) using the schoolSourcedId attribute. This produces a dependency on the orgs.csv.

Support for this Data Model removed in this Profile.

This file represents the links between the Resources and Classes data-sets from the OneRoster Rostering and Resources specification [OR-RES-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

Support for this Data Model removed in this Profile.

This file represents the links between the Resources and Courses data-sets from the OneRoster Rostering and Resources specification [OR-RES-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

This file represents the Courses data-set from the OneRoster Rostering specification.

The courses.csv file format and contents.
Column Field Header	Required	PII Sensitive	Format	Description	Profile Annotation
sourcedId	Yes	No	GUID	Unique ID for the course.
status	Yes for Delta	No	Enumeration	Permitted values for Delta mode: { active \| tobedeleted }. This MUST NOT be used for the Bulk mode.	"tobedeleted" applies to previous year data or deleted data. "active" applies to other than the above.
dateLastModified	Yes for Delta	No	DateTime	The date that this record was last modified. [ISO8601] format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ MUST be used. This MUST NOT be used for the Bulk mode.	Examples: "The date and time when the CSV was output".
schoolYearSourcedId	No	No	GUID Reference.	SourcedId of the associated AcademicSession with type of 'schoolYear'.	[AcademicSession.SourcedId] for the target year.
title	Yes	No	String	Name of this course.	Set any name that identifies the course. Example: For a homeroom class [AcademicSession.Title] + "ホームルーム" For a class related to lessons [AcademicSession.Title] + subject name
courseCode	No	No	String	Human readable code used to help identify this course.	Fixed:empty string ("").
grades	No	No	List of Strings	Grade(s) for which the class is attended. The permitted vocabulary should be agreed as part of the definition of the usage of this specification.	When specifying a grade, use the code content of the "Grade" code defined in APPLIC [APPLIC-CODE]. For compulsory education schools, secondary education schools, and etc., use the grade codes for elementary, junior high, and high schools.
orgSourcedId	Yes	No	GUID Reference.	SourcedId of an org to which this course belongs.	[Org.SourcedId] of the target organization.
subjects	No	No	List of Strings	Subject name(s) in human readable form. If the 'subjectCodes' attribute is present then the subjects and subjectCodes lists must have the same length and have order significance. The permitted vocabulary should be agreed as part of the definition of the usage of this specification. If the value of the "Course Title" contains commas, then those commas must be removed.	When specifying a subject, use the code content of the "Subject" code defined in APPLIC [APPLIC-CODE]. For subjects not defined in APPLIC, use any string. If the subject name is determined in the MEXT's Educational Data Standard, the reference will be changed.
subjectCodes	No	No	List of Strings	Subject codes(s) in machine readable form. If more than one subject code is needed, use double quotes, and separate with commas (per [RFC4180]). If the 'subjects' attribute is present the two lists must have the same length and have order significance. The permitted vocabulary should be agreed as part of the definition of the usage of this specification.	When specifying a subject, use the code content of the "Subject" code defined in APPLIC [APPLIC-CODE]. For subjects with undefined subject codes, do not enter the item itself. If subject codes are defined in the MEXT's Education Data Standards, the reference will be changed.

The dependencies of this file on other files when supporting bulk processing are:

This requires a reference to the associated school year (academicSession) using the schoolYearSourcedId attribute. This produces a dependency on the academicSessions.csv;
This requires a reference to the associated organization (org) using the ‘orgSourcedId’ attribute. This produces a dependency on the orgs.csv.

This file represents the Demographics data-set from the OneRoster Rostering specification.

The 'demographics.csv' file format and contents.
Column Field Header	Required	PII Sensitive	Format	Description	Profile Annotation
sourcedId	Yes	Identifier	GUID	Unique ID for the demographics. This MUST be the 'sourcedId' of the User whose demographics are being described.	[User.SourcedId] of the target user.
status	Yes for Delta	No	Enumeration	Permitted values for Delta mode: { active \| tobedeleted }. This MUST NOT be used for the Bulk mode.	"tobedeleted" applies to previous year data or deleted data. "active" applies to other than the above.
dateLastModified	Yes for Delta	No	DateTime	The date that this record was last modified. [ISO8601] format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ MUST be used. This MUST NOT be used for the Bulk mode.	Examples: "The date and time when the CSV was output".
birthDate	No	Yes	Date	The date of birth. ISO 861 format: 'YYYY-MM-DD'.
sex	No	Yes	Enumeration	Permitted values are: { male \| female \| unspecified \| other }. This vocabulary may be extended.
americanIndianOrAlaskaNative	No	Yes	Enumeration	Permitted values are: { true \| false }.	MUST NOT be used.
asian	No	Yes	Enumeration	Permitted values are: { true \| false }.	MUST NOT be used.
blackOrAfricanAmerican	No	Yes	Enumeration	Permitted values are: { true \| false }.	MUST NOT be used.
nativeHawaiianOrOtherPacificIslander	No	Yes	Enumeration	Permitted values are: { true \| false }.	MUST NOT be used.
white	No	Yes	Enumeration	Permitted values are: { true \| false }.	MUST NOT be used.
demographicRaceTwoOrMoreRaces	No	Yes	Enumeration	Permitted values are: { true \| false }.	MUST NOT be used.
hispanicOrLatinoEthnicity	No	Yes	Enumeration	Permitted values are: { true \| false }.	MUST NOT be used.
countryOfBirthCode	No	Yes	String	Country where the user was born. The permitted vocabulary should be agreed as part of the definition of the usage of this specification.	MUST NOT be used.
stateOfBirthAbbreviation	No	Yes	String	State where the user was born. The permitted vocabulary should be agreed as part of the definition of the usage of this specification.	MUST NOT be used.
cityOfBirth	No	Yes	String	City where the user was born.	MUST NOT be used.
publicSchoolResidenceStatus	No	Yes	String	An indication of the location of the users legal residence relative to (within or outside) the boundaries of the public school attended and its administrative unit. The permitted vocabulary should be agreed as part of the definition of the usage of this specification.	MUST NOT be used.

The dependencies of this file on other files when supporting bulk processing are:

This requires a reference to the associated user using the sourcedId attribute. This produces a dependency on the users.csv. This creates a corresponding dependency on the orgs.csv, roles.csv and userProfiles.csv files.

This file represents the Enrollments data-set from the OneRoster Rostering specification.

The enrollments.csv file format and contents.
Column Field Header	Required	PII Sensitive	Format	Description	Profile Annotation
sourcedId	Yes	No	GUID	Unique ID for the enrollment.
status	Yes for Delta	No	Enumeration	Permitted values for Delta mode: { active \| tobedeleted }. This MUST NOT be used for the Bulk mode.	"tobedeleted" applies to previous year data or deleted data. "active" applies to other than the above.
dateLastModified	Yes for Delta	No	DateTime	The date that this record was last modified. [ISO8601] format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ MUST be used. This MUST NOT be used for the Bulk mode.	Examples: "The date and time when the CSV was output".
classSourcedId	Yes	No	GUID Reference	SourcedId of the Class.	[Class.SourcedId] of the Target class.
schoolSourcedId	Yes	No	GUID Reference	SourcedId of an Org with type ‘school’.	[Org.SourcedId] of the target organization.
userSourcedId	Yes	Identifier	GUID Reference	SourcedId of the User.	[User.SourcedId] of the target user.
role	Yes	Yes	Enumeration	Permitted values are: { administrator \| proctor \| student \| teacher }. This vocabulary may be extended.
primary	No	No	Enumeration	Permitted values are: { true \| false }. Applicable only to teachers. Only one teacher should be designated as the primary teacher for a class in the period defined by the begin/end dates.	Fixed: For students: "false", For faculty and staff: If associating with the "homeroom" class: For the class teacher: "true" Otherwise: "false" If associating with the "scheduled" class: For the main subject teacher: "true" Otherwise: "false"
beginDate	No	No	Date	The start date for the enrollment (inclusive). This date must align with the associated academic session (term) identified in the class.
endDate	No	No	Date	The end date for the enrollment (exclusive). This date must align with the associated academic session (term) identified for the class.
metadata.jp.shussekiNo	No	No	String	Added for Japan Profile	For students: The user's attendance number in the target class. Staff numbers will not be output.
metadata.jp.publicFlg	No	Yes	Enumeration	Added for Japan Profile	"true" if public "false" if private

The dependencies of this file on other files when supporting bulk processing are:

This requires a reference to the associated class (class) using the classSourcedId attribute. This produces a dependency on the classes.csv. This creates a corresponding dependency on the academicSessions.csv and courses.csv files. The courses dependency creates a further set of dependencies on the academicSessions.csv and orgs.csv files;
This requires a reference to the associated school (org) using the schoolSourcedId attribute. This produces a dependency on the orgs.csv;
This requires a reference to the associated user (user) using the userSourcedId attribute. This produces a dependency on the users.csv. This creates a corresponding dependency on the orgs.csv, roles.csv and userProfiles.csv files.

Support for this Data Model removed in this Profile.

This file represents the mapping between LineItems and the corresponding Learning Objectives in the OneRoster Gradebook specification [OR-GBK-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

Support for this Data Model removed in this Profile.

This file represents the LineItems data-set from the OneRoster Gradebook specification [OR-GBK-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

Support for this Data Model removed in this Profile.

This file represents the mapping between the LineItems and ScoreScales data-sets from the OneRoster Gradebook specification [OR-GBK-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

Data Model altered in this Profile.

This file represents the Orgs data-set from the OneRoster Rostering specification.

The 'orgs.csv' file format and contents.
Column Field Header	Required	PII Sensitive	Format	Description	Profile Annotation
sourcedId	Yes	No	GUID	Unique ID for the org.
status	Yes for Delta	No	Enumeration	Permitted values for Delta mode: { active \| tobedeleted }. This MUST NOT be used for the Bulk mode.	"tobedeleted" applies to previous year data or deleted data. "active" applies to other than the above.
dateLastModified	Yes for Delta	No	DateTime	The date that this record was last modified. [ISO8601] format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ MUST be used. This MUST NOT be used for the Bulk mode.	Examples: "The date and time when the CSV was output".
name	Yes	No	String	Name of the organization.	Names listed in the School and Board of Education Code List [MEXT-SCH-CODE][MEXT-DIST-CODE] are preferred.
type	Yes	No	Enumeration	Permitted values are: { department \| school \| district \| local \| state \| national } This vocabulary may be extended.	Fixed: For board of education: "district" For school: "school"
identifier	No	No	String	Human readable identifier for this org e.g. NCES ID.	Board of Education: MEXT Board of Education Code[MEXT-DIST-CODE] School: MEXT School Code (13 digits)[MEXT-SCH-CODE]
parentSourcedId	No	No	GUID Reference.	SourcedId of an Org representing the Parent organization.	Fixed: For board of education (district): "" i.e. 'NULL' (NOT the word NULL). For schools: The board of education sourcedId

The dependencies of this file on other files when supporting bulk processing are:

Other orgs could be referenced in the SAME file through the parentSourcedId attribute. Therefore, for semantic consistency there are NO dependencies on OTHER files.

Support for this Data Model removed in this Profile.

This file represents the Resources data-set from the OneRoster Resources specification [OR-RES-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

Support for this Data Model removed in this Profile.

This file represents the mapping between Results and the corresponding Learning Objectives in the OneRoster Gradebook specification [OR-GBK-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

Support for this Data Model removed in this Profile.

This file represents the Results data-set from the OneRoster Gradebook specification [OR-GBK-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

Support for this Data Model removed in this Profile.

This file represents the mapping between the Results and ScoreScales data-sets from the OneRoster Gradebook specification [OR-GBK-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

The set of roles for a user in an org. A user can have 1-many roles in 1-many orgs. This is defined as a set of 1-1 mappings.

The 'roles.csv' file format and contents.
Column Field Header	Required	PII Sensitive	Format	Description	Profile Annotation
sourcedId	Yes	No	GUID	Unique ID for the role.
status	Yes for Delta	No	Enumeration	Permitted values for Delta mode: { active \| tobedeleted }. This MUST NOT be used for the Bulk mode.	"tobedeleted" applies to previous year data or deleted data. "active" applies to other than the above.
dateLastModified	Yes for Delta	No	DateTime	The date that this record was last modified. [ISO8601] format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ MUST be used. This MUST NOT be used for the Bulk mode.	Examples: "The date and time when the CSV was output".
userSourcedId	Yes	Identifier	GUID Reference	The user whose role is being defined.	[User.SourcedId] of the Target user.
roleType	Yes	No	Enumeration	Determines if this is the primary role. Only one role per organization can be 'primary'. Permitted values are: { primary \| secondary }	If there is only one, it must be primary.
role	Yes	Yes	Enumeration	The type of role. Permitted values are: { aide \| counselor \| districtAdministrator \| guardian \| parent \| principal \| proctor \| relative \| siteAdministrator \| student \| systemAdministrator \| teacher } This vocabulary may be extended.	Fixed: 児童生徒: student 教職者: teacher (includes all roles) 保護者: guardian 学校長・教育長: principal (add to teacher) 管理職(教育委員会): districtAdministrator 管理職(学校): siteAdministrator (add to teacher) システム管理者: systemAdministrator 試験監督官: proctor Other roles can also be used. * Mother and father are treated as guardians.
beginDate	No	No	Date	The start date on which the role became active (inclusive).	ISO8601 format (YYYY-MM-DD)
endDate	No	No	Date	The end date on which the role ceased to be active (exclusive).	ISO8601 format (YYYY-MM-DD)
orgSourcedId	Yes	No	GUID Reference	SourcedId of the Org within which the User has the assigned role.	[Org.SourcedId] of the target organization.
userProfileSourcedId	No	Identifier	GUID Reference	SourcedId of the UserProfile for the User.	[UserProfile.SourcedId] of the Target user.

The dependencies of this file on other files when supporting bulk processing are:

This requires a reference to the associated user using the userSourcedId attribute. This produces a dependency on the users.csv. This also produces a dependency on the orgs.csv;
This requires a reference to the associated org using the orgSourcedId attribute. This produces a dependency on the orgs.csv;
If a value for the userProfileSourcedId attribute is supplied, a link to the associated userProfile is established. This produces a dependency on the userProfiles.csv.

Support for this Data Model removed in this Profile.

This file represents the ScoreScales data-set from the OneRoster Gradebook specification [OR-GBK-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

This information is used to enable authentication/authorization/access management of the various systems/tools/apps/etc. available to the user.

The userProfiles.csv file format and contents.
Column Field Header	Required	PII Sensitive	Format	Description	Profile Annotation
sourcedId	Yes	Identifier	GUID	Unique ID for the userProfile.
status	Yes for Delta	No	Enumeration	Permitted values for Delta mode: { active \| tobedeleted }. This MUST NOT be used for the Bulk mode.	"tobedeleted" applies to previous year data or deleted data. "active" applies to other than the above.
dateLastModified	Yes for Delta	No	DateTime	The date that this record was last modified. [ISO8601] format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ MUST be used. This MUST NOT be used for the Bulk mode.	Examples: "The date and time when the CSV was output".
userSourcedId	Yes	Identifier	GUID	Unique ID for the corresponding user.
profileType	Yes	No	String	The type of user profile. This should be a human readable label that has some significance in the context of the related system, app, tool, etc.
vendorId	Yes	No	String	The unique identifier for the vendor of the system, tool, app, etc. which requires the use of this user profile.
applicationId	No	No	String	The unique identifier for the vendor of the system, tool, app, etc. which requires the use of this account.
description	No	No	String	A human readable description of the use of the account. This should not contain any security information for access to the account.
credentialType	Yes	Credential	String	The type of credentials for the user profile. This should be indicative of when this credential should be used.
username	Yes	Yes	String	The username for this profile.
password	No	Credential	String	The password for the user. This may or may not be an encrypted string. If encrypted, the processing system must be aware of the encryption method.

The extension mechanism should be used to support the exchange of the appropriate credentials and other details required for the profile.

The dependencies of this file on other files when supporting bulk processing are:

This requires a reference to the associated user using the userSourcedId attribute. This produces a dependency on the users.csv. This also produces a dependency on the orgs.csv.

Support for this Data Model removed in this Profile.

This file represents the links between the Resources and Users data-sets from the OneRoster Rostering and Resources specification [OR-RES-SM-12]. There is NO support for the exchange of this information in this Profile and so the data model has been removed.

This file represents the Users data-set from the OneRoster Rostering specification.

Several columns have been deleted and new ones added in this release.

The 'users.csv' file format and contents.
Column Field Header	Required	PII Sensitive	Format	Description	Profile Annotation
sourcedId	Yes	Identifier	GUID	Unique ID for the user.
status	Yes for Delta	No	Enumeration	Permitted values for Delta mode: { active \| tobedeleted }. This MUST NOT be used for the Bulk mode.	"tobedeleted" applies to previous year data or deleted data. "active" applies to other than the above.
dateLastModified	Yes for Delta	No	DateTime	The date that this record was last modified. [ISO8601] format and resolution of YYYY-MM-DDTHH:MM:SS.sssZ MUST be used. This MUST NOT be used for the Bulk mode.	Examples: "The date and time when the CSV was output".
enabledUser	Yes	No	Boolean	Permitted values are: { true \| false }. 'false' denotes that the user is an active record but system access is curtailed according to the local administration rules.	Fixed: "true"
username	Yes	Credential	String	User name.	Primary login ID/cloud ID issued by the main Idp. Without a primary login ID/cloud ID, an identifier used within the system is used.
userIds	No	Identifier	List of Strings	External machine-readable ID (e.g. LDAP id, LTI id) for this user. The ID must be accompanied by a type to indicate the nature of the Identifier. The Type and ID values are enclosed in ‘{}’ with a colon used to separate the values. If more than one userId is needed, use double quotes, and separate with commas (per [RFC4180]). Examples: {LDAP:Id} and "{LDAP:Id},{LTI:Id},{Fed:Id}"	For other app IDs, use {Prefix:Id}, *Prefix: SIS: Koumu, Microsoft: MS, Google: Google, Apple: Apple, AD: AD
givenName	Yes	Yes	String	User's first name.	Common name (first name) * May include external characters
familyName	Yes	Yes	String	User's surname.	Common name (surname) * May include external characters
middleName	No	Yes	String	User's middle name(s). If more than one then they are separated by a space.	Common name (middle name)
identifier	No	Identifier	String	Identifier for the user with a human readable meaning.	Reserve a universal ID for each student as defined by MEXT and etc.
email	No	Yes	String	Email address for the User.	MAY be set arbitrarily.
sms	No	Yes	String	SMS address for the User.	MAY be set arbitrarily.
phone	No	Yes	String	Phone number for the User.	MAY be set arbitrarily.
agentSourcedIds	No	Identifier	List of GUID References	SourcedIds of the Users to which this user has a relationship. If multiple IDs are required then use double quotes and separate with commas. Note: In most cases this will be for indicating parental relationships.	If parent information is linked: For students: Parent's [User.SourcedId] For parents: Student's [User.SourcedId] Other cases: MAY be set arbitrarily.
grades	No	Yes	String	Grade(s) for which a user with role 'student' is enrolled. The permitted vocabulary should be agreed as part of the definition of the usage of this specification.	When specifying a grade, use the code content of "学年" code defined in APPLIC [APPLIC-CODE]. For grades not defined in APPLIC, use an empty string (""). If the grade is determined in the MEXT's Educational Data Standard, change the reference.
password	No	Credential	String	The password for the user. This may or may not be an encrypted string. If encrypted the processing system must be aware of the encryption method.
userMasterIdentifier	No	Identifier	String	The master identifier that could be used to provide globally unique identification of the user across all of the tools, systems, apps, etc. available/accessed by the user.	Reserves a UUID that uniquely identifies a user when linking with other systems. For example, it is expected that a unique identifier will be output from SIS. In that case, the receiving side must treat it as a unique identifier for the user.
preferredGivenName	No	Yes	String	The given name by which the User prefers to be known.	Name to be displayed on the screen (first name) MAY include external characters.
preferredMiddleName	No	Yes	String	The middle names by which the User prefers to be known.	Name to be displayed on the screen (middle name).
preferredFamilyName	No	Yes	String	The family name by which the User prefers to be known.	Name (surname) to be displayed on the screen MAY include external characters.
primaryOrgSourcedId	No	Identifier	GUID Reference	The sourcedId of the primary 'org' for the 'user'. A user can have one or more 'roles' in one or more ''orgs' and so identification of the primary 'org' is required.	[Org.SourcedId] of the main organization to which the user belongs.
pronouns	No	Yes	String	The pronoun(s) by which this person is referenced. Examples (in the case of English) include 'she/her/hers', 'he/him/his', 'they/them/theirs', 'ze/hir/hir', 'xe/xir', or a statement that the person's name should be used instead of any pronoun.	SHOULD NOT be used.
metadata.jp.kanaGivenName	No	Yes	String	Added for Japan Profile	Common name (first name) * Hiragana, katakana, half-width, etc. are accepted.
metadata.jp.kanaFamilyName	No	Yes	String	Added for Japan Profile	Common name (surname) * Hiragana, katakana, half-width, etc. are accepted.
metadata.jp.kanaMiddleName	No	Yes	String	Added for Japan Profile	Common name (middle name) * Hiragana, katakana, half-width, etc. are accepted.
metadata.jp.homeClass	No	Yes	String	Added for Japan Profile	Main class (for students in special needs classes) [Class.SourcedId] of the class in which the student is enrolled.
metadata.jp.kanaPreferredGivenName	No	Yes	String	Added for Japan Profile	Display name (first name) * Hiragana, katakana, half-width, etc. are accepted.
metadata.jp.kanaPreferredFamilyName	No	Yes	String	Added for Japan Profile	Display name (surname) * Hiragana, katakana, half-width, etc. are accepted.
metadata.jp.kanaPreferredMiddleName	No	Yes	String	Added for Japan Profile	Display name (middle name) * Hiragana, katakana, half-width, etc. are accepted.

The relationship between users.csv, roles.csv, enrollment.csv, and userProfiles.csv is as follows:

The organizations to which a user belongs and their roles within those organizations are defined in roles.csv, and the classes to which a user belongs and their roles within those classes are defined in enrollments.csv.
A user's system and application accounts (username and password sets) are defined in userProfiles.csv.

The dependencies of this file on other files when supporting bulk processing are:

This produces an implicit dependency on the roles.csv file. This creates a dependency on the orgs.csv file;
This produces an implicit optional dependency on the userProfiles.csv file. This creates a dependency on the orgs.csv file;
There may be reference to agents (users) in the SAME file through the agentsSourcedIds attribute but this creates no new file dependencies;
There may be reference to the associated resources (resource) using the resourceSourcedIds attribute. This produces a dependency on the resources.csv.

This Section is NORMATIVE.

Several new data elements have been added in this Profile using the extension mechanism. However, it is recognized that implementers may wish to extend the specification. The REQUIRED mechanism for doing this is for implementers to use an extension space within the OneRoster data model, and then set their CSV parsers to read those extension attributes. Extensions are ONLY permitted by adding metadata named columns to the end of the set of columns already defined in the specification.

An example of creating such a proprietary extension is given in the Best Practices section of this document.

In this version the ability to extend some of the enumerated vocabularies has been added: currently, ONLY the classType (classes.csv), role (enrollments.csv and roles.csv), sex (demographics.csv), and type (academicSession.csv and orgs.csv) vocabularies MAY be extended. Each proprietary term must start with the characters 'ext:'.

An example of creating such an extension is given in the Best Practices section of this document.

In this profile a number of extensions have been defined. For the various CSV files these extensions are:

classes.csv file
- metadata.jp.specialNeeds (optional) - an enumeration used to denote if this is a special needs class
enrollments.csv file
- metadata.jp.shussekiNo (optional) - used to denote the student's attendance number in the associated class
- metadata.jp.publicFlg (optional) - used to denote public or private
users.csv file
- metadata.jp.kanaGivenName (optional) - Hiragana, katakana, half-width, etc. are accepted for the given name
- metadata.jp.kanaFamilyName (optional) - Hiragana, katakana, half-width, etc. are accepted for the family name
- metadata.jp.kanaMiddleName (optional) - Hiragana, katakana, half-width, etc. are accepted for the middle name
- metadata.jp.homeClass (optional) - sourcedId of the home/main class for students with special needs
- metadata.jp.kanaPreferredFamilyName (optional) - Hiragana, katakana, half-width, etc. are accepted for the preferred family name
- metadata.jp.kanaPreferredGivenName (optional) - Hiragana, katakana, half-width, etc. are accepted for the preferred given name
- metadata.jp.kanaPreferredMiddleName (optional) - Hiragana, katakana, half-width, etc. are accepted for the preferred middle name

NOTE: ALL of these new columns MUST be present in the corresponding CSV files. Therefore, additional proprietary extension columns MUST appear after these.

Examples of using these extensions is given in the Best Practices section of this document.

This Section is NOT NORMATIVE.

The file format for each of the data files is a comma separated values format (CSV) as specified in [RFC4180]. The encoding of the files is defined in Section 4.

When the data is exchanged as CSV files, there will be 1-10 CSV files. An exchange MUST include the manifest.csv file. The case of when only the manifest.csv is supplied is used to denote that no updates occurred. At most, 10 CSV files are exchanged i.e. there MUST NOT be more than one of each of the data CSV files. When the set of files are for bulk processing then they must be semantically consistent i.e. every object referenced in a file must also be defined in either the same, or one of the other files in the zip package.

The CSV files will be exchanged as a zip file. The encompassed files must be at the root level i.e. they MUST NOT be contained within an enclosing directory. There is NO constraint on the name of the zip file but it must have a file extension of zip. The compression must conform to [RFC1951]. Within the zip file there is NO preferred ordering of the CSV files.

The CSV files MUST be exchanged as a zipped file. These files must NOT be encrypted otherwise they will not pass validation: the transport mechanism is responsible for encrypting the data and so protecting the integrity of the CSV files.

The transport mechanism is out of scope for the CSV Binding. Therefore the 1EdTech Security Framework [SECURITY-11] is not applicable to this profile. However, in many cases the CSV files will contain privacy-sensitive information and so some form of security/privacy protection MUST be used when the files are exchanged e.g. Secure FTP, etc.

For 'bulk' exchange the set of CSV files MUST be semantically complete i.e. if a sourcedId reference for an object is used in one of the CSV files then that object MUST be defined somewhere in the set of CSV files (it may be the CSV file in which the reference occurs). The data models for the CSV files means that the following groups of files may be exchanged with the accompanying constraints of:

academicSessions.csv - this file may contain references to other academicSessions and so ALL such definitions must be contained within the same file. This CSV file may be exchanged independently of other files
classes.csv - this file MUST contain references to the relevant academicSession, course and organization objects. Therefore it must be accompanied with the academicSessions.csv, courses.csv and orgs.csv files
demographics.csv - this file MUST contain references to the relevant organization and user objects. Therefore it must be accompanied with the orgs.csv and users.csv files
enrollments.csv - this file MUST contain references to academicSession, class, course, organization and user objects. Therefore it must be accompanied with the academicSessions.csv, classes.csv, courses.csv, orgs.csv and users.csv files
courses.csv - this file MUST contain references to the associated organization and may contain references to academicSession objects. Therefore it must be exchanged with an orgs.csv file and may require an academicSessions.csv file
orgs.csv - this file may contain references to other organizations and so ALL such definitions must be contained within the same file. This CSV file may be exchanged independently of other files
users.csv - this file MUST contain references to the associated organization and may contain references to other user objects (whose definition must be contained within the same file). The roles for the user MUST also be provided. Therefore it must be exchanged with the roles.csv and orgs.csv files.

It should be noted that an implementation may require/supply more than the minimum set of semantically consistent files.

The sourcedId attribute is used to provide the unique identification of the associated object between the communicating end-systems. Ideally, these should be globally unique identifiers (the internal format/structure is an implementation dependent issue and NOT constrained to a form of Universal Unique Identifier, UUID). The identifiers MUST not be used as the internal data store keys i.e. a mapping between the identifier and the key should be maintained by an implementation.

Every data object is allocated a unique identifier i.e. its sourcedId. This identifier must be unique in the context of the two systems that access the object i.e. the identifiers do not have to be globally unique. The end-systems are responsible for maintaining the contextual integrity of these identifiers. The sourcedId is not required to have end-system significance except for enabling the associated record to be identified for the processing of the CSV file.

It is the inability to find a record for a given sourcedId that is used to define a deleted record. Therefore, an end-system should have its own unique key for identifying the associated record. This ensures that the record does not have to be deleted from the end-system to provide consistent interoperability deletion.

If an object has been deleted then the associated sourcedId MUST NOT be reassigned to another object. Therefore, once a sourcedId has been assigned it is permanently allocated to the associated object and so can be used to recover deleted data.

The sourcedId is used as the unique interoperability key. If data is being received from multiple sources e.g. the import and aggregation of many sets of CSV files, then it is possible that the same sourcedId may be used for different objects (each source will have some sourcedId generation/allocation mechanism and so the probability of a clash will depend on the sophistication of those approaches). It is recommended that systems make use of access control mechanism to minimize accidental data overwriting.

The scope of the sourcedId (UUID) MUST be unique within the context of the CSV file set. Persistence of the sourcedId is REQUIRED if DELTA processing is supported otherwise it is OPTIONAL. This is because a BULK transaction results in a destructive overwrite of the previous data-set.

The user class has a number of identifier fields. In keeping with 1EdTech specifications, the preferred practice is for the sourcedId field to be used wherever possible, across all systems. That is to say, the SIS should provide a sourcedId for a user to the LMS. The LMS should provide that same sourcedId for that user to any tools that it launches via LTI, rather than supplying some other identifier. This should be true across all orgs and roles.

The userId field is intended as a bridging piece in which any other machine readable id can be stored for a given user. This might be an LTI identifier, or it might be an active directory or LDAP identifier. If LMSs cannot use the sourcedIds for the user when making external calls, then this field can be used instead. There is support for the assignment of multiple userIds in which each identity has an assigned type (there is no predefined vocabulary for this type field and so it is left to local deployments to establish an appropriate vocabulary e.g. LDAP, LTI, etc.).

Also included is a field called identifier. This is purely for humans to use when referring to a particular user for whatever reason. It is not a machine-readable field and should not be processed as anything other than a human readable string.

These identifiers are purely for humans to use when referring to a particular instance. These fields are not designed to be machine readable, and should not be processed as anything other than a human readable string.

In Japan, the MEXT’s school codes and board of education codes are generated according to certain rules using school type, prefecture number, establishment classification, etc. and can be considered human readable identifiers.

Reserve the userMasterIdentifier property of the User class. As a setting for userMasterIdentifier property in Japan, a UUID is reserved that uniquely identifies a user when linking with other systems. For example, if the UUID is generated by a Student Information System, the receiving side must also treat it as a unique identifier for the user.

In BULK mode the status property MUST be blank. Therefore it is unclear how to identify between records that are active/inactive. The enabledUser property in the users.csv expresses the distinction for the user's record being active or inactive. The full range of states for the user's record is expressed by:

When the row is "missing" from the file the record state is to be interpreted as tobedeleted;
When the row is "present" the value of enabledUser=inactive denotes an inactive user record;
When the row is "present" the value of enabledUser=active denotes an active user record.

An example of the use of the extensions in the 'classes.csv' file is shown in Figure 3.

Figure 3 Example of the data model extension of the 'classes.csv' file.

An example of the use of the extensions in the 'enrollments.csv' file is shown in Figure 4.

Figure 4 Example of the data model extension of the 'enrollments.csv' file.

An example of the use of the extensions in the 'users.csv' file is shown in Figure 5.

Figure 5 Example of the data model extension of the 'users.csv' file.

It is recognized that implementers may wish to extend the specification. The preferred mechanism for doing this is for implementers to use an extension space within the OneRoster data model, and then set their CSV parsers to read those extension attributes. Extensions are ONLY permitted by adding 'metadata' named columns to the end of the set of columns already defined in the specification and those added in this Profile.

When extending a vocabulary the proprietary value MUST start with the substring "ext:". An example is for a new role with a value of: ext:tutor.

This Section is NORMATIVE.

The process for conformance testing implementations of OneRoster includes the following:

Go to the 1EdTech OneRoster CSV Validator for OneRoster 1.2. Conformance Test Suite links are available in the Subsection 7.2.1 (CSV import/export certification) of this document;
Follow the onscreen instructions to run the tests;
Once the test has been successfully run, submit a print out of the test results along with the following information to conformance@1edtech.org:
1. Your Name
2. Your Organization
3. Your Product Name and Version
4. Date the Product was tested
5. Whether you are a CSV Importer, CSV Exporter or CSV Importer/Exporter.

All Tests for the appropriate operational modes must be passed successfully to be considered 1EdTech OneRoster 1.2 CSV Japan K-12/Schools Profile compliant.

All Tests MUST be passed successfully to be considered 1EdTech OneRoster compliant.

After you have submitted your successful conformance information to conformance@1edtech.org, and received confirmation and a registration number from 1EdTech you may then apply the appropriate conformance mark. The 1EdTech Conformance Chart will list your conformance details. If you have any questions, please feel free to contact us at any point.

Membership in 1EdTech Consortium is the only way to achieve official conformance to the OneRoster 1.2 CSV Japan K-12/Schools Profiles. Products without a 1EdTech Conformance Registration Number are not considered to be compliant by 1EdTech.

The 1EdTech Conformance program provides conformance testing for:

The set of CSV files that are to be exchanged;
The systems that either import and/or export CSV files.

It should be noted that all filenames, column headers and data values are case sensitive. Incorrect use of case will result in the corresponding conformance error being reported.

Details about OneRoster conformance are available at the webpage: https://www.imsglobal.org/oneroster-conformance-testing.

The OneRoster 1.2 CSV Japan K-12/Schools Profile validator is available to test the validity of CSV files. This validator is available at: https://onerostervalidator.imsglobal.org:8443/oneroster-server-cts-webapp/instructions. The set of CSV files are submitted as single zipped file. The validator will check that the ‘manifest.csv’ file is present and correctly structured. Next it will check the accompanying data CSV files for individual correctness. Next it will check for cross-file semantic consistency. Finally it will provide a report on the correctness of the set of CSV files. Note that ONLY the ‘manifest.csv’ file is required in the zip file i.e. any combination of accompanying data model CSV files is permitted provided that these are semantically complete and self-consistent.

CSV files are defined as either 'BULK' or 'DELTA' processing. Bulk and Delta based CSV files have different content requirements and the validator will check for that consistency: all records in a single CSV file must be bulk or delta processing i.e. a mixture is NOT permitted and will be result in the file being declared invalid.

The set of files for a BULK exchange MUST be semantically complete i.e. any reference to a record, for example the reference to the user in the enrollment, requires that record to be in the file set. For a DELTA file set only the files that contain records that have been changed MUST be included.

The OneRoster CSV validator is definitive when establishing whether or not a set of CSV files is conformant to the OneRoster specification.

All systems, whether supporting import and/or export, must handle BULK processing content. Support for DELTA content is optional. Also, all systems must support the core set of rostering CSV files (this minimum set ensures semantic consistency for rostering information). Support for the non-rostering-oriented files is optional but the set of supported files must still create semantically consistent data exchange.

Determining whether or not a system that imports OneRoster CSV files is conformant is based upon a report generated from the importing of the reference test set of OneRoster CSV files. This test set contains multiple zip files each of which must be imported by the Implementation Under Test (IUT). This set of zip files consists of two types of test files:

CSV files that are syntactically correct and semantically consistent;
CSV files which are syntactically incorrect and/or semantically inconsistent.

In the case of the files with known errors, a system must indicate that the files are incorrect. How those errors are reported and the subsequent file processing is implementation dependent and not subject to conformance. However, establishing whether or not a system is compliant requires the vendor to demonstrate that the CSV files have been appropriately processed and any errors detected.

A conformant system is NOT required to import every type of data model CSV file. A conformant system must import, completely, the manifest.csv file, the mandatory set of CSV data files and any of the optional data model CSV files supported by the OneRoster system undergoing conformance (the set of supported CSV files must be identified during conformance). The correct CSV files must be processed appropriately i.e. updates according to any delta changes, etc.

An importing system MUST support all of the required and optional data fields within the OneRoster specification. It is not a requirement that all of the data is stored internally but an importer must not flag as in error a CSV file that contains data that cannot be stored by the importing system.

The test set includes files sets that are semantically incomplete and these inconsistencies must be detected and the appropriate error messages logged. The test set also includes CSV files that have extensions. A system is not required to process these extensions but it must not result in the import files being rejected as invalid. A system that can process bulk files only must be capable of detecting delta files as invalid and logging the appropriate error information.

If a manifest.csv file is NOT present in the zip file then an importing system MUST assume the set of files are not compliant to the Profile. The importing system must flag an error.h

The set of OneRoster 1.2 CSV Japan K-12/Schools Profile Reference Test CSV Files are available from 1EdTech through the OneRoster Conformance web pages (https://www.imsglobal.org/oneroster-conformance-testing).

The mandatory set, or core, of CSV data files that MUST be supported for rosters import is (note that it is NOT a requirement that every set of CSV files contain this core set):

‘academicSessions.csv’ - bulk mode;
‘classes.csv’ - bulk mode;
‘courses.csv’ - bulk mode;
‘enrollments.csv’ - bulk mode;
‘orgs.csv’ - bulk mode;
‘roles.csv’ - bulk mode;
‘users.csv’ - bulk mode.

Therefore, the CSV data files that MAY be supported for rosters import are:

‘academicSessions.csv’ - delta mode;
‘classes.csv’ - delta mode;
‘courses.csv’ - delta mode;
‘demographics.csv’ - bulk and/or delta mode;
‘enrollments.csv’ - delta mode;
‘orgs.csv’ - delta mode;
‘roles.csv’ - delta mode;
‘users.csv’ - delta mode;
‘userProfiles.csv’ - bulk and/or delta mode.

Any system claiming that it supports import of the above optional data files MUST demonstrate the correct importing of the reference test set as part of the conformance. Note that the requirement for semantic consistency means that not all combinations of the set of optionally supported file imports is permitted.

Determining whether or not a system that exports OneRoster CSV files is conformant is based upon the use of the OneRoster CSV validator to determine that the exported CSV files are valid. The IUT is required to export a set of CSV files that demonstrates the full range of the export capabilities of the IUT. These zip files must be validated by the OneRoster CSV validator. The resulting set of reports, and the corresponding CSV files, must be submitted to 1EdTech as part of the conformance claim.

The submitted set of zipped CSV files must include examples of every one of the possible CSV files and must support contain BULK and, if appropriate, DELTA data sets. Support for the full range of the data models must also be demonstrated.

The demonstration set may contain extension fields but these must be the last set of columns. The header names for the extensions must not duplicate any of the other header names in CSV.

A system is NOT required to create all of the CSV files. A conformant system MUST be capable of creating the manifest.csv file, the set of core data CSV files plus any of the other OneRoster CSV file as identified by the conformance claim and sustaining the semantic consistency. The range of data model CSV files created by the OneRoster system under test MUST be defined as part of the conformance. The mandatory, or core, set of CSV data files that MUST be supported for export is (note that it is NOT a requirement that every set of CSV files contain this core set):

The mandatory set, or core, of CSV data files that MUST be supported for rosters export is (note that it is NOT a requirement that every set of CSV files contain this core set):

‘academicSessions.csv’ - bulk mode;
‘classes.csv’ - bulk mode;
‘courses.csv’ - bulk mode;
‘enrollments.csv’ - bulk mode;
‘orgs.csv’ - bulk mode;
‘roles.csv’ - bulk mode;
‘users.csv’ - bulk mode.

Therefore, the CSV data files that MAY be supported for rosters export are:

‘academicSessions.csv’ - delta mode;
‘classes.csv’ - delta mode;
‘courses.csv’ - delta mode;
‘demographics.csv’ - bulk and/or delta mode;
‘enrollments.csv’ - delta mode;
‘orgs.csv’ - delta mode;
‘roles.csv’ - delta mode;
‘users.csv’ - delta mode;
‘userProfiles.csv’ - bulk and/or delta mode.

Any system claiming that it supports export of the above optional data files MUST demonstrate the correct exporting of the files using the OneRoster CSV Validator. The set of exported files MUST be semantically consistent otherwise the export capability will be declared invalid (the OneRoster CSV validator will check for this semantic consistency).

Exporting systems must supply all of the data that is defined as required and may supply any of the data fields defined as optional.

Systems that are certified as OneRoster CSV compliant will be categorized as:

CSV Importers - that support OneRoster CSV file importing only;
CSV Exporters - that support OneRoster CSV file exporting only;
CSV Importers/Exporters - that support OneRoster CSV file importing and exporting.

The functional capabilities of such systems are:

They shall support the importing of the manifest file;
They shall support the importing of the set of core rostering files in bulk processing mode;
They may support the importing of the 'demographics.csv' files in bulk processing mode;
They may support the importing of the 'userProfiles.csv' files in bulk processing mode;
They may support the importing of the full set of rostering files in delta processing mode (the nine files used for rostering);
They must support all of the data fields including those extension fields defined in this Profile;
They may support the processing of proprietary extension data fields.

A checklist for the required CSV file support for importing systems for each of the three service modes is shown in Table 7.1.

Table 7.1 The checklist for CSV file support for importing systems.
CSV File Name	Bulk Mode	Delta Mode
CSV File Name	Roster	Roster
manifest	R	R
academicSessions	R	O
classes	R	O
courses	R	O
enrollments	R	O
orgs	R	O
roles	R	O
users	R	O
demographics	O	O
userProfiles	O	O

The functional capabilities of such systems are:

They shall support the exporting of the manifest file;
They shall support the exporting of the set of core rostering files in bulk processing mode;
They may support the exporting of the 'demographics.csv' files in bulk processing mode;
They may support the exporting of the 'userProfiles.csv' files in bulk processing mode;
They may support the exporting of the set of full rostering files in delta processing mode (the nine files used for rostering);
They may support the exporting of the set of non-rostering files in bulk and/or delta processing modes;
They must supply all of the required data fields including those defined as extension fields;
They may supply any of the optional data fields;
They may supply proprietary extension data fields.

A checklist for the required CSV file support for exporting systems for each of the three service modes is shown in Table 7.2.

Table 7.2 The checklist for CSV file support for exporting systems.
CSV File Name	Bulk Mode	Delta Mode
CSV File Name	Roster	Roster
manifest	R	R
academicSessions	R	O
classes	R	O
courses	R	O
enrollments	R	O
orgs	R	O
roles	R	O
users	R	O
demographics	O	O
userProfiles	O	O

The functional capabilities of such systems are:

They shall support the importing and exporting of the manifest file;
They shall support the importing and exporting of the core set of rostering files in bulk processing mode;
They may support the importing and exporting of the 'demographics.csv' files in bulk processing mode;
They may support the importing and exporting of the 'userProfiles.csv' files in bulk processing mode;
They may support the importing and exporting of the full set of rostering files in delta processing mode;
They must support the importing of all of the data fields including the new extension fields defined in this Profile;
When exporting, they must supply all of the required data fields including the new extension fields required in this Profile;
When exporting they may supply any of the optional data fields;
They may support the import and/or export processing of proprietary extension data fields.

There is no requirement to maintain the integrity of the data set that is created by the import/export round-tripping.

A checklist for the required CSV file support for importing/exporting systems is shown in Table 7.3.

Table 7.3 The checklist for CSV file support for importing/exporting systems.
CSV File Name	Bulk Mode	Delta Mode
CSV File Name	Roster	Roster
manifest	R	R
academicSessions	R	O
classes	R	O
courses	R	O
enrollments	R	O
orgs	R	O
roles	R	O
users	R	O
demographics	O	O
userProfiles	O	O

This section is non-normative.

This Section is NON-NORMATIVE.

Table A1 is the dependency matrix for the CSV files. This shows the set of CSV files that MUST be supplied for BULK exchange; this dependency is created because the set of supplied CSV files must be semantically complete and the data model defines certain fields must be present within a CSV file. To read the matrix select the CSV file of interest in the left hand column. The entries along that row indicate if some other CSV file is required (R) or may be required (O) if an associated optional field has been included in the source CSV file.

The color coding for Table A1 is:-

Green - denotes a source file that has NO dependencies on the other CSV files (the manifest will include a single data file
Yellow - denotes a source file that has a dependency only on itself i.e. another row in the same CSV file (the manifest will include a single data file i.e. of either academicSessions.csv or orgs.csv). The term O(P) in the academicSessions.csv and the orgs.csv denotes an optional dependency in the same file through the parentSourcedId attribute
Orange - denotes a source file that has a dependency on some other file that itself is self contained i.e. a CSV file that is color-coded Green or Yellow. courses.csv has a dependency on the Yellow and/or Green coded files. The term O(SY) denotes an optional dependency on the schoolYearSourcedId attribute
Pink - denotes a source file that has a dependency on some other file that itself has other dependencies. Pink coded files are classes.csv, demographics.csv, roles.csv, userProfiles.csv and users.csv. For the classes.csv the terms mean:-
- R(T) denotes a required dependency on the termSourcedIds attribute
- R(S) denotes a required dependency on the courseSourcedIds attribute
- R[S] denotes a required dependency on the orgs.csv due to the dependency through the courseSourcedIds attribute
- O[S] denotes an optional dependency on the academicSessions.csv due to the dependency through the courseSourcedIds attribute
For the demographics.csv the terms mean:-
- R[U] denotes a required dependency on the users.csv file
- O[U] denotes an optional dependency on the userProfiles.csv due to the dependency through the sourcedId attribute
For the userProfiles.csv the terms mean:-
- R[U] denotes a required dependency on the users.csv file
For the users.csv the terms mean:-
- O(A) denotes an optional dependency in the same file through the agentSourcedIds attribute
Red - denotes a source file that as a further depth of dependency when compared to the files that are color coded Pink. Red coded files are enrollments.csv. The associated terms mean:-
- R[C] denotes a required dependency on the classes.csv file
- R[U] denotes a required dependency on the users.csv file
- R[S] denotes a required dependency on the courses.csv file
- O[U] denotes an optional dependency on the userProfiles.csv file
- O(SY) denotes an optional dependency on the academicSessions.csv due to the dependency on the schoolYearSourcedId attribute in the courses.csv file.

Table A1 - CSV files dependencies matrix.
File Names	Rostering
File Names	academic Sessions	classes	courses	demographics	enrollments	orgs	roles	user Profiles	users
academicSessions	O(P)
classes [C]	R(T), O[S]		R			R(S), R[S]
courses [S]	O(SY)					R
demographics						R[U]	R[U]	O[U]	R
enrollments	R[C], O(SY)	R	R[C]			R(S), R(U)	R[U]	O[U]	R
orgs						O(P)
roles						R		O	R
userProfiles						R[U]			R
users [U]						R	R	O	O(A)

The key conclusions are:

No CSV file is dependent on the demographics.csv and enrollments.csv files
The Rostering-oriented CSV file-set must consist of academicSessions.csv, classes.csv, courses.csv, enrollments.csv, orgs.csv, roles.csv and users.csv.

NOTE: An implementation may impose further constraints on the set of files required for semantic consistency i.e. more files may need to be supplied than the strict minimum.

This section is non-normative.

Publication history and revision details for this specification.
Version No.	Release Date	Comments
Version 1.0 / Final Release 1.0	1st October 2025	The first formal release of the Final Release publication of this profile document. This publication reflects that the profile is ready for general adoption.

[APPLIC-CODE]: APPLIC Code Dictionary. The Association for Promotion of Public Local Information and Communication. March, 2022. URL: https://www.applic.or.jp/2023/stand/APPLIC-0002-2022/APPLIC-0002-2022-11/APPLIC-0002-2022-11-13.pdf
[ISO/IEC10646]: ISO/IEC 10646: 2020 Information Technology - Universal Coded Character Set (UCS). ISO/IEC. December 2020. URL: https://www.iso.org/standard/76835.html
[ISO8601]: Representation of dates and times. ISO 8601:2004.. International Organization for Standardization (ISO). 2004. ISO 8601:2004. URL: http://www.iso.org/iso/catalogue_detail?csnumber=40874
[JIS-X-0213]: JIS X 0213. Japan Electronic Publishing Association. May 2022. URL: https://www.jepa.or.jp/ebookpedia/202205_5655/
[MEXT-DIST-CODE]: MEXT District Code. Ministry of Education, Culture, Sports, Science and Technology (MEXT). December, 2020. URL: https://www.mext.go.jp/b_menu/toukei/mext_00004.html
[MEXT-SCH-CODE]: MEXT School Code. Ministry of Education, Culture, Sports, Science and Technology (MEXT). December, 2020. URL: https://www.mext.go.jp/b_menu/toukei/mext_01087.html
[OR-CSV-12]: OneRoster 1.2.1 CSV Binding 1.0. Colin Smythe; Matthew Richards; Joshua McGhee. IMS Global Learning Consortium, Inc. August, 2023. IMS Final Release. URL: https://www.imsglobal.org/sites/default/files/spec/oneroster/v1p2/ims-oneroster-v1p2-final-csvbindv1p0.html
[OR-GBK-SM-12]: OneRoster 1.2 Gradebook Service Information Model 1.0. Colin Smythe; Matthew Richards; Joshua McGhee. IMS Global Learning Consortium, Inc. June, 2022. IMS Final Release. URL: https://www.imsglobal.org/sites/default/files/spec/oneroster/v1p2/ims-oneroster-gradebook-v1p2-final-infomodelv1p0.html
[OR-RES-SM-12]: OneRoster 1.2 Resource Service Information Model 1.0. Colin, Smythe; Matthew, Richards; Joshua, McGhee. IMS Global Learning Consortium, Inc. June, 2022. IMS Final Release. URL: https://www.imsglobal.org/sites/default/files/spec/oneroster/v1p2/ims-oneroster-resource-v1p2-final-infomodelv1p0.html
[OR-ROS-SM-12]: OneRoster 1.2 Rostering Service Information Model 1.0. IMS Global Learning Consortium, Inc. June, 2022. IMS Final Release. URL: https://www.imsglobal.org/sites/default/files/spec/oneroster/v1p2/ims-oneroster-rostering-v1p2-final-infomodelv1p0.html
[RFC1951]: DEFLATE Compressed Data Format Specification version 1.3. P. Deutsch. IETF. May 1996. Informational. URL: https://www.rfc-editor.org/rfc/rfc1951
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3629]: UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF. November 2003. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3629
[RFC4180]: Common Format and MIME Type for Comma-Separated Values (CSV) Files. Y. Shafranovich. IETF. October 2005. Informational. URL: https://www.rfc-editor.org/rfc/rfc4180
[SECURITY-11]: Security Framework 1.1. 1EdTech Consortium, Inc. June, 2020. URL: https://www.imsglobal.org/spec/security/v1p1/

[OR-OVIEW-12]: OneRoster 1.2 Standard 2.0. Colin, Smythe; Matthew, Richards; Joshua, McGhee. IMS Global Learning Consortium, Inc. September, 2022. IMS Final Release. URL: https://www.imsglobal.org/spec/oneroster/v1p2/

The following individuals contributed to the development of this document:

Name	Organization	Role
Shigeo Fujiwara	UCHIDA YOKO CO., LTD	Editor
Joshua McGhee	1EdTech Consortium	Editor
Colin Smythe	1EdTech Consortium	Editor
Yuji Tokiwa	1EdTech Japan Society	Editor
Tomoko Komori	UCHIDA YOKO CO., LTD
Yoko Saeki	TOKYO SHOSEKI CO., LTD
Kazuki Noritake	1EdTech Japan Society
Yuichi Fujimura	1EdTech Japan Society
Susan Haught	1EdTech Consortium

You are here

1EdTech OneRoster 1.2 CSV Binding: Japan K-12/Schools Profile

Abstract

1. Introduction

1.1 Scope and Context

1.2 Changes Made to the Base Specification by the Japan K-12/Schools Profile

1.3 Conformance Statements

1.4 Structure of this Document

1.5 Acronyms

2. Rostering in K-12/Schools in Japan

2.1 Japanese Educational System and its Administration

2.2 Challenges in Applying OneRoster to Japan

2.3 Extended Data Model

3. CSV Overview

3.1 Binding of the Data

3.2 Exchanging the CSV Files

3.3 Bulk/Delta Behavior Constraints

4. CSV Format

4.1 'manifest.csv'

4.2 'academicSessions.csv'

4.3 'categories.csv'

4.4 'classes.csv'

4.5 'classResources.csv'

4.6 'courseResources.csv'

4.7 'courses.csv'

4.8 'demographics.csv'

4.9 'enrollments.csv'

4.10 'lineItemLearningObjectiveIds.csv'

4.11 'lineItems.csv'

4.12 'lineItemScoreScales.csv'

4.13 'orgs.csv'

4.14 'resources.csv'

4.15 'resultLearningObjectiveIds.csv'

4.16 'results.csv'

4.17 'resultScoreScales.csv'

4.18 'roles.csv'

4.19 'scoreScales.csv'

4.20 'userProfiles.csv'

4.21 'userResources.csv'

4.22 'users.csv'

5. Extending the CSV Binding

5.1 Proprietary Data Elements

5.2 Proprietary Vocabulary Terms

5.3 Profile Defined Extensions

6. Best Practices

6.1 CSV File Handling Best Practices

6.1.1 File Encoding and File Ordering

6.1.2 Exchanging the CSV Files

6.1.3 Ensuring Semantic Consistency

6.2 Data Model Best Practices

6.2.1 Identifiers and their Use

6.2.1.1 Sourced Identifiers

6.2.1.2 User Ids

6.2.1.3 School and District Identifiers

6.2.1.4 Unique Identifier for the User

6.2.2 The enabledUser Property in the users.csv File

6.3 Using the Extension Fields

6.3.1 Profile Defined Extensions

6.3.2 Proprietary Extensions

7. Conformance & Certification

7.1 The Conformance Process

7.1.1 Conformance Testing Process

7.1.1.1 Requirements for OneRoster v1.2 CSV Conformance

7.1.1.2 OneRoster Conformance Mark

7.2 CSV Exchange Conformance

7.2.1 CSV File Compliance

7.2.2 Systems File Compliance

7.2.2.1 Importing CSV Files

7.2.2.1.1 Support for Importing Rosters

7.2.2.2 Exporting CSV Files

7.2.2.2.1 Support for Exporting Rosters

7.2.3 CSV File Processing Certification

7.2.3.1 CSV Importers Certification

7.2.3.2 CSV Exporters Certification

7.2.3.3 CSV Importers/Exporters Certification

A. File Dependencies Matrix

B. Revision History

B.1 Version History

C. References

C.1 Normative references

6.2.2 The `enabledUser` Property in the `users.csv` File