SCORM для сеансов xAPI и повторный ответ Activity + изменение Score

Я исхожу из SCORM и пытаюсь выяснить две связанные проблемы, связанные с тем, как выполнять обновление и находить самые последние данные (т. Е. Поиск передового опыта).

В SCORM у меня будет набор действий, в которых все будут хранить свои ответы и оценки (легко понять из документации и т. д.). «Как», который мне нужен, конкретно связан с возобновлением набора действий несколько раз, нажатием «сброса» и отправкой другого ответа на одно действие после отправки заявления.

Из того, что я читал с xAPI, говорится, что операторы неизменны - так что мне делать с этим.

Моя первая мысль заключалась в том, что я бы сделал идентификатор оператора, сгенерированный из идентификатора действия, и аннулировал старый ответ, когда он изменится, но это звучит неправильно (не в последнюю очередь потому, что он читается так, как будто вы не можете повторно использовать идентификатор даже с аннулированием) .

Таким образом, похоже, что идентификатор утверждения должен быть уникальным, что будет означать, что будет найдено несколько идентичных объектов - так что мне придется просматривать каждую попытку и проверять последнюю?

В настоящее время я рассматриваю возможность использования xAPIWrapper посередине.


person Rycochet    schedule 13.01.2016    source источник


Ответы (1)


Переход от SCORM к xAPI требует изменения мышления. SCORM имеет дело со статусами, которые обновляются; xAPI регистрирует события как журнал.

Вы можете думать об этом как о Facebook. Вы публикуете фото своего нового кота; месяц спустя вы публикуете фото своего кота на 1 месяц старше. Нет необходимости возвращаться и удалять старый пост. Если вам нужна последняя фотография вашего кота, вы просто идите и получите самую последнюю фотографию с тегом «Кот Риочета». Вы также можете просмотреть старые фотографии, чтобы увидеть, как развивалась ваша кошка. xAPI похож на поток активности на Facebook.

Итак, если кто-то набирает 10 баллов с первой попытки, а затем 20 баллов со второй попытки, вы просто отправляете второй набор утверждений о второй попытке. Нет необходимости избавляться от утверждений о старой попытке, которая произошла, и это полезные данные, чтобы увидеть, как развивался учащийся.

person Andrew Downes    schedule 13.01.2016
comment
Вот что я понял - так что, возвращая данные, я должен хранить все это в состоянии, чтобы оно могло обновляться и получать однократно, или я должен получать заявления и фильтровать? - person Rycochet; 13.01.2016
comment
Я не на 100% понимаю сценарий, но, конечно, вы должны использовать состояние для данных о состоянии, где это уместно. - person Andrew Downes; 15.01.2016
comment
Это действия тестового типа, поэтому при повторной загрузке они хотят иметь возможность отображать предыдущую оценку, но сохранить ее в состоянии достаточно просто, и это означает, что мне не нужно фильтровать утверждения — мой аспи-мозг просто не мог этого сделать. не понимаю, уже хранить его в одном месте, нет ничего плохого в том, чтобы сделать это и в другом месте :-P - person Rycochet; 15.01.2016
comment
Грубо говоря, API-интерфейс операторов предназначен для использования в отчетах, а API-интерфейсы состояния (и других API-интерфейсов документов) предназначены для создания закладок. Могут быть случаи, когда вы будете использовать все за пределами этого дизайна, но это полезное эмпирическое правило для большинства случаев. Технически это не дублирование данных. Государственный API говорит, что учащийся набрал 89 баллов, API-интерфейс заявления говорит, что учащийся набрал 89 баллов в это время. - person Andrew Downes; 18.01.2016
comment
Имеет смысл - надеюсь, это поможет другим, кто тоже пришел к этому с неправильным мышлением ;-) - person Rycochet; 21.01.2016