QTI Profile and IRIs

[bmottershead]

Where would a QTI Delivery System get all the IRIs it would need for generating the various event messages? They are not in the QTI Content Package or in the QTI content itself.

Is there a standardized way of arriving at the correct IRI from the information in the content package or the QTI content files? In 1.2, the Delivery System needs the IRIs for each level of the ASI structure (Test, TestPart, Section and Subsection, Item), as well as for each Outcome, Response, and Template Variable. The IRIs of the actor, context, and session are also needed. Can all of these be determined somehow from the information in the content package or in the content? If so, this method isn't in the spec, and if each Delivery System has to come up with its own scheme for assigning IRIs, it would likely be an interoperability issue. The IRIs are supposed to be dereferencable.

The 1.2 spec also requires the Delivery System, when generating Caliper events, to generate and describe numerous entities. This puts the responsibility for generating large numbers of IRI's on a QTI delivery engine which is generating Caliper events: for Attempts, AssessmentResults, TestResults, ItemResults, CorrectResponses, CandidateResponses, down to even Values. There are also the events themselves. The spec states that the events should have randomly-generated version 4 urn:uuid IRI's, so that takes care of those. But what about all the other entities that have to be generated and described? How are the IRIs to be generated in a manner which is interoperable with other delivery systems?

This is an issue also with the v1.1 version of the Caliper spec, but there are a lot more entities being referenced and described in 1.2. By the way, is it really necessary or desirable to model the QTI Results Reporting structure with so many discrete Entities, when many of the IRIs being generated are likely not to be dereferencable?

[padraig-ohiceadha]

It's not a requirement that all IRIs be de-referencable.
There can be an interoperability benefit where the IRIs are de-referencable (e.g. if you can de-reference an IRI for an item and retrieve the item XML then the even consumer would be able to obtain most of the additional information required to be able to do many of the analyses a psycho-metrician would be interested in.
Where a de-referencable IRI can not be provided the event generator can provide an urn:uuid which can be used to provide a distinct identify which can clarify if two entities across two different events with the same value are the same object or different objects.
And where a value has no independent existence outside it's containing object a "Blank Node Identifier" may be used.

"4.2 Identifiers
Linked Data relies on IRIs/URIs for the identification and retrieval of resources. Likewise, JSON-LD specifies the use of IRIs/URIs for identifying most nodes (i.e., JSON objects) and their attributes. Caliper too specifies the use of IRIs for identifying nodes (i.e., the things or entities being described) and their attributes.

IRI values MUST be absolute containing a scheme, path and optional query and fragment segments. A URI employing the URN scheme MAY be used as an identifier although care should be taken when employing a location-independent identifier since it precludes the possibility of utilizing it in future to retrieve machine-readable data over HTTP. If an IRI is deemed inappropriate for the resource a blank node identifier may be assigned."
and
"Blank Node Identifier: a string that begins with “_:” that is used to identify an Entity for which an IRI is not provided. An Entity provisioned with a blank node identifier is neither dereferenceable nor has meaning outside the scope of the JSON-LD document within which it resides."