Profiles Meeting 5/6
What challenges can be addressed with xAPI Profiles?
6 May 2020, 3:00pm Eastern
Meeting Minutes
Email eva@makingbetter.us to be added to the invite :)
Please join today’s meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/665670021
You can also dial in using your phone.
United States: +1 (312) 757-3121
Access Code: 665-670-021
Team
Host: Aaron Silvers
Community Manager/Secretary: Eva Rendle
Producer: Megan Bowe
In Attendance
Aaron Silvers (aaron@makingbetter.us)
Tom Creighton (tom@veracity.it)
Marcus Birtwhistle (marcus.birtwhistle.ctr@adlnet.gov)
Florian Tolk (florian.tolk.ctr@adlnet.gov)
Jono Poltrak (jono@veracity.it)
Eva Rendle (eva@makingbetter.us)
Jason Haag (jason@veracity.it)
Megan Bowe (megan@makingbetter.us)
Rob Chadwick (Rob@veracity.it)
Eleni Mangina (eleni.mangina@ucd.ie)
Today discussing - pragmatic realities of the xAPI data centered model
Benefits at Scale
Validating 1st Party Data from 3rd Party Systems
How is that done now?
How is that data used?
What is the value of the reporting today?
Of what and how much value is the impact sought?
How important is it to control the costs of downtime?
Defects. Mistakes that require additional time, resources, and money to fix. With content and media production, a defect might involve an interaction that requires the content to be re-published, triggering all manner of quality tests to be re-done.
Overproduction. Without clear guidance that applies to every component of a curriculum, or other collection of content using xAPI, content or systems might generate too much content that can’t and shouldn’t be used, but may skew results because the data looks acceptable.
Waiting. When work stops for reasons such as needing approval, or not having the needed information, many triggers for such downtime in learning and performance projects -- may be avoided with clear, unambiguous instructions for people and machines.
Non-utilised/underutilised talent. Nothing is worse for a developer than having to make sense of eLearning requirements. The professionals responsible for the requirements management, procurement, technical development, quality assurance and delivery of data-generating media, as well as the downstream customers of the data generated, often fail to recognise how difficult it is to generate these requirements, and usually there is a subset of requirements that is vetted and negotiated with every single vendor, sometimes for every single project with a given vendor. Having a clear set of unambiguous requirements and instructions enables everyone involved to focus on more interesting and constructive aspects of their job while eliminating a lot of redundant work.
Transportation. Moving data around from system to system often requires a series of processes. xAPI data can be generated on a mobile device and sent to an LRS, which performs processes to store the data. Other applications, like learning management systems, reporting systems and machine learning applications tend to extract this data in whole, parse and filter for what they need (since xAPI doesn’t offer a more refined querying… at least not specified… yet). All of this is made easier, and is made more resilient, if there’s a common set of expectations around that data.
Inventory. A surplus of data that can’t be used to meet the goals of an effort is not a good thing. It presents risks that are best avoided when the kind of data being generated, moved and stored about people is mindfully and explicitly accounted for. Transparency in this work is important; so, too, are practices to ensure we’re tracking only what will be useful, and will benefit the user’s learning, development and/or performance.
Motion. The ability to automate let alone scale across implementations, particularly for learning and performance, what have been otherwise implementation-specific approaches to data validation and management supports more flexible, streamlined and efficient workflows across different sets of stakeholders.
Extra Processing. Unnecessary effort, like the production of interactions that aren’t relevant for the learning or performance need, or extra communications with the LRS which contribute data that can’t or won’t be used, all carries hidden costs -- only some of which are realized before a contract ends.
Question: Florian Tolk - Read an article regarding xAPI recipes, and was wondering where that stood.
Answer: Recipes were the original attempt of this work by Rustici Software. There was no vetting, no community input, just grouping of information. Profile work is now trying to help solve ths same problem.
Next meeting (May 20th) will be highly technical on the subject of “What do xAPI Profiles do, per the specification, and what specifically don’t they do?” Focusing on the engineering and semantics of xAPI Profiles.
References & Source Material