Wednesday 26 November 2008

XCRI-CAP Schema in HIVE

Sam has been successful in transforming an example xml file (created from a XCRI-CAP xsd) into an SDI file for HIVE (an XML file marked-up for HIVE).

Sam is currently debugging the SDI file for validation and structure issues - in addition to making sure that the output XML file is valid for how the XCRI XML should look.

The software we are using is XMLSpy - a very useful development tool for this part of the project.

Work is continuing on refining the SDI file - in particular the issue of defining attributes for spceific elements. HIVE has a limited range of available attributes for schema elements - for example xml:lang="en-gb" is used with langstring for the title element. The problem is when XCRI refers to other attributes, for example, src / title / alt for image element or onclick attributes for x:div for description element.

XCRI Adoption

Link: http://www.jisc.ac.uk/media/documents/programmes/elearningcapital/ximfinalreport.pdf

Monday 24 November 2008

Mapping DIVAS Validation Document Attributes to XCRI-CAP

The following is a list of the attributes/element types that QA and the project team would like HIVE to specifically record against validations (these are also considered as the searchable elements) - possible XCRI-CAP elements are hyperlinked:

Thursday 20 November 2008

Understanding the XML

Useful link: http://www.w3schools.com/schema/schema_elements_ref.asp

I have been comparing the HIVE SDI XML file for IMS 1.3 and the XSD file.

Interestingly - the XML (SDI) file used by HIVE does not reference the LOM 1.3 XSD URL - however this does appear in the exported metadata XML - see:

HIVE must have this recorded somewhere else.

This is useful to know - as I am writing (attempting to write) an SDI file (XML) for XCRI-CAP. This is a bit trickier than the LOM example as LOM is neatly linear elements (hierarchical tree - see image)

XCRI - is somewhat less linear and object led - so writing out a structured tree for it may require some interrogation to identify elements and the branches/leaves. Essentially I need to write nested tags with attributes that tell HIVE how to provide the GUI/Boxes for the data inputer.

Exploring the XCRI Markup

See: http://wiki.teria.no/confluence/display/CIF/xcri-properties
See: http://www.bsi.mmu.ac.uk/courses/ects_example_rgu.xml

XCRI Documents

"An XCRI-CAP XML document MUST have one of the following resources as its root element:

* Catalog
* Provider
* Course

In general any provider SHOULD use Catalog as the root element.

The specification allows both Provider and Course as alternative root elements to enable REST-style operations to be provided by aggregators (much in the same way that the IETF Atom specification enables both feed and entry elements to be document roots).

Resources

A resource is something that can be uniquely identified [1]. In XCRI, we identify resources using a Uniform Resource Identifier (URI). A resource can possess a number of properties, which may be simple value-strings or can be structured.

XCRI-CAP specifies the following resource classes:

* catalogs advertise providers
* providers advertise courses
* courses are presented for enrolment any number of times through presentations
* presentations instantiate courses

Inheritable property values

Some elements may be inferred from their presence in a containing resource when not present in child objects. Specifically:

  1. Where a presentation does not contain a venue, an Aggregator SHOULD assume that the venue details (name, address, email, fax, phone, url, image) are exactly the same as the properties of the provider. An Aggregator MAY assume that the description is the same as that of the provider.
  2. Where a course does not contain an image, but its containing provider does, an Aggregator MAY use the image of the provider when displaying the course.
  3. Where a presentation does not contain an applyTo property, or a qualification does not contain an awardedBy and/or accreditedBy property, an aggregator SHOULD interpret this as meaning the capability is provided by the provider and use its contact information.

This enables XCRI documents to be less verbose by not repeating basic information"

From: http://www.xcri.org/wiki/index.php/XCRI_Course_Advertising_Profile#About

Wednesday 19 November 2008

Creating a XCRI-CAP GUI for HIVE



I have been interrogating the xml (SDI file) for the current IMS schema in HIVE.

In simple terms, the XML file appears to be a modified file, which is marked up against the HIVE syntax/markup - this markup outlines not only the schema hierarchy tree elements but also how they are presented to the metadata inputer.

The example I have here show the XML file in Dreamweaver and how it is represented in HIVE.

Tuesday 18 November 2008

XCRI-CAP & HIVE

If and when we decide to use XCRI-CAP as the metadata schema for HIVE (and this is not certain) we will have to 'configure' HIVE to accept this schema. This may be a simple process, but will require 'defining' the schema through creating an SDI file, which also assists in generating the GUI interface.

From HIVE admin guide:

"Chapter 3: Creating an SDI File
Hive imports, exports and stores metadata in XML format.
Standards bodies such as IMS, SCORM, and Learning Federation express the format of the metadata using an XML schema file. The actual metadata is stored in an XML instance file that can be validated against the schema file.

When a Hive user opens the Edit Metadata dialog, Hive dynamically generates a user interface into which the metadata is entered. From the user’s perspective, the format of the dialog closely matches the metadata format as published by the standards body.

As published by the standards body, the metadata XML schema file does not contain all of the information needed to generate the user interface. This extra information must be placed into a Structure Definition Instance (SDI) file. The SDI file is an XML instance file.

The SDI file contains:

  • Titles and descriptions of data items that are displayed on the GUI.
  • The type of field into which the data must be entered, for example, a single-line text entry field or date field.
  • The maximum number of characters that can be entered into a field.
  • Information that specifies whether the field is mandatory or optional.
  • Information that specifies whether multiple versions of the field are allowed."

XCRI-CAP


XCRI-CAP (Course Advertising Profile)

http://www.xcri.org/wiki/index.php/XCRI_Wiki

In essence the XCRI-CAP can be used to describe the courses being validated:

"A resource is something that can be uniquely identified [1]. In XCRI, we identify resources using a Uniform Resource Identifier (URI). A resource can possess a number of properties, which may be simple value-strings or can be structured.

XCRI-CAP specifies the following resource classes:

* catalogs advertise providers
* providers advertise courses
* courses are presented for enrolment any number of times through presentations
* presentations instantiate courses "

See: http://www.xcri.org/wiki/index.php/XCRI_Course_Advertising_Profile#Namespace

Monday 17 November 2008

JISC Project Meeting: Chelsea

Had a very useful and interesting meeting with JISC & other project groups.

Was interested to hear of the experiences of metadata schema related to validations and course descriptions from:


They had experience of developing and using the XCRI schema for course descriptions. This appears to be a more appropriate schema for this project (I hope) - I will investigate further.

Further to this - Staffs had it's own project associated with XCRI = http://www.staffs.ac.uk/xcri/

UPDATE
Spoke to project lead Peter Moss associated with staffsXCRI project. Main thrust of feedback was the difficult nature of the task. Insofar that the data is simply not collected in a way as to be extracted for XCRI - too much complexity to represent.

Doesn't bode well for DIVAS - however it was noted that the metadata being collected for DIVAS is at QA Validation, therefore, there could be a new precedence for collecting data against set elements at the validation stage. This in turn could be available for re-purposing for course description purposes.

Monday 10 November 2008

Back on track

After the set-back that was Microsoft Word badly marking up documents to create xml - I have been looking at how best to store/record/markup the documents using the LOM schema (through alternative data entry methods). Myself and Sam have met with Chris again to establish how the validation process handles these documents and how/why/where/what is recorded within the process.

We have a further meeting today to pin down exactly what LOM fields are being used and the method through which documents will be uploaded to HIVE and retrieved from it.