Vocabulary Considerations for xAPI

[Haag, Jason]

Hi Everyone,

ADL has published a white paper for public comment on controlled vocabulary considerations for the xAPI. 

The timing seems as as good as ever since just this week we heard from Adam Cooper (JISC Cetis) and others about the various tools they are using. This paper is not intended to be an exhaustive list of solutions. It is an initial exploration into the some of the development, discoverability, and management challenges that will need to address if we want to align xAPI vocabularies with best practices and standards. What are we missing? We want to hear from you. 

https://docs.google.com/a/adlnet.gov/document/d/1zBPKryuF1tXHTI-AYjXd0ctdWoq4o4P-Uq9SAhJfus0/edit?pli=1#

Simply respond to this thread on the xAPI google groups you are subscribed to if you would like to share your feedback or thoughts. If you are interested in leading or supporting any of the "Call-To-Action" items at the end of the paper, please contact us at xapi-vo...@adlnet.gov. 

Regards,

J Haag

-------------------------------------------------------
Advanced Distributed Learning Initiative
+1.850.266.7100(office)
+1.850.471.1300 (mobile)
jhaag75 (skype)
http://motifproject.org (MoTIF Project)
http://ml.adlnet.gov (Web)
http://twitter.com/mobilejson (Twitter)
http://linkedin.com/in/jasonhaag (LinkedIn)

[Andrew Downes]

Hi,

Thanks for sharing this; it looks like a lot of work has gone into this document and I appreciate that effort. I'll possibly respond in more detail next week, but a few initial thoughts from me personally:

• Overall, the document seems to be a lot more pessimistic than I would like both in relation to the spec itself and to real world practice. The most prominent example of an over-pessimistic view of the spec is the sentence "Instead, Activity Providers are free to publish different statements about the same activity using their own profiles and vocabularies.", which is not true. Whilst the Activity Provider MAY create and use their own identifiers where a suitable identifier does not already exist, where an identifier already exists, the Activity Provider SHOULD use the corresponding existing identifier.
• On machine readability, I welcome any work to standardise the publication of machine readable recipes, vocabularies and ways of populating statements and storing documents. It's important that any work in this area considers what's already in the spec and being used in practice: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md#54-identifier-metadata. 
  
• On discoverability, I'm yet to be won over as to the practical benefits of this. In every use case I can think of, the shared identifiers (i.e. not activity ids) will need to be selected by a developer, or at least an advanced authoring tool user (less advanced users will select from a list chosen by a developer). Developers will most likely use Google "xAPI Registry" or "Tin Can Registry" if they are not already familiar with a registry to use. 
• On the existing Registry at registry.tincanapi.com, I appreciate any work to advance the Registry. I think we can agree that the Registry does a fantastic job but could certainly benefit from additional work. It's important that any further work builds on, rather than replicates, the progress the Registry has made over the last couple of years. 
• It's also worth noting that the Registry has no Tin Can branding and contains identifiers including both "xapi" and "tincanapi" in the IRIs. Given the requirement in the spec to use existing IRIs and that the Registry hosts IRIs contributed by the community, it's misleading to take inclusion of IRIs containing "tincanapi" to imply that this indicates an earlier version of the spec (presumably 0.95?). I work with a lot of adopters and this is the first time I've come across the idea that the Registry is for 0.95 identifiers only; I don't believe this is genuine confusion amongst developers. 
• On governance, I think the amount of time required to create a recipe is an important consideration, with CMI5 being a good example. A bad, shared, recipe is better than no recipe [citation needed]. From my work with a few CoPs, but most recently the Open Badges group, a good approach seems to be to pick a relatively narrow focus, document is and then produce a prototype or test project, tweaking the recipe as required throughout development. I would cut down the amount of paperwork provided to CoPs and get them coining identifiers and trying things out sooner. The ability to create draft or trial identifiers is, I think, very important and one area where Registry could absolutely be improved. Currently with Open Badges we're recording the identifiers in Github with a plan to publish them as a version 1 recipe  into the Registry and anywhere else we can think of once we've got things more pinned down. 
• On existing technologies, I'm very keen to hear more about their practical benefits but am disposed to be wary of adopting anything without a clear practical argument for why. The first call to action point seems very sensible; we need to know more about these technologies but it's not practical for everybody to be expert in everything. If we can find people willing to put that effort in, that'd be great.

I hope these comments are helpful, and thanks again for producing this document. Let me know if any clarification of any of this would be helpful or if I've misunderstood anything. 

[☮ elf Pavlik ☮]

On 02/20/2015 08:49 PM, Haag, Jason wrote:
> Hi Everyone,
>
> ADL has published a white paper for public comment on controlled vocabulary
> considerations for the xAPI.

Hi Jason,

I forwarded your email to mailing lists of
* https://www.w3.org/wiki/WebSchemas
* https://www.w3.org/wiki/Socialwg & https://www.w3.org/wiki/Socialig
* http://www.w3.org/community/credentials/

I also hope you join next xAPI call on Wednesday! I will read the full
paper in next two days...

Ciao o/

> To unsubscribe from this group and stop receiving emails from it, send an email to xapi-spec+...@adlnet.gov.
>

[Jason Lewis]

Thanks for this, Jason!

This paper seems to be exactly on the right track. I have to say, I was beginning to lose hope re: consensus on the importance of linked data, semantic web ontologies, and other existing technologies that have the potential to render much of what the discussion seems to go back and forth about a solved problem.

I think in light of this paper, the current lack of an agreed-upon centralized repository/registry for vocabulary and profile data is a good thing. The ADL and Rustici repositories have provided some early examples of what a basic single registry could look like, and also I think point out why a federated model based on linked data and existing standards is necessary.

Very excited to continue work in this area, and glad to see the direction thinking about vocabularies is taking.

Thanks,

Jason Lewis

CTO, Yet Analytics, Inc.

410.428.0253 // yetanalytics.com

My GPG key can be found via: gpg --keyserver pgp.mit.edu --recv-keys 0xc30a0d63c4b43758

Key fingerprint: 2E05 8E7E DAC2 F264 F0C6  23A0 C30A 0D63 C4B4 3758

--
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/54EB36D2.7040300%40wwelves.org.

[Andrew Downes]

+1 to federation. My nightmare scenario is fragmentation without federation. 

[Haag, Jason]

Hence the call to action :-)

[dahn]

These are valuable considerations to be explored, though I don't agree with all of them. I put my comments on this most valuable ADL Vocabulary Document on my xAPI 2.0 Scratchpad in order to protect them from getting lost in mail universe.

First of all I'd like to consider the management of vocabularies as a special case of managing profiles of the spec, for which there should be general guidelines developed by a working group such as the one proposed in the call-to-action section.

• I can well imagine use cases where there will be domain specific vocabularies required and in these cases vocabulary entries will have to be defined and selected by domain experts - not by software developers.
  
• Also discoverability of words is a obviously a necessary pre-requisite for re-using them and for establishing any kind of vocabulary governance.
  
• I can also imagine use cases the implementation of which requires machine readability of semantic relations between words. For example if someone searches for statements like "X movedTo Y" and expects to also find statements saying "X walkedTo Y".
  

Perhaps I can detail those use cases when we have a place where use cases for xAPI 2.0 are collected.

Ingo

[Andrew Downes]

Having developed a better (any) understanding of linked data and json-ld (thanks Elf!), I'm now confused by the criticism of the Registry that it doesn't promote a linked-data approach. In fact, I'd argue that the Registry (and the spec itself) *do* promote a linked-data approach by providing facilities for users to host metadata at a URL/IRI. 

In practice, within the current specification, what would you want the Registry to do that it doesn't do already?

[Haag, Jason]

Andrew I'm working on providing feedback to your comments and others on the white paper so there will be more to come once everything is finally summarized. But I wanted to at least first respectfully reply to your inquiry. No, the registry does not currently support RDF and linked data. Just because it allows you to create an IRI/URI for verbs and activities does not mean it follows a linked data approach. RDF is a conceptual model, but there are many best practices and implementation specific requirements that the registry and we as a community do not follow. The white paper proposes applying an RDF approach to the vocabulary terms for xAPI to make them more semantically interoperable, discoverable, and reusable. That also means looking at a federated approach to publishing and discovering linked open vocabulary terms for xAPI. 

The paper is not a criticism of the TinCan registry. In fact, the paper gives credit to the registry for advancing our thinking about what might be possible. The paper is simply intended to identify areas where we might improve our practices and overall governance strategy. It would be great if RDF could be supported by the registry. But in order for that to happen, we need to apply practices to our vocabularies first! Hence, the purpose of the paper. 

-------------------------------------------------------
Advanced Distributed Learning Initiative
+1.850.266.7100(office)
+1.850.471.1300 (mobile)
jhaag75 (skype)
http://motifproject.org (MoTIF Project)
http://ml.adlnet.gov (Web)
http://twitter.com/mobilejson (Twitter)
http://linkedin.com/in/jasonhaag (LinkedIn)

[Andrew Downes]

Thanks for the response Jason! Criticism was perhaps a bad choice of word on my part. 

So do we know what the implementation specific requirements are exactly, or is that what the call to action is about working out? Or are they in fact listed in the white-paper and I just need to read it more carefully? 

[Jason Lewis]

Andrew: 

Start here: http://www.w3.org/TR/owl2-rdf-based-semantics/

I would also look at the Dublin Core Metadata Initiative standards.

LD and RDF/OWL are about linked semantic ontologies.

One nice thing about the prospect of moving forward with a proper standards body (be that IEEE, IETF, etc.) will be that we'll eventually have to specify a formal semantics for xAPI itself, as the current spec has REST a bit arse-about-face, specifying a representation of data without documenting its formal semantics first.

Jason Lewis

CTO, Yet Analytics, Inc.

410.428.0253 // yetanalytics.com

My GPG key can be found via: gpg --keyserver pgp.mit.edu --recv-keys 0xc30a0d63c4b43758

Key fingerprint: 2E05 8E7E DAC2 F264 F0C6  23A0 C30A 0D63 C4B4 3758

On Tue, Mar 10, 2015 at 9:39 AM, Andrew Downes <andrew...@scorm.com> wrote:

Thanks for the response Jason! Criticism was perhaps a bad choice of word on my part. 

So do we know what the implementation specific requirements are exactly, or is that what the call to action is about working out? Or are they in fact listed in the white-paper and I just need to read it more carefully? 

To unsubscribe from this group and stop receiving emails from it, send an email to xapi-spec+...@adlnet.gov.

[Haag, Jason]

As Jason pointed out a formal ontology for xAPI might be in order at some point. He isn't the first person to suggest this and it makes sense. I think it is okay though that it seems "arse backwards" as the time is right to nail these things down as we move to new versions of xAPI. Since it wasn't strictly defined previously it is kind of nice that we have an opportunity to address it now (rather than have done it too soon). But, now we are in a position that if we wait too long we could have some big problems with semantic interoperability in the long run. This approach also seems to be similar to what the Activity Streams 2.0 group is also taking: http://www.w3.org/TR/activitystreams-vocabulary. They also are just now applying better semantic power to Activity Streams 2.0. 

However, developing a formal ontology for xAPI could require quite an extensive amount of work. Perhaps something to consider for xAPI 2.0? 

For now, I think we can look at several of the resources in the paper, do some analysis of the different approaches, and come up with some general guidelines for publishing xAPI controlled vocabularies as RDF. We need to make this as simple as possible for CoPs. The broader ontology work Jason is referring to can be complex. 

Andrew, here are some of the resources we are currently examining for understanding the implementation requirements: http://www.w3.org/TR/ld-bp/ and http://www.w3.org/TR/swbp-vocab-pub/

-------------------------------------------------------
Advanced Distributed Learning Initiative
+1.850.266.7100(office)
+1.850.471.1300 (mobile)
jhaag75 (skype)
http://motifproject.org (MoTIF Project)
http://ml.adlnet.gov (Web)
http://twitter.com/mobilejson (Twitter)
http://linkedin.com/in/jasonhaag (LinkedIn)

--
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/CAK%2BdXPCCB3yCDAFxsQ1PG1d_4hpyXQ1M9M%2BFj00uNYoB6Bq13g%40mail.gmail.com.

[Jason Lewis]

Jason, I agree — definitely something to plan for a foundation for 2.0.  Sorry for the "arse backwards" remark, that was really about the specious claims to RESTfulness rather than the spec itself.

Coming up with a formal semantics is going to be a major undertaking, but I think it is the right time to begin; 1.x gives us a general idea of the shape of the data in a given representational format; we can start where we are now to determine a formal semantics for xAPI.

I think working with RDF will be instructive, as it's essentially (ignoring the undue emphasis on XML bindings) an entity-relationship data model, which is what we don't have at the moment in xAPI (viz. the discussion of identity equivalence assertions). 

This should be an interesting couple of months as we get started down this road :)

Jason Lewis

CTO, Yet Analytics, Inc.

410.428.0253 // yetanalytics.com

My GPG key can be found via: gpg --keyserver pgp.mit.edu --recv-keys 0xc30a0d63c4b43758

Key fingerprint: 2E05 8E7E DAC2 F264 F0C6  23A0 C30A 0D63 C4B4 3758

[Adam Cooper]

Folks -
I get worried when people start talking about RDF, OWL (and to some extent even JSON-LD). And I speak as someone who HAS written advocating that standards developers should use semantic web practices to make unambiguous statements about classes, properties, specialisation etc. And I think linked data IS important and useful, although it is also worth noting that some people who were significant advocates for LD around 2009 are also now emphasising that publishing the data is most important, and that we shouldn't get hung up on semweb purity when that introduces barriers. Look up "csv on the web"

IMO the absolutely most important thing is good clear definitions of concepts, with the concepts being relevant to the education/training context and described accordingly. Secondly that a good balance is struck between concepts that are so vague they are practically useless or are so highly contextualised to a particular way of doing things that they are either not used or are mis-used. Sadly, most interoperability specs I have seen (and possibly some I contributed to) are terrible. They frequently have tautological definitions, they are often written in developer-speak, presume narrow stereotype use cases, appear to presume a certain operating context, or are just plain vague... Sometimes people even assume a single word or a noun phrase is sufficiently descriptive.
To go for formal semantics without clear definitions would definitely be arse-backwards.

In respect of [verb] vocabularies, rather than the spec generally, I propose that semantic relations should be initially used to aid discovery of the "right" verb for a given use, and NOT for doing anything with the data. i.e. as informative aids to navigation rather than normative relations.

Cheers, Adam