The CASS Project encompasses a ground-to-cloud effort to build an open source system for managing and tracking human competence and competencies using Permissible Open Linked Data (opens new window).
- Linked - CASS objects use URLs as IDs. References to these objects can be made by using the object’s ID/URL. Because of the nature of URLs, CASS objects can be uniquely identified across the globe.
- Open - By default, all CASS data is public. Firewalls, whitelists, and other means are available to prevent this.
- Permissible - CASS objects are permissioned through use of Public Key Infrastructure. Entities (systems, users, apps) are identified by independently verifiable, signed, public keys. Read permission is controlled via the use of encryption.
# Client-Side (Reference Implementation)
- CaSS Authoring Tool (opens new window)
- Servlet Container (opens new window) (Tomcat (opens new window) on port 8080)
# Data Model
The CaSS schema is available here (opens new window).
# CaSS Repository (SkyRepo)
The CaSS Repository is a REST (opens new window) based JSON-LD (opens new window) object store with CRUD, Search, Permissioning, and Basic Identity Management functionality. It includes an extensible plugin infrastructure.
- SkyRepo attempts to follow RESTful HTTP best practices.
GEToperation is used to perform a READ
PUToperations will CREATE or UPDATE an object
DELETEoperation will DELETE an object
- Search is available using the
?q=<search query>format and follows ElasticSearch Simple Query Strings guidelines.
- Permissioning is applied for every query. Authentic requests are validated through the verification of “Signature Sheets” (a form of signed nonce+timestamp token sent with the request). OAuth-based permissioning is currently in development.
- Encrypted objects are not returned without a valid signature sheet from an object owner or reader.
- Objects, if owned, may not be updated without a valid signature sheet from the current object owner.
- Objects, if owned, may not be deleted without a valid signature sheet from the current object owner.
- Encrypted objects may be decrypted through use of the private key of one of the owners or readers.
- Encrypted objects may be created through the use of a public key of the intended owner.
- Basic Identity Management is a hashed username and hashed password based store for private keys. By default, CaSS Keys are generated client side and encrypted with a combination of the clear text username and password. As a result, the server owner does not have the capability to manage or recover a user’s keys.
We encourage people to use a different identity management system.
# Looking Around
For a more hands-on approach to understanding the specifics of CaSS, we should take a look at some data directly through your browser.
All data may be accessed by your browser.
- Navigate here (opens new window) in a new tab, open up a framework (like O*NET Expanded) and click the URL (opens new window) under the description.
- You will then see the JSON-LD representation of the Competency Framework.
- Under ‘competency’, there are many URL's. Click one to navigate to that competency.
- Here, you will see fields like 'name' and 'description'. These, as you would expect, are properties of the object according to the schema defined at
@typeare properties of the JSON-LD format.
@reader(if it exists) and
@signatureare properties of the KBAC extension to JSON-LD.
- Everything that begins with
@can be thought of to be metadata properties, and everything else is data.
If you would like to learn more about how JSON-LD works, you can visit this tutorial series on Structured Data (opens new window).
Hopefully, it is easy to imagine how a browser, scripting language, or other server would take advantage of this data. But reading data is of secondary importance to being able to find it. For that, we need search.
- Navigate here in a new tab. This performs a search query with the query being
*. Using ElasticSearch Simple Query Strings (opens new window), you can query in quite a few ways.
- First, replace
Addition. This performs a full text search for Addition in all fields.
- Next, replace
name:Addition. This requires the term Addition to appear in the name field.
- Next, replace
tract. This should come up with no results. By default, the search matches words, not strings segments. This can be overridden by using wildcards.
*tract*. This should come up with competencies that include terms such as subtract and contraction.
- Now try
name:*tract* AND description:*tract*. This will return competencies that have tract in both the name and description.
This can be used to construct search queries that filter based on the owner of the object, user search terms, or by type.