hied-course-brainstorming

Brainstorming on Course format

Contributors

• Jose Cuevas

See Also

• hied-course-examples
• hied-course-formats
• hied-course-brainstorming

What is happening?

• Course information is available in disparate formats which makes it hard to compare information, extract information and find information.
• Students Information Systems lack proper data exchange schemes and standards.
• No data syndication of course information among campuses.

Why would it help?

• A community format allows the use and sharing of course data commonly publish on the web.
• Provides semantics to academic information.
• Provides means to mechanically operate on web content for data that otherwise is published on PDF, printed, published with proprietary EDI or XML interfaces or worst jailed in a Student Information System.

Course entity analysis

There are various attempts to produce an schema or data model for Course information.

In 2005 MACE and the Course Working Group published the first schema for eduCourse. eduCourse was largely centered to an LDAP Schema and the eduPerson efforts. The primary motivation of the Course WG was the access to on-line e-learning materials. (IMHO!)

The UK oriented eXchange of Course-Related Information is geared for course advertising. The XCRI was built thinking about automation of course catalogs and RSS aggregation of course data which are more aligned with the notion of Microformats.

While XCRI and eduCourse are great advances they fall short of providing a standard that is widely supported agreed upon or used. In the absence of a single agreed-upon international standard we should attempt to provide a basic and flexible schema. We should attempt to look at the common denominators from all of these efforts and review the use-cases to identify priorities and needs.

Barriers

1. Exchange or semantics for course data requires to standardize many properties and enumerations. Its going to be a while before the international community settles on a standard.

There seems to be a clear pattern on what the common elements are among the available standards. The sheer number of course catalog's published online by university helps identify the common need and use.

The Postsecondary Electronic Standards Council has an approved standard for EDI and XML Transcripts which already offers a basic data model for Courses in the academic history. The standards of the PESC are supported by many of the mayor HiEd ERP vendors. (interesting)

The British eXchange of Course-Related Information, is an approved standard which is gaining good visibility among UK schools, even within the PESC.

Normalizing available standards

Comparison of fields supported among standards

1.1. Title
A human-readable title of the course.

• PSEC: 'CourseTitle', one language supported.
• XCRI: title, multiple languages using the 'xml:lang' attribute.
• eduCourse: N/A

1.2. Description
A human-readable description of the course.

• PSEC: N/A.
• XCRI: description
• eduCourse: N/A

1.3. Institution

• PSEC: CourseInstructionSite, CourseInstructionSiteName
• XCRI: relation? url?
• eduCourse: N/A

1.4. Identifier
Course identifier, particular to the university, call-number

• PSEC: OriginalCourseID
• XCRI: identifier, not clear how is this used in the scope of a course ID or is it just a reference id.
• eduCourse: courseID

1.5. Offering
A unit/class section.

• PSEC: CourseSectionNumber, CourseBeginDate, CourseEndDate
• XCRI: presentation
• eduCourse: sectionID, type, rendezvous

1.6. Credits
Eg Credit hours.

• PSEC: CourseCreditBasis, CourseCreditUnits, CourseCreditLevel, CourseCreditValue
• XCRI: Credit
• eduCourse: N/A

1.7. Level

• PSEC: CourseCreditLevel
• XCRI: qualification, level
• eduCourse: N/A

1.8. Requisites
Registration/Enrollment requirements.

• PSEC: N/A
• XCRI: N/A
• eduCourse: N/A

Data offered on courses by admissions agencies

• University and College Admissions Service (UCAS) is the UK body for admissions applications for undergraduate degree courses. For each course they offer, they have the following data:
  • Degree course name
  • Degree course code
  • Institution course code
  • Address and details of institution
  • Entry profile - that is, what requirements there are for admission
  • Date of application close

Suggested entities for a microformat

This section attempts to summarize the observations made and the result of a survey of course catalogs, course listings and course information published on the web.

Course
The course itself is used as a "academic activity" that belongs in a "Degree"/"Programe". It is an entity of transcripts and academic history and enrollment offerings.

Common core attributes of a course are:

• Title. A human readable title. May appear in multiple languages. Short/abbreviated and long forms.
• Description. A human readable description of the academic activity. Course requirements are often part of the description. While for must part enrollment requirements are listed separately.
• Course ID. A unique identifier of the course. Particular to the institution. Format varies. Usually a structured nomenclature is used. Used by information systems during enrollment and another system tasks as an ID.
• Enrollment requirements. Criteria needed to enroll in the course. Commonly known as pre-requirements, etc. Different from course requirements.
• Credits/Credit-Hours. Unit of effort required to complete the course and at the same time earned. The notion of credits hours are standard in the US and its territories (PR, GUAM, Virgin Island).
  • In the United Kingdom, credits are offered on a course-by-course basis. One must have the adequate number of credits to graduate, but it is more of a formality than it is in the United States.
• Level. Is it a Undergraduate, Graduate, Professional, etc. Commonly associated to the level of the degree for which this course is a requirement.

Course Offering
A course offering is the actual teaching section of a course. A course may have multiple teaching sections.

Common core attributes of a course offering are:

• Section ID. A unique identifier for the teaching section. Commonly used along the Course ID. Important for enrollment. Particular to the institution.
• Meetings. Times/dates in which the section meets. Commonly on week basis for the duration of a particular term. Seldom listed as absolute dates, instead most sites list them as reoccurring day and time events.
  • To make this slightly more complicated: there can be a mixture of different meeting types, and some are optional - for instance, a course may state that you have to turn up to all the lectures, and have to turn up to one or more of three field trips.
• Meeting modality. Is it a lab, lecture, field practice, online
• Professor. Who is teaching the course section. hCard!
• Location. Commonly a classroom and building. Must of the time the location is paired to a meeting. adr, geo!
• Term. The actual value ranges from textual values, to structured identifiers. Particular to an institution. Things commonly used are Summer, Spring, Fall and the year or academic year.
  • A list of some (traditional) academic terms can be found in the See also section of wikipedia:Michaelmas term

Course Catalog
A listing of courses available at a institution.

Degree
An academic program that needs to be completed to earn a degree. Includes courses as requirements.

Existing Microformats

Other microformats approved or in draft that could help a new Course microformat.

hCard
All people references must be in hCard. Eg professor.

adr, geo
Location references must use geo and adr. Yet not quite sure if "adr" is suitable because must of the time locations are listed as building and room number.

hCalendar
Seems a perfect candidate for meeting times, yet given that meetings are listed as reoccurring events on particular days and times this may not quite fit.

hListing
There is good potential to make course catalogs and course listings a hListing. At first glance this may require to broaden the scope of hListing.