Guidelines for Property Use

The various label properties are special. For any xAPI term with a natural language rendering in-Statement, such as a verb’s display, or an activity’s name, they’re for providing possible forms for that. For all xAPI terms they describe how to refer to them when displaying the vocabulary. For example, even though Activity Types don’t have a natural language rendering in statements, the label properties tell us how to write about them in documentation without putting the IRI everywhere.

The note properties, while often including natural language strings that can be used when displaying the vocabulary, also have more flexible uses, such as putting a Statement in the example property. But, like the label properties, they’re primarily descriptive; there’s little that a computer can do with them that couldn’t be done with just an HTML page.

Where we start to see the power of RDF is with the use of SKOS concept schemes, but also the PROV ontology. By relating a specific revision to an overall vocabulary concept scheme and its preceding revision, and then relating each xAPI term to the specific revision and the overall vocabulary, it becomes possible to quickly determine answers to questions like “have any terms been added or removed in this revision?”, “is this term in the most recent revision?”, and “are there any further revisions beyond revision X?” Note: the appropriate way to publish vocabulary datasets under this approach is, when the URL for the overall vocabulary is visited, redirect to the URL for the current revision of the vocabulary.

Add in prov:wasGeneratedBy, and it will also be possible to describe things like responsibility shifting for a vocabulary, such as the recent transition of ownership of cmi5 verbs to the ADL vocabulary. See the example below. While these capabilities may seem less important now, look at how many different groups are starting to coin terms already, in these very early days of xAPI. A small amount of extra information now, easily expressed, will make the future much easier. The PROV ontology exists to handle these sorts of provenance tracking in a sane, proven model.

In many ways the most immediately exciting part of using these terms will be the capabilities enabled by the SKOS semantic relationships such as broader, narrower, and so forth. Using these for in- and between-vocabulary relationships of terms will make it possible to answer questions like “are there any similar terms in other vocabularies?”, “what are all the verbs I need to query for if I want all the statements this verb applies to as a concept?”, “I have this natural language term, are there any xAPI verbs related to it?”, and even “If so what are the natural language terms they connect through?”.

results matching ""

    No results matching ""