안녕하세요, 주인장 이정구입니다. 이번에 검인정교과서와 한화의 주도 하에 프로젝트가 시작되는 디지털 교과서에 xAPI가 들어가게 됐습니다. 저도 그 프로젝트에 참여하게 됐고, 이제 막 시작 단계로 아직 어떻게 사용할 지에 대해서는 미지수지만 이해하기에 어렵다는 이야기를 들어 미리 공부하게 됐습니다.
아직 웹 상에서 디깅 해봤을 때, 정보가 많지 않아서 공식 문서에 의존할 수 밖에 없었습니다. 그래서 이번에 제가 공부하며 공식 문서를 한국어로 정리한 내용을 공유하고자 포스팅하게 됐습니다. 뭐 크롬 번역기로 돌린 상태로 봐도 무방하다만 똥번역이 은근 많고 생소한 단어도 많기 때문에 한땀한땀 읽어보며 번역하였습니다. 원어로 사용하는 부분이 많아서 그대로 단어 그대로 둔 경우가 많습니다. 본 내용을 읽을 때, 참고 부탁드립니다.
우선 xAPI에 대한 설명을 하자면, 다음과 같습니다. Experience API (또는 xAPI)는 학습 기술의 새로운 사양으로, 사용자가 가지고있는 광범위한 경험 (온라인 및 오프라인)에 대한 데이터를 수집 할 수있게 해줍니다. 이 API는 많은 기술의 개인 또는 그룹 활동에 대해 일관된 형식으로 데이터를 수집하고, 설사 규격과 다른 시스템이라 할지라도 xAPI의 간단한 어휘를 사용하여 활동 스트림을 수집하고 공유하여 안전하게 통신 할 수 있습니다. 바로 공식 문서를 읽어보면서 사용 방법을 알아보도록 하겠습니다.
1.0 소개
Introduction
Experience API (xAPI)는 학습 경험의 문서화와 전달을 촉진하기 위한 기술 명세로, 학습 경험을 설명하는 구조를 지정하고 이러한 설명을 전자적으로 교환하는 방법을 정의한다.
xAPI는 Advanced Distributed Learning (ADL) 이니셔티브의 노력으로, 미국에서 교육 및 훈련 관리와 전달을 표준화하고 현대화하기 위해 1997년에 설립됐다. 그 이후로 개인의 학습 경험을 형식적이고 구조화된 컴퓨터 기반 교육 이상으로 추적해야 함을 인식하는 데 인식이 점점 더 커지고 있다. 포지션에 대한 후보자의 적합성이나 다양한 작업 수행 능력을 평가할 때는 온라인 및 오프라인에서 발생하는 다양한 형식의 학습 경험을 고려해야 하지만 이 정보는 대부분 다양한 소스에 흩어져 있다. 이러한 필요성에서 xAPI 커뮤니티와 명세서가 탄생했다.
xAPI의 가정 :
- 학습 경험 및 그 결과에 대한 정보를 다양한 소스, 플랫폼 및 기술에 분산된 상태에서 분석할 필요가 있다.
- 이 정보를 수집, 저장 및 교환하는 데 공통으로 승인된 프레임워크를 개발하는 것이 이를 달성하는 가장 좋은 방법이다.
xAPI의 목표 :
- 다양한 맥락, 플랫폼 및 기술에서 기록된 학습 경험 및 그 결과를 이해하고 비교하기 쉽게 만드는 것이다.
- 학습 경험에 관한 정보를 생성, 수집, 저장 및 처리하는 서비스의 상호 운용성을 극대화하는 것이다.
- 이 명세를 준수하고 구현하는 응용 프로그램을 개발하려는 사람들에게 안내를 제공하는 것이다.
- 이 명세에 대한 준수 여부를 테스트할 수 있는 기준을 제공하는 것이다.
아래 문서에서는 이러한 목표를 달성하기 위해 설계된 xAPI 명세를 설명한다.
2.0 문서 사용법
How to Use This Document
이 문서는 Experience API(xAPI)를 어떻게 구현해야 하는지 설명하는 결정적인 문서이다. 이 문서는 이 기술을 구현하는 개인 및 조직을 대상으로 특별히 작성되었으며, 이러한 개인들이 서로 독립적이며 상호 운용 가능한 도구, 시스템 및 서비스를 개발하는 의도로 작성되었다.
가능한 한 이 문서에서 사용되는 언어와 포맷은 기술적이지 않은 독자들을 고려하여 작성되었다. 이 문서에서 특정한 부분을 'description' 또는 'rationale'로 표시한 것은 Experience API의 특정 측면에 대한 고수준 개요를 제공하기 위한 것이다. 'requirements', 'details' 또는 'examples '로 표시된 항목은 더 기술적인 내용이다.
이 명세서는 세 가지 부분으로 나누어진다. 제1부는 이 소개이다. 이 부분은 백그라운드, 고수준 개요 및 명세서의 나머지 부분을 읽는 방법에 대한 지침을 제공한다.
이 명세서의 제 2부에서는 이 명세서에서 사용되는 다양한 데이터 객체에 대한 데이터 모델을 정의한다. xAPI 데이터 모델 내에서 가장 중요한 객체는 ‘Statement’ 객체이다. 이 명세서는 Statement 객체의 속성(Actor, Verb, Object, Result 및 Context)과 이러한 속성의 값의 구문 규칙 및 표현 방법을 정의한다. 이 부분은 명세서를 구현하는 서비스가 일관된 데이터 구조를 따르도록 돕는다.
이 명세서의 제 3부에서는 명세서를 준수하는 서비스 간에 학습 경험에 관한 정보를 통신할 때 사용해야 하는 전송 방법을 설명한다. 이에는 요청 및 예상 응답의 형식이 포함된다. xAPI에서의 통신은 "학습 기록 저장소" (LRS)가 "컨텐츠"로부터 데이터를 받는 것에 제한되지 않는다. LRS는 "학습 기록 공급자"에서 "학습 기록 소비자" 또는 다른 LRS까지 다양한 서비스와 통신할 수 있다. xAPI는 REST 소프트웨어 아키텍처 스타일의 지침을 따르므로 데이터는 HTTP 요청과 응답을 통해 전송된다. 제3부에서는 LRS와 신뢰할 수 있는 "클라이언트" 간에 정보를 신뢰할 수 있는 방법으로 교환하기 위한 보안 방법도 정의한다.
2.1 MUST / SHOULD / MAY
xAPI 명세에 대한 준수와 관련하여 MUST, SHOULD 및 MAY 라는 용어로 식별된 세 가지 준수 수준이 있다. MUST 또는 MUST NOT 요구 사항을 구현하지 않는 서비스나 시스템은 준수하지 않는다. SHOULD 요구 사항을 충족하지 못하면 준수를 위반하는 것은 아니지만 명세서의 권장 사항을 준수하지 않는 것이다. MAY는 선택 사항을 나타내며, 개발자가 결정해야 하며 준수에 대한 결과가 없다. 이 용어들의 완전한 정의는 RFC 2119에서 찾을 수 있다.
SHOULD 뒤에 별표(*)가 올 경우 매우 강력한 권장 사항을 나타낸다. 이러한 권장 사항은 향후 버전에서 MUST 요구 사항이 될 예정이다. 이러한 권장 사항을 따르지 않으면 상호 운용성에 문제가 발생할 수 있으며 권장 사항의 구체적인 내용에 따라 다양한 문제가 발생할 수 있다. 이 권장 사항들은 이 버전에서는 MUST 요구 사항이 될 수 없으므로 변경이 불가능하다. xAPI 작업 그룹은 이러한 요구 사항을 MUST 요구 사항처럼 구현하는 것을 강력히 권장하며, 다른 권장 사항을 지원하면서도 이를 계속 지원할 것을 권장한다.
2.2 기술적 텍스트 및 테이블 해석 가이드라인
일반적으로 가이드라인이 기술적으로 보이거나 요구 사항처럼 보이면 해당 대로 해석해야 한다. 이는 특히 긴 설명이나 테이블의 경우에 특히 해당된다. 이러한 설명이나 테이블을 요구 사항 목록으로 나누는 것은 직관적이지 않고 길거나 해석하기 어려울 수 있다.
이 명세서 전체에서는 속성, 매개변수 등의 목록에 대한 요구 사항을 정의하는 데 테이블이 사용된다. 일반적으로 "optional" 이라는 개념은 객체를 생성하는 서비스와 관련이 있으며, 객체를 수신하고 해석하는 서비스는 해당 객체의 모든 속성을 해석할 수 있어야 한다. 속성이 선택 사항인 경우 데이터가 모든 상황에서 관련이 없을 수 있으므로, 데이터가 특정 상황에서 관련이 있다면 해당 속성이 채워질 것이다.
선택 사항인 속성이나 매개변수가 사용된 경우 해당 속성이나 매개변수가 포함된 객체의 속성 중에서 권장 또는 필수인 경우에만 해당 속성이나 매개변수가 권장 또는 필수이다.
명세서에서는 구현의 특정 측면에 관련된 요구 사항을 포함하지 않는 경우 해당 세부 사항이 명세서의 범위를 벗어나는 것으로 간주된다. 구현자가 합리적인 접근 방식을 결정하는 것이다. 이 명세서는 모호함을 피하려고 노력하며, 특정 영역에 요구 사항이 없더라도 일반적으로 해당 영역에 대한 이유를 제시한다.
3.0 직렬화와 JSON
Serialization and JavaScript Object Notation (JSON)
직렬화(Serialization)는 데이터 객체와 구조를 저장 또는 전송용 형식으로 번역하는 과정으로, 결과적인 직렬화를 통해 원래 데이터 객체를 재생성할 수 있는 방법이다. 일부 경우에는 데이터를 여러 가지 방법으로 직렬화할 수 있다. 예를 들어, 값이 true에 해당하는 불리언(boolean) 속성은 사용된 직렬화에 따라 true 또는 1로 표시될 수 있다.
xAPI는 직렬화에 대한 규칙으로 JSON을 따른다(따라서 불리언 값은 true 또는 false로 표시된다). 이 명세서에서 정의한 객체를 XML와 같은 다른 직렬화 방식을 사용하여 나타내는 것도 가능하다. 그러나 이 명세서의 범위를 벗어나며, 이 명세서에서 정의한 객체를 JSON 이외의 것으로 나타내는 것은 적합하지 않다.
JSON 내에서도 데이터를 직렬화하는 방법에는 변형이 가능할 수 있으며, 특히 시간에 관한 데이터 관련하여 데이터를 직렬화하는 방법이 다를 수 있다. 이것은 xAPI의 여러 기능이 시스템이 두 개의 Statements 이 동등한지 여부를 결정할 수 있는 능력에 의존하기 때문에 중요하다. Statements에 영향을 주는 속성에 대한 더 자세한 내용은 변경 불가성 및 예외 사항을 참고한다.
xAPI 내에서는 권장되진 않지만, JSON을 사용하면 개체가 빈 개체를 포함하는 속성을 가질 수 있다. Statements속성에 대한 데이터가 포함되지 않으면 속성이 전혀 사용되지 않는 것으로 예상되며, 모든 필수 속성은 값을 가져야 한다.
4.0 정의
Definitions
Activity: "나는 이것을 했다"에서 "이것"을 구성하는 객체 유형으로, Actor가 상호 작용한 대상이다. 활동은 교육 목적의 단위, 경험 또는 성과로, 동사와 의미 있는 조합으로 추적될 수 있다. 활동의 해석은 넓은 범위로, 활동은 실제나 가상의 의자와 같은 유형의 객체일 수 있다. xAPI 문장에서 "Anna가 케이크 레시피를 시도했다"에서 레시피는 xAPI 문장에서의 활동을 구성한다. 다른 활동의 예로는 책, e-러닝 코스, 하이킹, 미팅 등이 있다.
Activity Provider (AP): 이제는 학습 기록 공급자(Learning Record Provider)로 불린다. 이 변경은 활동 자체가 항상 소프트웨어의 책임이 아니라 추적 부분만 책임짐을 구별한다.
Actor: Statements을 사용하여 추적되는 개인 또는 그룹의 표현으로, 활동 내에서 작업을 수행한다. "나는 이것을 했다"에서 "나"에 해당한다.
Application Programming Interface (API): 소프트웨어 응용 프로그램 또는 도구에 접근을 허용하기 위해 생성된 규칙 및 표준의 집합이다.
Authentication: 신원을 확인하는 개념이다. 인증은 두 "신뢰할 수 있는" 당사자 간의 상호 작용을 허용한다.
Authorization: 역할을 기반으로 권한을 부여하는 것으로, 다른 당사자가 한 당사자를 "신뢰할 수 있는" 당사자로 만드는 프로세스이다.
Client: 요청을 통해 상호 작용할 수 있는 모든 엔터티를 가리키며 일부 예시로는 학습 기록 공급자, 학습 기록 소비자, 학습 기록 저장소(LRS), 학습 관리 시스템(LMS) 등이 있다.
Community of Practice (CoP): 공통의 목적, 역할 또는 목적에 연결된 실무자 그룹으로, 공통의 모드에서 작동한다. CoP는 특정 지식 도메인 또는 사용 사례 내에서 xAPI를 구현하는 데 중점을 두고 있다. CoP 또는 독립적인 개발자는 도메인별 어휘, 프로필 및 레시피를 작성할 수 있다. 이러한 실천 방법은 일반적으로 사용 사례를 정의하고 CoP 내에서 선호되는 다양한 어휘 용어, 동의어 및 관련 메타데이터를 정의하는 작업을 포함한다. 또한 기존의 어휘, 프로필 및 레시피를 다른 CoP 또는 xAPI 커뮤니티의 참가자가 이미 게시한 것을 재사용할 수 있다.
Document Profile Resource: 학습자 또는 활동에 관한 정보가 일반적으로 이름/문서 쌍 형식으로 유지되는 구조이다. 프로필과 혼동해서는 안 된다.
Endpoint: 서비스 지향 아키텍처에서의 진입점이다. xAPI는 통신이 발생하는 IRI를 엔드포인트로 정의함으로써 이 접근 방식을 반영한다.
Experience API (xAPI): 이 문서에서 정의된 학습 경험을 정의, 형식화 및 교환하는 데 사용되는 규칙의 집합이다. 독립적인 소프트웨어 프로그램이 이 정보를 교환하고 활용할 수 있도록 한다.
Immutable: 변경할 수 없는 것을 나타내는 형용사이다. 일부 예외를 제외하고 xAPI의 Statements은 변하지 않는다. 이로 인해 xAPI Statements이 LRS 간에 공유될 때 Statements의 여러 복사본이 동일하게 유지된다.
Internationalized Resource Identifier (IRI): IRL일 수 있는 고유한 식별자로, 동사, 활동 또는 활동 유형과 같은 객체를 식별하는 데 사용된다. Uniform Resource Identifier(URI)와 달리 IRI는 국제 언어를 지원하기 위해 ASCII 문자 집합 외의 문자를 포함할 수 있다.
IRI는 항상 스키마를 포함한다. 이것은 이 표준의 요구 사항은 아니지만 RFC 3987에 따라 IRI의 정의 일부이다. 때때로 "relative IRI"라고 불리는 것은 IRI가 아니다.
Internationalized Resource Locator (IRL): 이 문서의 맥락에서 IRL은 IRI를 URI로 변환하면(국제화된 자원 식별자를 URI로 변환하면) URL이 되는 IRI이다.
Inverse Functional Identifier: 특정 인물 또는 그룹에 고유한 식별자이다.
Learning Experience: 학습과 관련된 이벤트로, 그 내용은 다양하다. 예로서 책을 읽는 것, 온라인 코스 수강, 현장 여행, 자기 주도적 연구에 참여, 완료한 코스에 대한 인증서 수령 등이 있다.
Learning Management System (LMS): "하나 이상의 과정을 하나 이상의 학습자에게 관리하는 데 사용되는 소프트웨어 패키지입니다. LMS는 일반적으로 학습자가 자신을 인증하고 과정을 등록하고 과정을 완료하며 평가를 수행할 수 있는 웹 기반 시스템입니다." (Learning Systems Architecture Lab 정의). 이 문서에서 LMS는 사용자가 시스템 내에서 "신뢰할 수 있는" 사용자로 식별되어 학습 경험에 액세스할 수 있는 방법의 예로 사용된다.
Learning Record: xAPI 규칙에 따라 형식화된 학습 경험의 기록이다. 학습 기록은 Statements, 문서 및 그 부분을 포함하여 여러 형태로 나타난다. 이 정의는 모든 것을 포함하는 것을 의도한다.
Learning Record Consumer (LRC): 데이터를 처리하기 위해 학습 기록 저장소(LRS)에서 데이터를 액세스하는 xAPI 클라이언트로, 해석, 분석, 번역, 배포 및 집계를 포함한다.
Learning Record Provider (LRP): 학습 기록 저장소(LRS)로 데이터를 보내는 xAPI 클라이언트이다. 학습 기록 공급자는 학습 경험의 일부로 학습자를 모니터링하면서 학습 기록을 생성할 수 있다.
Learning Record Store (LRS): 학습 기록을 수신, 저장 및 액세스 제공하는 서버(웹 요청을 수신하고 처리할 수 있는 시스템)이다.
Metadata Consumer: IRI를 통해 표현되는 의미를 결정하고 IRI에 대한 메타데이터를 검색하려는 개인, 조직, 소프트웨어 프로그램 또는 기타 항목이다. LRS가 메타데이터 소비자일 수도 있고 아닐 수도 있다.
Metadata Provider: 이 명세서 내에서 사용할 IRI를 생성하거나 IRI에 대한 메타데이터를 호스팅하는 개인, 조직, 소프트웨어 프로그램 또는 기타 항목이다.
Persona: Actor를 고유하게 정의하는 하나 이상의 표현의 집합이다. 개념적으로 이는 "개인 이메일"과 "직장 이메일"을 가지는 것과 유사하다. 두 경우 모두 같은 사람이지만 다른 데이터, 연결 등을 가진다.
Profile: 특정 맥락에서 xAPI를 구현하기 위한 규칙 및 문서의 특정 집합이다. 프로필은 일반적으로 프로필 전용으로 만든 용어 어휘를 제공하며, 프로필 전용으로 만든 용어와 다른 어휘에서 참조된 용어를 제공한다. 때로는 프로필이 다른 상황을 위해 여러 어휘를 제공하거나, 누군가가 프로필을 만들지 않고 여러 소스에서 어휘를 선별할 수도 있다. 문서 프로파일 리소스와 혼동해서는 안 된다.
Registration: 특정 Activity을 경험하는 Actor의 인스턴스다.
Representational State Transfer (REST): 네트워크화된 웹 서비스를 설계하기 위한 아키텍처로서, HTTP 방식에 의존하고, 현재 웹에서 가장 좋은 관행으로서 사용한다.
Service: 분산 학습 프로세스의 하나 이상의 측면에 대한 책임이 있는 소프트웨어 구성 요소다. LMS는 일반적으로 여러 서비스를 결합하여 완전한 학습 경험을 디자인한다.
Statement: xAPI에서 추적할 이벤트 또는 경험의 증거로 사용되는 데이터 구조다. 여러 Statement의 집합은 시간에 따른 이벤트를 추적하기 위해 사용될 수 있으며 학습 경험에 대한 완전한 세부 정보를 추적하는 데 사용될 수 있다.
Tin Can API (TCAPI): 이 문서에서 정의된 API의 이전 이름으로, 경험 API에 대한 비공식 참조에서 종종 사용된다.
Verb: Statements내에서 활동(Activity) 내에서 Actor가 수행하는 작업을 나타낸다. 동사는 "나는 이것을 했다"에서 "했다"를 나타낸다.
Vocabulary: 특정 도메인에서 정보를 레이블링하거나 분류하는 데 사용되는 용어의 목록 또는 컬렉션이다. 어휘 사용은 모두가 동일한 단어를 동일한 의미로 사용하도록 보장한다. 어휘에 대한 자세한 내용은 xAPI 어휘 동반 명세서를 참조해야 한다.
5.0 xAPI 구성 요소들
xAPI Components
위 그림은 학습 경험의 추적을 보여준다. 학습자는 학습 경험을 가지고, 이 경험은 온라인 코스에서 발생할 수도 있고 직장에서 발생할 수도 있으며 여가 활동의 일부일 수도 있다. 실제로 아무 것이나 될 수 있다. 이 경험은 학습자를 대신하여 신뢰할 수 있는 학습 기록 공급자(Learning Record Provider, LRP)에 의해 추적된다. 학습 기록 공급자는 경험과 학습자 간의 신뢰할 수 있는 관계에 대한 책임도 맡을 수 있다. 이는 학습자를 위해 콘텐츠를 시작하고 콘텐츠와 관련된 디지털 권한을 관리하는 것을 포함할 수 있다.
학습 기록 공급자는 학습 기록을 생성하고 하나 이상의 학습 기록 저장소(Learning Record Store¸ LRS)로 보낸다. 학습 기록 저장소는 학습 기록을 저장하고 권한을 부여받은 모든 클라이언트에게 이를 사용할 수 있도록 한다. 학습 기록 소비자(Learning Record Consumer, LRC)는 학습 기록에 액세스하고 그것을 활용하는 클라이언트의 일종이다.
고유한 IRI로 식별되는 단일 Activity가 어떻게 정의되고 설명되는지를 이해하는 것은 xAPI의 핵심 개념 중 하나이다. 위 그림은 이 과정을 보여준다. Statements의 일부로서의 Activity는 Statements 내에서 채워질 수 있는 메타데이터 속성을 갖고 있으며, 이는 Statements의 Activity 정의에서 수행된다. 각 Activity의 ID는 IRI이며, 이 IRI의 해결 위치에 위치한 메타데이터가 있을 수 있다. IRI가 해결되는 위치에서 메타데이터 중 어떤 것이든 메타데이터 제공자의 관리 하에 있다. 메타데이터 제공자는 IRI가 영구적이고 올바르게 해결되도록 해야할 책임이 있다.
IRI가 결정되는 위치에 있는 모든 메타데이터는 메타데이터의 권위 있는 소스이며, Statements에서 받는 것에 대한 우선 순위로 활동 메타데이터의 학습 기록 저장소 표준 버전(학습 기록 저장소의 Activity 정의)을 채우는 데 사용될 수 있습니다. 메타데이터 소비자는 권위 있는 버전에 대해 IRI를 통해 메타데이터에 접근하거나 표준 버전에 대해 활동 리소스를 query할 수 있습니다.
xAPI는 개인 데이터에 대한 선택적 접근을 허용하는 프레임워크를 부여한다. 이것은 페르소나(Persona)라고 불리는 것의 관리를 통해 이루어진다. xAPI에서 각 페르소나는 "I did this"의 "I"를 나타내며 논리적으로 문장의 주제다. xAPI의 각 에이전트 또는 그룹은 페르소나에 해당하며, 학습 기록 저장소에 학습 기록을 보내는 학습자는 자신과 연관된 여러 페르소나(Agents)를 가질 수 있다.
위 그림에서 학습자는 여러 서비스에 액세스한다. 이러한 서비스 중 일부는 직장에서 사용되고, 다른 일부는 가정에서 사용된다. 어떤 것은 사회적인 목적으로 사용되고, 다른 것은 교육 또는 전문적인 목적으로 사용된다. 따라서 이러한 서비스 내에서는 여러 페르소나가 함께 작동한다. 이러한 각 서비스는 데이터를 학습 기록 저장소로 보낸 다음, 동일한 학습자의 세 가지 다른 페르소나에서 Statements를 갖는다.
학습 기록 저장소는 각 페르소나의 모든 정보를 하나의 "사람(Person)" 객체로 집계할 수 있다. 이 객체는 에이전트 리소스(Agents Resource)를 통해 학습 기록 저장소에서 검색할 수 있다. 학습 기록 저장소가 이러한 다중 페르소나가 단일 인물에 속한다는 것을 어떻게 알게 되는지는 이 명세서의 범위를 벗어나며, 학습 기록 저장소가 취할 수 있는 여러 가지 다른 접근 방식도 있다. 또한 어떤 학습 기록 저장소는 페르소나를 연관시키는 메커니즘을 가지지 않을 수도 있다.
6.0 xAPI 확장
Extending xAPI
xAPI는 몇 가지 방법으로 확장될 수 있다. 가장 주목할 만한 것은 Statements 내에서 큰 유연성을 제공하는Statements 확장이다. Community of Practic(CoP)는 특정 사용 사례에 대해 확장을 사용하는 방법에 동의하고 가능할 때마다 프로필을 활용하는 것이 좋습니다. 구현 세부 정보는 4.1 확장(Extensions)에서 다루고 있다.
About Resource는 xAPI가 확장을 지원하는 또 다른 경우이다. 학습 저장 는 이 명세 이상의 기능이나 동작을 전달하는 데 유용할 수 있다. 학습 기록 저장소는 About Resource에 확장을 사용하여 이러한 통신을 용이하게 할 수 있다.
마지막으로, 구현되는 리소스 세트가 이 문서에 의해 제한되지 않을 것으로 예상된다. 이 명세서에 정의된 리소스와 함께 구현되지 않은 리소스도 구현할 수 있으며, 이러한 리소스는 함께 공존할 수 있다.
7.0 프로필, 단어, 그리고 실천 커뮤니티(CoP)
Profiles, Vocabularies, and Communities of Practice
xAPI는 Statements의 구조를 엄격하게 정의하지만 해당 구조의 내용은 매우 유연하게 처리한다. 예를 들어, 명세서는 모든 Statements에 "Verb” 속성이 있어야 하지만 해당 속성의 값을 제한하지 않는다. 어떤 동사든 사용할 수 있다. 이러한 유연성은 xAPI가 명세서 작성자가 고려하지 않은 미래의 사용 사례를 포함하여 모든 맥락에서 사용될 수 있게 만들어 준다.
CoPs(Communities of Practice)는 적용 가능한 곳에 고유한 식별자를 제공함으로써 자신들의 프로파일(Profile)에 사용될 Verbs, Activity types, Contextual relationships, Extensions등을 정의할 것이다. CoPs는 이러한 식별자들 및 그 메타데이터를 어휘록에 정의할 것이다. 프로파일은 다루는 특정 사용 사례에 대한 xAPI에 추가하여 구현할 규칙 및 어휘의 세트이다. 그러한 커뮤니티가 존재하고 최고의 Practice를 공유하는 것이 매우 중요하다. 어휘를 출판하는 것에 대한 더 많은 정보는 Vocabulary Companion Specification 및 Vocabulary Primer를 참조한다.
프로파일은 Statements의 Context 내에서 고유한 "카테고리(category)"를 사용하여 프로파일을 구현하는 모든 Statements을 참조하는 것이 좋다. 예를 들어, 전통적인 단일 학습자, 단일 온라인 학습 사용 사례를 위해 설계된 cmi5와 같은 프로필이 있다. cmi5 Statements의 예는 부록 B: cmi5 예제에서 찾을 수 있다.
CoP를 통해 노력의 중복을 피하는 것이 강력히 권장되며, 동일한 문제를 해결하기 위한 다양한 방법을 너무 많이 만들면 유사한 도메인에서 단편화가 발생하고 상호 운용성을 손상시킬 수 있다. 의학 분야를 위한 CoP 예로 MedBiquitous Learning Experience Working Group가 있다.
동일한 문제를 해결하기 위해 너무 많은 방법을 만드는 것은 유사한 도메인에서 단편화를 야기하고 잠재적으로 상호운용성을 해칠 수 있기 때문에 노력의 중복을 피하기 위해 CoP가 매우 권장된다. 의료 분야에 대한 CoP의 예로는 MedBiquitous Learning Experience Working Group이 있다.
'📂 데이터베이스 > ◾ 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 2.0 Data 톺아보기 (1) | 2023.10.31 |
댓글