xAPI and people metadata

[berthelemy]

In another repo, @garemoko stated:

"... xAPI statements aren't designed to store metadata about people."

One of the biggest use cases for an LRS is for organisations to perform analytics, not just on which activities have been done, but also on who is doing them (eg. by department, demographic etc).

Am I missing something, or is this a big area missing from xAPI?

Cheers,

Mark

[garemoko]

Hi Mark,

From my point of view, the transmission of people metadata is outside of the scope of xAPI. There is the Agent Profile Resource but that's more for agent state data rather than metadata. As I mentioned in the other post, its also unstructured so you've not really going to gain much/any interoperbility benefit by using that.

The approach we take at Watershed is normally to bring this data in a csv file with the different columns representing different items of metadata about the person. That works well most of the time (except when people rename their columns - a common source of frustration!).

Standardizing columns names would certainly be helpful from the reporting tool's perspective. But if that also requires organizations to standardize their hierarchical structure, job roles and demographical groups, then the initiative to standardize could get complex and contentious fast. For that reason I advocate sticking with the flexibility of the humble csv.

There might also be some existing HR standards that deal with this sort of data, but if there are, I suspect they may not be widely adopted simply because I've never come across them dealing with our customers; they always give us the data in a csv format, and everybody has different columns.

You wouldn't want to include that data in statements because it's a lot of extra detail to have to include in every statement.

I hope that helps.

Andrew

[berthelemy]

Thanks Andrew,

I had hoped the Agent Profile Resource was going to be the answer. As you say, you wouldn't want to add this data to every statement.

There are IMS specifications which are designed to capture user information (eg. IMS Learning Information Services:https://www.imsglobal.org/lis/lisv2p0p1/LISSpecPrimerv2p0p1.html)

The Learning Information Services (LIS) specification is the
definition of how systems manage the exchange of information that
describes people, groups, memberships, courses and outcomes within
the context of learning.

But, you're right, these aren't widely used (if at all) in the corporate sector, unfortunately.

So, to get useful analytics from xAPI I will need to combine xAPI data with demographic data in a separate process.

You can close this ticket, as it feels that's unlikely to change, although it does seem to limit the usefulness of xAPI.

Thanks,

Mark

On 15/03/2017 18:52, Andrew Downes wrote:

Hi Mark,

From my point of view, the transmission of people metadata is outside of the scope of xAPI. There is the Agent Profile Resource https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Communication.md#26-agent-profile-resource but that's more for agent state data rather than metadata. As I mentioned in the other post, its also unstructured so you've not really going to gain much/any interoperbility benefit by using that.

The approach we take at Watershed is normally to bring this data in a csv file with the different columns representing different items of metadata about the person. That works well most of the time (except when people rename their columns - a common source of frustration!).

Standardizing columns names would certainly be helpful from the reporting tool's perspective. But if that also requires organizations to standardize their hierarchical structure, job roles and demographical groups, then the initiative to standardize could get complex and contentious fast. For that reason I advocate sticking with the flexibility of the humble csv.

There might also be some existing HR standards that deal with this sort of data, but if there are, I suspect they may not be widely adopted simply because I've never come across them dealing with our customers; they always give us the data in a csv format, and everybody has different columns.

You wouldn't want to include that data in statements because it's a lot of extra detail to have to include in every statement.

I hope that helps.

Andrew

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/adlnet/xAPI-Spec/issues/1032#issuecomment-286843402, or mute the thread https://github.com/notifications/unsubscribe-auth/ACZUz_g2qXcgrYcR-CVYuXez9i6Ziw2Tks5rmDNjgaJpZM4MZoR6.

-- Mark Berthelemy Managing Director Tel: 01773 881 227 Mob: 07922 146 761

Web: www.wyversolutions.co.uk

Wyver Solutions Ltd | Company number: 5731173 Registered in England | Registered address: First Floor, 6 Bridge Street, Belper, Derbyshire, DE56 1AX

[851597064]

Berthelemy, I know for a fact that someone has done work to build a flexible system that combines (semi-structured) user metadata and xAPI statement data. That work is on the backburner now, but there are some interesting and usable results.

[ellenm1]

This topic is very relevant to my work, so I'll be following any developments in this area. Perhaps we need standard profiles for the Agent Profile as well, or User Profiles at a higher level than the statement level. Seems like something like LIS could be incorporated as an extension, sort of.