Update: The Output of Project Tin Can is Experience API.

next generation scorm evolution project tin can
 

Ready to really dive in?
View the full
Tin Can API spec.

View the Tin Can API
“quick start” guide.

Home | Overview | Capabilities | Weaknesses | Next Steps

Weaknesses

There’s a ton of relevant information on this page, but if you want the latest and the greatest, visit experienceapi.com.

 

The nature of adding new functionality to something as far-reaching as e-learning specifications inherently involves design trade-offs and compromises. Focusing on one area often necessarily involves compromising on other areas. We’re well aware of these weaknesses, and we have suggested solutions for most of them. Look through the list, check out our suggestions, and let us know what you think.

  • Pingback: Getting to Know Project Tin Can (Next Generation SCORM) | onehundredfortywords()

  • shdanfo

    I’m new here, but have always felt the major weakness of AICC/SCORM was minimal agreement on semantics of the data being stored. Certain core data elements were well-defined (in the sense that both Content and LMS knew what they “meant”). But, in general, the spec was syntax, with no specified semantics (so only the content could interpret anything). This problem was always swept under the rug, rather than being addressed honestly and up-front. I’m not sure that this effort based on JSON is much different. An LMS should understand the semantics of statements made to it. Information must be communicated (rather than structured data that has no agreed-on meaning). JSON is just syntax; where is the semantic component of this new approach (or is it again to be found under the rug)? Tin Can’s position on this fundamental issue should be included in a top-level outline of the approach.

  • Ben Clark

    I’d be curious to know what sort of elements you would like to see better defined.

    The philosophy driving the Tin Can specification here has been: well defined set of core semantics: core verbs, completion, score; and syntax to support communities of practice establishing their own defined semantics.

    In particular, an important topic we’re thinking about and have been talking about in the specification working group is the concept of ‘Verb Extension’. We will not be able to define a core set of verbs that is sufficient for everyone, so we have a small set of core verbs (which itself needs some expansion), and will be defining a process for other’s to define their own verbs. These may be related to core verbs so an LMS that is not aware of the extension verbs can still get the ‘basic’ meaning of a statement, but it could extract more meaning if it handled the extension verb specifically.

    The big problem with saying that everything communicated has to have a meaning established by the spec is this severely limits what can be communicated. SCORM has been around for over 10 years, think of the changes in what people have wanted to communicate during that time.

    Again, common core semantics are important, so please do let us know about any holes in the core semantics of Tin Can that you are aware of and think will have broad applicability. But also leaving in place the ability to make statements that the LRS/LMS is not specifically designed to handle is an important feature, not a bug. This allows everything about a learning experience that one wants to track to be tracked, and then the portion of that tracking a system is designed to parse can be parsed. In the worst case, a system can still pass on a detail report that will at least have meaning to a human. Furthermore, in Tin Can statements can be passed between systems, so even if the first system can’t ‘understand’ a statement, it could be aggregated into another system that can.

  • Pingback: Why SCORM 2004 failed & what that means for Tin Can | eFront Blog()

  • If someone wants to tighten up semantics, it might be worth connecting with the Open Ontology Repository Initiative. I believe some #API development is underway there now. A couple of links follow:

    http://www.slideshare.net/yimpp/oor-openontologyrepositoryjun2010

    http://sandbox.oor.net/ontologies

    http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository