Skip to end of metadata
Go to start of metadata

Meeting Information




11 AM EDT/5 PM CEST (Central European Summer Time)

Attending: , Rachel Ellaway and JB McGee, co-chairs; Susan Albright, Ben Azan,  Dennis Glenn, Peter Greene, Grace Huang, Luke (SGUL), Debbie Sher, Valerie Smothers, Dan Walker.

Agenda Items

1. Review of in-person meeting

JB commented that both the developers meeting and working group meeting were lively. We spent a lot of time on general issues in the working group meeting. Rachel commented that throughout the conference the importance of getting it out as a standard was emphasized. JB agreed. It's the working groups decision to say when they are done. After the working group considers the spec to be ready, the Standards Committee reviews the specification, provides comments back to the working group, and sends the specification out for public review, during which the public may have comments. Once the public review comments have been addressed, the standards Committee votes on the specification.

JB commented that one issue yet to resolve is triggering. Other things can wait until future releases. Rachel added that other than triggering, an issue has been raised about counter changes on links, which does not currently exist in the spec. A Link is a relationship rather than object. Another issue has arisen in EViP- extensible elements. Campus wants to embed Question Test Interoperability (QTI) objects within pages. JB asked how critical that was. Rachel replied that for them it is critical. We haven't got a way that can be instantiated at any location. Susan added that they have been interested in that for a long time. Having it integrated would be preferable to having an external service.

Peter asked how you would extend. It's invoking an outside service. We have to be able to say what the player is able to do- what it does if it locates the service, what it does if it can't locate. Does it have to count on having that available? Rachel commented that MVP is the core functionality. We need to be able to build on that and have graceful degradation. To do that, we would need a typology of services. There are applets that will run QTI, others for mathml.

Ben commented that there was some talk about how to do this. We added Xtensible info elements, standard player would ignore them. Each system could add their own elements. Does that address the issue?

Rachel commented that is the model they looked at. Now they are looking at specific tags within schemas to standardize how that is done. Is it in dam or elsewhere, do we need a vocabulary type? The object needs to announce itself as a qti object. Peter commented that there is a clear way of representing questions and answers. But there may not be a well used service model. Can we leave a hook in that says take a web browser to this url? We could spend a long time at this. JB commented that we could maintain a list of services separate from the spec. The URL may not work without parameters.

Peter asked if Campus wants the player to deliver QTI assessment items. Rachel commented that they are interested in how this will work on the export side. JB asked do we pursue solving this problem, ignore it for now, or work on it for the next release? Rachel added that she thinks the solution is simple; we just need to decide on it. But we should run it past the Technical Steering Committee. JB agreed to have a separate conversation about this. If it is simple, it makes sense to solve it. But not on this call. Rachel added that Ben has done sterling work in thinking through many issues. It would be great for him to take this forward. Ben will come up with a proposal. Dan asked if we have a concept of external services. JB replied that this will be a more sophisticated version of that. We will discuss Ben's proposal via email.

2. Triggering discussion

Ben introduced the triggering document. Triggering is a way to return data to users. There are three models: 1) immediately - everything displayed to the user at once. 2) On trigger - user must select the item to see the full data. 3) On delay - the user must select the item to see data at a later point in the activity. The DAM node item has an attribute called display that determines which approach is taken. When the full data is displayed, the item comment and sub-nodes of the item are displayed as well. If an item is on delay, when do you get the results? How we have discussed previously, include same data again in a later node, data is returned to the user. Ben proposes a change - a returned display option. If an item is marked returned it is ignored unless it has been triggered, in which case it is displayed. It will always display item comment and embedded nodes. If you have 5 diagnostic tests in one node and they are on trigger, then reference the same ones using the returned flag later, it only shows those tests that have been ordered.

JB commented that it makes a lot of sense. He sees how that can be used for learner feedback. Dan commented that the word returned doesn't make sense, but other than that he likes it. JB suggested requested or ordered. Dan asked what happens when you return to a node you've already visited. If you return to a node that has interview items, and they are on delayed, if you've triggered the first 2 only then return later, what will be displayed? Ben - in his it would display a full fresh node. Valerie commented that this was inconsistent with the notion that data is returned when it is referenced after triggering. Rachel agreed that once an element has been shown, it should continue to be shown. She recommended keeping the state model as simple as possible. If you trigger in node 15 and reencounter in node 17, it should show you the data and there after. Dan asked would the player present the opportunity to trigger any untriggered elements. Rachel commented that yes, the untriggered elements should still be triggerable. The group agreed to move forward with Ben's proposal.

3. Scoring discussion

Valerie summarized that Emily Conradi from St George's had contacted her regarding a suggested change in scoring. They have situations where a learner can get to a node from many different points, and depending on the origin, they would like to have different affects on the learner's score. So the score would be associated with the link rather than the activity node. JB commented that it could become quite complex. You can still account for just about everything in current design. It may not be worth extra effort. JB recommended looking at the specific scenario. Labyrinth should be able to accommodate it. JB recommended continuing the conversation with Emily. JB asked Luke to relay the conversation to Emily. Should we change labyrinth and the spec, or can we accommodate St George's needs in other ways?

4. Open discussion


Action Items

  • No labels