Fwd: Re: xAPI Badges integration(Including references to badge assertions in Experience API activity streams)

27 views
Skip to first unread message

☮ elf Pavlik ☮

unread,
Feb 6, 2015, 1:54:08 PM2/6/15
to xapi-pro...@adlnet.gov
FYI: Feedback from one of leading spec editors via W3C Credentials CG

Please excuse me Fwd without self intro! I'll write one soon, for now
please just see my comment on github:
https://github.com/adlnet/xAPI-Spec/issues/577#issuecomment-73249230


-------- Forwarded Message --------
Subject: Re: xAPI Badges integration(Including references to badge
assertions in Experience API activity streams)
Resent-Date: Fri, 06 Feb 2015 17:12:54 +0000
Resent-From: public-cr...@w3.org
Date: Fri, 06 Feb 2015 12:12:28 -0500
From: Dave Longley <dlon...@digitalbazaar.com>
To: public-cr...@w3.org
CC: ☮ elf Pavlik ☮ <perpetua...@wwelves.org>, Nate Otto
<na...@ottonomy.net>

On 02/06/2015 10:53 AM, ☮ elf Pavlik ☮ wrote:
> On 02/05/2015 12:08 AM, Dave Longley wrote:
>> On 02/04/2015 04:51 PM, Nate Otto wrote:
>>> Friends and Badgers, (CC: Credentials Community Group)
>>>
>>> Andrew Downes, Jason Lewis, Ryan Smith and a few others have been doing
>>> some good work on defining how it might be possible to transport badges
>>> within xAPI "activity streams." (These streams are essentially
>>> collections of statements like "<entity> <verbed> <object>", or in this
>>> case, "Nate earned Badge #5"
> Dave, I wonder if you've noticed example of *signed* statement in xAPI spec
> * https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md#AppendixE
> * https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md#signature
>

I hadn't seen it until you pointed it out just now. I took a quick look:

1. Signing is done at the statement level (I can't tell if you can sign
more than one statement at once; it may be limited to just one at a time).

2. It seems to use JWS and indicates the original serialization of the
data is included as an attachment to the statement. This means that the
same data is effectively represented twice. There are some notes about
verification that require that the "original" statement be reconciled
against the "received" statement to ensure they are logically
equivalent. I assume this means doing some sort a semantic comparison
between the base64-encoded JSON statement (the payload that was actually
signed) and the JSON statement that contains it as an attachment. There
are some special exception rules for certain properties that must be
ignored when doing this comparison.

3. There's some other stuff in there about preferring X.509 certificates
and chains be specified and used, etc.

In short, my opinion is:

1. It's more complex than Linked Data Signatures 1.0 and you don't get
semantic comparison for free or in a generic way (RDF Dataset
Normalization).

2. It uses JWS in a custom way and uses an RDF-like data model that
isn't actually RDF despite being extremely close to it.

With their current approach, they can't use JWS tools out of the box
(they need to do something on top of them to *actually* verify
signatures) and they can't use RDF tools out of the box either.

Their spec use statements of triples (subject-verb-object) (sounds just
like RDF to me). Their spec transports these statements using JSON
(sounds just like JSON-LD to me). Their spec defines how to digitally
sign statements, continue to transport them as clear JSON, and
semantically compare them when verifying (sounds just like Linked Data
Signatures to me).

I think these parts of their spec should align with existing standards
work as their overall design goals seem to be nearly identical. I
haven't yet seen a good reason to deviate. They could focus more on
their value add and achieve better interoperability by building on
existing technology stacks instead of reinventing them with what appear
to be, at least to me, only slight changes.

Elf can speak more about aligning with the Social Web WG's Activity
Streams as well as he's deep in that work.


--
Dave Longley
CTO
Digital Bazaar, Inc.




signature.asc

Russell Duhon

unread,
Feb 6, 2015, 3:08:37 PM2/6/15
to ☮ elf Pavlik ☮, xAPI-Specification, xapi-pro...@adlnet.gov
I broadly agree that we could get more in alignment with some other standards, including those, though it isn't so straightforward as assumed; the main confusion is we don't use semantic web triples (not really all that close to them, even), just some similar language around the core of statements (statement data could be translated to triples, but that's just a general truism; *any* data could be translated to triples).

It'd be a bit hard for us to have relied on Linked Data Signatures too; it's *really* new; the 1.0 spec doesn't even have all the typos out. And while our JWS implementation is a little idiosyncratic, it was also built to integrate easily with the already fairly broadly adopted earlier versions of the spec. I wouldn't mind lining up with both for some future version of xAPI, at least based on my understanding of Linked Data Signatures so far, but by keeping our initial adoption of JWS narrow and lined up with existing xAPI spec work we were able to move much faster and still derive immediate value (which is still mostly theoretical for some aspects of the specs being recommended).

Sincerely,
Russell



--
You received this message because you are subscribed to the Google Groups "ADL xAPI Community of Practice & Profiles Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xapi-profile-c...@adlnet.gov.
To post to this group, send email to xapi-pro...@adlnet.gov.
Visit this group at http://groups.google.com/a/adlnet.gov/group/xapi-profile-cop/.
To view this discussion on the web visit https://groups.google.com/a/adlnet.gov/d/msgid/xapi-profile-cop/54D50DB9.1040809%40wwelves.org.

☮ elf Pavlik ☮

unread,
Feb 6, 2015, 3:46:59 PM2/6/15
to Russell Duhon, xAPI-Specification, xapi-pro...@adlnet.gov
On 02/06/2015 09:08 PM, Russell Duhon wrote:
> I broadly agree that we could get more in alignment with some other
> standards, including those, though it isn't so straightforward as assumed;
> the main confusion is we don't use semantic web triples (not really all
> that close to them, even), just some similar language around the core of
> statements (statement data could be translated to triples, but that's just
> a general truism; *any* data could be translated to triples).
>
> It'd be a bit hard for us to have relied on Linked Data Signatures too;
> it's *really* new; the 1.0 spec doesn't even have all the typos out. And
> while our JWS implementation is a little idiosyncratic, it was also built
> to integrate easily with the already fairly broadly adopted earlier
> versions of the spec. I wouldn't mind lining up with both for some future
> version of xAPI, at least based on my understanding of Linked Data
> Signatures so far, but by keeping our initial adoption of JWS narrow and
> lined up with existing xAPI spec work we were able to move much faster and
> still derive immediate value (which is still mostly theoretical for some
> aspects of the specs being recommended).
I think that I understand you very well. I mostly wanted to start
process where all working groups addressing similar challenges become
more familiar with each other's work.

I could work with fellow Social WG participants on clarifying our
current strategy in keeping Linked Data as an extra gain without putting
any extra burden on people who implement things! Will try to share a
wiki page in this group soon...


>
> Sincerely,
> Russell
Cheers,
elf Pavlik


signature.asc

Russell Duhon

unread,
Feb 6, 2015, 7:08:18 PM2/6/15
to ☮ elf Pavlik ☮, xAPI-Specification, xapi-pro...@adlnet.gov
That'd be fantastic, and I want to increase the dialogue as well, I just wanted to lay out why we didn't adopt all those things so far ;)

I could easily see a future where xAPI statements are really nice JSON-LD data (and thus natively triples) using several of the standards discussed directly. It'd be pretty nifty, actually.

:),
Russell


Ingo Dahn

unread,
Feb 8, 2015, 4:41:25 AM2/8/15
to xapi-pro...@adlnet.gov, fug...@gmail.com, xapi...@adlnet.gov

Hi,
I recall that the problem of alignment with other specs (for example the Activity Streams spec to mention just the closest one) has been brought up earlier during the development of the xAPI spec. The problem has never been handled in a systematic way and I recall the following three arguments that were given against doing it resp. for delaying it to the design of xAPI V2.0.
  1. The scope of the spec has never been precisely defined. There is no guidance to decide which use cases are in or out of scope. Consequently, whenever a new use case comes up, the priority of discussion is to find some way of handling it within xAPI rather than discussing whether another spec, possibly in combination with xAPI, might be more appropriate.Where other specs are mentioned (as for authentication issues) they are pulled into the spec ad hoc rather than providing an interface (say to some authentication spec). In fact, the latter is hard to do for the following reason.
  2. The current spec interleaves the information model with its JSON binding. Other specs will inevitably use different bindings and describing the relation between the specs is much more complex to do at the bindings level than it would be at the level of the information models. A clear separation of information model and binding was one of the key requests of IEEE looking at xAPI - most likely because IEEE needs a clear definition of the relation of xAPI with the other (IEEE) specs to determine its potential place in the IEEE spec ecosystem.
  3. Some participants expressed a political interest to serve their customers using just the one spec they support.
While I agree that considering xAPI incontext with other specs is a key issue, I don't see a possibility of changing these preconditions for a version 1.x. I am more optimistic for V2.0 (backwards compatible as much as possible). where the team is currently under formation and everybody interested is invited to join.
Best
Ingo

Johnson, Andy

unread,
Feb 9, 2015, 8:24:15 AM2/9/15
to Ingo Dahn, xapi-pro...@adlnet.gov, Russell Duhon, xAPI-Specification
We still currently meet every 4th Wednesday during the traditional specification Working Group time to discuss use cases and 2.0 issues.  We had been meeting every 2nd and 4th Wednesday but scaled back because the last 3 meetings drew no use cases or desired changes.  We welcome all use cases, but we need to have them defined and not just provided in a laundry list where non-ISDs (pretty much the makeup of those on the techncial working group spec calls, I apologize if I am in error there) are trying to determine requirements of each use case.  We're not equipped in talent or time to do that.  We welcome anyone to present a use case and we can work together to see which specs we know of (in this group you are likely to get a SCORM and xAPI bias as that's what we know best) to help solve the issue.  We'd like to know what features in xAPI 2.0 (other spec alignment would be great!) would enable the use case as well.  If anyone wants to step up immediately, I'll even provide this Wednesday's Conformance Testing call as a venue, otherwise Feb 25th is the next available date. 

Thanks for all you do!

Andy


--
You received this message because you are subscribed to the Google Groups "ADL xAPI Community of Practice & Profiles Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xapi-profile-c...@adlnet.gov.
To post to this group, send email to xapi-pro...@adlnet.gov.
Visit this group at http://groups.google.com/a/adlnet.gov/group/xapi-profile-cop/.

Andrew Downes

unread,
Feb 9, 2015, 9:13:53 AM2/9/15
to xapi-pro...@adlnet.gov
Thanks Andy, that's pretty much in line with how I wanted to respond to this: the working group is made up of volunteers with limited time, whether that's individuals or organisations volunteering their people. We want to hear more about JSON-JD and Activity streams, but this requires somebody with a good understanding of them clearly articulating the required changes to the specification (ideally making a PR) and convincingly arguing the benefits of those changes. We want to split up the data model and bindings and a plan is in progress to do so, but again it all takes time. 

On re-inventing the wheel, looking at JSON-LD this appears to be a relatively new specification that's development at broadly the same time as Tin Can.

Only place I disagree with Andy is that I'm put myself in the ISD piegon hole. ;-)


Reply all
Reply to author
Forward
0 new messages