Experience API

발행일	한국어 버전 : 2017년 11월 1일

IPR 및 유포에 관한 공지사항

이 표준을 활용하는 이는 표준을 적용하면서 인지하게 된 관련 특허 또는 지적재산권의 침해 가능성 사실을 코멘트와 함께 문서의 형태로 제공해야 한다.

IMS Korea는 이 문서에 명시된 기술의 적용 또는 활용과 관련된 지적재산권 또는 기타 권리의 적용범위와 유효성에 대한 입장, 또는 그러한 권리와 관련하여 어느 정도까지 허용될 것인지에 대한 입장을 표명하지 않는다. 뿐만 아니라, 그러한 권리를 파악하는 노력을 기울였다는 사실 또한 명시하지 않는다.

이 표준을 배포하거나 제품 또는 서비스 제공을 위해서 활용하고자 한다면, IMS Korea 표준화 포럼 사무국(한국교육학술정보원)에 승인 요청을 하고 이메일을 통해 승인을 받아야 한다.

IMS 정식회원 및 웹회원은 상기의 저작권 공지사항과 이 문장을 사본에 포함시키는 조건 하에 이 표준을 배포 및 활용할 수 있다. 그러나 저작권 공지사항 또는 IMS Korea 명칭이 표기된 부분을 삭제하는 등, 이 표준을 훼손하는 행위는 금지된다. 단, IMS Korea가 승인한 프로젝트그룹의 감독 하에 IMS Korea 표준을 수정하는 경우는 예외적으로 허용된다.

상기 부여된 제한된 승인 내용은 영속적이며, IMS Korea 또는 후임기관 그 누구라도 라이센스를 취소할 수 없다.

이 표준은 어떠한 보증도 하지 않으며, 특히 불침해에 대한 그 어떤 보증도 하지 않는다. 이 표준의 사용에 대한 책임은 온전히 사용자에 의하며, 그 어떤 컨소시엄이나 제공 주체도 이 표준을 사용함으로써 제3자가 직간접적으로 입을 수 있는 피해에 대해 책임지지 않는다.

이 표준은 ADL(Advanced Distributed Learning)에서 개발한 표준을 부합화 한 것으로, 원문 사이트는 다음과 같다 : https://github.com/adlnet/xAPI-Spec
그리고 저작권은 다음 웹사이트를 우선으로 한다 : http://www.apache.org/licenses/LICENSE-2.0

목 차

1.0 개정 내역
2.0 Experience API의 규칙
4.0 Statement
5.0 Miscellaneous Types
6.0 Run-time Communication
7.0 Data Transfer (REST)
부속서 A: Statement의 예시
부속서 B: 다른 유형의 Statement 객체의 예시
부속서 C: “cmi.interaction” 형식의 Activity에 대한 정의의 예시
부속서 D: Converting Statements to 1.0.0
부속서 E: 서명된 Statement의 예시
부속서 F. 모든 Endpoint 표

1.0 개정 내역

0.8 (Project Tin Can API Deliverable) to 0.9 (March 31, 2012)
Project Tin Can API를 제공한 Rustici 소프트웨어는 2012 년 4 월 킥오프 회의 이전에 API를 수정했다. 그것은 현재 사양 및 0.9버전 개정에 변경 사항을 이동하기 위해 회의에서 투표되었다.

0.90 to 0.95 (August 31, 2012)
“코어” Verbs 및 Activity 유형은 표준에서 제거되었다. 결과, 문맥, 상호작용 그리고 Activity 정의에 대한 참조 역시 제거 되었다. 실행자는 자신이 Verb를 만들기보다 커뮤니티에 정의된 Verb를 사용하는 것이 좋다.

Verbs, Activity 유형, 그리고 extension keys는 이제 URI이다.
다른 구현 세부사항 및 범위 일부 주위에 언어의 구조를 조정하거나 추가했다.
Agent들의 사람 중심 시점을 사용하는 것에서 개인 중심 시점으로 바뀌었다.
Friend of a Friend (FOAF) Agent 병합 요구 사항을 제거하였다.
Agent 객체는 이제 적어도 한 개가 아니라, 정확히 한 개의 고유한 property를 가지고 있어야 한다.

0.95 to 1.0.0 (April 26, 2013)
다양한 개선 사항 및 분류:

첨부파일 추가
Activity 메타 데이터는 XML이 아닌 JSON으로 저장된다.
Statement들의 voiding에 대한 변경
문서 API의 분류 및 명명
Statement API 쿼리의 변경
Signed Statements

1.0.0 to 1.0.1 (October 1, 2013)
분류사항 및 추가 예제:

여러 오타 수정
부록에 추가적인 예제 추가

2.0 Experience API의 규칙

Experience API는 경험의 Statement를 전달하고 Learning Record Store(LRS)에 안전하게 저장 될 수 있는 서비스이다. 이러한 경험의 Statement는 일반적으로 학습 경험이지만, API는 경험의 어떤 종류의 경험에 대한 Statement이라도 다룰 수 있다. Experience API는 이러한 학습 경험을 만들고 추적하는 활동 공급자에 따라 달라진다. 본 명세서는 데이터 모델과 이러한 작업을 수행하는 방법에 대한 관련 구성 요소를 제공한다.

특히, Experience API는 다음과 같은 기능을 제공한다.

Statement의 구조와 정의, 국가, 학습자, 활동과 개체들이 Activity 공급자에 의해 전달되는 수단이다.
저장소에 데이터를 전송하는 메서드와 이 객체들의 검색은(검증이 아님) 학습 레코드 저장소로부터 또는 저장소에서 이루어진다. 시스템이 레코드를 저장 또는 검색하는데에 Activity 공급자가 될 필요는 없다 레코드를 검색합니다. LRSs는 다른 LRSs와 통신하거나 시스템에 보고한다.
보안 메서드는 학습 레코드 저장소와 신뢰할 수 있는 자원들의 정보 교환을 허용한다.

Experience API는 온라인 학습과 훈련의 풍부한 아키텍처를 가능하게 할 수 있는 많은 구상된 기술들 중 첫 번째이다. Experience API가 지원하기위해 설계된 추가적인 기술로는 인증 서비스, 쿼리 서비스, 시각화 서비스, 그리고 개인 데이터 서비스등이 있다. 이러한 서비스의 구현 세부 사항은 여기에 지정되지 않은 반면, Experience API는 이를 염두에 두고 큰 건설적 비전으로 설계되어 있다.

2.1 Experience API에서의 ADL의 역할

Advanced Distributed Learning (ADL)의 발의는 Experience API의 개발에서 청지기와 기획자의 역할을 담당하고 있다. Experience API는 언제 어디서나 학습을 용이하게 하는 ADL 교육 및 학습 아키텍처의 한 부분으로 볼 수 있다. ADL은 Experience API를 유사한 사용 사례를 지원할 수 있는 SCORM (Sharable Content Object Reference Model)이 지원하는 것과 유사한 사용 경험 및 ADL로 수집되었지만 SCORM이 지원하지 못하는 다양한 사용 사례들을 지원 할 수 있는 SCORM의 진화 된 버전으로 보고 있다.

2.2 참여자들

“Experience API 프로젝트에 기여한 모든 사람에게 감사합니다. 많은 여러분은 주간 회의에 불려 전체 분산 학습 커뮤니티에 유용한 어떤 사양을 형성하는 데 도움이 되었습니다. 여러분은 많은 코드 샘플, 제품, 사양을 작성 및 적응하는 사람들을 돕기위한 문서 출시를 지원하였습니다. 또한 조직의 SCORM의 사용 및 기타 학습 우수 사례에 대한 유용한 정직한 정보를 제공에 관여하는 사람들 모두에게 감사하고 싶습니다. 사용 사례와 공유된 경험을 통해 지식을 공유하고, ADL과 지역 사회는 분명 교육 및 학습 아키텍처 만드는 첫 번째 단계인 Experience API를 확인합니다. 당신은 진정으로 우리가 우리의 훈련 및 교육 바로 최선을 만들기 위해 의존하는 지역 사회 지도자입니다.”

Kristy S. Murray, Ed.D. Director, ADL Initiative OSD, Training Readiness & Strategy (TRS)

2.2.2 참여자 수집 요구 사항

Experience API에 대한 요구 사항의 수집함에 있어, 많은 사람과 조직들이 SCORM에 대한 소중한 의견, 분산 학습 노력, 그리고 일반적으로 학습 기술 활동을 제공했다. 전제 목록은 아니지만, Learning Education 과 Training Standards Interoperability (LETSI) 그룹이 2008년에 수집한 백서, Rustici oftware UserVoice 웹 사이트, 일대일 인터뷰, Experience API 사양에 대하여 수집된 다양한 블로그의 중요한 자원들이 Experience API를 위해 수집되었다.

2.3 비기술적 경향에 대한 가이드 라인 읽기

이 문서는 다양한 시스템에서 Experience API를 구현히는 방법을 설명하는 최종 문서이다. 이 기술 문서는 상호 운용 가능한 개인과 상호 운용이 가능하며 상호 운용 가능한 상호 운용 가능한 도구, 시스템 및 서비스를 개발하는 개인 및 조직을 위해 특별히 작성된 기술 문서이다.

가능한 한 다양한 도구, 시스템 및 서비스는 아래에 설명된 사양에 기초하여 다양한 도구, 시스템 및 서비스를 고려하기 때문에 비기술적인 독자를 염두에 두어야 한다. 이러한 이유로 Experience API의 특정 측면에 대한 상위 수준 개요를 제공하는 섹션에는 설명 또는 이유가 표시된다. 요구 사항, 세부 사항 또는 예시로 표시된 문서의 항목은 더 기술적이다.

원칙적으로, 지침이 기술적이거나 요구 사항인 것처럼 보일 경우, 이와 같이 해석되어야 한다. 이것은 각각의 비직관적이거나 해부될 수 있는 긴 요구사항의 리스트의 더 길고 더 자세한 설명과 테이블들에 특히 사실이다.

3.0 정의 Definitions

Activity: Activity는 내가 “이것”을 했다면 “이것”의 객체를 만드는 형식이다. 이것은 행위자가 상호작용한 무언가이다. 그것은 Verb와 의미있는 조합으로 추적되는 교육, 경험, 또는 성능의 단위가 될 수 있다. Activity의 해석은 광범위하며, Activity는 (실제 또는 가상의) 의자와 같은 실재적인 물체일 수 있다. “안나는 케이크 레시피를 따라했다”라는 Statement에서, 레시피는 xAPI Statement의 관점에서 Activity를 구성한다. Activity의 다른 예로는 책, e-러닝 코스, 하이킹 또는 회의 등이 있다.

Activity Provider (AP): 학습 경험에 대한 정보를 기록하기 위해 LRS와 통신하는 소프트웨어 객체이다. 이 통신을 수행하는 소프트웨어 객체와 학습 자산을 묶을 수 있다는 것은 SCORM 패키지 유사 할 수 있지만, Activity 공급자는 보고하는 경험과 분리 될 수 있다.

Actor: Activity의 Statement에서 행위(Verb)를 하는 것으로 추적된 개인이나 그룹의 신원 또는 페르소나.

Authentication: 사용자 또는 시스템의 신원 확인의 개념. 인증을 통해 두 개의 “신뢰할 수 있는” 당사자 간의 상호 작용을 할 수 있습니다.

Authorization: 사용자 또는 시스템의 역할에 따라 권한의 행동 유도성; 다른 것에 의한 하나의 사용자 또는 시스템의 “신뢰”를 만드는 과정.

Base Endpoint: 슬래시를 포함한 모든 Experience API 엔드 포인트 최대 경로. 예를 들면 “http://example.com/xAPI/statements”의 Statement 엔드 포인트가 있는 LRS 엔드 포인트는 “http://example.com/xAPI/”에 기반한다.

Client: LRS와 상호 작용할 수 있는 개체를 말한다. Client는 Activity 제공자, 보고용 도구, LMS, 또는 다른 LRS가 될 수 있다.

Community of Practice: 일반적인 방식으로 운영되며, 일반적인 역할, 목적, 원인 등으로 연결된 그룹.

Experience API (xAPI): 이 문서에 정의 된 API, “Project Tin Can”의 제품이다. 플랫폼에 상관 없이 확장 가능한 학습 기록, 학습자 및 학습 경험 프로필을 저장하고 검색할 수 있는 간단하고 가벼운 방법이다.

Immutable: 변경할 수 없는 것을 설명하기 위해 사용하는 형용사. 몇 가지 예외로, xAPI Statement은 불변이다. 이 Statement은 LRSs 사이에 공유되는 경우, 정책의 여러 사본이 동일하게 유지되도록 한다.

Internationalized Resource Identifier (IRI): IRL 될 수 있는 고유 식별자. xAPI에서 모든 IRI는 스키마를 포함한 완전한 IRI여야 한다. 상대적 IRI는 사용할 수 없다. IRL는 이를 작성하는 사용자에 의해 제어되는 도메인 내에서 정의되어야 한다.

Internationalized Resource Locator (IRL): 본 문서의 맥락에서, IRL은 (URI 규칙에 IRI 당)을 URI로 변환 할 때, URL에 있는 IRI이다. 실제로 일부 커뮤니티는 xAPI 내에서 기술적으로 올바르지 않은 IRI를 사용하는 경우에도 URL을 사용한다.

Inverse Functional Identifier: 특정 개인이나 그룹의 고유 식별자이다. Agent 및 Group을 식별하는 데 사용된다.

Learning Management System (LMS): “하나 이상의 학습자의 하나 이상의 학습 과정을 관리하는 데 사용되는 소프트웨어 패키지. LMS는 일반적으로 학습자가 자신을 인증하고, 과정을 등록 및 수강하고, 평가를 수행 할 수 있는 웹 기반 시스템이다.” (Learning Systems Architecture Lab 정의). 이 문서에서는 학습 표준을 구현하는 기존 시스템의 맥락에서 사용된다.

Learning Record Store (LRS): 학습 정보를 저장하는 시스템. xAPI의 이전에는 일반적으로 LRS는 Learning Management Systems (LMS)였다. 그러나, 이 문서에서는 LLS라는 용어를 사용하여 전체 LMS가 xAPI를 구현하는 데 필요하지 않음을 명확하게 한다. xAPI는 작동하는 LRS에 따라 다릅니다.

MUST / SHOULD / MAY: xAPI 규격에 따르는 의무의 세 가지 수준. MUST (또는 MUST NOT)를 구현하는데 실패하는 시스템은 적합하지 않다. SHOULD를 구현하는데 실패하는 것은 시스템이 적합하지 않다는 것은 아니지만, 모범 사례는 될 수 없다. MAY는 적합성에 영향을 미치지 않고 개발자가 결정할 수 있는 옵션을 나타낸다.

Profile: 학습자 또는 활동에 대한 정보가 보관되는 구조로, 일반적으로 교육용 시스템 구성 요소에 의미가 있는 이름 / 문서 쌍으로 구성된다.

Registration: 특정 활동을 경험한 학습자의 인스턴스이다.

Representational State Transfer (REST): 네트워크 웹 서비스 설계를 위한 아키텍처. 그것은 HTTP 메소드를 사용하고 현재 웹 모범 사례를 사용한다.

Service: 분산 학습 과정의 하나 이상의 요소를 담당하는 소프트웨어 구성 요소. 일반적으로 LMS에선 완벽한 학습경험을 설계하기 위한 다양한 서비스들을 의미한다.

Statement: 학습 경험의 양상을 추적하기 위한 <context>안에서 <result>와 함께하는 <actor (learner)> <verb> <object> 의 간단한 구조. 여러 Statement 집합은 학습 경험에 대한 자세한 내용을 추적하는 데 사용될 수 있다.

Tin Can API (TCAPI): API의 과거 이름. Experience API에 대한 비공식적인 참조에 사용된다.

Verb: Statement에서 Activity 안의 Actor에 의해 행해지는 행위로 정의된다.

4.0 Statement

Description Statement는 xAPI의 핵심으로, 모든 학습 이벤트는 Statement로 저장된다. Statement는 “I did this” 와 같은 형식이다.

4.1 Statement Properties

Details Statement 속성의 세부 사항은 아래 표와 같다.

요소 Property	유형Type	상세	필수여부
id	UUID	UUID는 Activity Provider에 의해 설정되지 않은 경우 LRS에 의해 할당된다.	Recommended
actor	Object	Agent 혹은 Group Object의 형태로서 누구에 관한 Statement인지 표현한다. “I Did This”에서 “I”를 나타낸다.	Required
verb	Object	Learner 혹은 Team Object의 Action을 표현한다. “I Did This”에서 “Did”를 나타낸다.	Required
object	Object	Statement에서 Object가 되는 Activity, Agent, 혹은 또 다른 Statement를 의미한다. “I Did This”의 Statement에서 “This”를 나타낸다. 이 필드의 값으로 제공되는 Object는 “objectType” 필드를 포함해야한다. 지정되지 않는 경우 Object는 Activity인 것으로 가정한다.	Required
result	Object	결과 Object로서 지정된 Verb와 관련된 결과를 자세히 표시한다.	Optional
context	Object	Context는 Statement에 더 많은 의미를 부여한다. 예) a team the Actor is working with, altitude at which a scenario was attempted in a flight simulator.	Optional
timestamp	Date/Time	해당 Statement에서 설명하는 이벤트가 발생했을 때의 (ISO 8601에 따라 형식화된) Timestamp로, 지정되지 않은 경우, LRS는 “저장”시간의 값으로 이를 설정한다.	Optional
stored	Date/Time	해당 Statement가 기록될 때의 (ISO 8601에 따라 형식화된) Timestamp로 LRS에 의해 설정된다.	Set by LRS
authority	Object	해당 Statement가 참이라고 assert한 Agent이다. LRS가 authentication을 기반으로 검사하며, 공백으로 표시하는 경우 LRS에 의하여 설정된다.	Optional
version	Version	Semantic Versioning 1.0.0에 따라 형식화된 Statement의 xAPI 버전	Not Recommended
attachments	Array of attachment Objects	Statement에 첨부된 헤더	Optional

LRS 처리 중 (“id”, “authority”, “stored”, “timestamp”, “version”) 속성이 (잠재적이거나 필수적으로) 할당되는 경우를 제외하고 Statement는 변경할 수 없다. Statement에서 참조되는 Activity의 내용이 Statement 자체의 일부로 간주되지 않는다는 것을 기억하라. 따라서 Statementment는 불변하지만, 그 Statement에 의하여 참조되는 Activity는 변화할 수 있다. 이는 참조된 Activity가 변화하는 경우, JSON으로 deep serialization된 Statement 또한 변화함을 의미한다 (이에 대한 자세한 사항은 Statement API의 “format” 파라미터를 참조하라).

Requirements

Statement의 각 Property는 절대로 여러번 사용할 수 없다.
Statement는 반드시 “actor”, “verb”, “object”를 사용해야 한다.
Statement Property의 순서는 임의로 지정할 수 있다.

Example MUST 혹은 SHOULD 단계의 모든 속성을 사용하는 가장 간단한 Statement는 다음과 같다.

{
	"id": "12345678-1234-5678-1234-567812345678",
	"actor":{
	"mbox":"mailto:xapi@adlnet.gov"
	},
	"verb":{
	"id":"http://adlnet.gov/expapi/verbs/created",
	"display":{
	"en-US":"created"
	}
	},
	"object":{
	"id":"http://example.adlnet.gov/xapi/example/activity"
	}

더 많은 예시는 Appendix A: Example Statements를 참조하라.

4.1.1 ID

Description UUID (필수 요건은 RFC 4122를 참고하라. UUID는 반드시 표준 문자열 형식을 따른다).

Requirements

id 없이 Statement가 수신되는 경우 ID는 반드시 LRS에 의하여 생성되어야한다.
id는 Activity Provider에 의하여 생성되어야한다.

4.1.2 Actor

Description 필수적인 Agent 혹은 Group Object.

4.1.2.1 When the Actor ObjectType is Agent

Description Agent(개인)은 인물 또는 시스템이다.

Details

Agent는 반드시 Inverse Functional Identifier 네 가지 유형(4.1.2.3 Inverse Functional Identifier 참고) 중 한 가지로 식별되어야 한다;
Agent는 절대로 두 개 이상의 Inverse Functional Identifier를 포함할 수 없다.
Agent는 그룹 식별자로 사용되는 Inverse Functional Identifier를 사용해서는 안 된다.

아래의 표는 Agent Object의 속성을 나타낸다.

Property	Type	Description	Required
objectType	string	“Agent”. Statement의 Object로 사용되는 경우 외에는 선택적으로 사용된다.	Optional
name	String	Agent의 전체 이름	Optional
4.1.2.3 Inverse Functional Identifier 참고		Agent에 고유한 Inverse Functional Identifier	Required

4.1.2.2 When the Actor ObjectType is Group

Description Group은 Agent의 집합을 나타내며, Agent가 사용되는 대부분의 상황에서 사용될 수 있다. anonymous/identified 두 가지 유형의 그룹이 존재한다.

Details Anonymous Group은 임시팀과 같이 클러스터에 대한 식별자가 없는 사람들의 클러스터를 설명하기 위하여 사용된다.

Anonymous Group의 속성은 아래의 표와 같이 나타낸다.

Property	Type	Description	Required
objectType	String	“Group”.	Required
name	String	Group의 이름	Optional
member	Array of Agent Objects	Group의 멤버	Required

Identified Group은 고유 Agent의 클러스터를 식별하기 위하여 사용된다.

아래의 표는 Identified Group의 속성을 나타낸다.

Property	Type	Description	Required
objectType	String	“Group”.	Required
name	String	Group의 이름.	Optional
member	Array of Agent Objects	Group의 멤버.	Optional
4.1.2.3 Inverse Functional Identifier 참조		Group에 고유한 Inverse Functional Identifier	Required

Requirements

Statement를 사용하는 시스템은 동일한 멤버구성을 가지는 경우에도 반드시 각 Anonymous Group을 구분해야 한다.
Statement를 사용하는 시스템은 절대로 ‘member’ 속성의 Agent가 주어진 anonymous/Identified Group의 Agent의 정확한 목록을 구성한다고 가정해서는 안 된다.

Requirements for Anonymous Groups

Anonymous Group은 반드시 구성 Agent를 나열하는 ‘member’ property를 포함해야한다.
Anonymous Group은 절대로 ‘member’ property에서 Group Object를 포함해서는 안된다.
Anonymous Group은 절대로 Inverse Functional Identifier를 포함해서는 안된다.

Requiremenhts for Identified Groups

Identified Group은 정확히 하나의 Inverse Functional Identifier를 반드시 포함해야한다.
Identified Group은 절대로 ‘member’ property에서 Group Object를 포함해서는 안된다.
Identified Group은 Agent 식별자로 사용되는 Inverse Functional Indentifier를 사용하지 않는다.
Identified Group은 구성 Agent를 나열하는 ‘member’ property를 포함할 수 있다.

4.1.2.3 Inverse Functional Identifier

Description “Inverse Functional Identifier”는 오직 하나의 Agent 혹은 Identified Group로의 대응이 보장되는 Agent/Identified Group의 값이다.

Rationale 학습경험은 식별 가능한 개인/그룹으로부터 나온 것이 아니면 의미가 없다고 여겨진다. xAPI Statement에서, 이는 널리 알려진 FOAF 원리를 느슨하게 따르는 Inverse Functional identifier의 집합으로 이루어진다. (Friend Of A Friend 참조: http://xmlns.com/foaf/spec/#term_Agent).

Details

아래의 표는 가능한 모든 Inverse Functional Identifier 속성을 나타낸다.

Property	Type	Description
mbox	mailto IRI	“mailto:email address” 형식이 요구된다. email 주소만이 Agent에 할당되며, 이 외에는 이 속성과 mbox_sha1sum에 사용될 수 없다.
mbox_sha1sum	String	malito IRI의 SHA1 해시(즉, mbox 속성의 값). LRS는 mbox에 기반한 요청이 발생하는 경우 해시와 일치하는 Agent를 포함할 수 있다.
openid	URI	고유 Agent를 식별하는 openID
account	Object	기존 시스템의 사용자 계정. 예) LMS 혹은 인트라넷.

4.1.2.4 Account Object

Description Private 시스템(LMS 혹은 인트라넷) 혹은 public system(social networking site)와 같은 기존 시스템에 존재하는 사용자 계정

Details

Account Object를 제공하는 시스템이 OpenId를 사용하는 경우, Activity Provider는 account Object 대신 openid property를 사용해야 한다.
Activity Provider에서 Agent 혹은 Group에 대한 개인 식별 정보 노출이 우려되는 경우, 익명성을 유지하면서 사람에 대한 모든 Statement를 식별하는 (ex: account number) 불투명한 계정 이름을 사용해야 한다.

아래의 표는 Account Object의 모든 속성을 나타낸다.

Property	Type	Description	Required
homePage	IRL	계정이 켜져있는 시스템의 정식 홈페이지로, FOAF의 accountServiceHomePage를 기반으로한다.	Required
name	String	계정에 로그인하기 위하여 사용되는 고유 id 혹은 이름으로, FOAF의 accountName을 기반으로한다.	Required

Example

다음 예시는 불투명한 계정에 의하여 식별되는 Agent를 나타낸다:

	{
	"objectType": "Agent",
	"account": {
	"homePage": "http://www.example.com",
	"name": "1625378"
	}

4.1.3 Verb

Description Actor와 Activity 사이의 동작을 정의한다.

Rationale xAPI Statement의 Verb는 학습 경험 동안 수행된 작업을 서술한다. xAPI는 특정한 Verb를 규정하지 않는다. (Verb ‘ http://adlnet.gov/expapi/verbs/voided‘는 예외이다). 대신, 어떻게 Verb를 생성하는지를 정의함으로서 연습용 커뮤니티를 통해 맴버들이 의미 있는 Verb를 생성하고, 누구나 사용할 수 있도록 한다. 사전 정의된 Verb의 목록은 정의에 의해 제한되며, 모든 가능한 학습 경험을 효과적으로 캡처하지 못할 수 있다.

Details Statement에서 Verb는 IRI와 사람이 읽을 수 있는 방언이나 다양한 언어에 해당되는 display name의 집합과 IRI로 구성된 Object로 나타난다. Verb Object의 모든 속성은 다음과 같다.

Property	Type	Description	Required
id	IRI	Verb의 정의에 해당된다. 각 Verb 정의는 단어가 아닌 Verb의 의미에 해당한다. IRI는 Verb의 의미를 포함하고, 사람이 읽을 수 있어야한다.	Required
display	Language Map	하나 이상의 언어에서 사람이 읽을 수 있는 Verb의 표현형식이다. Statement의 의미에 어떠한 영향도 미치지 않지만, 이미 선택된 Verb의 사람이 읽을 수 있는 표기(display)를 제공하는 역할을 한다.	Recommended

Requirements

display 속성은 반드시 Verb IRI에 의하여 이미 결정된 의미를 설명하기 위하여 사용되어야 한다.
Statement를 읽는 시스템은 반드시 의미를 추론하는 Verb IRI를 사용해야한다.
display 속성은 절대로 Verb의 의미를 변경하는데 사용되어서는 안된다.
Statement를 읽는 시스템은 절대로 Statement에서 어떠한 의미를 추론하기 위해 display 속성을 사용해서는 안된다.
Statement를 읽는 시스템은 절대로 사람에게 표시하는 목적 외에 display 속성을 사용해서는 안된다. Statement의 집계 및 분류를 위하여 display 속성을 사용하는 것은 이 요구사항을 위반한 경우의 한 예이다.
display 속성은 모든 Statement에서 사용되어야 한다.
id에 포함된 IRI는 사람이 읽을 수 있어야하며 Verb의 의미를 함축해야 한다.

Example 아래의 예시는 권장되는 필드 설정으로 구성된 Verb를 나타낸다.

{
	"id":"http://www.adlnet.gov/XAPIprofile/ran(travelled_a_distance)",
	"display":{
	"en-US":"ran",
	"es" : "corrio"
	}

위 예시는 Verb를 설명하기 위한 목적으로 표현되었다. 이는 이러한 의미를 가진 Verb가 이 id로 정의된다는 것을 의미하는 것은 아니다. 이는 사전 정의된 Verb ‘http://adlnet.gov/expapi/verbs/voided‘ 를 제외하고, 문서에서 주어진 모든 예시에 적용된다.

4.1.3.1 Use in Language and Semantics of Verbs

Details

Semantics Verb id로 표현한 IRI는 단어 자체가 아닌, 단어의 특정 의미를 식별한다. 예를 들어, 영어 단어 “fired”는 “fired a weapon”, “fired a kiln”, “fired an employee”와 같이 문맥에 따라 다른 의미를 가질 수 있다. 이러한 경우, IRI은 단어 “fired”가 아닌 규정된 의미 중 하나를 식별해야한다. display 속성은 시제에 약간의 유연성을 가지고 있다. 반면, Verb IRI는 과거 시제에 국한되며, Activity 내에서 다른 시제로의 접합Verb가 의미가 통하는 경우에는 허락된다.

Language Experience API의 Verb는 IRI이며 특정 언어에 연결되지 않는 명확한 의미를 나타낸다. 예를 들어, http://example.org/firearms#fire와 같이 특정한 Verb IRI는 총을 쏘는(fire) 동작을 나타내며 Verb IRI http://example.com/ ف عل/خواندن는 독서 동작을 나타낸다.

4.1.3.1 Use in Communities of Practice

Description 어떤 시점에서 Communities of practice는 그들의 constituency를 충족할 수 있는 새로운 Verb를 설정해야 한다. 따라서, xAPI communities of practice는 Verb 어휘를 중심으로 프로필, 목록 및 저장소를 생성할 것으로 예상된다. ADL은 ADL 커뮤니티를 제공하는 xAPI에 대한 Verb를 포함하는 안내서를 만드는 중이다. 아래 요구사항의 이행에서, 권장되는 Verb의 IRI 모음이 존재한다. Activity Provider가 동일한 의미를 가진 다른 Verb를 사용하고자 하는 몇 가지 경우가 존재한다.

Requirements for Communities of Practice

새로운 Verb를 설정하는 사람은 반드시 IRI를 소유하거나, xAPI Verb를 표시하기 위해 소유자로부터 사용 허가를 반드시 받아야 한다.
새로운 Verb를 설정하는 사람은 IRI에 접근할 수 있는 Verb의 용법에 대하여 사람이 읽을 수 있는 설명을 만들어야 한다.

Requirements for Activity Providers

Activity Provider는 가능하면 대응하는 기존의 Verb를 사용해야 한다.
Activity Provider는 적합한 Verb가 존재하지 않는 경우 Verb를 만들고 사용할 수도 있다.

4.1.4 Object

Description Statement의 Object는 Activity, Agent/Group, Sub-Statement, Statement Reference가 될 수 있다. 즉, Statement “I did this”의 “this” 부분이다.

예제:

Object가 Activity로 나타나는 경우: “Jeff wrote an essay about hiking.”
Object가 Agent로 나타나는 경우: “Nellie interviewed Jeff.”
Object가 Sub-Statement 혹은 Statement Reference로 나타나는 경우(사람이 읽기에 비슷하지만 다른 구현법): “Nellie commented on ‘Jeff wrote an essay about hiking.”

Details Objects가 필드의 값으로 제공되는 경우 “object Type”을 포함해야 한다. 지정되지 않는 경우, objectType은 “Activity”로 간주된다. 이 외에 유효한 값은 다음과 같다: Agent, Group, SubStatement or StatementRef. Object의 속성은 objectType에 따라 변경된다.

4.1.4.1 When the ObjectType is Activity

Details Statement는 Statement의 Object로서 Activity를 표현할 수도 있다. 다음의 표는 이러한 경우에 Object의 속성을 나타낸다.

Property	Type	Description	Required
objectType	String	현재 시제일 경우, 반드시 “Activity”로 표현되어야 한다.	Optional in all cases
id	IRI	하나의 특정한 Activity에 대한 식별자	Required
definition	Object	메타데이터, 아래를 참조하십시오.	Optional

두 가지 Activity에 대하여 같은 id를 사용하는 것이 가능하다면, Activity에 대한 Statement의 타당성에 의문이 제기 될 것이다. 이것은 LRS가 두 개의 다른 Activity가 같은 Activity id를 절대 취급(참조)하지 않음을 의미한다. 즉, 다른 시스템과의 충돌이 발생하는 경우, 그 의도를 결정할 수 없다.

Activity Definition 아래 주어진 표는 Activity Definition Object의 속성을 나타낸다:

Property	Type	Description	Required
name	Language Map	Activity의 human readable/시각적 이름	Recommended
description	Language Map	Activity에 대한 설명	Recommended
type	IRI	The type of Activity.	Recommended
moreInfo	IRL	Activity를 시작하는 방법 등 Activity에 대한 human-readable한 정보를 문서로 해결한다.	Optional
Interaction 속성, Interaction Activities 참조.
extensions	Object	필요한 다른 속성의 지도(Extensions 참고)	Optional

Note: (Relative IRL로도 불리는) IRI 구성요소는 유효한 IRI가 아니다. Verb와 마찬가지로 Activity Provider가 Activity 유형을 탐색, 수립, 사용하는 것이 권장된다.

Activity Id Requirements

Activity id는 반드시 유일해야 한다.
Activity id는 반드시 언제나 같은 Activity를 참조해야 한다.
Activity id는 제작자가 이러한 목적에 사용하도록 허가된 도메인을 사용해 야한다.
Activity id는 모든 Activity id가 도메인 안에서 유일하도록 보장하는 스키마에 따라 작성되어야 한다.
Activity id는 Activity에 대한 IRL이나 메타데이터를 가리킬 수 있다.

LRS Requirements

LRS는 여러 저자/조직에서 사용되는 activity id가 인식되는 경우, 절대로 작업을 수행하지 말아야 한다.
LRS는 하나의 id로 서로 다른 Activity를 참조하도록 취급해서는 안된다.
저장된 것과 다른 Activity Definition을 가지는 Statement를 수신하는 경우, LRS는 Activity Provider가 정의를 변경할 수 있는 권한을 가질지의 여부를 결정해야하며, 그 결정이 긍정적인 경우 저장된 Activity Definition을 업데이트 해야 한다.
LRS는 Activity의 정의에 따라 약간의 수정을 허용할 수도 있다. 예를 들어, 맞춤법 수정에는 동의할 수 있으나 응답을 수정하는 변경 사항을 적용하지 않을 수 있다.

Activity Provider Requirements

Activity Provider는 여러 Activity를 통하여 Activity id가 재사용되지 않도록 반드시 확인해야 한다.
Activity Provider는 반드시 같은 id에 대하여 이전에 저장된 state/statement에 대하여 일관되고 호환되는 특정한 Activity id에 대한 state/Statement를 생성해야 한다.
Activity Provider는 호환성을 깨는 Activity의 새로운 버전(개정 또는 다른 플랫폼)을 절대로 허용하지 말아야 한다.

Metadata Requirements

Activity IRI가 IRL일 경우, LRS는 해당 IRL을 GET 해야하며, HTTP header에 다음을 포함해야 한다: “Accept: application/json, /“. 이는 LRS가 Activity id를 만나는 즉시 수행되어야 한다.
Activity id로 사용된 IRL에서 유용한 Activity Definition을 나타내는 JSON을 로딩함과 동시에, LRS는 로드된 정의에 포함되지 않은 이름과 정의를 유지하면서, 로드된 정의와 해당 Activity의 내부 정의를 통합해야 한다.
IRL 식별자로 구성된 Activity는 “application/json”의 Content-Type의 형식인 Statement에 사용되는 Activity Definition JSON 포맷을 사용하여 메타데이터를 호스팅할 수도 있다.
LRS가 Activity id로 사용되는 IRL에서 Activity Definition을 구문분석할 수 있는 모든 문서를 로드하는 동안, LRS는 Activity 정의의 내부 표현을 결정할 때, 이를 고려할 수도 있다.

Interaction Activities Rationale 기존의 e-learning은 상호작용 혹은 평가에 대한 구조를 포함하고 있다. Experience API의 유틸리티를 확장하기 위하여 다음과 같은 practice와 구조가 허락되었다. 이 규격은 SCORM 2004 4th Edition Data Model에서 차용한 상호작용에 대한 기본 정의를 포함한다. 이러한 정의는 상호작용 데이터를 기록하기 위한 간단하고 친숙한 유틸리티를 제공하는 것을 목적으로 한다. 이는 사용이 간편하며 제한적이다. 풍부한 상호작용 정의를 요구하는 지식공동체가 Activity의 유형과 정의의 확장을 통해 이를 수행할 것으로 예상된다.

Details 아래의 표는 Interaction Activity에 대한 속성을 나타낸다.

Property	Type	Description	Required
interactionType	String	SCORM 2004 4th Edition Run-Time Environment에 정의된 “cmi.interactions.n.type”.	Optional
correctResponsesPattern	An array of strings	SCORM 2004 4th Edition Run-Time Environment에 정의된 “cmi.interactions.n.correct_responses.n.pattern”에 대응되며 마지막 n은 배열의 인텍스에 해당한다.	Optional
choices \| scale \| source \| target \| steps	Array of interaction components	주어진 interactionType에 명시 (아래를 참조).	Optional

A Note on Delimiters SCORM 2004 4th Edition Run-Time Environment은 특정 구분문자가 해당 문자열에 대한 특정 정보를 전달하는 문자열에 추가되는 것을 허락하고 있다. 이에 대한 내용은 section 4.1.1.6: Reserved Delimiters of that document and referenced throughout the RTE data model 에서 설명하고 있다. 이러한 구분문자는 “Section 4.2.9.1: Correct Responses Pattern Data Model Element Specifics of the SCORM 2004 4th ed. RTE.”에 정의된 몇 가지 유형의 상호작용에 대한 올바른 응답 패턴 안에서 사용될 수 있다. Section 4.1.1.6과 Section 4.2.9.1에서 서술하는 구분문자의 순서에 몇 가지 모순이 존재한다. Experience API의 목적을 위하여 Section 4.2.9.1에서 서술된 구분문자의 순서를 사용한다.

Requirements

Interaction Activity에는 반드시 유효한 interactionType이 존재해야한다.
Interaction Activity는 Activity type “http://adlnet.gov/expapi/activities/cmi.interaction"을 포함해야 한다.
LRS는 유효한 interactionType을 소모함과 동시에, 아래의 표에 지정된 나머지 속성들에 대한 유효성 검사를 실시할 수도 있고, 나머지 속성들이 Interaction Activity에 대하여 유효하지 않을 경우 HTTP 400 “Bad Request”를 리턴할 수도 있다.

Interaction Components

Details Interaction components는 다음과 같이 정의된다.:

Property	Type	Description	Required
id	String	SCORM 2004 4th Edition Run-Time Environment에서 정의된 바와 같이 “cmi.interactions.n.id”에 대한 practice에 사용되는 값	Required
description	Language Map	interaction compenet에 대한 설명(예: 객관식 interaction에서 주어진 선택을 위한 텍스트)	Optional

다음 표는 주어진 interactionType과 interaction Activity를 위한 CMI interaction component의 지원 목록을 보여준다.

interactionType	supported component list(s)
choice, sequencing	choices
likert	scale
matching	source, target
performance	steps
true-false, fill-in, long-fill-in, numeric, other	[No component lists defined]

Requirements

interaction component 배열 내의 모든 id 값은 반드시 고유한 값이어야 한다.
interaction component의 id 값에는 공백이 존재하지 않아야 한다.

Example 각 cmi.interaction type에 대한 Activity Definition의 예제는 부록 C를 참조하시오.

When the “Object” is an Agent or a Group

Requirements

Agent 혹은 Group을 지정하는 Statement는 Object로서 반드시 ‘objectType’ 속성을 명시해야 한다.

Agent에 대한 자세한 내용은 Section 4.1.2 Actor를 참조하시오.

When the “Object” is a Statement

Rationale Statement를 Object로서 사용하는 경우는 크게 두 가지로 나뉜다. 먼저, Object는 이미 Statement Reference를 사용하여 존재하는 Statement의 형태로 나타날 수 있다. 일반적으로 Statement Reference는 독립적인 이벤트로 사용될 수 있는 경험에 대하여 주석을 달거나 평가하기 위하여 주로 사용된다. 또한 Statement를 무효화하는 특별한 경우에도 Statement Reference가 사용될 수 있다. 두 번째로, Object는 Sub-Statement를 사용하여 새로운 Statement가 될 수 있다. 일반적으로 Sub-Statement는 자신의 Statement로 오해의 소지가 될 수 있는 경험에 사용된다. 각각에 대한 유형은 아래에 정의한다.

Statement References

Description Statement Reference란 이미 존재하는 Statement에 대한 포인터이다.

Requirements

Statement Reference는 반드시 “StatementRef” 값으로 “objectType” 속성을 명시해야한다.
Statement Reference는 반드시 Statement의 UUID에 “id” 속성을 설정해야한다. LRS가 UUID와 존재하는 Statement가 유효한지를 확인하기 위한 요구사항은 존재하지 않는다.

다음 표는 Statement Reference Obejct에 대한 모든 속성을 나타낸다:

Property	Type	Description	Required
objectType	String	이 경우, 반드시 “StatementRef”	Required
id	UUID	Statement의 UUID	Required

Example 어떠한 Statement가 이미 8f87ccde-bb56-4c2e-ab83-44982ef22df0의 id 값을 가지고 되어있다고 가정하자. 다음의 예는 새로운 Statement를 사용하여 기존의 Statement에 어떻게 주석을 추가할 수 있는지에 대하여 나타내고 있다:

	{
	"actor" : {
	"objectType": "Agent",
	"mbox":"mailto:test@example.com"
	},
	"verb" :
	{
	"id":"http://example.com/commented",
	"display": {
	"en-US":"commented"
	}
	},
	"object" : {
	"objectType":"StatementRef",
	"id":"8f87ccde-bb56-4c2e-ab83-44982ef22df0"
	},
	"result" : {
	"response" :
	"Wow, nice work!"
	}

Sub-Statements

Description Sub-Statement는 상위 Statement의 부분을 포함한 새로운 Statement이다.

Requirements

Sub-Statement는 반드시 “SubStatement” 값으로 “objectType” 속성을 명시해야한다.
Sub-Statement는 반드시 Sub-Statement의 필수요건들 외에도, Statement로서 유효해야 한다.
Sub-Statement는 절대로 “id”, “stored”, “version”, “authority” 속성을 가질 수 없다.
Sub-Statement는 절대로 자신의 Sub-Statement를 포함해서는 안된다. 즉, 중첩할 수 없다.

Example Sub-Statement를 사용하는 흥미로운 방법은 intention의 Statement를 생성하는 것이다.

예를 들어, 어떤 행동을 계획했음을 나타내는 “<I> <planned> (<I> <did> <this>)” 와 같은 형식의 Statement를 생성하기 위하여 Sub-Statement를 사용할 수 있다. 다음에 서술되어 있는 구체적인 예시는 논리적으로 “I planned to visit ‘Some Awesome Website”를 나타낸다.

{
	"actor": {
	"objectType": "Agent",
	"mbox":"mailto:test@example.com"
	},
	"verb" : {
	"id":"http://example.com/planned",
	"display":{
	"en-US":"planned"
	}
	},
	"object": {
	"objectType": "SubStatement",
	"actor" : {
	"objectType": "Agent",
	"mbox":"mailto:test@example.com"
	},
	"verb" : {
	"id":"http://example.com/visited",
	"display":{
	"en-US":"will visit"
	}
	},
	"object": {
	"id":"http://example.com/website",
	"definition": {
	"name" : {
	"en-US":"Some Awesome Website"
	}
	}
	}
	}

4.1.5 Result

Description 해당 Statement에 관한 측정 결과를 표현하는 선택적 필드.

Details 다음 표는 Result object에 대한 속성을 나타낸다.

Property	Type	Description	Required
score	Object	경험의 품질 혹은 성공과 관련된 Agent의 점수. Score 참고	Optional
success	Boolean	Activity에 대한 시도가 성공했는지의 여부를 나타낸다.	Optional
completion	Boolean	Activity가 완료되었는지의 여부를 나타낸다.	Optional
response	String	해당 Activity에 대한 적절한 응답 포맷	Optional
duration	0.01 초의 정밀도로 ISO 8601에 따른 형식	Statement가 발생한 이후의 기간	Optional
extensions	Object	필요한 다른 속성의 지도. Extensions 참조	Optional

4.1.5.1 Score

Description Agent에 의하여 성취한 Activity의 등급을 표시하는 선택적인 필드.

Details 아래의 표에서 Score Object에 대하여 정의한다.

Property	Type	Description	Required
scaled	-1부터 1까지의 10진수	Cf. ‘cmi.score.scaled’ in SCORM 2004 4th Edition	Recommended
raw	min부터 max까지의 10진수(존재하지 않는 경우 제한 없음)	Cf. ‘cmi.score.raw’	Optional
min	(존재하는 경우)max보다 작은 10진수	Cf. ‘cmi.score.min’	Optional
max	(존재하는 경우)min보다 큰 10진수	Cf. ‘cmi.score.max’	Optional

Requirements

점수에 기반한 논리적 백분율을 알고있는 경우, Score Object는 ‘scaled’를 포함해야한다.
Score Object는 진행 또는 완료에 관한 점수에 사용되어서는 안된다. 대신에 extension profile에서 extension을 사용하는 방법이 권장된다.

4.1.6 Context

Description Statement에 컨텍스트 정보를 추가할 수 있는 장소를 제공하는 선택적 필드로서, 모든 속성은 선택 사항이다.

Rationale “context” 필드는 Statement에 몇 가지 컨텍스트 정보를 추가할 수 있는 장소를 제공한다. experience가 팀 활동의 일부로서 발생하거나, 혹은 어떤 넓은 활동에 맞는 experience인 경우에 이러한 experience에 대한 지침으로서 정보를 저장할 수 있다.

Details 다음의 표는 Context Object의 속성에 대하여 서술한다.

Property	Type	Description	Required
registration	UUID	Statement와 관련된 기록	optional
instructor	Agent (may be a Group)	Statement의 Actor로서 포함되지 않은 경우 Statement와 관련된 Instructor	optional
team	Group	Statement의 Actor로서 포함되지 않은 경우 Statement와 관련된 Team	optional
contextActivities	contextActivities Object	해당 Statement가 연관된 learning activity context 종류. 유효한 context 유형은 다음과 같다: “parent”, “grouping”, “category”, “other”.	optional
revision	String	Statement과 연관된 학습 활동의 수정사항으로 자유로운 형식으로 서술.	optional
platform	String	해당 학습활동의 experience에서 사용되는 플랫폼	optional
language	String (as defined in RFC 5646)	적용가능하고 알려진 경우, 해당 Statement에서 (주로) 발생한 experience가 기록되는 언어를 나타내는 코드	optional
statement	Statement Reference	해당 Statement의 콘텍스트로 간주되어야하는 또 다른 Statement	optional
extensions	Object	해당 Statement와 관련된 다른 도메인 한정 콘텍스트. 예를 들어, 비행 시뮬레이터의 고도, 대기 속도, 바람, 비행 자세, GPS 좌표는 모두 연관되어 있을 수 있다. (Extensions 참조)	optional

Requirements

Revision property는 반드시 Statement의 Object가 Activity인 경우에만 사용되어야 한다.
Platform property는 반드시 Statement의 Object가 Activity인 경우에만 사용되어야 한다.
Language property는 해당되지않거나 알려지지 않은 경우 절대로 사용할 수 없다.
Revision property는 (맞춤법 오류 등) 사소한 문제의 수정을 추적하는데 사용되어야 한다.
Activity의 learning objective, pedagogy, asset에 주요한 변화가 발생하는 경우 사용해서는 안 된다. (대신 새로운 Activity id를 사용한다.)

Note: xAPI의 범위에서 수정은 의미가 없다. 이는 레포팅 도구로서 사용할 수 있도록 간단하게 저장된다.

4.1.6.1 Registration Property

Description 특정 학습 활동을 수행중인 학습자의 인스턴스

Details LRS가 LMS의 필수적인 부분인 경우, LMS는 등록의 개념을 지원할 수 있다. Experience API는 보다 광범위하게 등록의 개념을 적용한다. 등록은 시도, 세션으로 간주될 수 있으며, 여러 Activity에 걸쳐있을 수 있다. Activity 완료시 등록이 종료된다는 것을 보장할 수 없으며, 반드시 하나의 Agent에 국한되어 등록된다는 것 또한 보장되지 않는다.

4.1.6.2 ContextActivities Property

Description 해당 Statement가 관련되는 학습 활동 컨텍스트의 유형의 맵.

Rationale 많은 Statement는 초점을 맞추고 있는 하나의 Object Activity뿐만 아니라, 문맥적으로 관련이 있는 다른 Activity들을 포함한다. “Context Activities”는 이러한 관련 Activity들을 구조화된 방식으로 표현할 수 있도록 허용한다.

Details 4가지 콘텍스트 유형이 존재한다. 주어진 Statement에서 이들을 모두 사용하거나, 일부를 사용하거나, 아무것도 사용하지 않을 수 있다:

Parent: Activity와 직접적인 관계가 있는 Statement의 Object로 대부분의 경우 하나의 Parent가 존재하거나 없을 수 있다. 복수로는 존재하지 않는다. 예: Quiz question에 대한 Statement는 부모 Activity로서 quiz를 가지고 있다.
Grouping: Activity와 간접적인 관계가 있는 Statement의 Object이다. 예: 코스는 자격의 일부이며, 코스는 여러 클래스로 이루어져있다. 코스는 클래스의 부모이며, 자격은 그룹화된 클래스와 관계가 있다.
Category: Statement를 분류하는데 사용되는 “Tags”는 동의어가 될 것이다. Category는 xAPI의 동작에 대한 “profile” 뿐만 아니라 다른 범주화를 가리키기 위하여 사용된다. 예: Anna가 생물학시험을 시도하고, Statement는 CMI-5 프로파일을 사용하여 추적된다. Statement의 Activity는 시험을 의미하며, 카테고리는 CMI-5 파일을 가리킨다.
Other: 하나의 필드에 적합하지 않은 context Activity. 예: Anna는 생물학 시험을 위한 교재를 공부한다. Statement의 Activity는 교재를 의미하며, 시험은 context Activity의 “other” type에 해당한다.

0.95 Statement는 1.0.0과 호환될 수 있도록 단일 Activity Object는 값으로 사용될 수 있다. Note: 이 섹션의 값은 Statement Object가 가진 모든 관계를 표현할 수 없다. 대신 (Object의 특성이 종종 그 결정에 중요하게 작용할지라도)특정 Statement에 대한 적절한 관계를 표현하기 위하여 사용된다. 예를 들어, 테스트는 부모로서의 한 부분으로, 코스를 포함하는 테스트에 대한 Statement로서 적절하지만, 그룹화 값의 일부가 될 수 있는 모든 가능한 학위 수여 프로그램을 포함할 수는 없다.

Requirements

contextActivity Object의 모든 key는 반드시 parent, grouping, category, other 중 하나여야 한다.
contextActivity Object의 모든 value는 반드시 단일 Activity Object 혹은 Activity Object의 배열이어야 한다.
LRS는 단일 Activity Object로 도달한다 할지라도 반드시 배열로서 contextActivity Object의 모든 값을 반환해야 한다.
LRS는 반드시 같은 Activity를 포함하는 배열의 길이로서 하나의 Activity Object를 반환해야 한다.
Client는 contextActivity Object 내의 모든 값이 단일 Activity Object 대신 Activity Object의 배열로 구성되어 있는지 확인해야 한다.

Example 다음과 같은 계층 구조에 대하여 생각해보자: “Questions 1 to 6”은 “Test 1”에, “Test 1”은 “Algebra 1” 코스에 차례로 속한다. “Test 1”을 Question 1 to 6의 부모로 선언하고 테스트의 한 부분으로 등록한다. 또한 계층 구조를 완전히 반영하는 “Algebra 1”에 대한 Statement로 그룹화된다. 이는 Statement의 Object가 Agent인 경우 특히 유용하며, Activity인 경우 그렇지 않다. “Andrew mentored Ben with context Algebra I”

	{
	"parent" : [
	{"id" : "http://example.adlnet.gov/xapi/example/test1"}
	],
	"grouping" : [
	{"id" : "http://example.adlnet.gov/xapi/example/Algebra1"}
	]

4.1.7 Timestamp

Description experience가 발생한 시간

Details Statement의 timestamp는 Stored(statement가 저장된 시간)와 다를 수 있다. 즉, experience의 발생과 LRS에 의한 Statement의 수신 사이에 지연이 있을 수 있다. 일정 시간 동안 experience가 발생한 경우, timestamp는 시작과 끝, 혹은 experience 동안의 어떠한 시점을 나타낼 수 있다. Community of practice는 다른 experience에 대한 timestamp를 기록할 적절한 시점을 정의할 것이다. 예를 들어, 레스토랑에서의 식사에 대한 experience를 기록하는 경우, 시작시간의 stamptime을 기록하는 것이 가장 적절할 것이다; 자격 만료에 대한 experience를 기록하는 경우는 종료시간의 stamptime을 기록하는 것이 가장 적절할 것이다. 이러한 예제는 예시의 용도로만 사용되며 반드시 이처럼 규정되는 것은 아니다.

Requirements

Timestamp는 반드시 ISO 8601의 형식에 따라야 한다.
Timestamp는 시간대를 포함해야 한다.
하위 Statement를 제외하고 timestamp는 현재 혹은 과거의 시간이어야 한다.
Timestamp는 일정 기간동안 발생한 experience 내의 어떠한 순간을 나타낼 수도 있다.
Timestamp는 적어도 3자리의 초를 나타낼 수 있는 정밀도로 반올림 혹은 내림할 수도 있다. (millisecond의 정밀도가 반드시 유지되어야 한다.)
Timestamp는 계획된 학습의 기한을 표시하기 위하여 하위 Statement의 내부에 포함되어 제공됨으로서 미래의 순간을 나타낼 수도 있다.

4.1.8 Stored

Description LRS에 의하여 Statement가 저장된 시간. stored 속성은 문자그대로 Statement가 저장된 시간이다. Statement가 발생한 시간을 기록하기 위해서는 Timestamp가 사용된다.

Requirements

Stored 속성은 반드시 ISO 8601의 형식에 따라야한다.
Stored 속성은 시간대를 포함해야한다.
Stored 속성은 현재 혹은 과거의 시간이어야 한다.
Stored 는 적어도 3자리의 초를 나타낼 수 있는 정밀도로 반올림 혹은 내림할 수도 있다. (millisecond의 정밀도는 반드시 유지되어야 한다.)

4.1.9 Authority

Description Authority 속성은 Statement가 사실이라고 assert한 사람/개체가 무엇인지에 대한 정보를 제공한다.

Details Asserting authority는 인증된 사용자/시스템/어플리케이션을 나타낸다.

Requirements

Authority는 반드시 3자 인증(3-legged OAuth)을 제외한 Agent여야하며, 반드시 두 Agent와 함께 Group을 구성해야한다. 두 Agent는 어플리케이션과 사용자를 나타낸다.
사용자가 (HTTP 기본 인증을 사용하여) 직접적으로 혹은 Group의 일부로서 포함되어 연결되는 경우, LRS는 반드시 전체 권한을 가진 Agent로서 사용자를 포함해야 한다.
LRS는 반드시 모든 Statement가 authority를 저장하고 있는지 확인해야 한다.
LRS는 모든 수신되어 저장된 Statement의 authority를 그 Statement가 전송되는데 사용된 자격으로 덮어쓰기 해야 한다.
LRS는 authority가 변경되지 않은 채로 남길 수 있지만, 강한 신뢰 관계가 확립된 경우에 한하여 극도로 조심히 행해야한다.
사용자가 (HTTP 기본 인증을 사용하여) 직접 혹은 3자 인증(3-legged OAuth)의 일부로서 연결하는 경우, LRS는 적합한 식별 속성과 사용자를 동일시한다.

OAuth Credentials as Authority

Description OAuth를 사용하기 위한 워크플로우로 2-legged와 3-legged OAuth를 모두 지원한다.

Details 이 워크플로우는 Statement가 검증도니 OAuth 연결을 사용하여 저장되었으며, LRS는 Statement의 authority 속성을 생성 및 수정한다고 가정한다. 3-legged OAuth 워크플로우에서 인증은 OAuth 사용자와 OAuth 서비스 제공자의 사용자를 모두 포함한다. 예를 들어, 인증된 트위터 플러그인을 통한 페이스북 계정으로의 요청은 클라이언트 어플리케이션으로서의 트위터, 사용자로서의 그들의 자격뿐만 아니라 그들의 고유한 조합으로 규정된 자격 증명을 포함한다.

Requirements

Authority는 반드시 그들 자신 혹은 3-legged OAuth의 경우 그룹의 일부로서 OAuth 소비자를 나타내는 Agent Object를 포함해야 한다.
OAuth 소비자를 나타내는 Agent는 반드시 계정에 의하여 식별되어야 한다.
OAuth 소비자를 나타내는 Agent는 반드시 “account name” 필드로 소비자 키를 사용해야 한다.
OAuth 소비자를 나타내는 Agent가 등록된 어플리케이션인 경우, token request endpoint는 반드시 계정 홈페이지로 사용되어야 한다.
OAuth 소비자를 나타내는 Agent가 등록되지 않은 어플리케이션인 경우, 반드시 일시적으로 증명된 endpoint가 계정 홈페이지로 사용되어야 한다.
계정 이름이 등록되지 않은 어플리케이션과 동일한 경우, LRS는 authority의 어플리케이션 부분을 절대로 신뢰해서는 안된다.(여러 개의 등록되지 않은 어플리케이션이 같은 소비자 키를 사용할 수 있다. 결과적으로, 임시로 발급된 증명과 계정 이름의 조합을 확인하기 위한 일관된 방법이 존재하지 않는다.)
등록되지 않은 각각의 소비자는 고유 소비자 키를 사용해야 한다.

Example OAuth 소비자와 사용자의 쌍

"authority":
	{
	"objectType" : "Group",
	"member": [
	{
	"account": {
	"homePage":"http://example.com/xAPI/OAuth/Token",
	"name":"oauth_consumer_x75db"
	}
	},
	{
	"mbox":"mailto:bob@example.com"
	}
	]

4.1.10 Version

Description Statement의 Version 정보는 LRS 데이터 처리 시스템이 그들의 방위를 얻을 수 있도록 돕는다. Statement 데이터 모델은 LRS 간의 데이터 흐름을 지원하기 위하여 모든 1.0.x 버전을 통하여 일관성이 보장된다. LRS는 허용하는 Statement version에 따라 몇 가지 유연성이 부여된다.

Requirements

Version은 반드시 API Versioning의 API version header의 형식을 따라야한다.

LRS Requirements

LRS는 반드시 version이 “0.”으로 시작하는 모든 Statement를 허용해야하며, 그렇지 않은 경우 유효성을 검사한다.
LRS는 반드시 version이 “0.”으로 시작하지 않는 모든 Statement를 거부해야한다.
LRS에 의하여 반환된 Statement는 반드시 허용된 version을 유지해야한다. version이 존재하지 않는 경우, version은 반드시0.0으로 설정된다.

Client Requirements

클라이언트가 Statement version을 설정하는 경우, 반드시0.0으로 설정해야한다.
클라이언트는 Statement version을 설정해서는 안된다.

4.1.11 Attachments

Description Learning experience의 증거를 제공하는 디지털 아티팩트.

Rationale 몇몇 경우에 attachment는 논리적으로 학습기록의 중요한 부분이 될 수 있다. ATC, 에세이, 비디오 등을 이용한 모의 커뮤니케이션을 생각할 수 있다. experience의 결과로 부여된 인증서(의 이미지)는 이러한 attachment의 또 다른 예이다. 이는 attachment를 저장하고, LRS에서 이를 검색하는 경우 유용하게 사용된다. 하위 Statement에 대한 attachment를 포함하고 싶은 경우, Statement의 attachment 필드에 attachment를 포함하고, 일반적으로 Statement에 포함되는 페이로드를 포함할 것을 강력하게 권고한다.

Details 아래의 표는 Attachment Object에 대한 모든 속성을 나타낸다.

Property	Type	Description	Required
usageType	IRI	해당 attachment의 사용을 식별한다. 예를 들어, attachment를 사용하는 한 예로, “완료 인증서”를 포함하는 방법이 존재한다. 이러한 용도로 사용되는 IRI 유형의 경우, 완료 인증서와 함께 만들어지고, 사용되어야한다.	Required
display	Language Map	해당 attachment의 표시 이름(제목)	Required
description	Language Map	attachment에 대한 설명/td>	Optional
contentType	Internet Media Type	attachment의 콘텐츠 타입	Required
length	Integer	octet에 포함된 데이터의 길이	Required
sha2	String	Attachment 데이터의 SHA-2 (SHA-256, SHA-384, SHA-512) 해시. SHA-224는 사용할 수 없다: 최소 256비트의 키 사이즈를 권장한다.	Required
fileUrl	IRL	Attachment 데이터가 검색되거나, 이를 사용하여 검색 가능한 IRL.	Optional

Procedure for the exchange of attachments

attachment를 포함하는 Statement는 다음에 서술된 Transmission Format에 따라 해석된다.
Statement는 “multipart/mixed” Content-Type을 사용하여 수신시스템으로 전송된다. attachment는 이러한 전송의 끝부분에 위치한다.
Statement의 첫 부분에 있는 정보를 기반으로 수신시스템은 Statement의 승인여부를 결정한다.
attachment가 승인되는 경우, 원시 데이터의 SHA-2와 헤더에 선언된 SHA-2를 비교하여 원시데이터의 attachment와 attachment 헤더를 매치시킨다. 이 외의 방법은 절대로 수행할 수 없다.

Requirements for Attachment Statement Batches A Statement batch, Statement results, attachment를 포함하는 단일 Statement는 반드시 다음 조건 중 하나를 만족해야 한다:

attachment 필터가 거짓인 Statement result의 경우를 제외하고, 반드시 모든 attachment에 대하여 fileUrl을 포함하며 “application/json” 유형이어야 한다.
RFC 1341과 다음 서술된 조건과의 혼합/다중의 정의에 부합해야한다:
다중 부분 문서의 첫 부분은 반드시 “application/json” 유형의 Statement 자신을 포함해야한다.
각 추가적인 부분은 attachment에 대한 raw 데이터를 포함하며, Statement의 논리적 부분을 형성한다. Statement 자원에 대한 PUT/POST를 수행하는 경우 이러한 기능을 사용할 수 있다.
(Statement의) 첫 부분의 이후에 반드시 각 부분의 헤더에 X-Experience-API-Hash 필드를 포함해야한다.
이 필드는 반드시 해당 부분을 포함하는 attachment에 대응하는 attachment 선언의 “sha2” 속성과 일치하도록 설정해야한다.
(Statement의) 첫 부분 이후에 반드시 각 부분의 헤더에 반드시 “binary” 값을 가지는 Content-Transfer-Encoding 필드를 포함해야한다.
같은 attachment가 함께 전송되는 여러 Statement에 사용되는 경우에한하여, attachment 데이터의 복사본을 포함해야한다.
각 부분의 헤더에 Content-type 필드를 포함해야하는 경우, 첫 부분은 반드시 “application/json”이어야한다.

LRS Requirements

Client의 요청이 존재하는 경우, LRS는 반드시 위에서 설명한 Transmission Format의 attachment를 포함해야 한다. (Section 7.2 “Statement API” 참조).
LRS는 attachment의 요청이 없는 경우, 절대로 Statement를 다른 LRS로부터 pull 할 수 없다.
LRS는 수신된 attachment 데이터를 포함하지 않고 다른 LRS로 Statement를 push할 수 없으며, push하는 경우, attachment에 대하여 진행된다.
“application/json” 타입의 문서에 대한 PUT/POST를 수신하는 경우, LRS는 반드시 attachment Object를 포함하지 않는 Statement의 배치를 승인해야한다.
“application/json” 타입의 문서에 대한 PUT/POST를 수신하는 경우, LRS는 반드시 지정된 fileUrl을 가지는 attachment Object를 포함하는 Statement의 배치를 승인해야한다.
“multipart/mixed” 타입의 문서에 대한 PUT/POST를 수신하는 경우, LRS는 반드시 위에서 설명한 Transmission Format의 attachment를 포함하는 Statement의 배치를 승인해야한다.
“multipart/mixed” 타입의 문서에 대한 PUT/POST를 수신하는 경우, LRS는 반드시 fileUrl과 자신의 해시를 기반으로 수신된 attachment 부분 모두를 포함하지 않는 Statement의 배치를 기각해야한다.
“multipart/mixed” 타입의 문서에 대한 PUT/POST를 수신하는 경우, LRS는 attachment 부분을 Content-Transfer-Encoding의 binary라고 가정해야한다.
LRS는 LRS가 허용하도록 구성된 것보다 더 큰 (배치의) Statement를 기각할 수 있다.

Note: mime/multipart 형식을 사용하는 Statement 배치가 attachment를 포함할 필요는 없다.

Client Requirements

위에서 서술한 바와 같이, Client는 attachment가 포함된 Statement를 전송할 수 도 있다.
“POST”를 사용하는 경우, Client는 일부 또는 전부에 attachment가 포함된 다중 Statement를 전송할 수도 있다.
모든 attachment Object가 “multipart/mixed” 형식을 기반으로 모든 요구사항을 무시하는 fileUrl을 포함하고 있는 경우, Client는 “application/json” 형식의 배치를 전송할 수도 있다.

Example Attachment를 포함하는 Statement의 간단한 예제가 아래에 제시되어 있다. 다음과 같은 사항에 유의하라:

샘플의 경계는 유효한 문자 클래스를 보여주기 위하여 선택되었다;
선택된 경계는 어떠한 부분에도 나타나지 않는다;
가독성을 위하여 attachment 샘플은 taxt/plain으로 구성되어있다. 인코딩을 수행하지 않은 ‘image/jpeg’와 같이 ‘binary’ 유형이라 할지라도, 원시 octet은 포함된다;
RFC 1341에 따라, 경계는 <CRLF> 를 따른다 — 헤더에 선언된 경계 문자열을 따른다.

메시지를 빌딩/파싱하는 경우 <CRLF>를 기억하라.

Headers:

Content-Type: multipart/mixed; boundary=abcABC0123'()+_,-./:=?X-Experience-API-Version:1.0.0

Content:

--abcABC0123'()+_,-./:=?Content-Type:application/json {
	"actor": {
	"mbox": "mailto:sample.agent@example.com",
	"name": "Sample Agent",
	"objectType": "Agent"
	},
	"verb": {
	"id": "http://adlnet.gov/expapi/verbs/answered",
	"display": {
	"en-US": "answered"
	}
	},
	"object": {
	"id": "http://www.example.com/tincan/activities/multipart",
	"objectType": "Activity",
	"definition": {
	"name": {
	"en-US": "Multi Part Activity"
	},
	"description": {
	"en-US": "Multi Part Activity Description"
	}
	}
	},
	"attachments": [
	{
	"usageType": "http://example.com/attachment-usage/test",
	"display": {
	"en-US": "A test attachment"
	},
	"description": {
	"en-US": "A test attachment (description)"
	},
	"contentType": "text/plain; charset=ascii",
	"length": 27,
	"sha2": "495395e777cd98da653df9615d09c0fd6bb2f8d4788394cd53c56a3bfdcd848a"
	}
	]
	}
	--abcABC0123'()+_,-./:=?Content-Type:text/plainContent-Transfer-Encoding:binaryX-Experience-API-Hash:495395e777cd98da653df9615d09c0fd6bb2f8d4788394cd53c56a3bfdcd848a here is a simple attachment--abcABC0123'()+_,-./:=?--

4.1.12 Data Constraints

Details Statement에 사용된 모든 속성은 특정 유형으로 제한되며, 그 유형은 Statement 처리 시스템의 동작을 제한한다. 명확하게 하기 위하여, 특정한 주요 요구사항은 호환 시스템이 특정 방식으로 수행되어야 함을 강조하며, 아래에 자세히 서술되어있다.

Client Requirements 다음의 요구사항은 이를 강조 및 명확화하고 구현 지침을 제공하기 위하여 다른 곳에 이미 포함된 주요한 요구사항을 반복한다. 전체 IRI의 유효성 검사는 극도로 힘든 작업이며, 클라이언트에게 데이터의 이식성을 보장하기 위한 부담이 너무 크다.

IRI를 요구하는 value는 반드시 유효한 IRI와 함께 전송해야 한다.
비슷한 이유로, language map의 key는 반드시 유효한 RFC 5646 language 태그로 전송되어야 한다.
문자열 접합과 달리, library는 IRI를 구성하는데 사용되어야 한다.

LRS Requirements

LRS는 반드시 다음과 같은 Statement를 기각해야 한다:
- (inside extension 외에) null 값을 가지고 있는 경우.
- number 값이 요구되는 자리에 (string이 number를 포함하더라도) string 값이 포함되어 있는 경우.
- boolean 값이 요구되는 자리에 (string이 boolean을 포함하더라도) string 값이 포함되어 있는 경우.
- (mailto IRI, UUID, or IRI와 같이)특정한 형식이 요구되는 string의 자리에 어떠한 형식도 따르지 않는 key/value(empty string을 포함).
- key가 표준에서 규정한 경우와 일치하지 않는 경우.
- 열거값으로 규정된 value의 경우에 주어진 표준과 정확하게 일치하지 않는 경우.
LRS는 반드시 스키마 없이 IRL, IRI, IRI 값이 포함된 Statement를 기각해야한다.
LRS는 반드시 적어도 언어 맵 키에 대한 토큰 길이의 시퀀스가 RFC 5646 표준과 일치하는지 확인해야 한다.
LRS는 반드시 적어도 IEEE 754 32비트 부동소수점의 정밀도로 수를 처리하고 저장해야 한다.
LRS는 반드시 Statement의 동일한 유형의 값에 대하여 요구되는 동일한 기준에 파라미터 값이 유효한지 확인해야 한다. Note: JSON에서 문자열 파라미터 값은 사용되지 않는다.
LRS는 형식을 따르지 않는 기각 요구사항을 충족하기 위해 IRL, IRI, IRI 형식에 대하여 최적의 유효성검사를 실시할 수 있다.
LRS는 형식을 따르지 않는 기각 요구사항을 충족하기 위해 language map key에 대하여 최적의 유효성검사를 실시할 수 있다.

4.2 Retrieval of Statements

Description Statements의 컬렉션은 “Statements” endpoint에 Query를 수행하여 검색할 수 있다. 자세한 사항은 섹션 7.2 “Statement API”를 확인하라.

Details 다음 표는 Statement API의 Query 결과의 데이터 구조를 나타낸다.

Property	Type	Description	Required
statements	Array of Statements	Statements의 List. 만약 반환된 리스트가 (paginate로 인하여) 제한되어 있고, 더 많은 결과가 있는 경우 이 Statement result Object의 “more” Element가 제공하는 IRL 내 컨테이너의 “statements” Property 내에 위치한다.	Required
more	IRL	Relative IRL은 추가 결과를 받아오는 데 사용되는데, 결과에는 전체 경로가 포함되고 선택적으로 scheme, host, port가 제외된 쿼리문이 포함될 수 있다. 만약 더 받아 올 결과가 없다면 빈 문자열이다. 이 IRL은 LRS에 의해 반환된 이후 최소 24시간은 사용할 수 있어야 한다. 이러한 IRL들과 쿼리 데이터를 저장하는 상황을 방지하기 위해서는, LRS가 IRL이 계속해서 Query할 수 있는 필요 정보를 전부 포함하고 있어야 하지만, 매우 긴 IRLs를 생성하는 것은 피해야 한다. The Consumer는 반환된 IRL에서 어떤 meaning이라도 interpret해선 안된다.	결과가 제한적(Limited) 이라면 Required, 그렇지 않다면 Optional

Requirements

more property에 의해 반환된 IRL은 반드시(MUST) LRS에 의해 반환된 후 24시간동안 사용할 수 있어야 한다.
LRS는 IRLS와 연관된 Statements의 데이터를 저장할 필요성을 피하기 위해 Query를 계속하기 위한 정보들을 포함할 수도 있다.
LRS는 more property 내에서 매우 긴 IRLs를 생성해서는 안 된다.
Consumer는 more property에서 반환된 IRL에서 어떤 의미를 해석하려고 시도해서는 안 된다.

4.3 Voided

Rationale LRS가 정확하고 collection of data를 완료하는 것은 Statements가 논리적으로 변경되거나 삭제될 수 없다는 사실에 의해 보장된다. 이러한 Statements의 불변성은 Experience API의 분산 특성을 가능하게 만드는 핵심 요소이다. 그러나, 모든 Statements가 발행된 후 영구적으로 유효하지는 않다. 실수 혹은 다른 요소들로 인하여 Statements가 유효하지 않게 될 수 있는데, 이를 “voiding a Statement”라 칭하고, reserved된 Verb인 “http://adinet.gov/expapi/verbs/voided“를 사용한다. 다른 statement를 void한 statement는 스스로 void될 수 없다.

Requirements

다른 Statement를 무효화하는 statement를 발행했을 때, 무효화하는 Statement의 Object는 반드시 “StatementRef”에 “objectType” 필드 세트를 갖고 있어야 한다..
다른 Statement를 무효화하는 statement를 발행했을 때, 무효화하는 Statement의 Object는 반드시 무효화 되는 statement(statement-to-be-voided)의 id를 id 필드에 갖고 있어야 한다.
다른 Statement를 무효화하는 statement를 수신했을 때, LRS는 HTTP 403 ‘Forbidden’을 포함하고, source authorized to void Statement가 아닌 전체 요청을 거절해야 한다.
다른 Statement를 무효화하는 statement를 수신했을 때, LRS는 대상 Statement를 찾지 못했을 경우 descriptive error를 반환하여야 한다.
다른 Statement를 무효화하는 statement를 수신했을 때, LRS는 무효화된 Statement에 의해 도입된(introduced) Activity나 Agent를 롤백할 수도 있다.
이전에 Void된 statement를 “Unvoid”하고 싶은 Activity Provider는 해당 Statement를 새 id로 다시 발행해야 한다.
Reporting System은 기본적으로 void되거나 void하는 Statements를 보여서는 안 된다.

Note: 다른 Statements에 대한 references를 만드는 법에 대해서는 Section 4.1.4.3 When the “Object” is a Statement 내의 “Statement References”를 참조하고, 무효화된 Statements가 query될 때 어떻게 되는 지는 7.2 Statement API의 StatementRef를 참조하라.

Example 해당 예제는 Statement id “e05aa883-acaf-40ad-bf54-02c8ce485fb0”를 갖는 Statement를 무효화한다.

{
	"actor" : {
	"objectType": "Agent",
	"name" : "Example Admin",
	"mbox" : "mailto:admin@example.adlnet.gov"
	},
	"verb" : {
	"id":"http://adlnet.gov/expapi/verbs/voided",
	"display":{
	"en-US":"voided"
	}
	},
	"object" : {
	"objectType":"StatementRef",
	"id" : "e05aa883-acaf-40ad-bf54-02c8ce485fb0"
	}

4.4 Signed Statements

Description Statement는 더 강하고 튼튼한 무결성과 신뢰성을 제공하기 위해 문 안에 디지털 서명 을 포함할 수 있다.

Rationale 일부 Statement는 규정(regulatory)이나 법적 의미(legal significance), 또는 신뢰성과 무결성에 대한 강하고 확실한 증거가 필요하다. 이러한 증거는 statement가 원래 작성된 시스템에 대한 신뢰나 시스템에 대한 접속 없이도 Statement를 검증할 때 필요하다. 디지털 서명은 서드 파티 시스템이 statements를 인증할 수 있게 한다.

Details 서명된 Statements는 JSON web signature(JWS)를 포함한다. 이로 인해, Statement의 original serialization이 서명과 함께 포함될 수 있다. 상호 운용성을 위해 JWS 알고리즘의 “RSA + SHA” 시리즈가 선택되었으며, 검색성을 위해 서명자의 X.509 인증서가 사용되어야 한다(SHOULD).

Requirements

서명된 Statement는 반드시 “http://tools.ietf.org/html/draft-ietf-jose-json-web-signature" 에 정의된 JWS로 정의되어야 하고, usageType이 “http://adlnet.gov/expapi/attachments/signature“ 이고 contentType이 “application/octet-stream” 인 attachment여야 한다.
JWS signature는 반드시 signature가 추가되기 전 생성된 Statement의 유효한 JSON serialization의 payload를 갖고 있어야 한다.
JWS signature는 반드시 “RS256”,”RS384”, 또는 “RS512”의 알고리즘을 사용하여야 한다.
JWS signature는509 인증서와 연결된 개인 키에 기초하여(based) 생성되어야 한다(SHOULD).
509가 sign에 사용되었다면, JWS 헤더는 관련된 인증 체인에 “x5c” property를 포함하여야 한다.
LRS는 반드시 HTTP 400이 포함된 잘못된 signature를 거절해야 한다.
LRS는 signature가 well formed인지 검증하기 위해 rejected statement의 response 안에 메세지를 포함해야 한다. LRS는 반드시 다음 행동들을 수행해야 한다.
JWS signature를 Decode하고, JWS signature payload에서 Statement의 signed serialization을 불러온다.
수신된 Statement가 원본 statement와 논리적으로 일치하는지 확인한다.
논리적 동등함을 검사할 때, “id”, “authority”, “stored”, “timestamp” 또는 “version”로 인한 차이 또는 LRS processing의 필요(required)는 반드시 무시된다.
JWS 헤더가509 인증서를 포함하는 경우 JWS에 정의된 대로 해당 인증서의 signature를 확인한다.
클라이언트는 LRS가 허용했기 때문에 signature가 유효할 것이라 가정해선 절대로 안 된다.

Note: X.509 인증서가 포함된 Statement의 검증)은 보안 측정이 아닌 signature의 실수를 바로잡으려는 단계이다. 서명된 statement를 인증하는 단계는 무결성 요구의 정도와 해당 명세의 범위 바깥에 있는지에 따라 달라진다.

예제 Appendix E: Example Signed Statement 참조.

5.0 Miscellaneous Types

5.1 Document

Description Experience API는 Activity Providers가 독단적으로 Activity, Agent, 혹은 두 가지의 조합과 관련된 documents의 형태로 임의의 데이터를 저장할 수 있게 하는 기능을 제공한다.

Details 다음 표는 해당 명세의 다른 많은 표에서 보이는 것과는 달리 JSON Object가 아니라 일반적인 property이다. id는 IRL에 저장되어 있고, “updated”는 HTTP 헤더 정보이며, “contents”는 객체가 아닌 HTTP document 그 자체이다.

Property	Type	Description
id	String	AP에 의해 설정됨, agent나 activity 범위 내에서 유일함(unique).
updated	Timestamp	해당 문서가 최근 언제 수정되었는지
contents	Arbitrary binary data	document의 내용

5.2 Language Map

Description Language map은 키가 RFC 5646 Language Tag이고 값이 태그의 language specified인 사전이다. 이 맵은 다른 언어로 해당 문자열의 지식을 바탕으로 완전히 가능한 한 채워야한다.

5.3 Extensions

Description Extensions는 Activity Definitions의 일부, Statement context의 일부, 혹은 Statement result의 일부로써 사용 가능하다. 각각의 경우에 이들은 특정 방법에서 elements를 확장하기 위한 자연적인 방법을 제공하기 위해 의도되었다. 이러한 Extensions의 content는 단지 하나의 application에서만 가치 있을 수도 있지만, 업무 전체에서 사용되는 규칙으로 사용될 수도 있다.

Details Extensions는 map으로써, 그리고 현재 존재하는 statement 일부와의 논리적인 연결로써 정의된다. extension의 값은 어떤 JSON 값이나 데이터 구조일 수 있다. Statement context 안의 extensions는 core experience에게 context를 제공하는데 그것들은 결과로써 제공된 elements에게 관련된 어떤 것을 내놓는다. Activity에게 extensions는 application이나 community를 조작하기 위한 추가적인 정의와 관련된 정보를 제공한다. IRI 키 하위에 위치한 extension 값의 의미와 구조는 IRI을 조정하는 사람(person)에 의해 정의된다.

Requirements

extension map의 키는 반드시 IRIs여야 한다.
LRS는 반드시 extensions map의 값을 기초로 하는 Statement를 거절해선 안 된다.
Clients는 Experience API conformant tools의 상호 운용성의 이점을 위해 내장된 요소에 가능한 한 많은 정보를 매핑하기 위해 노력해야 한다.
모든 extension IRI는 컨트롤러를 가져야 한다.
IRL extension key의 컨트롤러는 IRL에서 IRL accessible에서 지원하는 extension의 의도하는 meaning에 대해 human-readble한 설명을 만들어야 한다.

Note: 스스로의 extensions에 의해 전적으로 정의된 statement는 다른 system이 이해할 수 없는 의미없는 statement가 된다.

5.4 Identifier Metadata

Description 추가 정보는 식별자에 대한 Statement에서 제공될 수 있다. 이것은 IRI에 대한 메타데이터가 해석할 필요 없이 표현될 수 있게 한다.

Details 해당 명세에서는 몇 가지 타입의 IRI 식별자가 존재한다.

Verb
Activity id
Activity type
extension key
attachment usage type

Activity ids의 supplying metadata에 대해서는 the Activity Definition Object를 참조 바람.

다른 모든 identifiers에 대한 supplying metadata는 아래의 format을 참조 바람.

Property	Type	Description	Required
name	Language Map	Human readable한 / visual name	Optional
description	Language Map	설명	Optional

전술한 바와 같이 해당 메타데이터가 제공되는 경우 이것은 이것이 설명하는 identifier에 관한 정보의 정규적인 출처이다. Verbs와 마찬가지로, Activity Provider는 Activity ID가 아닌 모든 유형의 IRI 식별자에 대해 확립되고 널리 채택 된 식별자를 찾아 사용하는 것이 좋다.

Requirements

Metadata는 identifier가 제공할 수도 있다.
Metadata가 제공됐다면 그 안에 name과 description은 포함되어야 한다.
위의 식별자 IRI들에 대해, IRI가 이 사양과 함께 사용하기 위해 만든 IRL 인 경우 해당 IRL의 컨트롤러는 IRL이 요청 될 때 해당 IRL에서 이 JSON 메타 데이터를 사용할 수 있도록 해야 하며 콘텐츠 유형으로 'application/json "이 요청된다.
Identifier가 이미 존재하는 경우 Activity Provider는 대응하는 기존 Identifier를 사용하여야 한다.
Activity Provider는 적절한 Identifier가 존재하지 않는 경우 자신의 Verbs를 만들어 사용할 수 있다.
번역의 경우처럼, 누락 된 세부 정보를 채우기 위해 다른 정보 소스를 사용하거나 제공되지 않거나 로드 할 수없는 경우에, 이 메타 데이터를 완전히 대신 사용할 수도 있다. 이 식별자는 식별자의 IRL에 저장된 다른 형식의 메타 데이터를 포함 할 수도 있다 (특히 해당 식별자가 이 사양과 함께 사용하도록 작성되지 않은 경우).

6.0 Run-time Communication

섹션 6과 7은 Experience API의 보다 더 기술적인 측면, 즉 Activity Provider와 LRS 사이에서 Statements가 전송되는 것을 어떻게 처리하는 가에 대한 자세한 사항들을 다룬다. 라이브러리들의 숫자는 명세의 해당 부분을 처리하는 기술범위(JavaScript 포함)에 대한 under development 이다. 그러므로 명세의 해당 부분에 대한 모든 세부사항을 완전히 이해하는 것은 콘텐츠 개발자들에게 필수적이지 않을 수 있다.

6.1 Encoding

Requirement

모든 문자열은 반드시 UTF-8 포맷으로 해석하고 인코딩해야 한다.

6.2 API Versioning

Rationale 명세의 미래 수정안들은 Statement에 속성들을 추가하는 것과 같은 변동 사항들을 소개할 수 있다. Statements를 검색하는 시스템들은 다른 버전의 Statements를 포함하는 응답을 받을 수 있다. 이러한 버전의 차이들이 정확히 처리되고, 부분적이거나 혼합된 LRS 버전 구현이 존재하는지 알아내기 위해 버전 헤더를 허용해야 한다. Semantic Versioning을 사용하면 사양 변경시의 호환성을 확실히 알기 위해 Client와 LRS들을 허용해야 한다.

Details 1.0.0부터 시작해서, xAPI는 Semantic Versioning 1.0.0.에 따라 versioning된다. Client로 부터의 모든 요청과 LRS로 부터의 모든 응답은 “X-Experience-API-Version”의 이름과 함께 HTTP 헤더와 값으로써의 버전을 포함한다. 예시: X-Experience-API-Version : 1.0.1

LRS Requirements

LRS는 반드시 모든 응답에 “X-Experience-API-Version” 헤더를 포함해야 한다.
LRS는 반드시 해당 헤더를 “0.1”로 설정해야 한다.
LRS는 반드시 “0”의 버전 헤더가 포함된 요청을 버전 헤더가 “1.0.0”인 것처럼 받아들여야 한다.
LRS는 반드시 “0.0” 이전 버전 헤더를 포함하는 request들이 헤더에서 명시된 이전 버전과 완전히 일치하는 버전 구현으로 라우팅 되지 않는 한 거부해야 한다.
LRS는 반드시 “1.0” 혹은 그 이상의 버전 헤더를 포함하는 요청은 거부해야 한다.
LRS는 반드시 이러한 거부들이 문제에 대한 짧은 설명을 포함하는 HTTP 400 에러 응답에 의해 생성되어야 한다.

Client Requirements

Client는 반드시 모든 응답안에 “X-Experience-API-Version” 헤더를 포함해야 한다.
Client는 반드시 해당 헤더를 “0.1”로 설정해야 한다.
Client는 “0.0” 혹은 그 이후의 버전을 포함하는 응답들을 받는 것을 용인해야 한다.
Client는 추가적인 사항들을 포함하는 데이터 구조들을 받는 것을 용인해야 한다.
Client는0.0 버전에서 정의되지 않은 사항들은 무시해야 한다.

Conversion Requirements

시스템들은 절대로 새 버전의 Statements를 이전 버전의 형식으로 변환(예를 들어, 버전의 차이를 처리하기 위해)해서는 안된다.
시스템들은 Appendix D: Converting Statements to 1.0.0에서 서술된 방식을 따르는 것에 한해서 이전 버전의 Statements를 새 버전으로 변환 할 수도 있다.

6.3 Concurrency

Description 동시실행 제어는 API 소비자가 오래된 데이터에 기반한 변동사항들을 LRS로 PUT 하지 않도록 확실하게 하는 것이다.

Details xAPI는 PUT이 이미 존재하는 데이터를 덮어쓰기 할 수 있는 아래와 같은 API 부분의 동시실행 제어를 구현하기 위해 HTTP 1.1 개체 태그(ETag)들을 사용할 수 있다.

State API
Agent Profile API
Activity Profile API

State API는 상태 충돌 가능성이 있기 때문에 동시실행 헤더가 없는 PUT 요청을 허용할 수 있다. 아래의 요구사항들은 오직 Agent Profile API와 Activity Profile API를 지원한다.

Client Requirements

Client는 If-Match 헤더 혹은 If-None-Match 헤더를 반드시 포함하는 Agent Profile API 혹은 Activity Profile API 중 하나를 사용한다.

LRS Requirements

GET 요청을 위한 LRS 응답은 반드시 ETag HTTP 헤더를 응답에 추가해야한다. (LRS ETag 포맷 명세를 위한 이유는 스스로 계산하는것을 읽지 못하는 API 소비자들을 허용하기 위해서 이다.)
GET 요청을 위한 LRS 응답은 반드시 콘텐츠 SHA-1 다이제스트의 16진법 문자열이 되기 위해 해당 헤더의 값을 계산해야 한다.
GET 요청을 위한 LRS 응답은 반드시 헤더를 quotes로 감싸야 한다.
소비자가 마지막으로 문서를 불러온 후에 변동사항을 감지하기 위한 ETag를 HTTP 1.1이 포함한다면 PUT 요청을 위한 LRS 응답은 반드시 If-Match 헤더를 RFC2616로 서술된대로 처리해야 한다.
소비자를 알 수 없는 자원의 존재를 감지하기 위해 HTTP 1.1이 “*“를 포함한다면 PUT 요청을 위한 LRS 응답은 반드시 If-None-Match 헤더를 처리해야 한다.

위 PUT 요청 사례 중 하나에서 헤더 전제 조건이 실패하면, LRS는:

반드시 HTTP 상태로 412 “Precondition Failed”를 반환해야 한다.
반드시 자원으로의 변환을 생성하지 말아야 한다.

이미 존재하는 리소스에 대한 헤더없이 PUT 요청을 받으면, LRS는:

반드시 HTTP 상태로 409 “Conflict”를 반환해야 한다.
반드시 본문에 대해 설명하는 평문을 반환해야한다. 소비자는 아래의 행위를 해야 한다.
- 자원의 현재 상태를 검사한다.
- 충돌 해결을 위한 현재 ETag를 포함하는 “If-Match” 헤더를 설정한다.
반드시 자원으로의 변환을 생성하지 말아야 한다.

6.4 Security

Rationale 상호운용성의 균형과 다른 환경들의 보안 요구사항 다양성을 위해, 몇가지 인증 선택이 정의된다.

Details 아래의 표는 가능한 인증 시나리오들을 설명한다. 등록된 어플리케이션은 LRS로 등록된 OAuth 소비자로서 LRS를 통해 인증하는 어플리케이션이다. 알려진 사용자는 LRS 상 혹은 LRS가 신뢰하는 시스템 상에서의 사용자 계정이다.

	알려진 사용자	알려지지 않은 사용자
등록된 어플리케이션	OAuth를 위한 표준 워크플로우	LRS는 어플리케이션이 추가적인 사용자 자격증명 없이 xAPI에 접근하는 것을 신뢰한다. OAuth 토큰 단계들은 불리지 않는다.
등록되지 않은 어플리케이션	어플리케이션 Agent는 등록된 Agent로 정의되지 않고 LRS는 신원상에서 가정을 생성할 수 없다.
비 어플리케이션	비 어플리케이션이 연결될 때 까지는, OAuth 대신 HTTP Basic Authentication이 사용된다.
비 인증	테스트가 목적일 경우에는, LRS에 의한 지원이 가능 할 수 있다.

Requirements LRS는 반드시 다음과 같은 방법들 중 최소한 하나를 이용한 인증을 지원해야 한다:

“HMAC-SHA1”, “RSA-SHA1”, “PLAINTEXT”의 서명 방법들을 이용한 OAuth 1.0 (RFC 5849),
HTTP Basic Authentication
Common Access Cards (최신 버전의 상세를 따르는 구현)
LRS는 반드시 Statements의 validity 상에서 생성 혹은 할당, 판단과 자격증명 사용에 기반하여 수행될 수 있는 실행들을 결정하는 것을 처리해야 한다.

6.4.1 Process of Each Scenario

Requirements

LRS는 반드시 어플리케이션의 이름과 유일한 소비자 키(식별자)를 기록해야 한다.
LRS는 반드시 해당 등록을 완료하는 매커니즘 혹은 다른 시스템으로 할당하는 것과 유사한 매커니즘을 제공해야 한다.
LRS는 반드시 다음과 같은 xAPI의 지원을 완료하기 위한 설정이 가능해야 한다:
- 아래의 방식들 중 하나라도 포함해야 한다.
- 아래의 시나리오들의 워크플로우 중 하나안에서 이루어져야 한다.
LRS는 (보안의 이유에서) 다음과 같이 할 수 있다.
- 아래의 방법들중 하위 집합을 지원 할 수 있다.
- 등록된 어플리케이션 혹은 알려진 사용자를 제한 할 수 있다.
LRS는 “HMAC-SHA1”와 “RSA-SHA1” 서명을 이용한 OAuth를 최소한으로 지원해야 한다.

Application registered + known user Process and Requirements

섹션4.2 OAuth Authorization Scope에서는 표준 OAuth 워크플로우(해당 명세에서의 세부사항이 아닌)를 완료하기 위해 endpoints를 사용한다.
만약 인증의 이 형식이 Statements를 기록하는데 사용되고 명시된 권한이 없다면, LRS는 등록된 어플리케이션을 표현하는 Agent와 알려진 사용자를 표현하는 Agent를 구성하는 그룹으로서의 권한을 기록해야 한다.

Application registered + user unknown Process and Requirements

등록된 어플리케이션의 자격증명을 포함하고 빈 토큰과 token secret을 포함하는 OAuth를 이용하여 서명된 요청을 받아들인다.
만약 이 자격증명의 형식이 Statements를 기록하고 권한 없음으로 명시되는데 사용된다면, LRS는 등록된 어플리케이션을 표현하는 Agent로써 권한을 기록해야 한다.

Application not registered + known user Process and Requirements

빈 consumer secret을 사용한다.
“Temporary Credential” 요청을 부른다.
“consumer_name”과 다른 보통의 파라미터들을 명시한다; 그러면 사용자는 “consumer_name”와 더해서 인증될 수 없는 허가를 요청하는 어플리케이션의 identity 경고를 보게 될 것이다.
OAuth가 어플리케이션을 명시한 후부터, LRS는 반드시 그룹으로서 어플리케이션과 증명된 사용자 둘다 포함하는 권한을 기록해야 한다.

No application + known user Process and Requirements

LRS 로그인에 해당하는 username/password의 조합을 이용한다.
로그인에 의해 식별되는 Agent처럼 기록되기 위한 권한, 다음을 제외하고...
- 다른 권한이 명시됨, 그리고...
- LRS는 알려진 사용자를 이 권한으로 명시하는 것을 신뢰한다.

No authorization Process and Requirements

HTTP Basic Authentication 시험에서 주어져야하는 요청으로부터 온 명백하게 허가되지 않은 요청을 구별하기 위해서, 요청은 빈 username과 password에 기반하는 HTTP Basic Authentication를 위한 헤더를 포함해야한다.

6.4.2 OAuth Authorization Scope

Description 다음은 LRS와 어플리케이션의 통신에서 xAPI를 사용하여 오용의 가능성을 최소화 하면서 어플리케이션이 필요로 하면서 달성하고자하는 접근 레벨을 협상하기 위해 xAPI를 사용한 어플리케이션의 통신과 LRS를 인가해야 하는 범위를 위한 권장사항들이다. 각 범위의 제한들은 요청과 관련된 사용자 계정위에 놓여진 어떤 보안 제한을 추가한다.

Details 아래 표 목록은 xAPI 범위 값이다:

Scope	Permission
statements/write	아무 Statement 쓰기
statements/read/mine	“me”로 Statement 쓰여진 읽기, 만약 현재 토큰으로 Statement를 쓰기를 실행한다면 이것은 LRS가 할당할 수 있는 권한 매칭과 함께한다.
statements/read	read any Statement
state	상태 데이터 읽기/쓰기, 제한된 Activities와 Actors는 현재 토큰으로 이 관계를 결정하는 것이 가능한 extent에 관련된다.
define	Activities와 Actors (재)정의하기. 이것이 허락되지 않았을 때 만약 Statement를 저장한다면, ids는 저장될 것이고 LRS는 검사목적을 위해 원본 Statement를 저장할 수 있다. 하지만 그 어떤 Actors나 Activities의 내부의 표현은 갱신하지 말아야 한다.
profile	profile 데이터 읽기/쓰기, 제한된 Activities와 Actors는 현재 토큰으로 이 관계를 결정하는 것이 가능한 extent에 관련된다.
all/read	제한없는 읽기 접근
all	제한없는 접근

OAuth Extended Parameters “consumer_name”과 “scope” 파라미터가 OAuth 1.0의 부분이 아닌 것에 주목하라, 그러므로 만약 조회 문자열 혹은 파라미터 형식으로서 통과되어야 한다면 OAuth 헤더가 아니다.

OAuth Endpoints

Name	Endpoint	Example
Temporary Credential Request	OAuth/initiate	http://example.com/xAPI/OAuth/initiate
Resource Owner Authorization	OAuth/authorize	http://example.com/xAPI/OAuth/authorize
Token Request	OAuth/token	http://example.com/xAPI/OAuth/token

Example Scope의 목록은 요청되는 중인 권한들을 결정한다. 예를 들어, 지시자는 “statements/read”를 도구로서 승인할 수 있다. 하지만 LRS는 그것의 직접적인 자격증명으로 LRS에 질의할 때 지시자가 읽을 수 있는 Statements의 도구를 여전히 제한한다. (Statements가 그것의 학생들에게 관계되는 것처럼)

Requirements

LRS는 반드시 OAuth 2.0에서 정의된 scope 파라미터를 받아들여야 한다.
만약 명시된 범위가 없다면 LRS는 반드시 “statements/write”와 “statements/read/mine”의 scope 요청을 가정해야 한다.
LRS는 반드시 최소한으로 “all”의 범위를 지원해야 한다.
LRS는 다른 범위들을 지원 할 수도 있다.
승인될 요청들의 가능성을 올리기 위해, Client는 최소한으로 요구되는 범위들만 요청해야 한다.

7.0 Data Transfer (REST)

Description 이 섹션에서는 xAPI가 4개의 sub-API(Statement, State, Agent, Activity Profile)로 이루어져 있다는 것을 설명한다. Experience API의 이 네 가지 subAPI들은 RESTful HTTP 메서드에 의해서 처리된다. Statement API는 learning records 를 추적하는 데에 스스로를 이용할 수 있다.

주의: 설명서에 주어진 모든 예시 endpoints안의, “http://example.com/xAPI/” 는 LRS의 예시 base endpoint이다. 이 뒤의 다른 모든 IRI syntax는 특정한 endpoint의 사용을 나타낸다.

Requirements

이 표준에서 반드시 그들의 의도된 문맥 안에서 LRS가 인정하지 않는 어떤 파라미터를 사용하는 모든 API들에 대한 요구는 LRS가 반드시 HTTP 400 Bad Request 상태로 거부해야 한다. (주의: LRSs는 이 표준에 없는 파라미터들에 대해 인식하고 행동할 수도 있다.).
LRS는 반드시 여기에 설명돼있는 파라미터들과 케이스만 다르고 실질적으로 같은 파라미터들을 사용하는 모든 API들로부터 오는 request를 HTTP 400 Bad Request 상태로 거부해야 한다.
LRS는 반드시 어떤 batch가 거절되는 statement에서 그 statement의 batch를 거부해야 한다.

7.1 Error Codes

Description 아래에 있는 목록은 API안의 다양한 method 에서 반환할 수 있는 HTTP 오류 코드 에 대한 일반적인 지침을 제공한다.

Details

400 Bad Request - 타당하지 않거나 없는 argument에 의해 발생된 오류 상황을 나타낸다.
401 Unauthorized - 인증이 필요하거나 인증이 request에 post되었는데 주어진 자격이 거절됐을 경우를 나타낸다.
403 Forbidden - request가 주어진 자격에 대해 공인(승인)되지 않았다는 것을 나타낸다. 이것은 주어진 자격을 거절하는 것과는 다르다는 것을 주의하라. 이 경우는, 자격은 입증이 돼있었지만 인증된 클라이언트가 해당 action을 수행하는 것이 허가되지 않은 것이다.
404 Not Found - 요구된 자원을 찾을 수 없다는 것을 나타낸다. 예를 들면 어떤 State혹은 Agent Profile, 특정한 문서를 타겟으로 하는 Acitivity Profile API call이나 단일 statement를 받아오는 메서드와 같이, 특별히 식별된 자원을 반환 하는 어떤 method에 의해 반환 됐을 수 있다.
409 Conflict - State API, Agent Profile혹은 Activity Profile API나 PUT, POST call 상태에 있는 등, 현재 리소스 상태와의 충돌에 의한 에러 상황을 나타낸다. 자세한 내용은3 Concurrency 에 나와있다.
412 Precondition Failed - request와 post된 사전 조건 달성 실패로 인한 오류 상황을 나타낸다. State 혹은 Agent Profile이나 Activity Profile API call등의 경우에 나올 수 있다. 자세한 내용은3 Concurrency 에 나와있다.
413 Request Entity Too Large - LRS가 해당 Statement 혹은 document의 용량이 LRS에 허용된 크기보다 더 커서 거절한 경우를 나타낸다. LRS는 어떤 제한을 고르는 것도 자유이고 아무 기준(예를 들면 권한에 따라)을 토대로 이 제한을 바꾸어도 되지만 반드시 어떤 사이즈의 statement들도 받아들일 수 있도록 설정할 수 있어야 한다.
500 Internal Server Error - 일반적인 오류 상황, 특히 서버 동작 중 예측하지 못한 예외를 나타낸다.

Requirements

LRS는 반드시 위의 목록에 있는 에러 상황에 적합한 에러 코드를 반환해야 한다.
LRS는 에러의 원인을 설명하는 메시지를 response에 반환해야 한다.

7.2 Statement API

Description Experience API의 기본 통신 매커니즘

7.2.1 PUT Statements

Details Example endpoint: http://example.com/xAPI/statements 주어진 id로 statement를 저장한다. 리턴 값: 204 No Content

Parameter	Type	Default	Description	Required
statementId	문자열		저장될 statement 의 Id	Required

Requirements

LRS는 반드시 이미 존재하는 statementID를 가진 statement의 수신을 기반으로 state를 수정해서는 안 된다. 대신 409 Conflict나 204 No Content 오류코드로 응답해야 하고, LRS는 반드시 statement나 다른 Object를 변경해서는 안 된다.
LRS가 이미 다른 Statement를 가진 id의 Statement를 받으면 수신한 Statement와 맞는 것이 있는지 확인하고 없으면 409 Conflict 오류코드를 반환해야 한다.
LRS는 검색에 사용 가능한 이미 저장된 Statements 전에 응답을 할 수도 있다.

7.3.3 POST Statements

Details Example endpoint: http://example.com/xAPI/statements Statement, 혹은 Statements 집합을 저장한다. PUT method는 특정한 Statement id를 타겟으로하기 때문에 여러 개의 Statements를 저장하거나 Statement id를 처음으로 생성하지 않는 하나의 Statement를 저장할 때는 PUT이 아니고 POST가 반드시 쓰여야 한다. 대용량의 Statements를 생성하는 시스템에 대한 대안은 AP상에 API의 LRS 사이드를 제공하고, LRS가 그 API에 새로 만들어졌거나 갱신된 Statements 목록을 주기적으로 조회하게 하는 것이다. 이것은 LRS에 많은 양의 데이터를 제공하는 시스템에 한해서만 실질적인 옵션일 것이다. 리턴 값: 200 OK, Statement id(s) (UUID).

Requirements

LRS는 반드시 이미 존재하는 statementID를 가진 statement의 수신을 기반으로 state를 수정해서는 안 된다. 대신 409 Conflict 나 200 OK 오류코드로 응답해야 하고, LRS는 반드시 statement나 다른 Object를 변경해서는 안 된다.
LRS가 이미 다른 Statement를 가진 id의 Statement를 받으면 수신한 Statement와 맞는 것이 있는지 확인하고 없으면 409 Conflict 오류코드를 반환해야 한다.
LRS는 검색에 사용 가능한 이미 저장된 Statements 전에 응답을 할 수도 있다.
GET Statements는 POST를 사용해서 불러와야 하고, 쿼리 문자열에 제한이 있기 때문에 필요하면 필드를 형성해야 한다. 자세한 내용은 Section 7.8 Cross Origin Requests를 참조하라.
LRS는 반드시 통과된 파라미터들을 기반으로 Statement를 추가하는 POST와 Statements를 나열하는 POST를 구분해야 한다. 자세한 내용은 See Section 7.8 Cross Origin Requests를 참조하라.

7.2.3 GET Statements

Details Example endpoint: http://example.com/xAPI/statements 이 method는 하나 혹은 여러 개의 Statement를 불러올 때 쓰인다. 만약 statementID 혹은 voidedStatementID 파라미터가 구체적으로 명시돼있다면 단일 Statement가 반환된다. 다른 경우에는: A StatementResult Object, 저장된 시간, 승인의 주체, 그리고 목록의 최대 길이를 기준으로 역순으로 나열된 Statement가 반환된다. 만약 추가적인 결과가 가능하면, 그것을 검색하기 위한 IRL은 StatementResult 객체에 포함될 것이다. 리턴 값: 200 OK, Statement or Statement Result (See Section 4.2 for details)

Parameter	Type	Default	Description	Required
statementId	String		불러낼 Statement의 ID	Optional
voidedStatementId	String		불러낼 Voided Statement 의 ID. Voided Statements 참고	Optional
agent	Agent 혹은 식별된 그룹 객체 (JSON)		식별된 Agent 혹은 그룹이 Actor 이거나 Statement의 객체일 경우에만 Statements를 반환하는 필터. • 각 객체에 대해 같은 Inverse Functional 식별자가 쓰였고 그 Inverse Functional 식별자들이 같은 값을 가질 때 Agents 혹은 식별된 그룹이 같다고 한다. • 이 필터의 목적을 위해, 위에 설명 한대로 그들의 Inverse Functional 식별자를 기준으로 특정한 Agent에 상응하는 멤버들을 가진 그룹은 똑같은 것으로 간주된다. 자세한 것은 agent/group 참고	Optional
Verb	Verb id (IRI)		특정한 verb id에 맞는 Statements만 반환하는 필터	Optional
Activity	Activity id (IRI)		Statement의 객체가 특정한 아이디를 가진 Activity 인 경우에만 Statements를 반환하는 필터.	Optional
registration	UUID		특정 등록 번호(아이디)에 부합하는 statement만 반환하는 필터. 한 activity에 할당된 한 Actor를 위해 특정한 등록 아이디가 자주 쓰일 것이라고 해도 그것은 가정돼서는 안 된다. 만약 특정 Actor나 Activity에 대한 statement만 반환된다 하더라도 그 파라미터들 또한 구분돼야 한다.	Optional
related_activities	Boolean	False	Activity 필터를 광범위하게 적용. Context Acitivies 혹은 서브 statement에 포함된 속성들 중 어떤 오브젝트가 그 파라미터의 평범한 행동 대신에 Activity 파라미터에 대응하는 statement를 포함한다. 대응은 ‘activity’ 파라미터에 대한 방법과 같은 방법으로 정의된다.	Optional
related_agents	Boolean	False	Agent 필터를 광범위 하게 적용. Actor, Object, Authority, Instructor, Team, 혹은 포함된 서브 statement의 특성들 중 어떤 것이, 그 파라미터의 일반적인 행동 대신, Agent 파라미터와 대응하는 Statement를 포함한다. 대응은 ‘agent’ 파라미터에 대한 방법과 같은 방법으로 정이 된다.	Optional
since	Timestamp		특정 timestamp 이후에 저장된 statement 들만 반환된다.	Optional
until	Timestamp		특정 timestamp 이전에 저장된 statement만 반환된다.	Optional
limit	음이 아닌 정수	0	Statement의 최대 개수가 반환된다. 0은 서버가 허용하는 최댓값 Maximum 반환을 의미한다.	Optional
format	String: (“ids”, “exact”, or “canonical”)	exact	”ids”이면, Agent, Activity 그리고 집단 Object가 그들을 구분하는 데에 필요한 최소한의 정보를 포함한다. 익명 그룹에서 이것은 각각의 멤버를 구분하는 데에 필요한 최소한의 정보를 포함한다는 것을 의미한다. “exact” 이면, 정확히 statement가 도착했을 때 첨부된 Agent, Activity 그리고 그룹 Object가 반환된다. 그들을 불러오기 위해 쓰이는 LRS requesting statement 는 “exact” 포맷을 써야 한다. “canonical” 이면, 아래에 정의된 언어 필터링 과정을 적용한 뒤에 LRS에 의해 정해진 Activity Objects의 표준적 정의로 populate된 Activity Objects를 반환하고 Agent Objects를 “exact” 모드로 반환한다. Canonical Language Process: Activity Objects 는 이름과 설명을 위한 언어 지도 Objects를 가지고 있다. 하나의 지도에 대해서 하나의 언어만 반환돼야 한다. “canonical”이 되는 format의 이벤트 에서는, 이 지도들 각각에 대해 하나의 언어만 반환돼야 한다. 가장 적절한 언어를 고르기 위해서, LRS는 Accept-Language header 를 적용할 것이다. 단, 포함될 언어 항목을 고르기 위해 자원(statements의 리스트) 전체가 아니라 언어 지도 각각에 대해 이 로직을 적용한다는 점은 다르다. Accept-Language header 참고. RFC 2616	Optional
attachments	Boolean	False	true 일 경우, LRS는 복수 응답 포맷을 사용하고 이전에 설명한 것 처럼 모든 attachments를 포함한다. false인 경우, LRS는 Content-Type 어플리케이션/제이슨으로 정의된 응답을 보내고, attachments를 사용할 수 없다.	Optional
ascending	Boolean	False	true의 경우, 저장된 시간의 오름차순으로 결과를 반환한다.	Optional

Requirements

LRS는 반드시 HTTP 400 에러로 statementId 와 voidedStatementId 파라미터들을 둘 다 가지고 있는 리소스에 대한 어떤 요구도 거부해야 한다.
LRS는 반드시 HTTP 400 에러로 statementId 혹은 voidedStatementId 파라미터들을 가지고 있고 또한 attachments 혹은 format을 제외한 다른 파라미터를 가지고 있는 리소스에 대한 어떤 요구들도 거절해야한다.
LRS는 반드시 "저장된 "속성을 갖거나 갖게 될 모든 Statement의 검색에 사용할 수 있는 확실한 timestamp와 함께 ISO8601 통합 날짜와 시간 형식에 대한 모든 응답을 헤더의 ”X-Experience-API-Consistent-Through“에 포함해야 한다. 이 시간은 과도한 로드와 같은 일시적인 조건을 고려해야하며, 이는 Statement이 검색에 지연되는 원인이 될 수 있다.
GET statement 의 attachment 속성이 사용됐고 “true”로 설정돼 있다면 LRS는 반드시 다수의 응답 포맷을 사용하고1.11에 나와 있는 대로 모든 attachment를 포함해야 한다.
GET statement 의 attachment 속성이 사용됐고 “false”로 설정 돼있다면 LRS는 반드시 attachment raw 데이터를 포함해서는 안되며, application/json 을 보고해야 한다.

Filter Conditions for StatementRefs 시간이나 순서 기반이 아닌 필터 파라미터들(다시 말해, since, until, limit가 아닌 파라미터들)에 대해, 타겟이 되는 Statement가 그 필터 조건을 만족하면 StatementRef를 Statement의 오브젝트로 사용해서 다른 Statement를 타겟으로 하는 Statements또한 그 필터 조건을 만족할 것이다. 시간이나 순서 기반의 파라미터들 또한 반드시 이런 방식으로 StatementRef를 만들어 Statement에 적용돼야만 한다. 이 규칙은 반복적으로 적용되고, 그래서 ‘a’ 가, ‘c’를 타겟으로 삼는 ‘b’를 타겟으로 삼을 때, “Statement c” 가 위에 설명된 필터 조건들을 만족할 때 “Statement a” 또한 조건들을 만족한다. 예를 들어, “Ben passed explosives training” 라는 Statement를 생각해보자. 그리고 Statement: “Andrew confirmed “를 덧붙여 보자. 추가된 Statement는 “Ben”이나 “explosives training”에 대해 언급하지 않을 것이다. 하지만 “Ben” 에 대한 Actor 필터나 “explosives training” Activity 필터를 통해 Statement를 불러올 때 그들이 불러오는 순서나 시간으로 나뉘면 두 Statements가 모두 필터 조건에 대응하고 반환될 것이다. 이 섹션은 Statementf 를 statementId 나 voidedStatementId로 검색할 때에는 적용하지 않는다. 주의: 문맥 안의 statement field에서 사용되는 StatementRefs 은 Statements가 걸러지는 방법에 영향을 끼치지 않는다.

7.2.4 Voided Statements

Requirements

LRS는 반드시 voidedStatementId로 요구되지 않은 이상, 어떤 비어버린(has been voided)Statement도 반환해서는 안 된다.
LRS는 반드시 명시적이거나 암시적인, 시간 혹은 순서 기반의 검색을 이용해 Statements를 검색할 때 비워진(voided) Statement를 타겟으로 하는 어떤 Statements를 반환해야 한다. 단, filter conditions for StatementRefs 섹션에 나와있는 것처럼 그 Statement가 비어있으면 안 된다. 이것은 비우려는(voiding) Statement를 포함하는데, 그 Statement는 비워질 수 없다. 보고 도구는 비우려는(voiding) Statement의 타겟으로 어떤 비워져 있는 Statement의 존재와 statementID도 인식할 수 있다.

*비워진 Statement를 검색하려는 보고 도구는 이들을 voidedStatementId로 각각 요구해야 한다.

7.3 Document APIs

세가지 문서 API들은 학습 활동 제공자와 Agents를 위한 문서 저장소를 제공한다. 각각의 API에 대한 세부 사항은 아래 섹션에서 찾을 수 있고, 이 섹션에 있는 정보는 세가지 API 모두 해당하는 내용이다.

Details

API	Method	Endpoint	Example
State API	POST	activities/state	http://example.com/xAPI/activities/state
Activity Profile API	POST	activities/profile	http://example.com/xAPI/activities/profile
Agent Profile API	POST	agents/profile	http://example.com/xAPI/agents/profile

Requirements

Activity Provider들은 LRS가 사전에 알고 있지 않은 Agents와 활동에 대해 어떤 문서 API들을 보낼 수도 있다.
LRS는 절대로 활동과 Agent에 대해 사전에 알고 있지 않다고 해서 문서를 거부해서는 안 된다.

JSON Procedure with Requirements Activity Provider가 문서에 content type application/json으로 변수들을 저장하면, 그들은 POST를 이용해 그들을 변수 집합으로 보고 조작할 수 있다. 아래 과정은 과정과 과정의 요구사항을 보여준다. 예를 들면 한 문서는 다음을 포함한다.

{
	"x" : "foo",
	"y" : "bar"

LRS가 POST 존재하는 content type이 application/json 인 문서에 대해 content type application/json로 request를 받았을 때, LRS는 반드시 이미 있는 문서와 포스트 된 문서를 병합해야만 한다. 이 문맥에서 병합은 다음과 같이 정의된다.

각각의 문서로 Object가 묘사되는 경우
Object에 대해 정의된 속성들이 각각 포스트 되며, 원래 있던 Object의 상응하는 속성을 포스트된 Object의 값과 같게 만든다.
가능한 원래 있던 Object 의 모든 json serialization 을 요구사항에서 언급된 문서로 저장한다.

최상위 Object가 최상위 속성이어도, 오직 최상위 속성들만 병합된다는 것을 주의하라. 원래 각각의 속성의 전체 내용은 새로운 속성의 내용으로 각각 바뀐다. 예를 들면 이 문서는 위의 원래 문서와 같은 id로 POST 되었다:

{
	"x" : "bash",
	"z" : "faz"

LRS 에 저장된 결과:

{
	"x" : "bash",
	"y" : "bar",
	"z" : "faz"

만약 원래 문서가 존재하면, 원래 문서 혹은 포스트 될 문서는 “application/json” Content-Type을 가지고 있지 않거나 혹은 둘 중 하나가 JSON Object로 파싱 될 수 없는 경우 LRS는 반드시 400 Bad Request HTTP 상태 코드로 답해야 하고 타겟 문서를 요구된 결과처럼 갱신 하면 안 된다. 만약 기존 문서가 존재하지 않는다면, LRS는 반드시 그 request를 PUT request처럼 다루고 post 될 문서를 저장해야 한다. 병합이 성공적으로 끝나면, LRS는 반드시 204 No Content HTTP 상태 코드로 답해야만 한다. 만약 AP가 한 속성을 지워야 한다면, AP는 아래에 설명된 것처럼 문서 전체를 바꾸기 위해 PUT request를 사용해야 한다.

7.4 State API

Description 일반적으로, 이것은 자신의 내부 저장소가 없거나 여러 디바이스들에 걸쳐 상태가 지속되야만 하는 Activity Provider를 위해 급조된 영역이다.

Details Call 의 의미는 stateId 파라미터에 의해 불려온다. 만약 이것이 포함되면, GET 과 DELETE 메소드들은 “stateID”로 구분되는 단일 state 문서에 의거해 행동할 것이다. 아니면, GET은 가능한 아이디들을 반환하고, DELETE는 다른 파라미터들을 통해 주어진 문맥상의 모든 state를 삭제할 것이다.

Single Document (PUT | POST | GET | DELETE) Example endpoint: http://example.com/xAPI/activities/state 특정 Activity, Agent 그리고 (만약 특정하다면) registration의 문맥 안에 존재하는 주어진 stateID로 구체화된 문서를 저장하고, 불러오거나 지운다. (PUT | POST | DELETE): 204 No Content 를 반환. (GET): 200 OK, State Content 를 반환.

Parameter	Type	Description	Required
activityId	String	이 state와 연관된 Activity id.	Required
agent	JSON	이 state와 연관된 Agent.	Required
registration	UUID	이 state와 연관된 registration id.	Optional
stateId	String	주어진 문맥에서 이 state의 id.	Required

Multiple Document GET Example endpoint: http://example.com/xAPI/activities/state 해당 문맥의 모든 state 데이터의 아이디들을 불러온다. (Activity + Agent [ + registration if specified]). 만약 “since” 파라미터가 명시돼있으면, 이것은 특정 timestamp(exclusive)부터 업데이트 됐거나 저장된 엔트리들로 한정된다. 반환 값: 200 OK, 아이디의 배열

Parameter	Type	Description	Required
activityId	String	이 state들과 관련된 Activity id.	Required
agent	JSON	이 state들과 관련된 Agent.	Required
registration	UUID	이 state들과 관련된 registration id.	Optional
since	Timestamp	특정 timestamp(exclusive)부터 저장된 state들의 아이디들만 반환된다.	Optional

Multiple Document DELETE Example endpoint: http://example.com/xAPI/activities/state 해당 문맥상의 모든 state 데이터들을 삭제한다. (Activity + Agent [+ registration if specified]). 반환 값: 204 No Content

Parameter	Type	Description	Required
activityId	String	이 state들과 관련된 Activity id.	Required
agent	JSON<	이 state들과 관련된 Agent.	Required
registration	UUID	이 state 와 관련된 registration id.	Optional

7.5 Activity Profile API

Description Activity Profile API는 State API와 매우 비슷하므로, Activity Profile API는 Activity와 관련된 임의의 키/문서 쌍이 저장되는 것을 허용한다.

Details Call의 의미는 profileId 파라미터로부터 불려온다. 이것이 포함되면, GET 메서드는 “profileID”로 식별된 단일 문서에 의거해 행동한다. 그렇지 않으면 GET은 가능한 아이디들을 반환한다. Activity Profile API은 또한 LRS로부터 온 Activity의 자세한 설명을 불러오는 방법을 포함한다.

Full Activity Object GET Example endpoint: http://example.com/xAPI/activities 명시된 Activity Object 전체를 로드한다. 반환 값: 200 OK, Content

Parameter	Type	Description	Required
activityId	String	로드할 Activity들과 관련된 id.	Required

Parameter	Type	Description	Required
activityId	String	해당 프로파일과 관련된 Activity id.	필수
profileId	String	해당 프로파일과 관련된 profile id.	필수

Multiple Document GET Example endpoint: http://example.com/xAPI/activities/profile 한 Activity를 위한 모든 프로파일 엔트리들을 로드한다. 만약 “since” 파라미터가 명시돼있으면, 이것은 특정 timestamp(exclusive) 이후에 업데이트 되거나 저장된 엔트리로 한정된다. 리턴 값: 200 OK, id의 목록

Parameter	Type	Description	Required
activityId	String	해당 프로파일들과 관련된 Activity id.	필수
since	Timestamp	특정 timestamp(exclusive)부터 저장된 프로파일들의 아이디들만 반환된다.	선택적

7.6 Agent Profile API

Description Activity Profile API는 State API와 매우 비슷하므로, Activity Profile API는 Activity와 관련된 임의의 키/문서 쌍이 저장되는 것을 허용한다.

Details call의 의미는 profileId 파라미터에 의해 주도된다. 만약 이것이 포함된다면, GET 메소드는 “profileId”에 의해 식별된 단일 정의된 문서에 따라 행동한다. 그 외에는, GET 은 가능한 ids를 반환할 것이다. 또한 Agent Profile API는 디렉토리 서비스와 같은 외부 서비스로부터 파생된 Agent에 대한 조합된 정보로 특정한 Object를 검색하기 위한 메소드를 포함한다.

Combined Information GET

Details 예시 endpoint: http://example.com/xAPI/agents 명시된 Agent를 위한 특정한 person Object를 반환한다. Person Object는 Agent Object와 매우 유사하다. 하지만 각 속성이 단일 값을 가지는 대신 배열 값을 가지며, 다중식별 사항을 포함하는데 적합하다. 인수는 여전히 배열이 아닌 단일 식별자를 포함하는 평범한 Agent Object인 것에 주의하라. 이것은 person은의 FOAF 개념으로부터의 발생하는 차이다. person은 이곳을 LRS Agent 데이터의 person-centric view 가리키는데 사용된다. 하지만 Agents는 한 persona(한 문맥에서의 person)을 나타낸다.

Requirements

LRS는 Person Object를 위한 다중식별 property들의 반환이 가능하다. Object는 명백하게 주어진 권한이 증가하는 자격증명 접속을 충족해야 한다.
LRS는 403 “Forbidden”을 포함하는 불충분한 특정 요청을 거부해야 한다.
LRS가 반환을 위한 Agent에 대한 어떤 추가 정보도 가지지 않는다면, LRS는 반드시 질의되었을 때 여전히 Person Object를 반환해야 한다. 하지만 Person Object는 요청된 Agent에 관련된 정보만 포함한다.

Person Properties

Details

Parameter	Type	Description	Required
objectType	String	“Person”	필수적
name	Array of strings.	검색을 위한 Agents 이름들의 목록	선택적
mbox	“mailto:email address” 형식 내에서의 IRIs의 배열	검색을 위한 Agents 이메일 주소들의 목록	선택적
mbox_sha1sum	Array of strings.	mailto IRIs의 SHA1 해쉬값들의 목록(mbox property로 이동하는 것처럼)	선택적
openid	Array of strings.	검색을 위한 Agents를 유일하게 식별하는 openids의 목록	선택적
account	Array of account objects.	적합한 계정들의 목록. 완전한 계정 Objects. List of accounts to match. 반드시 완전한 account Objects (homePage와 name)로 제공되어야 한다.	선택적

참고: Section 4.1.2.1 Agent. Returns: 200 OK, Expanded Agent Object

Parameter	Type	Description	Required
agent	Object (JSON)	확장된 Agent 정보를 불러올 때 사용되는 Agent 표현	필수적

Requirements 모든 배열의 사항들은 반드시 멤버와 Agent Objects로 부터 유사하게 명명된 사항처럼 동일한 정의를 덧붙여야 한다.

Parameter	Type	Description	Required
agent	Object (JSON)	이 프로파일에 관련된 Agent	필수적
profileId	String	이 프로파일에 관련된 프로파일 id	필수적

Multiple Agent or Profile GET Example endpoint: http://example.com/xAPI/agents/profile Agent를 위한 모든 프로파일 엔트리의 ids 불러온다. 만약 “since” 파라미터가 명시되면, 이것은 timestamp(exclusive)가 명시될 때부터 갱신되거나 저장되는 엔트리들을 제한한다. Returns: 200 OK, id의 List

Parameter	Type	Description	Required
agent	Object (JSON)	이 프로파일과 관련된 Agent	필수적
since	Timestamp	타임스탬프(배타적인)가 명시될 때부터 저장되는 프로파일들의 ids만 반환된다.	선택적

7.7 About Resource

Description xAPI 버전이 지원되는 것을 포함하는 LRS에 대한 정보를 담고 있는 JSON Object를 반환한다.

Rationale 주로 이 자원은 여러 xAPI 버전을 지원하는 클라이언트가 LRS와 통신 할 때 사용할 버전을 결정할 수 있도록 한다. 확장들에는 다른 사용법을 알리기 위해 허용하는 것이 포함된다.

Details

Information GET Example endpoint: http://example.com/xAPI/about Returns: 200 OK, Single ‘about’ JSON document.

Property	Type	Description	Required
version	버전 문자열들의 배열	이 LRS가 지원하는 xAPI 버전들	필수적
extensions	Object	요구되는 다른 사항들의 map	선택적

Requirements

LRS는 반드시 각각의 주 버전을 위해 아래에 서술된 JSON 문서를 반환해야 한다. 여기에는 LRS가 따르는 최신의 비주류 버전과 패치 버전의 버전 사항이 포함된다.
- 이 명세의0.0 버전에서는, “1.0.0”을 반드시 포함되는 것을 의미한다; 그리고 “0.9”, “0.95”는 포함 될 수도 있다. (이 요구사항의 목적을 위해서는, “0.9”와 “0.95”는 주 버전에서 고려된다)
LRS는 이 자원으로의 비인증 접근을 허용해야 한다.
LRS는 반드시2 API Versioning에 의해 충족될 때 그 외의 버전 헤더에 기반하는 요청을 거부하지 말아야 한다.

7.8 Cross Origin Requests

Description xAPI의 목표들 중 하나는 cross-domain 추적을 허용하는 것이다. 비록 xAPI가 다른 브라우저들보다 어플리케이션으로부터 추적하는 것을 허용하도록 탐색할 지라도, 브라우저들은 여전히 지원받는 것이 필요하다. Internet Explorer 8과 9는 Cross Origin Resource Sharing을 구현하는 것이 아니라 Cross Domain Request API(오직 “GET”과 “POST”만 지원하기 때문에 아래에 서술되는 xAPI의 모든것을 사용할 수 없다.)를 사용한다. 또한 HTTP 헤더들을 집합으로 허용하지 않는다.

Details/Requirements 다음은 오직 아래에 언급된 제한들 때문에 특정 콜을 위한 보통의 표현형식을 이용할 수 없을 때, 소비자들을 위해 사용하는 alternate syntax를 서술한다.

Method: 모든 xAPI 요청들을 발행하는 것은 반드시 POST여야 한다. 의도된 xAPI 메소드는 반드시 요청시 오직 질의 문자열 파라미터로써 포함되어야 한다. (예: http://example.com/xAPI/statements?method=PUT) Headers: HTTP 헤더에서 나타날 것으로 예상되는 어떤 필수적인 파라미터라도 반드시 같은 이름으로 된 파라미터 형식을 포함해야 한다. Content: 만약 xAPI 콜이 콘텐츠를 보내는 것에 관련된다면, 그 콘텐츠는 반드시 “content”로 불리어지는 파라미터 형식으로 인코딩되어야 한다. LRS는 UTF-8 문자열로서 이 콘텐츠를 이해할 것이다. 이진 데이터를 저장하는 것은 이 표현형식으로 지원되지 않는다. Attachments: 첨부 데이터를 보내는 것은 multipart/mixed 요청을 보내는 것이 필수적이다. 그러므로 첨부 데이터를 보내는 것은 이 표현형식으로 지원되지 않는다. 4.1.11. Attachments 부분을 참조하라.

LRS는 반드시 위의 표현형식을 지원해야 한다.

Internet Explorer 10 이하의 버전에서는 HTTP와 HTTPS 사이에서의 Cross Domain Requests를 지원하지 않는다고 알려야 한다. 이것이 의미하는 것은 IE9 이하를 위해, 만약 LRS가 HTTPS 도메인 상에 있다면, Client가 Statement를 보내는 것은 반드시 HTTPS 상에 있어야 한다. 만약 LRS가 HTTP 상에 있다면, Clilent도 반드시 그래야 한다. LRS로부터의 다른 스키마(HTTP혹은 HTTPS)에서 호스팅되는 Client 코드가 있는 IE8 and IE9을 지원하는 Client Activity Provider를 위해 필수적으로 요구되는 상황이 있을 수 있다. 이런 상황에서는, LRS로 통신하기 위해 프록시가 요구된다. 두 가지 간단한 해결방법이 있을 수 있다. 1) LRS로 Client 코드처럼 같은 스키마 상에서 통과하는 프록시를 설정하는 것. 2) 목표 LRS로 Client 코드를 라우팅하는 것처럼 같은 스키마 상에서 중개자 server-side LRS를 호스팅하는 것.

LRS는 이 요구사항을 지원하는 HTTP와 HTTPS endpooints 둘 다 제공하는 것을 선택할 수 있다.
LRS와 Client는 이 스키마를 사용하기 위한 결정을 내리기 전에 보안 위험성에 대해 고려해야 한다.

7.9 Validation

Description LRS의 기능은 xAPI의 Statements 검색과 저장이다. 이런 작업들을 수행하는데 충분한 정보를 가지고 있는 동안은, 그것들을 처리하는 것이 예상된다. Experience API 내에서의 Statements 인증은 의미가 아닌 오로지 표현형식에 초점이 맞춰져 있다. Verb 정의, Activity 타입, 확장들 사이의 의미의 유효성을 확실히 하기 위한 규칙은 Activity Provider가 Statement를 보내는 것의 책임성을 강요한다.

Requirements

LRS는 구조에 관한 규칙을 강요해야 한다.
LRS는 의미에 관한 규칙을 강요하지 말아야 한다.

7.10 HTTP HEAD

Description LRS는 실제문서가 아닌 오직 HTTP헤더를 이용하여 메타 정보 반환에 의한 HEAD 요청들에 대해 응답할 것이다.

Rationale 만약 특정한 Statement가 존재하거나, 상태 혹은 Activity나 Agent 프로파일과 같은 문서의 변경 날짜를 결정할 때, Clients가 LRS에 접근하는 것은 검사를 필요로 할 수도 있다. 특히 규모가 큰 문서를 위해서는 전체 문서에서 변경 날짜를 검사하는 것은 더 효율적이지 않다.

LRS Requirements

LRS는 반드시 동일한 HTTP GET 요청 예외 이외에 대해서는 응답할 수 있는 것처럼 어떤 HTTP HEAD 요청에 대해 응답해야 한다:
- message-body는 반드시 누락되어야 한다.
- LRS 자원 낭비를 피하기 위해, Content-Length 헤더는 누락될 수 있다.

부속서 A: Statement의 예시

간단한 Statement의 예시 (줄바꿈은 오직 표시 목적으로 사용)

{
"id":"fd41c918-b88b-4b20-a0a5-a4c32391aaa0",
"actor":{
"objectType": "Agent",
"name":"Project Tin Can API",
"mbox":"mailto:user@example.com"
},
"verb":{
"id":"http://adlnet.gov/expapi/verbs/created",
"display":{
"en-US":"created"
}
},
"object":{
"id":"http://example.adlnet.gov/xapi/example/simplestatement",
"definition":{
"name":{
"en-US":"simple statement"
},
"description":{"en-US":"A simple Experience API statement. Note that the LRS does not need to have any prior information about the Actor (learner), the verb, or the Activity/object."}
}
}

전형적인 “attempted” Verb를 사용한 간단한 완성:

{
"actor":{
"objectType": "Agent",
"name":"Example Learner",
"mbox":"mailto:example.learner@adlnet.gov"
},
"verb":{
"id":"http://adlnet.gov/expapi/verbs/attempted",
"display":{
"en-US":"attempted"
}
},
"object":{
"id":"http://example.adlnet.gov/xapi/example/simpleCBT",
"definition":{
"name":{
"en-US":"simple CBT course"
},
"description":{
"en-US":"A fictitious example CBT course."
}
}
},
"result":{
"score":{
"scaled":0.95
},
"success":true,
"completion":true
}

사용할 수 있는 속성의 대부분을 보여주는 긴 예제. 이 예제는 권한과 LRS에 의해 설정 저장 특성을 포함하는 LRS에 의해 반환 성명을 보여준다:

{
"id": "6690e6c9-3ef0-4ed3-8b37-7f3964730bee",
"actor": {
"name": "Team PB",
"mbox": "mailto:teampb@example.com",
"member": [
	{
	"name": "Andrew Downes",
	"account": {
	"homePage": "http://www.example.com",
	"name": "13936749"
	},
	"objectType": "Agent"
	},
	{
	"name": "Toby Nichols",
	"openid": "http://toby.openid.example.org/",
	"objectType": "Agent"
	},
	{
	"name": "Ena Hills",
	"mbox_sha1sum": "ebd31e95054c018b10727ccffd2ef2ec3a016ee9",
	"objectType": "Agent"
	}
	],
	"objectType": "Group"
	},
	"verb": {
	"id": "http://adlnet.gov/expapi/verbs/attended",
	"display": {
	"en-GB": "attended",
	"en-US": "attended"
	}
	},
	"result": {
	"extensions": {"http://example.com/profiles/meetings/resultextensions/minuteslocation":
	"X:\\meetings\\minutes\\examplemeeting.one"
	},
	"success": true,
	"completion": true,
	"response": "We agreed on some example actions.",
	"duration": "PT1H0M0S"
	},
	"context": {
	"registration": "ec531277-b57b-4c15-8d91-d292c5b2b8f7",
	"contextActivities": {
	"parent": [
	{
	"id": "http://www.example.com/meetings/series/267",
	"objectType": "Activity"
	}
	],
	"category": [
	{
	"id": "http://www.example.com/meetings/categories/teammeeting",
	"objectType": "Activity",
	"definition": {
	"name": {
	"en": "team meeting"
	},
	"description": {
	"en": "A category of meeting used for regular team meetings."
	},
	"type": "http://example.com/expapi/activities/meetingcategory"
	}
	}
	],
	"other": [
	{
	"id": "http://www.example.com/meetings/occurances/34257",
	"objectType": "Activity"
	},
	{
	"id": "http://www.example.com/meetings/occurances/3425567",
	"objectType": "Activity"
	}
	]
	},
	"instructor" :
	{
	"name": "Andrew Downes",
	"account": {
	"homePage": "http://www.example.com",
	"name": "13936749"
	},
	"objectType": "Agent"
	},
	"team":
	{
	"name": "Team PB",
	"mbox": "mailto:teampb@example.com",
	"objectType": "Group"
	},
	"platform" : "Example virtual meeting software",
	"language" : "tlh",
	"statement" : {
	"objectType":"StatementRef",
	"id" :"6690e6c9-3ef0-4ed3-8b37-7f3964730bee"
	}
	},
	"timestamp": "2013-05-18T05:32:34.804Z",
	"stored": "2013-05-18T05:32:34.804Z",
	"authority": {
	"account": {
	"homePage": "http://cloud.scorm.com/",
	"name": "anonymous"
	},
	"objectType": "Agent"
	},
	"version": "1.0.0",
	"object": {
	"id": "http://www.example.com/meetings/occurances/34534",
	"definition": {
	"extensions": {
	"http://example.com/profiles/meetings/activitydefinitionextensions/room":
	{
	"name": "Kilby",
	"id" : "http://example.com/rooms/342"
	}
	},
	"name": {
	"en-GB": "example meeting",
	"en-US": "example meeting"
	},
	"description": {
	"en-GB": "An example meeting that happened on a specific occasion with certain people present.",
	"en-US": "An example meeting that happened on a specific occasion with certain people present."
	},
	"type": "http://adlnet.gov/expapi/activities/meeting",
	"moreInfo": "http://virtualmeeting.example.com/345256"
	},
	"objectType": "Activity"
	}

부속서 B: 다른 유형의 Statement 객체의 예시

Statement의 객체의 목적은 Activity, Agent, Group 또는 Statement가 될 수 있다. 이 부록에서는 각각의 예를 제공한다.

Activity

{
	"id": "http://www.example.co.uk/exampleactivity",
	"definition": {
	"name": {
	"en-GB": "example activity",
	"en-US": "example activity"
	},
	"description": {
	"en-GB": "An example of an activity",
	"en-US": "An example of an activity"
	},
	"type": "http://www.example.co.uk/types/exampleactivitytype"
	},
	"objectType": "Activity"

Agent

{
	"name": "Andrew Downes",
	"mbox": "mailto:andrew@example.co.uk",
	"objectType": "Agent"

Group 이 예제는 회원과 식별된 그룹을 보여준다.

{
	"name": "Example Group",
	"account" : {
	"homePage" : "http://example.com/homePage",
	"name" : "GroupAccount"
	},
	"objectType": "Group",
	"member": [
	{
	"name": "Andrew Downes",
	"mbox": "mailto:andrew@example.com",
	"objectType": "Agent"
	},
	{
	"name": "Aaron Silvers",
	"openid": "http://aaron.openid.example.org",
	"objectType": "Agent"
	}
	]

Statement 이 예제는 참조 Statement인 하위 Statement 객체를 보여준다.

{
	"objectType": "SubStatement",
	"actor" : {
	"objectType": "Agent",
	"mbox":"mailto:agent@example.com"
	},
	"verb" : {
	"id":"http://example.com/confirmed",
	"display":{
	"en":"confirmed"
	}
	},
	"object": {
	"objectType":"StatementRef",
	"id" :"9e13cefd-53d3-4eac-b5ed-2cf6693903bb"
	}

부속서 C: “cmi.interaction” 형식의 Activity에 대한 정의의 예시

True-false

"definition": {
	"description": {
	"en-US": "Which of these prototypes are available at the beta site?"
	},
	"type": "http://adlnet.gov/expapi/activities/cmi.interaction",
	"interactionType": "choice",
	"correctResponsesPattern": [
	"golf[,]tetris"
	],
	"choices": [
	{
	"id": "golf",
	"description": {
	"en-US": "Golf Example"
	}
	},
	{
	"id": "facebook",
	"description": {
	"en-US": "Facebook App"
	}
	},
	{
	"id": "tetris",
	"description": {
	"en-US": "Tetris Example"
	}
	},
	{
	"id": "scrabble",
	"description": {
	"en-US": "Scrabble Example"
	}
	}
	]

Fill-in

"definition": {
	"description": {
	"en-US": "Ben is often heard saying: "
	},
	"type": "http://adlnet.gov/expapi/activities/cmi.interaction",
	"interactionType": "fill-in",
	"correctResponsesPattern": [
	"Bob's your uncle"
	]

Long-fill-in

"definition": {
	"description": {
	"en-US": "What is the purpose of the xAPI?"
	},
	"type": "http://adlnet.gov/expapi/activities/cmi.interaction",
	"interactionType": "long-fill-in",
	"correctResponsesPattern": [
	"{case_matters=false}{lang=en}To store and provide access to learning experiences."
	]

Likert

"definition": {
	"description": {
	"en-US": "How awesome is Experience API?"
	},
	"type": "http://adlnet.gov/expapi/activities/cmi.interaction",
	"interactionType": "likert",
	"correctResponsesPattern": [
	"likert_3"
	],
	"scale": [
	{
	"id": "likert_0",
	"description": {
	"en-US": "It's OK"
	}
	},
	{
	"id": "likert_1",
	"description": {
	"en-US": "It's Pretty Cool"
	}
	},
	{
	"id": "likert_2",
	"description": {
	"en-US": "It's Damn Cool"
	}
	},
	{
	"id": "likert_3",
	"description": {
	"en-US": "It's Gonna Change the World"
	}
	}
	]

Matching

"definition": {
	"description": {
	"en-US": "Match these people to their kickball team:"
	},
	"type": "http://adlnet.gov/expapi/activities/cmi.interaction",
	"interactionType": "matching",
	"correctResponsesPattern": [
	"ben[.]3[,]chris[.]2[,]troy[.]4[,]freddie[.]1"
	],
	"source": [
	{
	"id": "ben",
	"description": {
	"en-US": "Ben"
	}
	},
	{
	"id": "chris",
	"description": {
	"en-US": "Chris"
	}
	},
	{
	"id": "troy",
	"description": {
	"en-US": "Troy"
	}
	},
	{
	"id": "freddie",
	"description": {
	"en-US": "Freddie"
	}
	}
	],
	"target": [
	{
	"id": "1",
	"description": {
	"en-US": "Swift Kick in the Grass"
	}
	},
	{
	"id": "2",
	"description": {
	"en-US": "We got Runs"
	}
	},
	{
	"id": "3",
	"description": {
	"en-US": "Duck"
	}
	},
	{
	"id": "4",
	"description": {
	"en-US": "Van Delay Industries"
	}
	}
	]

Performance

"definition": {
	"description": {
	"en-US": "This interaction measures performance over a day of RS sports:"
	},
	"type": "http://adlnet.gov/expapi/activities/cmi.interaction",
	"interactionType": "performance",
	"correctResponsesPattern": [
	"pong[.]1:[,]dg[.]:10[,]lunch[.]"
	],
	"steps": [
	{
	"id": "pong",
	"description": {
	"en-US": "Net pong matches won"
	}
	},
	{
	"id": "dg",
	"description": {
	"en-US": "Strokes over par in disc golf at Liberty"
	}
	},
	{
	"id": "lunch",
	"description": {
	"en-US": "Lunch having been eaten"
	}
	}
	]

Sequencing

"definition": {
	"description": {
	"en-US": "Order players by their pong ladder position:"
	},
	"type": "http://adlnet.gov/expapi/activities/cmi.interaction",
	"interactionType": "sequencing",
	"correctResponsesPattern": [
	"tim[,]mike[,]ells[,]ben"
	],
	"choices": [
	{
	"id": "tim",
	"description": {
	"en-US": "Tim"
	}
	},
	{
	"id": "ben", "description": {
	"en-US": "Ben"
	}
	},
	{
	"id": "ells",
	"description": {
	"en-US": "Ells"
	}
	},
	{
	"id": "mike",
	"description": {
	"en-US": "Mike"
	}
	}
	]

Numeric

"definition": {
	"description": {
	"en-US": "How many jokes is Chris the butt of each day?"
	},
	"type": "http://adlnet.gov/expapi/activities/cmi.interaction",
	"interactionType": "numeric",
	"correctResponsesPattern": [
	"4:"
	]

Other

"definition": {
	"description": {
	"en-US": "On this map, please mark Franklin, TN"
	},
	"type": "http://adlnet.gov/expapi/activities/cmi.interaction",
	"interactionType": "other",
	"correctResponsesPattern": [
	"(35.937432,-86.868896)"
	]

부속서 D: Converting Statements to 1.0.0

Rationale 이것은 1.0.0 사양이며, 구현자는 같은 사양의 이전 버전을 고려해야 할 필요가 없다. 그러나 이전 버전의 주의할만한 추가사항은 볼 수 없었다. 이 데이터 변환은 이전 버전을 사용하고, 일관된 방식으로 새로운 구현하는 것이 가능하게 추적되는 데이터를 유지하기 위해 특정된다.

Details

0.9 버전 기반으로 생성된 Statement 변환하기 0.9에서 작성된 Statement를 변환하는 1.0.0 시스템은 반드시 다음 단계를 따라야 한다.

statement가 무효 또는 Verb, 활동 유형, 또는9 사양에 포함되지 않은 속성을 사용 한 경우 변환되지 않는다.
“verb”는 “http://adlnet.gov/expapi/verbs/"가 접두사.
어떤 완전한 IRI가 아닌 Activity id 접두사는 “tag:adlnet.gov,2013:expapi:0.9:activities:“
어떤 완전한 IRI가 아닌 확장 키의 접두사는 ”tag:adlnet.gov,2013:expapi:0.9:extensions:“
Activity 형식 접두사는 “http://adlnet.gov/expapi/activities/“
각각의 Agent (Actor)에 대하여:
- 이 순서의 역기능 식별자 검색: “mbox, mbox_sha1sum, openid, account”. 발견된 첫 번째 역기능 식별자를 유지하고 나머지는 버린다.
- 위의 역기능 식별자에서, 배열의 첫 번째 요소를 역시는 식별자 속성 값으로 사용하기 위해 가지고 나머지 요소를 버린다.
- “name” 속성이 존재하는 경우, 나머지 요소를 버리고, “name” 배열의 첫 번째 요소는 동일하게 설정.
- 남아있는 모든 속성을 제거한다.
만약 있다면, 경우 Statement에서 “voided” 속성을 제거한다. 무효화 속성 값에 해당하는 경우에는, Statement이 변환되어서는 안된다는걸 기억하라.
“version” 추가: “0.0”
권위가 이전 집합이 아닌 경우, 변환 및 “unknown”의 accountName을 수행하는 시스템에 대응하는 홈 페이지로 설정 홈 페이지와 계정에 의해 식별되는 에이전트에 대한 권한을 설정한다.
컨텍스트에서 Statement 필드가 설정된 경우 Statement에서 제거한다.
“stored”을 포함하여, 수정하지 않고 다른 모든 필드를 보존한다. Statement이 다른 시스템으로 전달되는 경우 저장은 여전히 업데이트 해야한다.

0.95버전을 기반으로 생성된 Statement 변환하기 0.95에서 작성된 Statement를 변환하는 1.0.0 시스템은 반드시 다음 단계를 따라야 한다.

statement가 무효가 된 경우, 변환하지 않는다.
만약 있다면, 경우 statement에서 “voided” 속성을 제거한다. 무효화 속성 값에 해당하는 경우에는, Statement가 절대로 변환되어서는 안된다는걸 기억하라.
“version” 추가: “0.0”
권위가 이전 집합이 아닌 경우, 변환 및 “unknown”의 accountName을 수행하는 시스템에 대응하는 홈 페이지로 설정 홈 페이지와 계정에 의해 식별되는 에이전트에 대한 권한을 설정한다.
컨텍스트에서 Statement 필드가 설정된 경우 Statement에서 제거한다.
“stored”을 포함하여, 수정하지 않고 다른 모든 필드를 보존한다. Statement이 다른 시스템으로 전달되는 경우 저장은 여전히 업데이트 해야한다.

예시 A 0.9 Statement:

{
"id": "d1eec41f-1e93-4ed6-acbf-5c4bd0c24269",
"actor": {
"objectType": "Person",
"name": [
"Joe Schmoe",
"Joseph Schmoseph"
],
"mbox": [
"mailto:joe@example.com"
],
"openid": [
"http://openid.com/joe-schmoe"
]
},
]"verb": "completed",
"inProgress": false,
"object": {
"objectType": "Activity",
"id": "http://www.example.com/activities/001",
"definition": {
"name": {
"en-US": "Example Activity"
},
"type": "course"
}
},
"result": {
"completion": true
},
"context": {
"instructor": {
"objectType": "Person",
"lastName": [
"Dad"
],
"firstName": [
"Joe's"
],
"mbox": [
"mailto:joesdad@example.com"
]
},
"contextActivities": {
"parent": {
"objectType": "Activity",
"id": "non-absolute-activity-id",
"definition": {
"name": {
"en-US": "Another Activity"
}
}
}
}
},
"timestamp": "2012-06-01T19:09:13.245Z",
"stored": "2012-06-29T15:41:39.165Z"

1.0.0으로 변환

{
"version": "1.0.0",
"id": "d1eec41f-1e93-4ed6-acbf-5c4bd0c24269",
"actor": {
"objectType": "Agent",
"name": "Joe Schmoe",
"mbox": "mailto:joe@example.com"
},
"verb": {
"id": "http://adlnet.gov/expapi/verbs/completed",
"display": {
"en-US": "completed"
}
},
"object": {
"objectType": "Activity",
"id": "http://www.example.com/activities/001",
"definition": {
"name": {
"en-US": "Example Activity"
},
"type": "http://adlnet.gov/expapi/activities/course"
}
},
"result": {
"completion": true
},
"context": {
"instructor": {
"objectType": "Agent",
"mbox": "mailto:joesdad@example.com"
},
"contextActivities": {
"parent": [
{
"objectType": "Activity",
"id": "tag:adlnet.gov,2013:expapi:0.9:activities:non-absolute-activity-id",
"definition": {
"name": {
"en-US": "Another Activity"
}
}
}
]
}
},
"timestamp": "2012-06-01T19:09:13.245Z",
"stored": "2012-06-29T15:41:39.165Z",
"authority": {
"objectType": "Agent",
"account": {
"homePage": "http://www.example.com",
"name": "unknown"
}
}

부속서 E: 서명된 Statement의 예시

4.4 Signed Statements에 서술되어 있는 서명된 Statement의 예시이다. 원래의 Statement 직렬화는 서명된다. 이 예시의 줄바꿈은 CR+LF (0x0D + 0x0A)를 포함한다.

{
"version": "1.0.0",
"id": "33cff416-e331-4c9d-969e-5373a1756120",
"actor": {
"mbox": "mailto:example@example.com",
"name": "Example Learner",
"objectType": "Agent"
},
"verb": {
"id": "http://adlnet.gov/expapi/verbs/experienced",
"display": {
"en-US": "experienced"
}
},
"object": {
"id": "https://www.youtube.com/watch?v=xh4kIiH3Sm8",
"objectType": "Activity",
"definition": {
"name": {
"en-US": "Tax Tips & Information : How to File a Tax Return "
},
"description": {
"en-US": "Filing a tax return will require filling out either a 1040, 1040A or 1040EZ form"
}
}
},
"timestamp": "2013-04-01T12:00:00Z"

서명에 사용되는 X.509 인증서에 대한 개인 키의 예시:

공인 X.509 인증서 예시

인증 기관 인증서 예시

JWT 헤더. 알고리즘을 지정함에 따라, 인증서 체인과 함께 서명 인증서가 포함되어 있음을 참고하라.

{
"alg": "RS256",
"x5c": [
"MIIDATCCAmqgAwIBAgIJAMB1csNuA6+kMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlUZW5uZXNzZWUxGDAWBgNVBAoTD0V4YW1wbGUgQ29tcGFueTEQMA4GA1UEAxMHRXhhbXBsZTEiMCAGCSqGSIb3DQEJARYTZXhhbXBsZUBleGFtcGxlLmNvbTAeFw0xMzA0MDQxNTI4MzBaFw0xNDA0MDQxNTI4MzBaMIGWMQswCQYDVQQGEwJVUzESMBAGA1UECBMJVGVubmVzc2VlMREwDwYDVQQHEwhGcmFua2xpbjEYMBYGA1UEChMPRXhhbXBsZSBDb21wYW55MRAwDgYDVQQLEwdFeGFtcGxlMRAwDgYDVQQDEwdFeGFtcGxlMSIwIAYJKoZIhvcNAQkBFhNleGFtcGxlQGV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDjxvZXF30WL4oKjZYXgR0ZyaX+u3y6+JqTqiNkFa/VTnet6Ly2OT6ZmmcJEPnq3UnewpHoOQ+GfhhTkW13j06j5iNn4obcCVWTL9yXNvJH+Ko+xu4Yl/ySPRrIPyTjtHdG0M2XzIlmmLqm+CAS+KCbJeH4tf543kIWC5pC5p3cVQIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUVs3v5afEdOeoYeVajAQE4v0WS1QwHwYDVR0jBBgwFoAUyVIc3yvra4EBz20I4BF39IAixBkwDQYJKoZIhvcNAQEFBQADgYEAgS/FF5D0Hnj44rvT6kgn3kJAvv2lj/fyjztKIrYS33ljXGn6gGyA4qtbXA23PrO4uc/wYCSDICDpPobh62xTCd9qObKhgwWOi05PSBLqUu3mwfAe15LJBJBqPVZ4K0kppePBU8m6aIZoH57L/9t4OoaL8yKs/qjKFeI1OFWZxvA=",
"MIIDNzCCAqCgAwIBAgIJAMB1csNuA6+jMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlUZW5uZXNzZWUxGDAWBgNVBAoTD0V4YW1wbGUgQ29tcGFueTEQMA4GA1UEAxMHRXhhbXBsZTEiMCAGCSqGSIb3DQEJARYTZXhhbXBsZUBleGFtcGxlLmNvbTAeFw0xMzA0MDQxNTI1NTNaFw0yMzA0MDIxNTI1NTNaMHExCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlUZW5uZXNzZWUxGDAWBgNVBAoTD0V4YW1wbGUgQ29tcGFueTEQMA4GA1UEAxMHRXhhbXBsZTEiMCAGCSqGSIb3DQEJARYTZXhhbXBsZUBleGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1sBnBWPZ0f7WJUFTJy5+01SlS5Z6DDD6Uye9vK9AycgV5B3+WC8HC5u5h91MujAC1ARPVUOtsvPRs45qKNFIgIGRXKPAwZjawEI2sCJRSKV47i6B8bDv4WkuGvQaveZGI0qlmN5R1Eim2gUItRj1hgcC9rQavjlnFKDY2rlXGukCAwEAAaOB1jCB0zAdBgNVHQ4EFgQUyVIc3yvra4EBz20I4BF39IAixBkwgaMGA1UdIwSBmzCBmIAUyVIc3yvra4EBz20I4BF39IAixBmhdaRzMHExCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlUZW5uZXNzZWUxGDAWBgNVBAoTD0V4YW1wbGUgQ29tcGFueTEQMA4GA1UEAxMHRXhhbXBsZTEiMCAGCSqGSIb3DQEJARYTZXhhbXBsZUBleGFtcGxlLmNvbYIJAMB1csNuA6+jMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEADhwTebGk735yKhm8DqCxvNnEZ0NxsYEYOjgRG1yXTlW5pE691fSH5AZ+T6fpwpZcWY5QYkoN6DnwjOxGkSfQC3/yGmcUDKBPwiZ5O2s9C+fE1kUEnrX2Xea4agVngMzR8DQ6oOauLWqehDB+g2ENWRLoVgS+ma5/Ycs0GTyrECY="
]

JWS 서명

ew0KICAgICJhbGciOiAiUlMyNTYiLA0KICAgICJ4NWMiOiBbDQogICAgICAgICJNSUlEQVRDQ0FtcWdBd0lCQWdJSkFNQjFjc051QTYra01BMEdDU3FHU0liM0RRRUJCUVVBTUhFeEN6QUpCZ05WQkFZVEFsVlRNUkl3RUFZRFZRUUlFd2xVWlc1dVpYTnpaV1V4R0RBV0JnTlZCQW9URDBWNFlXMXdiR1VnUTI5dGNHRnVlVEVRTUE0R0ExVUVBeE1IUlhoaGJYQnNaVEVpTUNBR0NTcUdTSWIzRFFFSkFSWVRaWGhoYlhCc1pVQmxlR0Z0Y0d4bExtTnZiVEFlRncweE16QTBNRFF4TlRJNE16QmFGdzB4TkRBME1EUXhOVEk0TXpCYU1JR1dNUXN3Q1FZRFZRUUdFd0pWVXpFU01CQUdBMVVFQ0JNSlZHVnVibVZ6YzJWbE1SRXdEd1lEVlFRSEV3aEdjbUZ1YTJ4cGJqRVlNQllHQTFVRUNoTVBSWGhoYlhCc1pTQkRiMjF3WVc1NU1SQXdEZ1lEVlFRTEV3ZEZlR0Z0Y0d4bE1SQXdEZ1lEVlFRREV3ZEZlR0Z0Y0d4bE1TSXdJQVlKS29aSWh2Y05BUWtCRmhObGVHRnRjR3hsUUdWNFlXMXdiR1V1WTI5dE1JR2ZNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0R05BRENCaVFLQmdRRGp4dlpYRjMwV0w0b0tqWllYZ1IwWnlhWCt1M3k2K0pxVHFpTmtGYS9WVG5ldDZMeTJPVDZabW1jSkVQbnEzVW5ld3BIb09RK0dmaGhUa1cxM2owNmo1aU5uNG9iY0NWV1RMOXlYTnZKSCtLbyt4dTRZbC95U1BScklQeVRqdEhkRzBNMlh6SWxtbUxxbStDQVMrS0NiSmVINHRmNTQza0lXQzVwQzVwM2NWUUlEQVFBQm8zc3dlVEFKQmdOVkhSTUVBakFBTUN3R0NXQ0dTQUdHK0VJQkRRUWZGaDFQY0dWdVUxTk1JRWRsYm1WeVlYUmxaQ0JEWlhKMGFXWnBZMkYwWlRBZEJnTlZIUTRFRmdRVVZzM3Y1YWZFZE9lb1llVmFqQVFFNHYwV1MxUXdId1lEVlIwakJCZ3dGb0FVeVZJYzN5dnJhNEVCejIwSTRCRjM5SUFpeEJrd0RRWUpLb1pJaHZjTkFRRUZCUUFEZ1lFQWdTL0ZGNUQwSG5qNDRydlQ2a2duM2tKQXZ2MmxqL2Z5anp0S0lyWVMzM2xqWEduNmdHeUE0cXRiWEEyM1ByTzR1Yy93WUNTRElDRHBQb2JoNjJ4VENkOXFPYktoZ3dXT2kwNVBTQkxxVXUzbXdmQWUxNUxKQkpCcVBWWjRLMGtwcGVQQlU4bTZhSVpvSDU3TC85dDRPb2FMOHlLcy9xaktGZUkxT0ZXWnh2QT0iLA0KICAgICAgICAiTUlJRE56Q0NBcUNnQXdJQkFnSUpBTUIxY3NOdUE2K2pNQTBHQ1NxR1NJYjNEUUVCQlFVQU1IRXhDekFKQmdOVkJBWVRBbFZUTVJJd0VBWURWUVFJRXdsVVpXNXVaWE56WldVeEdEQVdCZ05WQkFvVEQwVjRZVzF3YkdVZ1EyOXRjR0Z1ZVRFUU1BNEdBMVVFQXhNSFJYaGhiWEJzWlRFaU1DQUdDU3FHU0liM0RRRUpBUllUWlhoaGJYQnNaVUJsZUdGdGNHeGxMbU52YlRBZUZ3MHhNekEwTURReE5USTFOVE5hRncweU16QTBNREl4TlRJMU5UTmFNSEV4Q3pBSkJnTlZCQVlUQWxWVE1SSXdFQVlEVlFRSUV3bFVaVzV1WlhOelpXVXhHREFXQmdOVkJBb1REMFY0WVcxd2JHVWdRMjl0Y0dGdWVURVFNQTRHQTFVRUF4TUhSWGhoYlhCc1pURWlNQ0FHQ1NxR1NJYjNEUUVKQVJZVFpYaGhiWEJzWlVCbGVHRnRjR3hsTG1OdmJUQ0JuekFOQmdrcWhraUc5dzBCQVFFRkFBT0JqUUF3Z1lrQ2dZRUExc0JuQldQWjBmN1dKVUZUSnk1KzAxU2xTNVo2RERENlV5ZTl2SzlBeWNnVjVCMytXQzhIQzV1NWg5MU11akFDMUFSUFZVT3RzdlBSczQ1cUtORklnSUdSWEtQQXdaamF3RUkyc0NKUlNLVjQ3aTZCOGJEdjRXa3VHdlFhdmVaR0kwcWxtTjVSMUVpbTJnVUl0UmoxaGdjQzlyUWF2amxuRktEWTJybFhHdWtDQXdFQUFhT0IxakNCMHpBZEJnTlZIUTRFRmdRVXlWSWMzeXZyYTRFQnoyMEk0QkYzOUlBaXhCa3dnYU1HQTFVZEl3U0JtekNCbUlBVXlWSWMzeXZyYTRFQnoyMEk0QkYzOUlBaXhCbWhkYVJ6TUhFeEN6QUpCZ05WQkFZVEFsVlRNUkl3RUFZRFZRUUlFd2xVWlc1dVpYTnpaV1V4R0RBV0JnTlZCQW9URDBWNFlXMXdiR1VnUTI5dGNHRnVlVEVRTUE0R0ExVUVBeE1IUlhoaGJYQnNaVEVpTUNBR0NTcUdTSWIzRFFFSkFSWVRaWGhoYlhCc1pVQmxlR0Z0Y0d4bExtTnZiWUlKQU1CMWNzTnVBNitqTUF3R0ExVWRFd1FGTUFNQkFmOHdEUVlKS29aSWh2Y05BUUVGQlFBRGdZRUFEaHdUZWJHazczNXlLaG04RHFDeHZObkVaME54c1lFWU9qZ1JHMXlYVGxXNXBFNjkxZlNINUFaK1Q2ZnB3cFpjV1k1UVlrb042RG53ak94R2tTZlFDMy95R21jVURLQlB3aVo1TzJzOUMrZkUxa1VFbnJYMlhlYTRhZ1ZuZ016UjhEUTZvT2F1TFdxZWhEQitnMkVOV1JMb1ZnUyttYTUvWWNzMEdUeXJFQ1k9Ig0KICAgIF0NCn0.ew0KICAgICJ2ZXJzaW9uIjogIjEuMC4wIiwNCiAgICAiaWQiOiAiMzNjZmY0MTYtZTMzMS00YzlkLTk2OWUtNTM3M2ExNzU2MTIwIiwNCiAgICAiYWN0b3IiOiB7DQogICAgICAgICJtYm94IjogIm1haWx0bzpleGFtcGxlQGV4YW1wbGUuY29tIiwNCiAgICAgICAgIm5hbWUiOiAiRXhhbXBsZSBMZWFybmVyIiwNCiAgICAgICAgIm9iamVjdFR5cGUiOiAiQWdlbnQiDQogICAgfSwNCiAgICAidmVyYiI6IHsNCiAgICAgICAgImlkIjogImh0dHA6Ly9hZGxuZXQuZ292L2V4cGFwaS92ZXJicy9leHBlcmllbmNlZCIsDQogICAgICAgICJkaXNwbGF5Ijogew0KICAgICAgICAgICAgImVuLVVTIjogImV4cGVyaWVuY2VkIg0KICAgICAgICB9DQogICAgfSwNCiAgICAib2JqZWN0Ijogew0KICAgICAgICAiaWQiOiAiaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g_dj14aDRrSWlIM1NtOCIsDQogICAgICAgICJvYmplY3RUeXBlIjogIkFjdGl2aXR5IiwNCiAgICAgICAgImRlZmluaXRpb24iOiB7DQogICAgICAgICAgICAibmFtZSI6IHsNCiAgICAgICAgICAgICAgICAiZW4tVVMiOiAiVGF4IFRpcHMgJiBJbmZvcm1hdGlvbiA6IEhvdyB0byBGaWxlIGEgVGF4IFJldHVybiAiDQogICAgICAgICAgICB9LA0KICAgICAgICAgICAgImRlc2NyaXB0aW9uIjogew0KICAgICAgICAgICAgICAgICJlbi1VUyI6ICJGaWxpbmcgYSB0YXggcmV0dXJuIHdpbGwgcmVxdWlyZSBmaWxsaW5nIG91dCBlaXRoZXIgYSAxMDQwLCAxMDQwQSBvciAxMDQwRVogZm9ybSINCiAgICAgICAgICAgIH0NCiAgICAgICAgfQ0KICAgIH0sDQogICAgInRpbWVzdGFtcCI6ICIyMDEzLTA0LTAxVDEyOjAwOjAwWiINCn0.FWuwaPhwUbkk7h9sKW5zSvjsYNugvxJ-TrVaEgt_DCUT0bmKhQScRrjMB6P9O50uznPwT66oF1NnU_G0HVhRzS5voiXE-y7tT3z0M3-8A6YK009Bk_digVUul-HA4Fpd5IjoBBGe3yzaQ2ZvzarvRuipvNEQCI0onpfuZZJQ0d8

서명된 Statement

{
"version": "1.0.0",
"id": "33cff416-e331-4c9d-969e-5373a1756120",
"actor": {
"mbox": "mailto:example@example.com",
"name": "Example Learner",
"objectType": "Agent"
},
"verb": {
"id": "http://adlnet.gov/expapi/verbs/experienced",
"display": {
"en-US": "experienced"
}
},
"object": {
"id": "https://www.youtube.com/watch?v=xh4kIiH3Sm8",
"objectType": "Activity",
"definition": {
"name": {
"en-US": "Tax Tips & Information : How to File a Tax Return "
},
"description": {
"en-US": "Filing a tax return will require filling out either a 1040, 1040A or 1040EZ form"
}
}
},
"timestamp": "2013-04-01T12:00:00Z",
"attachments": [
{
"usageType": "http://adlnet.gov/expapi/attachments/signature",
"display": { "en-US": "Signature" },
"description": { "en-US": "A test signature" }
"contentType": "application/octet-stream",
"length": 4235,
"sha2": "672fa5fa658017f1b72d65036f13379c6ab05d4ab3b6664908d8acf0b6a0c634"
}
]

Note: 첨부된 서명은 표시되지 않으며, Attachment 메시지 형식은 Section 4.1.11 Attachment를 참조하라.

부속서 F. 모든 Endpoint 표

Endpoint (LRS앞에 오는 각 Endpoint의 기본 Endpoint)	Function
statements	Statement Storage/Retrieval
agents	Agent Object Storage/Retrieval
agents/profile	Agent Profile API
activities	Activity Object Storage/Retrieval
activities/profile	Activity Profile API
activities/state	State API
about	LRS Information
OAuth/initiate	Temporary Credential Request
OAuth/authorize	Resource Owner Authorization
OAuth/token	Token Request