[공식 문서 한글 번역판] xAPI docs 2.0 Data 톺아보기

728x90

1.0 문서
Documents

Experience API는 학습 기록 공급자(LRP)가 임의의 데이터를 문서 형태로 저장할 수 있는 기능을 제공한다. 이 데이터는 대체로 비구조화되어 있으므로 유연성을 가질 수 있다. 문서 동작에 대한 자세한 내용은 Part 3에서 확인할 수 있다.

2.0 진술문
Statements

2.1 목적

Statements은 xAPI에서 추적할 경험 또는 이벤트의 증거다. Statements은 기계 판독 가능한 JSON 형식을 따르지만 자연어를 사용하여 쉽게 Description할 수도 있다. 이것은 설계 과정에 매우 유용할 수 있다. Statements은 개별 경험의 합계 이상의 전체적인 의미를 제공하기 위해 집계 및 분석되도록 의도되어 있다.

2.2 서식 Requirements

Details
Statements에서 사용된 모든 Property은 특정 데이터 Type으로 제한된다. 명확성을 위해 여기서 주요 Requirements을 문서화하며, xAPI 구성 요소가 이 명세서를 준수하기 위해 특정 방식으로 작동해야 하는 경우를 강조한다.

Requirements

Statements과 다른 객체는 빈 객체의 값을 포함해서는 안 된다.
Statements은 각 Property을 한 번 이상 사용해서는 안 된다.
Statements은 "actor", "verb", "object"를 사용해야 한다.
Statements은 Property을 어떤 순서로든 사용할 수 있다.
LRS는 예외로 명시된 Property을 제외한 다른 Property의 다른 직렬화를 반환해서는 안 된다.

학습 레코드 제공자 Requirements
다음 Requirements은 이미 다른 곳에 포함되어 있는 매우 중요한 Requirements을 강조하며, 명확하게 하고 구현 지침을 제공하기 위해 반복되는 Requirements이다. 완전한 IRI(국제화 리소스 식별자) 유효성 검사 및 Property이 한 번만 나타나야 하는 유효성 검사와 같은 일부 Type의 유효성 검사는 매우 어려우므로 데이터 이동성을 보장하는 부담이 대부분의 경우 학습 레코드 제공자에게 있다.

IRI를 필요로 하는 값은 유효한 IRI와 함께 전송되어야 한다.
언어 맵 키의 경우 유효한 RFC 5646 언어 태그와 함께 전송되어야 하며, 비슷한 이유로 인해 유효한 키여야 한다.
IRI를 구성하기 위해 문자열 연결이 아닌 라이브러리를 사용해야 한다.
값은 그렇게 명시되지 않은 경우 대소문자 구분해야 한다.
대소문자 구분되지 않는 데이터를 전송할 때 소문자를 사용해야 한다.
이 명세서에서 명시적으로 허용되지 않는 한 Statements에 추가 Property을 추가해서는 안 된다. 객체 내에서 Property을 여러 번 사용해서는 안 되며, 객체 내에서 Property이 여러 번 사용되면 LRS의 동작이 정의되지 않는다. 대부분의 LRS는 사용하는 코드 언어의 기존 JSON 구문 분석 기능을 사용할 것으로 예상된다.

Note: LRS는 추가 Property이 포함된 Statements을 거부하는 것이 좋다. Statements에 추가 Property이 포함되면 해당 Statements은 모든 LRS와 상호 운용되지 않을 것으로 예상된다.

LRS Requirements

LRS는 잘못된 데이터 Type을 사용한 경우나 null 값을 포함하는 Statements(내부 확장에서는 제외)을 거부해야 한다.
LRS는 언어 맵 키의 토큰 길이 순서의 시퀀스가 RFC 5646 표준과 일치하는지 최소한 확인해야 한다.
LRS는 IEEE 754 32비트 부동 소수점 숫자의 정밀도를 최소한으로 처리하고 저장해야 한다.
매개 변수 값을 Statements의 동일한 Type의 값에 필요한 표준과 동일한 표준으로 유효성 검사해야 한다. * 문자열 매개 변수 값은 JSON에서와 같이 인용되지 않으므로 문자열로 취급된다.
LRS는 명시되지 않은 경우 모든 값을 대소문자 구분으로 처리해야 한다.
LRS는 IRL 및 IRI 형식에 대한 형식에 맞지 않는 거부 Requirements을 충족시키기 위해 최선을 다할 수 있다.
LRS는 언어 맵 키에 대한 형식에 맞지 않는 거부 Requirements을 충족시키기 위해 최선을 다할 수 있다.
추가 Property을 Statements 및 다른 객체에 추가해서는 안된다. 명세서에 명시적으로 허용되지 않는 한 LRS는 해당 추가 Property이 포함된 Statements을 거부해야 한다.

2.3 Statements 라이프사이클

Statements은 추적된 학습 경험에 대한 정보다. 일반적으로 Statements에 나타난 정보는 이미 발생한 일이다. 따라서 "display" 또는 Verb ID의 인간이 읽을 수 있는 부분에 사용되는 자연어는 일반적으로 과거형을 사용할 것으로 예상된다.

Statements은 영구적이라고 예상된다. 이 명세서 내에서 Statements을 취소하는 유일한 방법은 그것을 무효화하는 것이다. 무효화는 Statements을 파괴하는 것이 아니라 Statements의 증거가 무시되어야 함을 나타낸다.

2.3.1 Statements의 불변성

Statements은 변경할 수 없다(불변성). 다음은 이 규칙에 대한 예외 또는 이 규칙에 포함되지 않는 영역이다.

LRS 처리 중에 잠재적 또는 필요한 Property 할당("id", "authority", "stored", "timestamp", "version").
Statements에서 참조하는 활동 정의.
Statements에서 참조되는 활동 정의의 내용은 Statements 자체의 일부로 간주되지 않는다. 이것은 Statements을 JSON으로 심층 직렬화하면 참조된 활동 정의가 변경될 경우 Statements이 변경될 수 있다는 것을 의미한다(세부 내용은 Statement Resource의 "format" 매개 변수를 참조).
Statements에서 참조하는 Verb.
Verb의 "display" Property은 Statements 자체의 일부로 간주되지 않는다(세부 내용은 Statement Resource의 "format" 매개 변수를 참조).
타임스탬프 데이터의 직렬화.
이것은 불변 Statements 자체의 일부로 간주되지 않는다. 예를 들어, Statements의 "timestamp" 및 "stored" Property은 저장된 시간과 다른 시간대로 반환될 수 있지만 참조하는 시점에는 영향을 미치지 않아야 한다. 자세한 내용은 2.4.7 Timestamp 및 2.4.8 Stored 을 참조.
순서 없는 목록의 직렬화.
Group 내 Agent 목록은 순서가 없는 목록으로 간주되지 않는다. 따라서 LRS는 Group 내 Agent 목록을 어떤 순서로든 반환할 수 있다. Group을 참조하려면 Groups을 참조.
Attachments
Attachments은 Statements의 일부가 아니며 클라이언트가 요청할 때 Attachments이 없는 Statements을 반환할 것이다(세부 내용은 Statement Resource의 "attachments" 매개 변수를 참조).
대소문자 구분.
일부 Property은 대소문자를 구분하지 않으며, 대소문자 변경은 불변성에 영향을 주지 않는다. 예를 들어 이메일 주소의 도메인 부분은 대소문자를 구분하지 않는다. 대소문자 민감한 텍스트에는 소문자를 사용하는 것이 좋다.

다음은 명시적으로 예외가 아니며 이 규칙에 포함되는 사항이다.

결과 지속시간.
월, 년 및 분의 길이가 가변적이며 "타임스탬프" Property이 경험의 시작, 중간 또는 끝을 나타내는 방식으로 유연하므로 LRS는 결과 지속시간을 정확하게 역직렬화하고 시간 단위를 변환할 수 없다. 이러한 이유로 결과 지속시간은 Statements 비교를 위한 문자열로 간주된다.

Statements 비교 Requirements
이 명세서에는 Statements이 일치하는지 확인하기 위해 Statements을 비교해야 하는 여러 시나리오가 나열되어 있다. 이러한 시나리오에서는 다음 규칙이 적용된다.

Statements 불변성에 대한 예외로 인한 차이는 무시되야 한다.
예외로 나열되지 않은 Property의 다른 직렬화와 관련된 차이는 무시해서는 안 된다.

2.3.2 무효화

Rationale
LRS가 정확하고 완전한 데이터 컬렉션을 가지고 있다는 확신은 Statements이 논리적으로 변경되거나 삭제할 수 없다는 사실로 보장된다. Statements의 이러한 불변성은 Experience API의 분산 구조를 가능하게 하는 핵심 요소다.

그러나 모든 Statements이 발행된 후에도 영원히 유효한 것은 아니다. 실수 또는 다른 요인으로 인해 이전에 만든 Statements이 무효로 표시되어야 할 수 있다. 이를 "Statements 무효화"라고 하며, 여기에는 예약된 Verb http://adlnet.gov/expapi/verbs/voided이 사용된다. 다른 Statements을 무효화하는 Statements은 자체로 무효화될 수 없다.

Requirements

다른 Statements을 무효화하는 Statements을 발행할 때 무효화하는 Statements의 객체는 "objectType" Property이 StatementRef로 설정되어야 한다.
다른 Statements을 무효화하는 Statements을 발행할 때 무효화 할 Statements의 "id" Property을 사용하여 해당 Statements의 ID를 지정해야 한다.
LRS는 포함된 Statements이 무효화되었는지 여부를 해당 Statements 자체가 무효화 Statements이 아니며 LRS에 무효화 Statements을 참조하는 무효화 Statements도 포함되어 있는 경우에만 고려해야 한다.
다른 Statements을 무효화하는 Statements을 수신하면 LRS는 Statements을 무효화하는 Statements을 포함한 요청 전체를 거부해야 하며, 요청이 Statements을 무효화할 권한이 없는 소스에서 온 경우 403 Forbidden로 전체 요청을 거부해야 한다.
다른 Statements을 무효화하는 Statements을 수신하면 LRS는 해당 Statements의 "object"가 존재하지 않는 이유로 요청을 거부해서는 안 된다.
다른 Statements을 무효화하는 Statements을 수신하면 LRS는 방금 무효화된 Statements에 의해 소개된 활동 또는 Agent 정의에 대한 변경 사항을 롤백할 수 있다.
이전에 무효화된 Statements을 "다시 무효화"하려는 학습 레코드 제공자(Learning Records Provider)는 해당 Statements을 새로운 ID로 다시 발행해야 한다.
Note:

Example
다음 예제 Statements은 Statements ID "e05aa883-acaf-40ad-bf54-02c8ce485fb0"을 식별하고 무효화한다.

{
             "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"
             }
}

2.4 Statements Property

Details

Statement의 각 Property에 대한 자세한 내용은 아래 표에 Description되어 있다.

Property	Type	Description	Required
id	UUID	LRS에서 설정되지 않았다면 학습 레코드 제공자 (Learning Record Provider)에서 설정한 UUID	추천
actor	Object	Statement가 어떤 Agent 또는 Group을 대상으로 하는지	필수
verb	Object	액터(Actor)가 취한 동작	필수
object	Object	Statement의 대상이 되는 활동, Agent 또는 다른 Statement	필수
result	Object	측정된 결과를 나타내는 추가 Details를 담은 결과 객체	선택
context	Object	Statement에 더 많은 의미를 부여하는 context. 예를 들어, Actor가 함께 작업하는 팀 또는 비행 시뮬레이터에서 시나리오를 시도한 고도 등.	선택
timestamp	Timestamp	이 Statement에서 Description하는 이벤트가 발생한 시간의 타임스탬프. 제공되지 않으면 LRS에서 설정.	선택
stored	Timestamp	이 Statement가 기록된 시간의 타임스탬프. LRS에서 설정.	LRS에 의해 설정
authority	Object	이 Statement가 참임을 주장하는 Agent 또는 Group. 인증을 기반으로 LRS에서 확인. 제공되지 않거나 학습 레코드 제공자(Learning Record Provider)와 LRS 간의 강력한 신뢰 관계가 설정되지 않은 경우 LRS에서 설정.	선택
version	Version	Statement와 관련된 xAPI 버전, Semantic Versioning 1.0.0.에 따라 형식화.	추천되지 않음
attachments	Ordered array of Attachment Objects	Statement에 첨부된 Attachments의 헤더	선택

예제

가장 간단한 Statement의 예제로, 모든 필수 또는 권장 Property을 사용하는 경우를 보여준다. 관련이 있는 경우 선택 Property도 채우는 것이 좋다. 이 Statement가 LRS에서 반환될 때 LRS에서 추가한 몇 가지 Property이 포함된다.

{
    "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>"
    }
}

2.4.1 ID

Description

UUID(RFC 4122의 변형 2의 모든 버전이 유효하며 UUID는 표준 문자열 형태여야 함).

Requirements

만약 id가 제공되지 않은 상태에서 Statement를 받으면, LRS는 Statement id를 생성해야 한다.
Statement id는 가능한 경우 학습 레코드 제공자(Learning Record Provider)가 생성해야 한다.

2.4.2 Actor

Description
Actor는 어떤 동작을 수행한 사람 또는 Group을 정의한다. Statements의 Actor는 Agent 또는 Group일 수 있다.

2.4.2.1 Actor의 objectType이 Agent인 경우

Description
Agent는 개인 또는 시스템을 나타낸다.

Details
Agent는 역기능 식별자(Inverse Functional Identifier) 중 하나로 식별되어야 한다(2.4.2.3 Inverse Functional Identifier 참고).

Agent는 하나 이상의 역기능 식별자를 포함해서는 안 된다.
Agent는 Group 식별자로 사용되는 역기능 식별자를 사용해서는 안 된다.

아래 표는 Agent 객체의 Property을 나열한다:

Property	Type	Description	Required
objectType	문자열	Agent가 Statements의 오브젝트로 사용될 때만 필수	선택
name	문자열	Agent의 전체 이름	선택
Agent의 고유한 역기능 식별자		Agent 고유의 역함수 식별자(IFI).	필수

2.4.2.2 Actor의 objectType이 Group일 때

Description
Group은 Agent의 집합을 나타내며, Agent가 사용되는 대부분의 상황에서 사용할 수 있다. Group에는 익명 Group(Anonymous Groups)과 식별 Group(Identified Groups) 두 가지 Type이 있다.

Details

익명 Group(Anonymous Group)은 이 Group에 대한 식별자가 없는 경우에 사용되며, 예를 들어 즉석에서 구성된 팀(Ad hoc team) 등을 Description하는 데 사용된다.
아래 표는 익명 Group의 모든 Property을 나열한다.

Property	Type	Description	Required
objectType	문자열	Group(Group)	필수
name	문자열	Group의 이름	선택
member	Agent 오브젝트의 배열	이 Group의 구성원. 이것은 순서가 없는 목록.	필수

식별 Group(Identified Group)은 Agent의 집합을 고유하게 식별하기 위해 사용된다.
아래 표는 식별 Group의 모든 Property을 나열한다.

Property	Type	Description	Required
objectType	문자열	Group(Group)	필수
name	문자열	Group의 이름	선택
member	Agent 오브젝트의 배열	이 Group의 구성원이다. 순서가 없는 목록.	선택
see 2.4.2.3 Inverse Functional Identifier	Group에 고유한 역기능 식별자	필수

Requirements

학습 레코드 소비자(Learning Record Consumer)는 동일한 구성원 집합을 가지고 있더라도 각 익명 Group을 구별해야 한다.
학습 레코드 제공자(Learning Record Provider)는 Group에 대한 여러 Statements을 발행하거나 데이터를 집계하거나 Group과 관련된 문서를 저장하고 검색하려는 경우 식별 Group을 사용해야 한다.
학습 레코드 제공자는 주어진 익명 Group 또는 식별 Group의 "member" 속성에 대한 완전하거나 일부 Agent 목록을 포함할 수 있다.
Statements을 반환하는 LRS는 Group 구성원 목록을 어떤 순서로든 반환할 수 있다.

익명 Group에 대한 Requirements

익명 Group은 "member" 속성을 포함해야 한다. 구성원을 나열하는 속성.
익명 Group은 "member" 식별자에 Group 오브젝트를 포함해서는 안 된다.

식별 Group에 대한 Requirements

식별 Group은 정확히 하나의 역기능 식별자를 포함해야 한다.
식별 Group은 "member" 속성에 Group 오브젝트를 포함해서는 안 된다.
식별 Group은 Agent 식별자로 사용되는 역기능 식별자를 사용해서는 안 된다.
식별 Group은 "member" 속성에 구성원 Agent 목록을 포함할 수 있다.

2.4.2.3 역기능 식별자(Inverse Functional Identifier)

Description
역기능 식별자는 Agent나 식별된 Group의 값을 나타내며, 해당 Agent나 식별된 Group을 고유하게 식별할 수 있도록 보장된다.

Rationale
데이터를 저장하고 검색하기 위해 Agent와 Group은 고유하게 식별될 필요가 있다. xAPI 명세에서는 이를 역기능 식별자를 사용하여 달성하며, 이는 널리 인정받는 FOAF 원칙( Friend Of A Friend)에 영감을 받았다.

Details

아래 표는 모든 가능한 역기능 식별자 속성을 나열한다.

Property	Type	Description
mbox	mailto IRI	필수 형식: "mailto:email address" 이 Agent에 할당된 적이 있고 앞으로 할당될 이메일 주소만 사용하고 다른 이메일 주소는 이 속성 및 mbox_sha1sum에 사용해야 한다.
mbox_sha1sum	문자열	mailto IRI의 16진수로 인코딩된 SHA1 해시(예: mbox 속성 값)이다. 요청이 mbox를 기반으로 하는 경우, LRS에 일치하는 해시가 있는 에이전트가 포함될 수 있다.
openid	URI	Agent를 고유하게 식별하는 openID.
account	객체	기존 시스템(예: LMS 또는 내부 네트워크)의 사용자 계정.

Client Requirements

· 이메일 주소의 도메인 부분은 대소문자를 구분하지 않는다. 클라이언트는 "mbox_sha1sum" 속성의 SHA1 해시를 계산할 때 이메일 주소의 도메인 부분을 소문자로 사용해야 한다.

2.4.2.4 계정 객체(Account Object)

Description
개인 시스템(LMS 또는 인트라넷) 또는 공용 시스템(소셜 네트워킹 사이트)과 같은 기존 시스템의 사용자 계정.

Details

계정 객체를 제공하는 시스템이 OpenID를 사용하는 경우, 학습 레코드 제공자(Learning Record Provider)는 계정 객체 대신 openid 속성을 사용해야 한다.
Agent 또는 Group에 대한 개인 식별 가능 정보를 공개하지 않고도 해당 Agent 또는 Group에 관한 모든 Statements을 식별하기 위해 Agent 또는 Group에 대한 불투명한(account number와 같은) 계정 이름을 사용해야 한다.
아래 표는 계정 객체의 모든 속성을 나열한다.

Property	Type	Description	Required
homePage	IRL	계정이 있는 시스템의 정식 홈 페이지. 이것은 FOAF의 accountServiceHomePage를 기반으로 한다.	필수
name	문자열	이 계정에 로그인할 때 사용되는 고유한 ID 또는 이름. 이것은 FOAF의 accountName을 기반으로 한다.	필수

예시 다음 예시는 불투명한 계정으로 식별된 Agent를 보여준다.

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

2.4.3 Verb (Verb)

Description
Verb는 Actor와 Activity 간의 동작을 정의한다.

Rationale
xAPI Statements의 Verb는 학습 경험 중에 수행된 동작을 설명한다. xAPI는 특정한 Verb를 지정하지 않는다. (예외로 예약된 Verb http://adlnet.gov/expapi/verbs/voided가 있다.) 대신, 커뮤니티가 자신들의 회원에게 의미 있는 Verb를 설정하고 누구나 사용할 수 있도록 Verb를 어떻게 만들어야 하는지 정의한다. 사전에 정의된 Verb 목록은 정의에 따라 제한적일 수 있으며 모든 가능한 미래 학습 경험을 효과적으로 포착하지 못할 수 있다.

Details
Verb(Verb)는 Statements에 객체로 나타나며 IRI와 여러 언어 또는 방언에 해당하는 인간이 읽을 수 있는 Verb의 의미를 제공하는 표시 이름으로 구성된다. 아래 표는 Verb 객체의 모든 Property을 나열한다.

Property	Type	Description	Required
id	IRI	Verb 정의에 해당한다. 각 Verb 정의는 단어가 아니라 Verb의 의미에 해당한다.	필수
display	언어 맵	여러 언어에서 Verb의 인간이 읽을 수 있는 표현이다. 이것은 Statements의 의미에는 영향을 주지 않지만 선택한 Verb에 이미 결정된 의미를 인간이 읽을 수 있는 표시로 제공한다.	권장

Verb ID Requirements

Statements을 읽는 시스템은 Verb IRI를 사용하여 의미를 추론해야 한다.
id에 포함된 IRI는 사람이 원시 Statements을 검토하여 Verb를 다른 유사한 (구문상으로) Verb와 구별할 수 있는 충분한 의미를 제공해야 한다.
단일 Verb IRI는 여러 의미를 나타내기 위해 사용해서는 안 된다.

Verb 표시 학습 기록 제공자 Requirements

"display" 속성은 모든 Statements에서 사용해야 한다.
"display" 속성은 이미 Verb IRI로 결정된 의미를 Description하기 위해 사용해야 한다.

Verb 표시 LRS Requirements

아래 Requirements은 LRS가 API를 통해 반환하는 "display" 속성과 관련이 있다.

정확한 형식의 Statements을 조회할 때, LRS는 Statements 내에 포함된대로 "display" 속성을 정확하게 반환해야 한다(포함 또는 미포함 여부).
ID 형식의 Statements을 조회할 때, LRS는 "display" 속성을 포함하지 않아야 한다 (선택).
정확한 형식의 Statements을 조회할 때, LRS는 해당 Verb의 정규 표시를 반환해야 한다.
LRS는 Verb의 "display" 속성을 포함된 Statements, 3.2 Hosted Metadata에 Description된 메타데이터의 "name" 속성 또는 다른 위치에서 정의된 Verb의 표시를 기반으로 정규 표시를 결정할 수 있다.

Verb 표시 학습 기록 사용자 Requirements

아래 Requirements은 학습 기록 사용자가 학습 기록 소비자에 의해 사용자에게 표시된 표시 Property과 관련이 있다.

" display " 속성은 Verb의 의미를 변경하는 데 사용해서는 안 된다.
학습 기록 사용자는 Statements에서 의미를 추론하기 위해 " display " 속성을 사용해서는 안 된다.
학습 기록 사용자는 " display " 속성을 사용자에게 표시하기 위한 목적 외에는 어떤 목적으로도 사용해서는 안 된다. " display " 속성을 Statements의 집계나 분류에 사용하는 것은 이 Requirements을 위반한 예다.
학습 기록 사용자는 사용자 인터페이스에서 Statements의 Verb를 표시할 때 Statements에 포함된 Verb의 " display " 속성, 3.2 Hosted Metadata에 설명된 메타데이터의 "name" 속성 또는 다른 위치에서 정의된 Verb의 표시 중 하나를 렌더링하는 선택을 할 수 있다. 이때, 단어의 의미와 다른 표현과 시제를 인간이 읽을 수 있도록 변경할 수 있다.

예시
다음 예제는 권장되는 속성이 설정된 Verb를 보여준다. 미국 영어와 스페인어 언어를 사용한다.

{
    "id":"<http://example.com/xapi/verbs#defenestrated>",
    "display":{
        "en-US":"defenestrated",
        "es" : "defenestrado"
    }
}

위 예제의 Verb는 설명 목적으로 포함됐다. 이것은 이 id로 정의된 의미가 있는 Verb가 있다는 것을 의미하는 것이 아니다. 이 사양 문서에 제시된 모든 예약된 Verb에 적용되며(http://adlnet.gov/expapi/verbs/voided를 예외로 적용) 이 id로 이러한 의미가 정의되었음을 의미하지 않는다.

2.4.3.1 언어 및 Verb 의미에서의 사용

Details
Semantics

Verb ID에 의해 나타낸 IRI는 단어 자체가 아니라 단어의 특정 의미를 식별한다.

예를 들어, 영어 단어 "fired"는 맥락에 따라 다른 의미를 갖을 수 있으며 "fired(무기 발사)", "fired(가마 발사)", 또는 "fired(직원 해고)"와 같이 다를 수 있다. 이 경우 IRI는 이러한 특정 의미 중 하나를 식별한다.

"display" 속성은 시제에 대해 어느 정도 유연성을 가진다. Verb ID의 인간이 읽을 수 있는 부분은 일반적으로 과거 시제를 사용할 것이지만, "display" 속성 내에서 Verb를 다른 시제로 활용하는 것이 Statements 전체에 가장 적합한 경우 허용된다.

Language

경험 API의 Verb는 IRI이며 특정 언어와 관련되지 않는 특정 의미를 나타낸다.

예를 들어, 특정 Verb IRI인 http://example.org/firearms#fire는 총을 발사하는 동작을 나타낼 수 있고, Verb IRI인 http://example.com/فعل/خواندن은 책을 읽는 동작을 나타낼 수 있다.

2.4.4 Object (객체)

Description 객체(Object)는 수행된 동작 대상을 정의한다. Statements의 객체는 활동(Activity), Agent/Group(Agent/Group), 하위 Statements(SubStatement) 또는 Statements 참조(Statement Reference)가 될 수 있다.

일부 예제:

객체가 활동인 경우: "Jeff가 하이킹에 대한 에세이를 썼다."
객체가 Agent인 경우: "Nellie가 Jeff를 인터뷰했다."
객체가 하위 Statements 또는 Statements 참조인 경우 (사람이 읽기 쉽게 표시되는 방식이 다름): "Nellie가 'Jeff가 하이킹에 대한 에세이를 썼다'에 댓글을 달았다."

Details 이 Property의 값으로 제공되는 객체는 "objectType" Property을 포함해야 한다. 지정되지 않은 경우 objectType은 활동(Activity)으로 가정된다. 다른 유효한 값은 Agent, Group(Group), 하위 Statements(SubStatement) 또는 Statements 참조(StatementRef)이다. 객체의 Property은 objectType에 따라 변경된다.

2.4.4.1 ObjectType이 활동(Activity)인 경우

Details Statements은 Statements의 객체로 활동을 나타낼 수 있다. 다음 표는 이 경우의 객체 Property을 나열한다.

Property	Type	Description	Required
objectType	String	현재 사용될 때 Activity 여야 한다.	선택
id	IRI	단일 고유한 Activity를 식별하기 위한 식별자이다.	필수
definition	Object	메타데이터, 아래 참조	선택

동일한 id가 두 가지 다른 Activity에 사용될 수 있다면, 이러한 Activities에 대한 Statements의 유효성이 의심스러워질 수 있다. 이것은 LRS가 (참조를 통한) 동일한 Activity id를 두 개의 다른 Activities에 속한다고 생각하더라도, 이 id에 대한 충돌이 다른 시스템과 발생할 때, 어떤 Activity가 의도되었는지를 결정하는 것이 불가능하다는 것을 의미한다.

Activity 정의 아래 표는 Activity 정의 객체의 Property을 나열하고 있다.

Property	Type	Description	Required
name	Language Map	Activity의 인간이 읽을 수 있는/시각적 이름이다.	추천
description	Language Map	Activity의 Description이다.	추천
type	IRI	Activity의 Type이다.	추천
moreInfo	IRL	Activity에 대한 인간이 읽을 수 있는 정보를 해결한다. 이 정보에는 Activity를 실행하는 방법이 포함될 수 있다.	선택
extensions	Object	필요한 다른 Property들의 맵 (확장)	선택

*IRI fragment(가끔 상대 IRL로 불리는)는 유효한 IRI가 아닙니다. Verb와 마찬가지로, xAPI를 구현하는 사람들은 이미 정립되고 널리 사용되는 Activity Type을 찾아서 사용하는 것이 권장된다.

Activity id Requirements

Activity id는 고유해야 한다.
Activity id는 항상 동일한 Activity를 참조해야 한다.
Activity id는 창조자가 이 목적으로 사용할 권한이 있는 도메인을 사용해야 한다.
Activity id는 해당 도메인 내에서 모든 Activity id가 고유함을 보장하는 방식으로 생성해야 한다.
Activity id는 메타데이터 또는 Activity의 IRL을 가리킬 수 있다.

LRS Requirements

LRS는 동일한 Activity id가 여러 작성자 및/또는 조직에서 사용되고 있다고 인식할 때 조치를 취해서는 안 된다.
LRS는 동일한 Activity id에 대한 참조를 다른 Activities에 대한 참조로 처리해서는 안 된다.
LRS는 저장된 Activity 정의와 다른 Activity 정의를 포함한 Statement를 받을 때, Learning Record Provider가 정의를 변경할 권한이 있는지 여부를 결정하고, 이 결정이 긍정적인 경우 저장된 Activity 정의를 업데이트해야 한다.
LRS는 새로운 정의를 받을 때 기존의 정의를 작은 수정을 가해서 변경할 수 있다. (예: 철자 수정)
LRS는 업데이트된 정의를 기반으로 Activity의 정의에 중대한 변경을 가해서는 안 된다. (예: 정정된 응답 변경)

Learning Record Provider Requirements

Learning Record Provider는 Activity id가 여러 Activity 전체에 걸쳐 사용되지 않도록 해야 한다.
Learning Record Provider는 동일한 Activity id에 대한 저장된 상태 또는 Statements와 호환되고 일관성을 유지하는 Statements만 생성해야 한다.
Learning Record Provider는 새 버전 (즉, 개정 또는 다른 플랫폼)의 Activity가 호환성을 파괴하지 않도록 해야 한다.

상호작용 활동(Interation Activities)

Rationale

전통적인 e-러닝은 상호작용 또는 평가를 위한 구조를 포함하고 있었습니다. 이러한 실천 및 구조를 Experience API의 유틸리티로 확장하려는 방법으로, 이 명세에는 SCORM 2004 4판 데이터 모델에서 빌린 상호작용에 대한 내장 정의가 포함되어 있다. 이러한 정의는 상호작용 데이터를 기록하기 위한 간단하고 익숙한 유틸리티를 제공하기 위해 의도되었습니다. 1.0.3부터 SCORM 데이터 모델에 대한 직접적인 참조가 제거되기 시작했으며, 이 문서에 직접 포함된 관련 Requirements이 있다.

이 상호작용 정의는 사용하기 쉽고 따라서 제한적이다. 보다 풍부한 상호작용 정의를 필요로 하는 커뮤니티들은 Activity Type 및 Activity 정의 확장의 사용을 통해 그러한 작업을 수행할 것으로 예상된다.

Details

상호작용 활동의 Property은 아래 표에 나열되어 있다.

Property	Type	Description	Required
interactionType	문자열 (String)	상호작용의 Type이다. 가능한 값은: true-false, choice, fill-in, long-fill-in, matching, performance, sequencing, likert, numeric, other 이다.	필수
correctResponsesPattern	문자열 배열 (Array of Strings)	상호작용에 대한 올바른 응답을 나타내는 패턴이다. 이 패턴의 구조는 interactionType에 따라 다양한다. 이에 대한 자세한 내용은 아래에 Description되어 있다.	선택
choices	scale	source	target

상호작용 Type 아래 표는 각 interactionType에 해당하는 상호작용 Type을 Description한다. 이러한 상호작용 Type은 원래 SCORM 2004 4th Edition 실행 환경의 "cmi.interactions.n.type"에서 허용된 상호작용 Type을 기반으로 한다. 각 상호작용 Type에 대한 예제 정의는 부록 C를 참조하십시오.

interactionType	설명 (Description)
true-false	두 가지 가능한 응답 (true 또는 false)를 가지는 상호작용이다.
choice	학습자가 선택할 수 있는 여러 가능한 선택지를 가지는 상호작용이다. 학습자가 목록에서 하나의 답변만 선택할 수 있는 경우와 여러 항목을 선택할 수 있는 경우를 모두 포함한다.
fill-in	학습자가 문자열 형식의 짧은 응답을 제공해야 하는 상호작용이다. 일반적으로 올바른 응답은 단어의 일부, 한 단어 또는 몇 마디로 이루어집니다. "짧은"이란 일반적으로 올바른 응답 패턴 및 학습자 응답 문자열이 250자 이하일 것으로 예상된다.
long-fill-in	학습자가 문자열 형식의 긴 응답을 제공해야 하는 상호작용이다. "긴"이란 일반적으로 올바른 응답 패턴 및 학습자 응답 문자열이 250자 이상일 것으로 예상된다.
matching	학습자에게 한 세트(원본 세트)의 항목을 다른 세트(대상 세트)의 항목과 매칭하도록 요청하는 상호작용이다. 항목들은 정확하게 짝지어질 필요가 없으며, 하나의 대상 항목이 여러 개 또는 아무것도 짝지어질 수 있다.
performance	학습자가 여러 단계를 필요로 하는 작업을 수행해야 하는 상호작용이다.
sequencing	학습자에게 한 세트의 항목을 순서대로 정렬하도록 요청하는 상호작용이다.
likert	학습자에게 스케일에서 선택할 수 있는 이산형 선택을 요청하는 상호작용이다.
numeric	학습자로부터 숫자 응답을 요구하는 모든 상호작용이다.
other	위에서 정의된 것과 맞지 않는 다른 Type의 상호작용이다.

응답 패턴(Response Patterns)

아래 표는 각 상호작용 Type에 대한 "correctResponsesPattern" Property 내의 문자열 형식을 개요로 Description한다. 이 형식은 또한 결과 객체 내에서 학습자 응답을 나타내는 데 사용된다. 이러한 형식은 원래 SCORM 2004 4th Edition 실행 환경에서 정의된 "cmi.interactions.n.correct_responses.n.pattern" 에 관련된 Requirements을 기반으로 한다. 각 형식에 대한 예제는 부록 C를 참조하십시오.

interactionType	형식 (Format)
true-false	true 또는 false
choice	[,]로 구분된 항목 id 목록. 응답에 하나의 항목만 포함하는 경우 구분 기호를 사용해서는 안 됨.
fill-in 및 long-fill-in	[,]로 구분된 응답 목록. 응답에 하나의 항목만 포함하는 경우 구분 기호를 사용해서는 안 됨.
matching	[,]로 구분된 일련의 일치하는 쌍 목록. 각 쌍은 원본 항목 id 다음에 대상 항목 id가 따릅니다. 항목은 여러 개의 쌍에 나타날 수 있다. 쌍 내의 항목은 [.]로 구분된다. 쌍은 [,]로 구분된다.
performance	단계 id와 해당 단계 응답을 포함하는 단계 목록. 단계 id와 응답은 [.]로 구분된다. 단계는 [,]로 구분된다. 응답은 fill-in 상호작용의 문자열 또는 numeric 상호작용의 숫자 범위일 수 있다.
sequencing	[,]로 구분된 항목 id의 순서가 정해진 목록.
likert	단일 항목 id
numeric	최소값과 최대값으로 표시된 숫자 범위. 최소값 또는 최대값이 없는 경우 해당 숫자가 생략될 수 있지만 구분 기호는 여전히 사용된다. 예: [:]4는 최대값이 4이고 최소값이 없음을 나타낸다. 올바른 응답 또는 학습자 응답이 범위가 아닌 단일 숫자인 경우 구분 기호 없이 단일 숫자를 사용할 수 있다.
other	이 Type의 상호작용에 적합한 형식이면 어떤 형식이든 유효한다.

올바른 응답 패턴(Correct Responses Pattern)

올바른 응답 패턴은 응답 패턴의 배열을 포함한다. 학습자 응답이 해당 배열의 응답 패턴 중 하나와 일치하는 경우 학습자 응답이 올바른 것으로 간주된다. 응답 패턴이 구분된 목록인 경우, 학습자 응답이 해당 목록의 모든 항목과 일치해야 학습자 응답이 올바른 것으로 간주된다. 예를 들어, 다음과 같은 값으로 정의된 올바른 응답 패턴을 고려해야 한다.:

"correctResponsesPattern": [
"foo[,]bar",
"foo"
]

이 예제에서 "foo"와 "bar" 둘 다 올바른 학습자 응답이다. "bar" 단독으로는 올바르지 않다.

올바른 응답 패턴(Correct Responses Pattern)은 사용될 경우 가능한 올바른 응답의 모든 목록을 나타내는 것을 목적으로 한다. 질문의 기준이 복잡하고 올바른 응답을 완전하게 나열할 수 없는 경우, 학습 기록 제공자는 "correctResponsesPattern" Property을 사용하지 않도록 권장된다.

학습 기록 소비자는 응답을 올바른 응답 패턴과 비교하여 성공을 추론할 수 없으며, 항상 올바른 응답 패턴이 완전하지 않을 수 있다고 가정해서는 안 된다. 학습 기록 제공자는 학습자 응답이 올바른 응답 패턴과 일치하지 않는 경우에도 질문을 올바르다고 표시할 수 있지만, 이 경우 예외적인 상황을 제외하고 권장하지 않는다.

올바른 응답 패턴이 빈 배열을 포함하는 경우, 이것은 올바른 답변이 없음을 의미한다. 모든 답변이 부정확한 경우이다. 어떤 답변이 올바른 경우 (예: 설문 조사에서), 올바른 응답 패턴 Property이 생략된다.

문자열 매개변수(Characterstring parameters) 위에서 Description한 응답 내의 일부 값은 특정 추가 매개변수로 시작될 수 있다. 이러한 매개변수는 원래 SCORM 2004 4th Edition 실행 환경에서 정의된 문자열 구분 기호에 기반한다. 이러한 매개변수는 {parameter=value} 형식으로 표시된다. 부록 C의 long-fill-in 예제를 참조하십시오.

문자열 매개변수는 LRS에서 유효성 검사되지 않다. Statements 데이터를 해석하는 시스템은 유효하지 않은 문자열 매개변수와 값에 대해 최선의 판단력을 사용하여 해석하거나 무시할 수 있다.

다음 매개변수는 나열된 상호작용 Type에 대한 목록 문자열을 나타내는 문자열의 시작 부분에서 유효한다.

다음 매개변수는 나열된 상호작용 Type의 각 항목의 시작 부분에서 유효한다.

매개변수	기본값	Description	값	상호작용 Type
case_matters	false	항목 목록 내의 대소문자가 중요한지 여부.	true 또는 false	fill-in, long-fill-in
order_matters	true	항목 목록 내의 순서가 중요한지 여부.	true 또는 false	fill-in, long-fill-in, performance

다음 매개변수는 나열된 상호작용 Type의 각 항목에서 유효한다.

매개변수	Description	값	상호작용 Type
lang	항목 내에서 사용된 언어.	RFC 5646 언어 태그	fill-in, long-fill-in, performance (문자열 응답만 해당)

Requirements

상호작용 활동(Interaction Activities)은 유효한 interactionType을 가져야 한다.
상호작용 활동(Interaction Activities)은 활동 Type http://adlnet.gov/expapi/activities/cmi.interaction을 가져야 한다.
LRS는 유효한 interactionType을 소비한 후 Interaction Activities에 대한 나머지 Property을 Interaction Activities에 대해 지정된대로 유효성을 검사하고, Interaction Activities에 대한 나머지 Property이 Interaction Activities에 대해 유효하지 않은 경우 400 Bad Request를 반환할 수 있다.
LRS는 응답 패턴과 관련된 문자 제한을 강제로 설정해서는 안 된다.
LRS는 어떤 interactionType의 경우에도 correctResponsesPattern 배열의 길이를 제한해서는 안 된다.

상호작용 구성 요소는 다음과 같이 정의된다:

Property	Type	Description	Required
id	문자열	목록 내에서 상호작용 구성 요소를 식별한다.	필수
description	언어 맵	상호작용 구성 요소에 대한 Description (예: 다중 선택 상호작용에서 특정 선택지의 텍스트)	선택

interactionType에 따라 상호작용 활동은 상호작용 구성 요소 목록을 포함하는 추가 Property을 가질 수 있다. 이러한 추가 Property을 "상호작용 구성 요소 목록"이라고 한다. 다음 표에서는 주어진 interactionType에 해당하는 Interaction Activity의 지원되는 상호작용 구성 요소 목록을 보여줍니다.

interactionType	지원되는 interaction component list	Description
choice, sequencing	choices	상호작용에서 선택 또는 순서 지정을 위한 옵션 목록
likert	scale	Likert 척도에서 사용 가능한 옵션 목록
matching	source, target	매칭 상호작용에서 매칭해야 하는 소스 및 대상 목록
performance	steps	성과 상호작용을 구성하는 요소 목록
true-false, fill-in, long-fill-in, numeric, other	[구성 요소 목록을 지원하지 않음]

Requirements

Interaction Components 배열 내에서 모든 id 값은 고유해야 한다.
상호작용 구성 요소의 id 값은 공백을 포함해서는 안된다.

예시

각 cmi.interaction Type에 대한 활동 정의 예제는 부록 C를 참조하십시오.

2.4.4.2 Agent 또는 Group을 Object로 지정할 때

Requirements

Agent 또는 Group을 Object로 지정하는 Statements는 "objectType" Property을 지정해야 한다.

Agent에 대한 자세한 내용은 Actor 섹션을 참조하십시오.

2.4.4.3 Object가 Statement인 경우

Rationale

Statement를 Object로 사용하는 두 가지 가능성이 있다. 첫 번째로, Statement Reference를 사용하여 이미 존재하는 Statement 형태를 Object로 사용할 수 있다. Statement References의 일반적인 사용 사례는 독립적인 이벤트로 추적할 수 있는 경험에 대한 평가 또는 의견을 달거나, Statement를 무효화하는 특별한 경우도 해당된다. 두 번째로, SubStatement를 사용하여 새로운 Statement로 Object를 만들 수 있다. 각 Type은 아래에서 정의된다.

Statement References (Statement 참조)

Description

Statement Reference는 다른 이미 존재하는 Statement를 가리키는 포인터이다.

Requirements

Statement Reference는 objectType Property을 StatementRef로 지정해야 한다.
Statement Reference는 id Property을 Statement의 UUID로 설정해야 한다. LRS는 UUID가 존재하는 Statement와 일치하는지를 검증할 필요가 없다.

Statement Reference Object의 모든 Property

Property	Type	Description	Required
objectType	문자열	이 경우 반드시 StatementRef 여야 한다.	필수
id	UUID	Statement의 UUID이다.	필수

예제

어떤 "Statement"가 이미 id가 8f87ccde-bb56-4c2e-ab83-44982ef22df0인 "Statement"로 저장되어 있다고 가정하면, 아래 예제는 원본 "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!"
             }
}

SubStatements (하위 문장)

Description SubStatement(하위 문장)은 포함하는 Statement의 일부로 포함되는 StatementRef와 유사하지만, StatementRef와 달리 발생한 이벤트를 나타내지 않다. 예를 들어, 잠재적인 미래 Statement의 예언이나 교사가 학생을 평가할 때 학생이 실제로 그 행동을 수행하지 않았더라도 교사가 찾는 행동을 Description하는 데 사용할 수 있다.

Requirements

SubStatement는 "objectType" Property을 "SubStatement"로 지정해야 한다.
SubStatement는 다른 SubStatement Requirements과 함께 Statement로 유효성을 검사해야 한다.
SubStatement는 "id", "stored", "version", 또는 "authority" Property을 가져서는 안 된다.
SubStatement는 자체적으로 SubStatement를 포함해서는 안 된다. 즉, 중첩될 수 없다.

예제

SubStatements의 흥미로운 사용 사례 중 하나는 의도를 나타내는 Statements를 만드는 것이다. 예를 들어, SubStatements를 사용하여 다음과 같은 형식의 Statements를 만들 수 있다: "<I> <planned> (<I> <did> <this>)", 이를 통해 "나는 '멋진 웹사이트'를 방문하기로 계획했다"는 논리적인 상태를 나타낼 수 있다.

{
             "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": {
                                       "objectType": "Activity",
                                       "id":"<http://example.com/website>",
                                       "definition": {
                                                    "name" : {
                                                                 "en-US":"Some Awesome Website"
                                                    }
                                       }
                          }
             }
}

2.4.5 결과

Description

Result Object의 선택인 Property으로, 해당 Statement와 관련된 측정 결과를 나타낸다.

Details

아래 표는 Score Object의 Property을 정의한다.

Property	Type	Description	Required
scaled	-1에서 1 사이의 십진수	스케일링 및/또는 정규화로 수정된 경험과 관련된 점수	권장
raw	min 및 max (있는 경우)	문장에 Description된 경험에서 Agent가 달성한 점수. 스케일링 또는 정규화로 수정되지 않다.	선택
min	min 및 max (있는 경우)	문장에 Description된 경험에 대한 가능한 가장 낮은 점수	선택
max	min 및 max (있는 경우)	문장에 Description된 경험에 대한 가능한 가장 높은 점수	선택

Score Object의 Property은 SCORM 2004 4th Edition에서 정의된 cmi.score의 해당 Property을 기반으로 한다. "scaled" 및 "raw" Property은 스케일링 및 정규화가 다른 Community of Practice 내에서 Learning Record Providers에 의해 다르게 적용될 수 있기 때문에 직접적으로 관련되지 않을 수 있다. 스케일링 및 정규화는 이 명세의 범위를 벗어납니다.

Requirements

Score Object는 논리적으로 퍼센트 기반의 점수가 알려진 경우 "scaled"를 포함해야 한다.
Score Object는 진행 또는 완료와 관련된 점수에 사용해서는 안 된다. 대신, (가능하면 범용적인 Community of Practice에서 제공되는) 확장을 고려하십시오.

2.4.6 context

Description Statement에 Context 정보를 추가할 수 있는 선택인 Property이다. 모든 "Context" Property은 선택이다.

Rationale

"Context"의 Property은 Statements 일부 상황에 맞는 정보를 추가할 수 있는 장소를 제공한다. Statements은 경험에 대한 강사, 팀 기반 활동의 일부로 이런 경험이 발생한 경우, 경험이 어떤 더 넓은 활동에 어떻게 부합하는지 등의 정보를 저장할 수 있다.

Details

다음 표에는 Context Object의 Property이 포함되어 있다.

Property	Type	Description	Required
registration	UUID	Statement가 연결된 등록 정보.	선택
instructor	Agent (Group일 수 있음)	Statement와 관련된 강사 (Statement의 Actor로 포함되지 않은 경우).	선택
team	Group	Statement와 관련된 팀 (Statement의 Actor로 포함되지 않은 경우).	선택
contextActivities	contextActivities Object	이 Statement와 관련된 학습 활동 context Type의 맵.	선택
revision	String	이 Statement와 관련된 학습 활동의 수정 버전. 형식은 자유롭다.	선택
platform	String	이 학습 활동 경험에서 사용된 플랫폼.	선택
language	String (RFC 5646로 정의됨)	이 Statement에서 기록된 경험에 적용되는 언어를 나타내는 코드 (주로) 경우, 가능한 경우와 알려진 경우.	선택
statement	Statement Reference	이 Statement의 context로 고려할 다른 Statement.	선택
extensions	Object	이 Statement와 관련된 도메인별 context의 맵. 예를 들어 비행 시뮬레이터에서 고도, 공기 속도, 바람, 자세, GPS 좌표가 모두 관련이 있을 수 있다. (확장 참조)	선택

Requirements

"revision" Property은 Statement의 Object가 Activity인 경우에만 사용해야 한다.
"platform" Property은 Statement의 Object가 Activity인 경우에만 사용해야 한다.
"language" Property은 적용되지 않거나 알려지지 않은 경우에는 사용해서는 안 된다.
"revision" Property은 일반적인 문제 수정(예: 맞춤법 오류)을 추적하는 데 사용해야 한다.
"revision" Property은 학습 목표, 교육 방법 또는 자산의 중대한 변경이 있는 경우 사용해서는 안 된다. (새로운 Activity id를 대신 사용하면 된다).

참고: xAPI 범위 내에서 Revision은 행동적 영향이 없다. 데이터를 해석하고 표시하는 데 사용할 수 있도록 저장되기만 한다.

2.4.6.1 Registration Property (등록 속성)

Rationale/Details LRS가 LMS(Learning Management System)의 핵심 부분인 경우 LMS는 등록 개념을 지원하는 경우가 많습니다. Experience API는 등록 개념을 더 넓게 적용한다. 등록은 시도, 세션일 수도 있으며 여러 활동에 걸칠 수 있다. 활동을 완료하면 등록이 종료되는 것을 기대하지 않다. 또한 등록은 단일 Agent에 국한되지 않을 수 있다.

등록은 State 리소스 내에서 문서를 저장할 때도 사용되며, 북마크용이다. 일반적으로 동일한 등록은 동일한 학습 경험에 대한 Statement 및 State 리소스에 대한 요청에 모두 사용되어 경험에 대한 모든 데이터가 일관되게 기록된다.

2.4.6.2 ContextActivities Property (컨텍스트 활동 속성)

Description

이 Statement와 관련된 학습 활동 context Type의 맵이다.

Rationale

많은 Statements는 단 하나의 (Object) 활동에만 관련되는 것이 아니라 다른 문맥적으로 관련 있는 활동과 관련이 있다. "contextActivities" Property은 이러한 관련 활동을 구조화된 방식으로 나타낼 수 있도록 한다.

Details

네 가지 유효한 context Type이 있다. 특정 Statement에는 모든, 어떤 Type도 포함되지 않을 수 있다.

Parent: 직접적으로 Statement의 Object인 활동과 관련된 활동이다. 대부분의 경우, 하나 또는 여러 개의 합리적인 부모 또는 없음이 있으며, 여러 개는 아닙니다. 예를 들어, 퀴즈 문제에 관한 Statement는 퀴즈를 부모 활동으로 갖게 될 것이다.
Grouping: 직접적인 관계가 없는 활동과 관련된 활동이다. 예를 들어, 자격증의 일부인 과정이다. 해당 과정에는 여러 클래스가 있다. 과정은 클래스를 부모로 갖고, 자격증은 클래스를 Group으로 갖게 된다.
Category: Statement를 범주화하는 데 사용되는 활동이다. "tag"가 동의어가 될 수 있다. 범주는 xAPI 동작 프로필 및 기타 범주화를 나타내는 데 사용되어야 한다. 예를 들어, Anna가 생물학 시험을 시도하고, Statement가 cmi5 프로필을 사용하여 추적되었으며, Statement의 활동은 시험을 참조하고 범주는 cmi5 프로필이다.
Other: 다른 Property에 맞지 않는 context 활동이다. 예를 들어, Anna가 생물학 시험을 위해 교과서를 공부한다. Statement의 활동은 교과서를 참조하고, 시험은 다른 Type의 context 활동이다.

단일 활동 객체는 0.95 Statement와 호환되도록 허용되므로, 1.0.0 버전을 고려할 때 주의해야 한다.

Requirements

contextActivities Object의 모든 키는 parent, grouping, category 또는 other 중 하나여야 한다.
contextActivities Object의 모든 값은 단일 활동 객체 또는 활동 객체의 배열이어야 한다.
LRS는 contextActivities Object의 모든 값을 동일한 활동을 포함하는 배열로 반환해야 하며, 이 배열은 단일 활동 객체인 경우에도 동일한 활동을 포함해야 한다.
학습 기록 공급자는 contextActivities Object의 모든 값을 단일 활동 객체가 아닌 활동 객체의 배열로 변환해야 한다.

예제 다음의 계층 구조를 고려해보세요: "질문 1부터 6"은 "시험 1"의 일부로 간주되며, "시험 1"은 "대수 1" 과목에 속한다. 여섯 개의 문제는 "시험 1"을 부모로 갖고 있으며, "대수 1"에 대한 다른 Statement와 함께 Group화된다. 이러한 계층 구조를 완전히 반영하려면, Statement의 Object가 Agent가 아닌 Activity인 경우에 유용한다. "Andrew가 context로 '대수 1'을 가진 '앤드류가 벤을 멘토링함'".

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

2.4.7 Timestamp (타임스탬프)

Description

경험이 발생한 시간이다.

Details

"Timestamp" Property은 Timestamp Type이다. ISO 8601의 일반적인 형식에 따라 포맷이 지정되며, 이 Statement 내에서 Description된 이벤트가 발생한 시간에 해당한다. LRS에 제출되는 Statement에 포함되지 않은 경우, LRS는 저장된 경우와 동일한 값을 사용하여 채웁니다.

Statement의 "timestamp Property"은 Statement가 저장된 시간인 "stored" Property과 다를 수 있다. 즉, 경험이 발생한 시점과 해당 Statement가 LRS에 의해 수신되기까지의 지연이 있을 수 있다.

경험이 시간 동안 발생하는 경우 "timestamp" Property은 경험의 시작, 끝 또는 경험 중 어떤 지점을 나타낼 수 있다. 다양한 경험에 대한 타임스탬프를 기록하기 위한 적절한 지점은 관행 공동체에서 정의할 것으로 예상된다. 예를 들어, 레스토랑에서 식사 경험을 기록할 때 경험의 시작 지점을 기록하는 것이 가장 적합할 수 있으며, 자격증 완료 경험을 기록할 때는 경험의 끝 지점을 기록하는 것이 가장 적합할 수 있다. 이러한 예는 Description적인 목적으로만 제공되었으며 강제적인 것은 아닙니다.

Requirements

Timestamp 데이터 Type에 관한 Requirements은 섹션 4.5 ISO 8601 Timestamps를 참조하라.
"timestamp" Property은 제공되지 않은 경우 LRS에서 "stored" Property의 값으로 설정되어야 한다.
"timestamp" Property은 경험 중 어떤 지점도 나타낼 수 있으며 반드시 시작 또는 끝이 아니어야 한다.
학습 기록 공급자는 Statement의 "timestamp" Property에 미래 시간을 사용해서는 안 된다.
SubStatement는 미래의 "timestamp" Property을 가질 수 있다.
시계 오류로 인한 문제를 방지하기 위해 LRS는 현재 시간보다 큰 값을 가진 타임스탬프를 거부해서는 안 된다.

2.4.8 Stored (저장됨)

Description Statement가 LRS에 의해 저장된 시간이다. 이는 LRS가 Statement를 수신한 시간과 저장될 때까지의 어떤 시간이든 될 수 있다.

Details

"stored" Property은 Timestamp Type이다. "stored" Property은 Statement가 저장된 정확한 시간이다.

Requirements

Timestamp 데이터 Type에 관한 Requirements은 아래의 ISO 8601 Timestamps를 참조하라.
"stored" Property은 LRS에 의해 설정되어야 하며, LRS는 받은 Statement의 "stored" Property에 현재 또는 과거 시간을 사용해야 한다.

2.4.9 Authority (권한)

Description

권한 Property은 이 Statement가 참된 것임을 주장한 주체(누가 또는 무엇이 주장했는지)에 대한 정보를 제공한다.

Details

주장 권한은 인증된 사용자 또는 일부 시스템 또는 애플리케이션을 나타낸다.

Requirements

권한은 Agent 여야 하며, 3-legged OAuth의 경우 두 개의 Agent로 구성된 Group이어야 한다. 두 개의 Agent는 응용 프로그램과 사용자를 함께 나타낸다.
사용자가 직접 연결하는 경우(HTTPS 기본 인증을 사용하는 경우) 또는 Group의 일부로 포함되는 경우, LRS는 사용자를 Authority의 전체 Agent로 포함해야 한다.
모든 저장된 Statements에 권한이 있도록 해야 한다.
LRS는 저장하는 모든 Statements의 권한을 덮어쓰도록 해야 한다(보내진 Statement의 권한에 따라 검증한 후 덮어써야 함).
LRS는 제출된 권한을 변경하지 않을 수 있지만, 강력한 신뢰 관계가 설정된 경우에만 주의를 기울여 변경해야 한다.
사용자가 직접 연결하는 경우(HTTPS 기본 인증을 사용하는 경우) 또는 3-legged OAuth의 일부로 사용자가 포함된 경우, 사용자를 법적으로 식별할 수 있는 Property 중 하나로 식별해야 한다.

OAuth 자격증명을 권한으로 사용

Description

OAuth 사용을 위한 워크플로우이다. 2-legged 및 3-legged OAuth를 모두 지원한다.

Details

이 워크플로우는 확인된 OAuth 연결을 사용하여 저장된 Statement를 저장한다고 가정하며, LRS는 Statement의 권한 Property을 만들거나 수정한다.

3-legged OAuth 워크플로우에서 인증은 OAuth 소비자와 OAuth 서비스 프로바이더의 사용자 모두를 포함한다. 예를 들어, Twitter 플러그인이 Facebook 계정에서 승인한 요청은 Twitter를 클라이언트 응용 프로그램, 사용자로서의 그들 자신, 그리고 두 가지의 고유한 조합으로서 특정 자격증을 포함한다.

Requirements

권한은 OAuth 소비자를 나타내는 Agent 객체를 포함해야 하며, 3-legged OAuth의 경우 Group의 일부로 나타낼 수도 있다.
OAuth 소비자를 나타내는 Agent는 계정을 식별하기 위해 사용해야 한다.
OAuth 소비자를 나타내는 Agent는 계정의 "name" Property의 값으로 소비자 키를 사용해야 한다.
OAuth 소비자를 나타내는 Agent가 등록된 응용 프로그램인 경우 계정의 "homePage" Property의 값으로 토큰 요청 엔드포인트를 사용해야 한다.
OAuth 소비자를 나타내는 Agent가 등록되지 않은 응용 프로그램인 경우 계정의 "homePage" Property의 값으로 임시 자격증 엔드포인트를 사용해야 한다.
Agent가나 Agent Group으로서의 권한 Property에서 응용 프로그램 부분을 신뢰해서는 안 된다(여러 등록되지 않은 응용 프로그램이 동일한 소비자 키를 선택할 수 있으므로 임시 자격증과 계정 이름의 이 조합을 확인하는 일관된 방법이 없다.).
각 등록되지 않은 소비자는 고유한 소비자 키를 사용해야 한다.

예시

OAuth 소비자와 사용자의 페어링

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

2.4.10 Version (버전)

Description

Statements 내의 버전 정보는 학습 기록 소비자가 정신을 차릴 수 있도록 도와줍니다. Statement 데이터 모델은 모든 1.0.x 버전을 통해 일관되게 보장되므로 이러한 LRS 간의 데이터 흐름을 지원하기 위해 LRS에게는 수용되는 Statement 버전에 대한 몇 가지 유연성이 부여된다.

Requirements

버전은 Versioning에서 API 버전 헤더에 지정된 대로 포맷되어야 한다.

LRS Requirements

LRS는 그들이 그 외에 유효성을 검사하는 경우 버전이 1.0.으로 시작하는 모든 Statements를 수용해야 한다.
버전이 지정되었지만 1.0.으로 시작하지 않은 모든 Statements를 LRS는 거부해야 한다.
LRS에서 반환된 Statements는 받아들여진 버전을 유지해야 한다. 버전이 지정되지 않은 경우 버전은 1.0.0으로 설정되어야 한다.

학습 기록 제공자 Requirements

학습 기록 제공자가 Statement 버전을 설정하는 경우, 그것은 1.0.0으로 설정해야 한다.
학습 기록 제공자는 가능하면 Statement 버전을 설정하지 않아야 한다.

참고: "version" Property이 최신 패치 버전이 아닌 1.0.0 값을 포함해야 하는 Requirements은 그 이유가 있다. 1.0.x의 어떤 버전의 Statement도 1.0.0 데이터 모델을 준수한다. 실제로 하나의 Statement는 명세의 다른 패치 버전을 따르는 여러 요청에 여러 번 포함될 수 있다. 어떤 요청에서 사용되는 "X-Experience-API-Version" 헤더를 통해 따르는 명세의 패치 버전을 결정할 수 있다.

2.4.11 Attachments (첨부)

Rationale

어떤 경우에는 Attachment가 학습 기록의 논리적으로 중요한 부분이다. 에세이, 비디오 등일 수 있다. 이러한 Attachment의 또 다른 예는 경험의 결과로 부여된 (이미지) 자격증이다. 이러한 Attachment를 LRS에 저장하고 검색할 수 있는 방법이 필요하다.

Details

아래 표는 Attachment 객체의 모든 Property을 나열한다.

Property	Type	Description	Required	응답 요청 파라미터
usageType	IRI	Attachment의 사용 방법을 식별한다. 예를 들어, "완료 인증서"를 포함하는 것이 기대되는 사용 사례 중 하나이다. 이러한 사용 사례에 해당하는 IRI는 코인되어 완료 인증서 Attachments과 함께 사용되어야 한다.	필수
display	Language Map	Attachment의 표시 이름(제목)이다.	필수
description	Language Map	Attachment에 대한 Description이다.	선택
contentType	Internet Media Type	Attachment의 콘텐츠 Type이다.	필수	Content-Type
length	Integer	Attachments 데이터의 길이(octets)이다.	필수	Content-Length
sha2	String	Attachments 데이터의 SHA-2 해시이다. 이 Property은 fileUrl도 지정된 경우에도 항상 필요한다.	필수	X-Experience-API-Hash
fileUrl	IRL	Attachment 데이터를 검색하거나 이전에 검색 가능한 URL이다.	선택

SubStatement에 대한 Attachments을 포함하려면 Statement의 Attachment 객체에 Attachments을 포함하고 Statement와 같은 방식으로 페이로드를 포함하는 것이 강력하게 권장된다.

2.5 Statements 검색

Description Statement 리소스에서 쿼리를 수행하여 Statements 컬렉션을 검색할 수 있다. 자세한 내용은 Statement 리소스를 참조하십시오.

Details 다음 표는 Statement 리소스에 대한 쿼리 결과의 데이터 구조를 보여줍니다.

Property	Type	Description	Required
statements	Array of Statements	Statements의 목록이다. 반환된 목록이 제한되었고 더 많은 결과가 있는 경우, "more" Property이 포함된 컨테이너 내의 "statements" Property에 위치한다. 일치하는 Statements가 없는 경우, 이 Property에는 빈 배열이 포함된다.	필수
more	IRL	추가 결과를 가져올 수 있는 상대적인 IRL이다. 전체 경로와 선택으로 쿼리 문자열을 포함하지만 스킴, 호스트 및 포트는 제외된다. 더 이상 결과를 가져올 수 없는 경우 빈 문자열이다.	필수 (목록이 제한된 경우), 그렇지 않으면 선택 사항이다.

Requirements

"more" Property에서 검색한 IRL은 반환된 후 최소 24시간 동안 사용 가능해야 한다.
LRS는 IRL 및 관련된 쿼리 데이터를 저장할 필요 없이 "more" Property IRL 내에서 필요한 모든 정보를 포함해야 한다.
LRS는 "more" Property 내에서 극단적으로 긴 IRL을 생성하면 안 된다.
LRS는 "more" Property에서 검색한 IRL이 액세스될 때 원래 쿼리 시점에서 포함되어야 했던 Statements를 포함하고 그 사이에 무효 처리된 Statements를 제외하도록 동일한 쿼리를 다시 실행할 수 있다.
또는 LRS는 이 방법을 사용하여 "more" Property에 반환할 Statements 목록을 저장(cache)할 수 있으며 이 방법을 사용하는 경우 무효 처리된 Statements를 저장된 Statements 목록에서 제거할 수 있다.
학습 기록 소비자는 "more" Property에서 반환된 IRL에서 의미를 해석하려고 노력해서는 안 된다.

2.6 Signed Statements (서명된 진술)

Description

서명된 Statement에는 Statement의 신뢰성과 무결성을 강력하고 지속적으로 입증하기 위한 디지털 서명이 포함될 수 있다.

Rationale

일부 Statements는 규제나 법적인 중요성이 있거나, 신뢰성과 무결성의 강력하고 지속적인 증거가 필요할 수 있다. 이러한 Statements를 환경을 신뢰하지 않고 또는 해당 환경에 액세스하지 않고도 확인해야 할 수도 있다. 디지털 서명을 통해 제3자가 이러한 Statements를 확인할 수 있게 된다.

Details

서명된 Statements는 usageType 및 "application/octet-stream" contentType을 사용하는 Attachments로서 JSON 웹 서명 (JWS)을 포함한다. 이를 통해 서명을 추가하기 전의 Statement의 원래 직렬화가 포함된다. 상호 운용성을 위해 "RSA + SHA" 시리즈의 JWS 알고리즘이 선택되었으며, 서명자의 발견 가능성을 위해 X.509 인증서를 사용해야 한다.

Signature Requirements

서명된 Statement는 "http://adlnet.gov/expapi/attachments/signature" usageType 및 "application/octet-stream" contentType을 사용하는 디지털 서명 (JWS)을 포함해야 한다.
JSON 웹 서명을 생성하기 위해 JWS Compact Serialization을 사용하는 것이 좋습니다. JWS JSON Serialization의 사용은 강력하게 권장되지 않으며 다른 시스템과 상호 운용성이 낮을 가능성이 있으며 향후 버전에서 금지될 예정이다.
JWS 서명은 서명이 추가되기 전의 완전한 Statement의 유효한 JSON 직렬화를 페이로드로 가져야 한다.
JWS 서명은 "RS256", "RS384" 또는 "RS512" 알고리즘을 사용해야 한다.
JWS 서명은 X.509 인증서와 연관된 개인 키를 기반으로 만들어져야 한다.
X.509를 사용하여 서명한 경우 JWS 헤더에 연관된 인증서 체인을 포함해야 한다.

LRS Requirements

서명이 잘못된 서명을 포함한 Statements를 저장하는 요청은 400 Bad Request로 거부되어야 한다.
LRS는 거부된 statement의 응답에 메시지를 포함해야 한다.
서명이 잘 형성된 것인지 확인하기 위해 LRS는 다음을 수행해야 한다.
JWS 서명을 디코딩하고 JWS 서명 페이로드에서 Statement의 서명 추가 전 원래 직렬화를 로드한다.
원래 Statement가 수신된 Statement와 논리적으로 동등한지 확인한다. Statement comparison Requirements을 참조하십시오.
JWS 헤더에 X.509 인증서가 포함된 경우 JWS로 정의된대로 해당 인증서에 대한 서명을 확인한다.
위에서 Description한 서명 Requirements이 충족되었는지 확인한다.

참고 포함된 X.509 인증서를 사용하여 검증하는 단계는 서명에서 발생한 오류를 잡기 위한 것으로, 보안 조치가 아닙니다. 서명된 Statement를 인증하는 단계는 필요한 확신 수준에 따라 다를 것이며, 이 사양의 범위를 벗어납니다.

클라이언트 Requirements

클라이언트는 위에서 Description한 서명 Requirements을 따라야 한다.
클라이언트는 LRS가 서명을 수락한 경우에도 서명이 유효하다고 가정해서는 안 된다.

예제 예제 서명된 Statement에 대한 자세한 내용은 부록 D: 서명된 Statement 예제를 참조하십시오.

3.0 메타 데이터
Metadata

3.1 IRI Requirements

xAPI는 식별자로 IRI를 사용한다. IRI 사용은 고유성을 보장하고 해결 가능성을 촉진한다. LRS 및 Learning Record Provider는 각 IRI에 대한 책임을 아래에 Description된 대로 가지고 있다. Activity Definitions에는 여기에서 찾을 수 있는 추가 규칙이 있다.

메타데이터 제공자 Requirements

이러한 Requirements은 새로운 IRI를 정의하는 Learning Record Provider에도 적용된다.

새로운 IRI를 정의하는 메타데이터 제공자는 자체적으로 제어하거나 컨트롤러로부터 사용 허가를 받은 IRI만 사용해야 한다(SHOULD*).
새로운 Verb IRI를 정의하는 메타데이터 제공자는 자체적으로 제어하거나 컨트롤러로부터 사용 허가를 받은 IRI만 사용해야 한다.
적합한 식별자가 이미 있는 경우, 메타데이터 제공자는 해당 기존 식별자를 사용하고 새로운 식별자를 만들어서는 안 된다.
기존 식별자를 재사용할 때, 메타데이터 제공자는 정확한 문자 동등 IRI가 사용되도록 해야 한다(SHOULD*).
메타데이터 제공자는 적합한 식별자가 이미 존재하지 않는 경우 자체 식별자를 만들 수 있다.
식별자를 정의할 때, 메타데이터 제공자는 단일 페이지에서 여러 식별자에 대한 정의를 포함할 수 있도록 앵커가 포함된 IRI를 사용할 수 있다.
식별자를 정의할 때, 메타데이터 제공자는 소문자 IRI를 사용해야 한다.

LRS Requirements IRI를 저장하거나 비교할 때, LRS는 RFC 3987의 5.3.1 (간단한 문자열 비교) 및 5.3.2 (구문 기반 정규화)에 Description된 하나 이상의 접근 방법만 사용해야 하며, 같은 RFC의 5.3.3 (스킴 기반 정규화) 또는 5.3.4 (프로토콜 기반 정규화) 또는 다른 어떤 접근 방법도 사용해서는 안 된다(SHOULD*). LRS는 IRI가 포함되어 있는 매개 변수 및 필드에서 모든 IRI와 동일한 IRI 비교 및 정규화 규칙을 적용해야 한다.

3.2 호스팅된 메타데이터

Description

식별자에 대한 추가 정보는 Statement 내에서 제공될 수 있으며, 식별자 IRI가 가리키는 위치에서 호스팅될 수 있다. Statement에 메타데이터를 포함하면 메타데이터를 해결하지 않고도 IRI에 대한 메타데이터를 표현할 수 있다. IRI 위치에 메타데이터를 호스팅하면 해당 IRI의 소유자가 해당 IRI에 대한 정규 메타데이터를 정의할 수 있다.

Details

이 사양에서 사용되는 여러 Type의 IRI 식별자가 있다.

Activity id에 대한 호스팅된 메타데이터 구조는 Activity Definition Object.에서 확인할 수 있다.

다른 모든 식별자에 대한 호스팅된 메타데이터 구조는 아래 형식을 참조하십시오.

Property	Type	Description	Required
name	Language Map	인간이 읽을 수 있는/시각적인 이름. Verb의 경우 이는 Statement의 "display" Property과 동등한다.	선택
description	Language Map	Description	선택

호스팅된 메타데이터는 위에서 Description한 JSON 개체를 포함하는 문서로 구성된다. 이 호스팅된 메타데이터가 제공되는 경우 해당 식별자에 대한 정보의 정규 소스이다. xAPI를 구현하는 사람들은 Activity id를 제외한 모든 Type의 IRI 식별자에 대해 확립되고 널리 사용되는 식별자를 찾아보고 사용하는 것이 좋습니다.

메타데이터 제공자 Requirements

메타데이터는 식별자와 함께 제공될 수 있다.
메타데이터가 제공되면 "name" 및 "description"을 모두 포함해야 한다(SHOULD*).
위에서 언급한 식별자 IRI 중 하나에 대한 메타데이터 제공자는 해당 IRI의 의도된 사용에 대한 인간이 읽을 수 있는 Description을 IRI에서 액세스할 수 있도록 해야 한다.
위에서 언급한 식별자 IRI 중 하나에 대한 JSON 메타데이터를 요청할 때 해당 IRI에서 사용 가능한지 확인해야 한다(Content-Type이 application/json으로 요청됨).
IRI가 Activity를 나타내는 경우 메타데이터 제공자는 Activity Definition JSON 형식을 사용하여 메타데이터를 호스팅할 수 있으며, Content-Type이 application/json으로 설정된다.

LRS Requirements

LRS는 메타데이터 소비자로서 작동하고 IRI 식별자를 해결하려고 시도할 수 있다.
Activity IRI가 URL인 경우 LRS는 그 URL을 GET하려고 시도하고 HTTP 헤더에 다음을 포함해야 한다: Accept: application/json, /. 이 작업은 LRS가 처음 Activity id를 만난 후 가능한 한 빨리 수행되어야 한다.
유효한 Activity Definition으로 파싱할 수 있는 JSON을 URL로부터로드한 후 LRS는 로드된 정의를 해당 Activity의 정규 정의에 통합해야 한다. 로드된 정의에 포함되지 않은 이름 또는 정의를 유지해야 한다.
LRS가 Activity id로 사용되는 URL에서 파싱 가능한 Activity Definition을 로드할 수 있는 문서를 로드하는 경우 LRS는 해당 Activity의 정의의 정규 표현을 결정할 때 이 정의를 고려할 수 있다.

메타데이터 소비자 Requirements

메타데이터 소비자가 IRI에서 메타데이터를 가져온 경우 해당 IRI에서 찾은 메타데이터가 해당 메타데이터에 포함된 Property 및 언어에 대해 권한이 있는 것으로 가정해야 한다.
메타데이터 소비자는 누락된 Details를 채우거나 제공되지 않았거나 로드할 수 없거나 메타데이터 소비자가 신뢰하지 않는 경우 호스팅된 메타데이터를 완전히 무시할 가능성이 큽니다. 다른 정보 소스를 사용하여 누락된 Details를 채울 수 있으며, 이 정보 소스에는이 사양을 사용하도록 동전화되지 않은 경우 특히 식별자의 IRI에서 저장된 다른 형식의 메타데이터가 포함될 수 있다.

4.0 특수 데이터 유형 및 규칙
Special Data Types and Rules

다음은이 사양에서 일반적으로 발견되는 추가 규칙이 필요한 데이터 Type이다.

4.1 확장

Description

확장은 Activity Definitions의 일부로, Statement의 "context" Property의 일부로 또는 Statement의 "result" Property의 일부로 사용할 수 있다. 각 경우 확장은 특정한 사용을 위해 이러한 Property을 확장하는 자연스러운 방법을 제공하는 것이 목적이다. 확장의 내용은 특정 애플리케이션에서 유용한 것이거나 전문 분야의 커뮤니티에서 사용하는 규약일 수 있다.

Details

확장은 맵으로 정의되며 논리적으로 그것들이 존재하는 Statement 부분과 관련이 있다. 확장의 값은 JSON 값 또는 데이터 구조 일 수 있다. "context" Property의 확장은 핵심 경험에 맥락을 제공하며 "result" Property의 확장은 어떤 결과와 관련된 요소를 제공한다. Activities 내에서 확장은 사용자 정의 애플리케이션이나 커뮤니티 내에서 Activity를 정의하는 데 도움이 되는 추가 정보를 제공한다. IRI 키 아래의 확장 값의 의미와 구조는 IRI를 제어하는 사람에 의해 정의된다.

Requirements

확장 맵의 키는 IRI여야 한다.
LRS는 확장 맵의 값에 기초하여 Statement를 거부해서는 안 된다.
Learning Record Providers는 가능한 한 많은 정보를 내장된 요소로 매핑하여 Experience API 호환 도구 간의 상호 운용성을 활용해야 한다.
모든 확장 IRI는 컨트롤러가 있어야 한다.
IRL 확장 키의 컨트롤러는 해당 IRL에서 지원되는 확장의 의도된 의미에 대한 인간이 읽을 수 있는 Description을 IRL에서 액세스할 수 있도록 해야 한다.

참고: 확장만으로 정의된 Statement는 다른 시스템에서 해석할 수 없으므로 의미가 없어집니다.

4.2 언어 지도

Description

언어 지도는 키가 RFC 5646 언어 태그이고 값이 해당 태그에서 지정된 언어의 문자열인 사전이다. 이 맵은 가능한 한 해당 언어의 문자열에 대한 지식을 기반으로 최대한 완전히 채워져야 한다.

일반적으로 각 언어 문자열에 대한 가장 짧은 유효한 언어 코드가 선호된다. ISO 639 언어 코드에 ISO 3166-1 국가 코드를 추가하면 기본 언어(예: 스페인어의 경우 es)와 지역(예: 멕시코에서 사용되는 스페인어 방언인 es-MX)을 지정할 수 있다. 특정 ISO 639 언어 코드만 알고있는 경우 가능한 ISO 3166-1 국가 코드를 추측하지 마십시오. 예를 들어, 기본 언어만 알고있는 경우(예: 영어) 상위 수준 언어 태그 en을 사용하면 된다. 구체적인 지역 변형을 알고있는 경우 전체 언어 코드를 사용하면 된다.

참고: 중국어 언어의 경우 zh로 표현되는 중요한 언어 다양성 때문에 ISO 639 언어 코드만으로는 충분하지 않다.

언어 지도 내 문자열의 내용은 일반 텍스트이다. HTML 태그나 마크다운과 같은 형식 코드는 렌더링되지 않고 사용자에게 문자열이 표시될 때 코드로 표시될 것으로 예상된다. 이 규칙의 중요한 예외는 언어 지도 객체가 확장 내에서 사용되며 해당 확장 IRI의 소유자가 특정 형식의 코드가 렌더링될 것이라고 명시적으로 명시한 경우이다.

4.3 IRIs

국제화 된 리소스 식별자 또는 IRI는 유일한 식별자로 해석 될 수도 있는 고유 식별자이다. 해결 않는 것은 필수 사항이 아니므로 IRL 대신 IRI/URI가 사용된다. 식별자에 사용되는 문자의 최대 유연성을 허용하기 위해 IRI는 ASCII 문자 집합 외의 일부 문자를 포함할 수 있는 IRI를 사용한다.

4.4 UUIDs

범용 고유 식별자 또는 UUID는 전 세계적으로 고유한 128비트 값을 나타낸다. IRI와 달리 UUID는 해결 가능성을 기대하지 않으며 완전히 다른 형식을 가집니다. UUID는 표준 문자열 형식이어야 한다. RFC 4122의 변형 2를 사용하는 것이 권장된다.

4.5 ISO 8601 타임스탬프

타임스탬프는 특정한 시간을 나타내는 형식이다. ISO 8601의 일반 형식에 따라 형식화된다. LRS에 보내진 명세서는 적어도 밀리 초까지 정밀도를 유지해야 할 것으로 예상된다.

Requirements

타임스탬프는 ISO 8601에 따라 형식화되어야 한다.
타임스탬프는 RFC 3339에서 Description한 형식을 사용하여 표현되어야 한다. 이 형식은 ISO 8601의 프로필이다.
타임스탬프는 최소한 초의 소수점 이하 3 자리까지의 정밀도를 보존해야 한다.
타임스탬프는 시간대를 포함해야 한다.
타임스탬프에 시간대가 포함된 경우 LRS는 참조 된 시점이 영향을받지 않는 한 원래 Statement에서 사용한 시간대와 다른 시간대를 사용하여 타임스탬프를 반환할 수 있다.
LRS는 타임스탬프를 UTC 시간대로 반환해야 한다.
타임스탬프는 초당 3 자리까지의 정밀도를 적어도 유지하거나 반올림하여 0.01 초까지 절단될 수 있다.

4.6 ISO 8601 기간

기간은 무언가가 소요된 시간을 나타내는 문자열이다.

Requirements

기간은 ISO 8601: 2004 (E) 섹션 4.4.3.2의 기간 형식을 사용하여 표현해야 한다. 대체 형식 (시간 점에 사용되는 형식과 일치하도록 허용되는 ISO 8601: 2004 (E) 섹션 4.4.3.3에 Description된 형식)은 사용해서는 안 된다.
Learning Record Providers는 최대 0.01 초의 정밀도를 제공해야 한다.
Learning Record Providers는 더 적은 정밀도를 제공할 수 있으며 예를 들어 대학 학위를 읽는 경우 정밀도는 월 또는 년일 수 있다.
0.01 초 정밀도를 초과하는 기간을 수신하면 LRS는 요청을 거부하지 않아야 하지만 "기간" Property을 0.01 초 정밀도로 절단할 수 있다.
기간을 비교할 때 0.01 초 정밀도를 포함하지 않아야 한다.

Example

Example	Description
PT4H35M59.14S	네 시간, 삼십오 분, 59.14 초.
PT16559.14S	위와 같은 시간 기간을 초로 표현한 것.
P3Y1M29DT4H35M59.14S	년, 월, 일을 포함한 지속 기간.
P3Y	대략 세 년간, 예: 자격 취득 완료.
P4W	네 주. 주는 다른 시간 기간과 결합될 수 없다. 'P4W1D'는 유효하지 않다.

아래 표는 일부 Example ISO 8601 기간을 제공한다. 이 목록은 전체적인 것이 아닌 참고 목적으로 제공된다. 예를 들어, 기간이 초(또는 초의 분수) 단위로 추적된다면 이것을 시, 분, 초로 변환할 필요가 없다.

728x90

저작자표시

'📂 데이터베이스 > ◾ EXPERIENCE API' 카테고리의 다른 글

xAPI 단어 사전 만드는 방법 (1)	2023.11.03
xAPI 동사(Verb)와 활동(Activity)의 차이 (1)	2023.11.01
[공식 문서 한글 번역판] xAPI docs 3.0 Communication 톺아보기 (1)	2023.10.31
[공식 문서 한글 번역판] xAPI docs 1.0 About 톺아보기 (2)	2023.10.31