1 / 39

Content Specifications

Content Specifications. Content Packaging Content Launch Content Runtime API Question and Test. Content Packaging. Aim: to transport Content between Systems Content can be compound and structured A Package carries its own metadata Structural and metadata info in special file

oleg-talley
Télécharger la présentation

Content Specifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Content Specifications • Content Packaging • Content Launch • Content Runtime API • Question and Test

  2. Content Packaging • Aim: to transport Content between Systems • Content can be compound and structured • A Package carries its own metadata • Structural and metadata info in special file • Content files are ‘flat’ within the package • Compressed zip/JAR format

  3. Content PackagingThe Manifest • Every IMS Package has a Manifest • Must be called: META-INF/MANIFEST.IMS • This is a nested tree structure of sub-Packs • Allows multiple files to be aggregated • The root Pack is called the Manifest

  4. Content PackagingPACKS Contain: • one METAD element (holds metadata) • one CORG element (Content Organisation) and • Either: one DATA element (a Content file) • Or: one or more (sub) PACK elements

  5. Content PackagingA SimplePACK PACK METAD CORG DATA (Note: each data element is wrapped in a Pack)

  6. Content PackagingA CompoundPACK PACK METAD CORG PACK (Note: Packs can be wrapped in a Pack)

  7. Content PackagingThe METAD Element • Contains one or more META elements • a META element contains • a TYPE • a NAME (of the metadata file) • The IMS type element holds IMS meta-data • Other types may be included: • install • launch

  8. Content PackagingThe METAD Element METAD Meta-data (“ims”) Meta-data (“install”) Meta-data (“launch”)

  9. Content PackagingThe CORG Element • Can contain multiple TOCs • a TOC can be more than a Table of Contents • Can be an index, suggested paths, etc • Extending to also hold active sequencers • CORG elements cannot reference upwards • a CORG is optional but recommended

  10. Content PackagingThe CORG Element CORG Table of Contents 1: Historical Sequence Table of Contents 2: By Geographic Distribution Table of Contents 3: Animated Diagrams

  11. Content PackagingThe DATA Element • These are references to zipped files • They are the ‘payload’ of the Package • The Payload files can be: • web pages, programs, any type of data file, etc. • Data Elements may also reference URLs to external files

  12. Content Launch • How do Content & LMS talk together? • V0.5 used CORBA, RMI and DCOM • An IMS system would have to support ALL • Vendor Wars! • Also large and relatively complex to • Implement • Install • Operate

  13. Content LaunchSolution • LMS initializes Content with a Proxy • Proxy has an IMS defined API • Content knows how to talk to Proxy • Proxy knows how to talk to LMS • Hides the underlying comms infrastructure • IMS rises above Vendor wars

  14. Content LaunchABindingProblem • Content implemented in various languages • HTML, JavaScript, Java, ActiveX, etc • Therefore need a ‘binding’ for each type • LMS needs to provide a proxy in each language • the right ‘binding’ must be given to the Content • Java could be a universal binder/adapter, but Vendor wars break out again.

  15. Content Runtime API • Once communication established, need: • An agreed way to communicate • Proposed: • A virtual tree hierarchy data schema • A simple set of messages • getValue, setValue in the ‘Data Tree’ • Move virtual location in data tree.

  16. Content Runtime API • XML used for interchange format • LMS translates internal data structures into XML format specified by IMS • Info about learner and profile • Info about content and metadata • Info about state of LMS • Also need info about learning group

  17. Learner Profile - PAPI • Personal and Private Information - PAPI • Also being submitted to IEEE LTSC 1484 • More than record of achievement • Seeking to support Intelligent Tutoring • Preferences likely to become complex • Work with live Content and Sequencers

  18. Learner Profile - PAPI • Personal (Private - name, address, email, etc) • Preferences (Public - accessability, learning style…) • Performance (Machine - performance & assessment) • Portfolio (Human - work produced by the learner) Security is an important part of the PAPI spec

  19. Learner Profile - PAPICodings, API & Protocols • PAPI codings. A PAPI record may be coded in a PAPI coding. The data interchange is facilitated among data exchange participants by an agreed coding specification. • PAPI Application Programming Interfaces (APIs). The API is a control transfer mechanism (control is transferred from caller to callee) that affects data interchange. • PAPI protocols. The protocols are both control transfer and data transfer mechanisms. “A conforming implementation shall include one or more bindings to codings, APIs, and/or protocols.”

  20. Learner Profile - PAPI The IEEE 1484.1 Learning Technology System Architecture (LTSA) specification PAPI applies to both Individual and Groups of Learners

  21. Learner Profile - PAPISpecial account taken of: • Nomadic and Sporadic users • Distributed Systems • Lifelong Learning = distributed over time • Synchronise Local & Remote Profile Servers

  22. Learner Profile - PAPISecurity • Features specified in the context of threats • Based on: • ANSI IISP security model • the work of ISO/IEC JTC1 SC27

  23. Learner Profile - PAPISecurity Considers: • Perimeter integrity • Inbound threats (entering, changing data) • Outbound threats (taking data) • Security strength

  24. Learner Profile - PAPISecurity Personal, Preference, Performance & Portfolio security considered under scenarios, e.g. • Naming of views • Who has access • Unauthorized reads • Unauthorized write • Transfer to/from back office Discussion is ‘informative’ - no solutions yet!

  25. Groups • Set out in original IMS Requirements • Part of original 0.5 spec, but dropped in 0.6 • Needed for Classes and group learning • Group Scope accepted at last Tech Board

  26. Groupsthe need • Course Preparation and Admin Systems (Prospectus publishing and Enrolment Systems) • Enrolment Systems and LMS • Between Learning Management Systems • Server-based and personal/portable LMS • Runtime Services and multi-user Content • Extend single user content to provide group access • LMS and analysis systems (e.g. evaluation) • enable association between person/s & content

  27. GroupsSupport two functional areas • Bulk data exchange format between Systems • Run-time access to Group data by Content

  28. Groupsthe basic scheme Group • optionally contains Members • optionally contains Resources • optionally contains SubGroups

  29. Group Content IMS Package IMSMetadataItem URL IMSPackage Members IMSProfile E-Mail Sub-Groups Sub-Group 1 Sub-Group 2 GroupsElaborating the scheme

  30. GroupsSketch of schema <Group> <Members> <Teachers> … </Teachers> <Learners> … </ Learners > </Members> <Resources> … </Resources> <SubGroups> … </SubGroups> </Group>

  31. Admin & Support Systems(Enterprise Systems) • Main objective: integrate Admin & LMS an essential prerequisite • Define a set of Messages (Transactions) • Define a supporting Protocol

  32. Admin & Support SystemsRequirements • Neutral wrt Data & Function distribution • Conform to IMS Data architecture & protocols • Support Publish/Subscribe & Query/Response • Core Messages with Minimal Required Data • Extensible • Support Critical ‘Enterprise’ Systems: Human Resources, Student Admin, eMail, Security, Directory Services

  33. Admin & Support SystemsRequirements • Define Messages for Basic Data & Processes • Compatible with other IMS Specifications • Incorporate other Standards Initiatives • SPEEDE/Express • PESC (Post Secondary Education Standards) • SIF (MS K-12 Schools Interoperability Framework)

  34. eCommerce • Initially: Brad Cox’s SuperDistribution • Supported Component approach • Aggregation / Disaggregation • Pay per use to top level vendor • Payments flow down the chain • Flexible payment policies • But • needs a security chip built into every machine!

  35. eCommerce • Large vendors didn’t like it • Superdistribution seen as ‘in the future’ • New group studying existing options • No reports produced yet

  36. Taking IMS Further IMS Specs due Summer or Autumn ‘99 Still in formation period Trial and Implementation sequence: • Test draft specs by implementing in Systems • With tools, can develop IMS compliant Content • When got systems and content, can implement Live Systems with users

  37. Taking IMS Further UK IMS Centre is setting up 4 Groups: • Metadata • Content • Learning Management Systems • Administrative Systems and Student Profile

  38. Taking IMS Further Aims: • Create a group of interoperable systems • Test Specs by implementing • Check if any UK Requirements not met • Make input into Spec development Contact: b.olivier@bangor.ac.uk

  39. Taking IMS Further • IMS Web site: http://www.imsproject.org • Gaining full access to restricted areas, email: l.rowlands@bangor.ac.uk

More Related