Follow

Is there a standard Tin Can database architecture or schema?

Avatar

No, there is no standard LRS database schema, every LRS implementer is free to choose their own data storage architecture. In early implementations, there seems to be a split between people using traditional relational structures and people using NoSQL data stores.

As we watch the early LRS implementations emerge, it will be interesting to see the schemas and best practices that emerge.

Fortunately though, a standardized database schema isn't necessary for data to be ported between systems. The Tin Can API itself can be used to pull (or push) all of the statements from one LRS into another. This system-to-system communication is a significant use case that the spec is designed around.

Was this article helpful?
2 out of 2 found this helpful
Have more questions? Submit a request

Comments

  • Avatar
    Chris P

    Creating a database that stores the whole TinCan specification is a large job that requires understanding and translating every detail and option contained within the specification. For new developers of TinCan systems on database backends, the schema is the first step. It needn't form part of the specification, but it would be a massive practical help to have a template database schema to get going with - just an E-R diagram would save hours.

    The closest I've found to a shortcut is translating github.com/adlnet/ADL_LRS/blob/master/lrs/models.py - is there anything clearer?

  • Avatar
    Chris P

    To any others with similar needs, there's a very handy E-R diagram on wikipedia:

    http://en.wikipedia.org/wiki/File:LOM_base_schema.png

    Looks comprehensive although I haven't gone through it in detail yet.

  • Avatar
    knowingpark

    CouchDB is a (nosql) json document store.
    It has a http api built in.
    You write queries using javascript (map/reduce) functions.
    It seems like a perfect LRS for TinCan data.
    Would you agree?

  • Avatar
    Brian J. Miller

    @knowingpark CouchDB by itself is *not* an LRS, and usually only having a JSON document store isn't going to be sufficient as there are other parts of the specification aside from the statement stream itself. The document APIs in particular need to be able to store arbitrary binary data (granted you *could* encode it into JSON and stuff it in a JSON document store), and that binary data needs to be returned in a specific way on retrieval. There are also a number of other validation requirements that need to be met, etc. that direct API calls to something like CouchDB are unlikely to be able to provide so it would be very difficult to make it a conformant LRS.

    Having said all of that, CouchDB would be a perfectly fine backing store for an LRS for statement storage.

    For more on what it means to be an LRS have a look at: https://tincanapi.com/building-a-learning-record-store/

Powered by Zendesk