JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for CETIS-QTI-SIG Archives


CETIS-QTI-SIG Archives

CETIS-QTI-SIG Archives


CETIS-QTI-SIG@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CETIS-QTI-SIG Home

CETIS-QTI-SIG Home

CETIS-QTI-SIG  2001

CETIS-QTI-SIG 2001

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Notes from Ottowa IMS QTI meeting

From:

Niall Sclater <[log in to unmask]>

Reply-To:

Niall Sclater <[log in to unmask]>

Date:

Tue, 2 Oct 2001 16:40:58 +0100

Content-Type:

multipart/mixed

Parts/Attachments:

Parts/Attachments

text/plain (5 lines) , ottowa.txt (28 lines)

 I attach notes I took at the Ottowa IMS QTI Working Group meeting.  The official minutes are also available on the IMS QTI forum.  Apologies for the delay but I was waiting for them to be checked by the Working Group before circulating them.  Minutes from our recent SIG meeting and the date of our next meeting - early December in Luton - (hmmm that has a certain ring to it, like "Paris in the Spring" - not) will follow shortly.

All the best
Niall.


IMS QTI Working Group, Ottowa, 20-21 August 2001 Notes from N.Sclater. This meeting concentrated on reviewing the draft v1.2 results interoperability, outcomes processing and selection and ordering specifications before they are submitted to the Technical Board for approval. We had an initial look at contextres; there was a query on the use of the Genidentifier element. The GUID is inherited from the Enterprise and LIP specs. The options were to just have a basic GUID or to keep the three sub fields: typname, source & ID. See page 97 of ASI. It was decided that source is removed and that we will just include typename & id. Datetime uses an ISO standard - 8601 Summaryres: the status attribute refers to whether this is the final score, after human checking for example. Statusdescription was changed to statusvalue. Duration is also defined under ISO8601. Scorereliability is to be added ie if you took the test more than once what is the reliability of it. Ammendments were made to the various attributes of score. Assessmentres: the original asi didn't have the concept of grade. There was discussion as to how you calculate grade from score - this is not obvious. Grade contains gradevalue and gradecut. Gradeset is being removed but gradecut being kept. There was a discussion on metadata and how to incorporate ims metadata into results. Response: responseidentifier was moved from responseform into an attribute of response. A problem is how to identify whether someone didn't reply or not. SCORM: the mapping of results has been done by ADL and is straightforward - it will be posted to the forum imminently. SCORM - IMS QTI integration will not be achieved before the end of this year. ADL is particularly interested in the implementation experience of QTI and is keen to do a joint plugfest at some stage. Agreed to try and compile list of people who are using the spec and they can choose if they want to make their entry public or private. It was noted that people are complaining that the element names are often too cryptic in QTI. You're not actually saving anything by leaving out full element and attribute names. The EML people started off with cryptic ones and now have huge but comprehensible ones. Before moving to schemas it would be worth making element names easier to understand. It was also mentioned that IMS policy will be to use underscores when there are two words. We then started rewriting all names in results. Outcomes processing: This allows you to define your own scoring algorithms by defining the differences between inputs and outputs. We spent much of the second morning going through the various outcomes processing use cases. Can Studios, a new member of the group had a query. They are using Shockwave to render qti. They need to position text with xy coordinates using mattext. There was concern about ammending the spec from an interoperability perspective. Precise text positioning might not be appropriate for participants requiring large text for instance. However other elements such as images already have positioning data. There is a need to apply a context for the xy coordinates - does the position relate to the screen, the window or what? It was agreed, after much discussion, that coordinates for text would be incorporated but it should be ensured that there is something in the spec saying that the rendering system can ignore these coordinates if necessary.

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
October 2013
June 2013
April 2013
March 2013
November 2012
August 2012
May 2012
February 2012
January 2012
November 2011
October 2011
September 2011
August 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003
2002
2001


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager