[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-learningspec] learning maps questions
Hi Amber, Attached some information about LOM and the XSD. Kind regards, Birgit From: Amber Swope <amber@ditastrategies.com> Hi there, Does anyone have a copy of the (IEEE Standard for Learning Object Metadata (IEEE 1482.12.1-2002)? I’d be interested to know if this type of relationship is part of the standard. Thanks, A From: Birgit Strackenbrock [mailto:birgit@xstructuring.eu] Hi Amber and Eliot, Interesting discussion. Maybe I have one more alternative: within LOM you can define relations. At the moment only a small set of the metadata defined in LOM is also defined in DITA lclom. But it should not be difficult to make a specialization for LOM relation in the lclom or to include LOM as a foreign XML (like MathML). Because, it is metadata you can add it to your topic or to your topicref. Birgit From: dita-learningspec@lists.oasis-open.org <dita-learningspec@lists.oasis-open.org> On Behalf Of Amber Swope Thanks for the information about the process and technology required to address the “where used” challenge. It verified my understanding of the complexity. I guess the best advice we can give to folks with this use case is to work with their CMS vendor on the support. Have a great day, A From: dita-learningspec@lists.oasis-open.org [mailto:dita-learningspec@lists.oasis-open.org] On Behalf Of Eliot Kimber I should also mention that a challenge within content management systems is keeping the where-used index up to date as new versions of maps and topics are created. This can be generalized as the “versioned hyperdocument management problem”, something I’ve written and spoken about at length over the last 20 years or so. The D4ST link management application attempts to provide appropriate version-aware link management in the context of DITA content managed through the git version control system. Basically, every time a new commit is made on a branch the link management application recalculates the where-used index. This is a fairly naïve approach that won’t scale very well but is easy to implement. It also depends on the feature of git that allows you to commit multiple files as a single atomic action, as well as the use of branches, which lets users be more selective about when they actually trigger an index update. In a more complete CMS system the index updating would need to be more sophisticated so that it can be done more or less incrementally rather than reconstructing the entire index on every commit. This is all to say: while the data processing is, conceptually, not that hard, there are a number of practical details that make a complete implementation within a non-trivial-scale CMS fairly challenging from an engineering and user interface standpoint. In my experience I’ve found several business domains that really require this full sophistication of link management:
We don’t usually see the same level of sophistication required for more mundane technical documentation (software and non-safety-critical hardware) and non-educational professional publishing (books, magazines, etc.). So it should be no surprise that no current off-the-shelf DITA-aware content management systems really provide the level of link management sophistication required by sophisticated learning content. This is compounded by the fact that the learning business community is both small, relative to tech content or general Publishing, and is also very fractured, with a lot of focus on delivery tools but not much focus on authoring. Even companies that are primarily or entirely focused on learning are still so small that no one of them can really fund the tooling they need, or at least they have a hard time justifying the budget required to build such tooling. If I had independent wealth or even a secondary source of income or any skill at business development I would be eager to try to build such a system but it is not something I could do by myself (the D4ST Link Manager is the closest I’ve been able to come and even that has languished in the face of my need to do billable work). Cheers, E. From: <dita-learningspec@lists.oasis-open.org> on behalf of Eliot Kimber <ekimber@contrext.com> In the abstract the data processing is a special case of the more general “where used” question: for a given element, what links point to it? In DITA this processing requires processing each root map to collect the set of all topicrefs and construct the key spaces for each such map (remembering that in DITA 1.3 a single root map can define any number of distinct key spaces through the key scope feature). That gives you the set of all map-to-topic links and those topic-to-topic relationships established by the navigation topicref hierarchy and relationship tables (if any). Finally, you process each topic to find all the conrefs, xrefs, and explicit links to other topics. You now have all knowledge about the links to all elements within the DITA content set. From that knowledge you can build an index where the lookup key is the storage location and DITA-specific address of the target element and the value is the list of links to that element. The list of links has to include information about the linking element itself, the map context of the link, the topic that contains the link (for links from topics), etc. Basically, anything you can know about the link and its context needs to be captured (or easily determined by inspection of the linking elements themselves). The DITA for Small Teams Link Manager application does exactly this. https://github.com/dita-for-small-teams/dfst-linkmgmt-basex Given this general where-used index it’s then simply a matter of filtering on those links that are to or from objectives, e.g., by using the topic type of the objective topics or the element type of objective-specific xrefs or whatever the distinction mechanism is. That then gives you, for a given element (topic, interaction, etc.), what objectives it is associated with. The data processing challenge is all in the details of DITA addressing: constructing key spaces, resolving conrefs, constructing effective links following conref resolution, etc. But once you’ve implemented this processing in a given processing context (e.g., your CMS or a general-purpose XQuery library or whatever), you never have to do it again (at least not until the standard is updated). All DITA-aware CMS systems that are key aware should *already provide* this level of functionality, at least for DITA 1.2 (that is, one key space per root map). DITA-aware CMS systems that are not key aware, such as SDL’s LiveLink, could not provide this functionality at all without first implementing key awareness. If you are not using a CMS it would still be possible to do the processing I’ve described above in a brute force way—the processing that the D4ST link management application does could be done by e.g., Saxon using most of the same XQuery code, it would just be a lot slower and might require a lot of memory. Basically, using an XQuery database (or any kind of database) is a processing optimization but doesn’t really change the data processing problem or general implementation approach. Of course, different databases will offer different optimization features. For example, using BaseX, which is open source, I had to construct my own indexing approach, but with MarkLogic I would take a different approach to leverage MarkLogic’s proprietary indexing and search features, which would make it possible to manage millions of topics efficiently, whereas the BaseX approach is limited to a few 1000 or 10s of 1000s of topics (although I haven’t really stressed BaseX’s scalability nor had the chance to focus on the performance of my XQuery code). Cheers, Eliot From: Amber Swope <amber@ditastrategies.com> Also, any suggestions how to address the requirement to find all the content topics associated to a specific objective? I realize that there are some repository-specific considerations, but this is a challenge that all my clients want to address. Thanks, A From: Eliot Kimber [mailto:ekimber@contrext.com] Yes, #6: xrefs from learning objects or assessments to the objectives that apply to them. It makes sense to have things point to their objectives, it does not make sense to have objectives point to the things (because the set of things is potentially unbounded but for any thing the set of objectives is both finite and small). Cheers, E. From: Amber Swope <amber@ditastrategies.com> Can you please explain your xref option to me? I thought you were suggesting #6 below… As usual, the issue isn’t that there aren’t options on how to do it in DITA…but rather how to select the best option. Thanks, A From: dita-learningspec@lists.oasis-open.org [mailto:dita-learningspec@lists.oasis-open.org] On Behalf Of Eliot Kimber I assumed that explicit pointing from objectives to the things to which they applied would never be the right answer. Also, I only think of related links as something that is generated based on relationships established in maps, so it would never occur to me that it could be an option. Cheers, E. From: Amber Swope <amber@ditastrategies.com> See ARS note below From: Amber Swope [mailto:amber@ditastrategies.com] Thanks for the prompt response, Eliot. One of my clients needed to support multiple learning objectives per module and to specify to which objective each content unit applied. They used subjectScheme to classify their learning objectives and define the key reference (using <subjectdef>) and then associated the objectives using <topicsubject> for each <topicref> as appropriate. For them the classification in the subjectScheme map was useful and worth the overhead. I agree that this might be a lot of overhead if you don’t need the classified objective list. The goal is to clearly establish an association between a learning objective and its associated content, which could include any content type, but is required for assessment. Important considerations are:
Dawn and I advocate for creating each learning objective as a separate topic and the associating that topic with its related content. As for where the association occurs, I think we need to review the options. Here are the ones I’ve identified:
Benefits: can associate the same content to different learning objectives in different contexts if module supports only one objective, then can define once for entire module Considerations: Associate is context-specific and there is no easy way to find associated content in CCMS Must define key value for each objective in each module Cannot use learning maps (currently) Cannot easily see objective in context of the content (need to see the module map)
Benefits: Can define key values for objectives in one place an associate the same content to different learning objectives in different contexts If relationship changes, no impact on related topics Considerations: Associate is context-specific and there is no easy way to find associated content in CCMS Must define key reference for each objective in each module Cannot use learning maps (currently) Cannot easily see objective in context of the content (need to see the module map) Must maintain objective map
Benefits: Can classify objectives an associate the same content to different learning objectives in different contexts If relationship changes, no impact on related topics Considerations: Associate is context-specific and there is no easy way to find associated content in CCMS Must define key reference for each objective in each module Cannot use learning maps (currently) Cannot easily see objective in context of the content (need to see the module map) Must maintain subjectScheme map
Benefits: an associate the same content to different learning objectives in different contexts Can store relationship table in separate map and reuse in multiple modules Can use learning maps If relationship changes, no impact on related topics Considerations: Association is context-specific and there is no easy way to find associated content in CCMS Cannot easily see objective in context of the content (need to see the module map) Must maintain relationship table
Benefits: Can easily see objective in context of the content Can search in CCMS and find associated content Can use learning maps Considerations: Not easy to support associating the same objective in multiple contexts (all objectives associated in all contexts) Cannot include in non-L&T topics without specialization Must set value to instruct transform to not generate the objective content when topics are rendered If relationship changes, must check topic out and update
Benefits: Can easily see objective association in context of the content Can use learning maps Considerations: Not easy to support associating the same objective in multiple contexts (all objectives associated in all contexts) no easy way to find associated content in CCMS Must set value to instruct transform to not generate the objective content when topics are rendered If relationship changes, must check topic out and update ARS: I guess you have the reference from the objective to the related content (using <related-links>, but that means that you’d have to check out and update the objective file every time you needed to associate it…I don’t think that would be acceptable? None of these options seems ideal; the big challenge is when you have the abstract association (options 1-4), there is no easy way to find all the related items. Have a great day, A From: dita-learningspec@lists.oasis-open.org [mailto:dita-learningspec@lists.oasis-open.org] On Behalf Of Eliot Kimber Looking at the content models of <learningPreAssessmentRef> and < learningPostAssessmentRef> it looks like the original design assumed there would not be a need for substructure, which seems rather short sighted looking at it now. I can assure you that I never gave it a moment’s thought during the original L&T development I was involved in. I assume the purpose of the keydef here is to bind a key to the objective topic so it can then be referenced in order to associate it with the assessment referenced. If so, putting it inside the learningPreAssessmentRef would be rather odd practice—I’d expect that you would have a separate branch in the map that organizes all the objectives independent of any use of them. But it wouldn’t actually matter where the keydef went. Using topicsubject is an interesting idea but I think it’s too tightly bound to subject schemes, which incurs a lot of overhead. But I think it would make sense to have a similar object-specific reference that means “this objective is an objective of the parent topicref’s referenced resource”. Note that simply allowing <topicref> within these two topicref types would then allow both keydef and topicsubject to be used (once the classification domain was integrated into your map types). If the requirement is to be able to associate objective *topics* with other topics in order to establish an “objective of” relationship between the objective topic and the other topic (presumably a learning object or assessment of some kind), then in addition to something analogous to topicsubject, there are only three mechanisms available within the DITA (that I can think of):
I’m not a big fan of subject scheme maps—I think using relationship tables would be more natural and obvious. I think the xref approach is required regardless (basically giving you a replacement for the current in-topic objective lists or maybe simply a way to augment those lists with L&T-defined links to the objectives defined elsewhere). Cheers, E. From: <dita-learningspec@lists.oasis-open.org> on behalf of Amber Swope <amber@ditastrategies.com> I’m working with Dawn on documenting ways to associate learning objectives and was trying to associate learning objectives to references in learning maps. I tried to associate an objective with an assessment topic. However, the <learningPreAssessmentRef> and <learningPostAssessmentRef> elements do not allow <keydef> or <topicsubject>. They only support <learningGroup> and <learningObject>. It turns out that none of the learning reference elements allow <keydef> or <topicsubject>. Does this mean that there is no way to associate objectives at the referenced topic level in a learning map other than using relationship tables? Was this intentional? If not, can we address this? Are there any other elements that we should consider allowing within the specialized learning referencing elements? Thanks and have a great day, A --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
Attachment:
WhatIsIEEELOM.pdf
Description: Adobe PDF document
<?xml version = "1.0" encoding = "UTF-8"?> <xs:schema xmlns="http://www.imsglobal.org/xsd/imsqti_metadata_v2p2" targetNamespace="http://www.imsglobal.org/xsd/imsqti_metadata_v2p2" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="IMS QTI MD 2.2.0" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:annotation> <xs:documentation> XSD Data File Information ========================= Author: Colin Smythe (IMS Global UK) and Mark McKell (IMS Global, USA) Date: 1st September, 2015 Version: 2.2 Status: Final Release Description: This is the Platform Specific Model of the Metadata object in the IMS QTIv2.2 Specification Information Model. It is this representation that is used to produce the XSD binding for the IMS QTI Metadata v2.2. History: This version supercedes the full IMS QTIv2.1 Metadata specification. License: IPR and Distribution Notices This machine readable file is derived from IMS Global specification IMS Question and Test Interoperability (QTI) Version 2.2 found at http://www.imsglobal.org/question and the original IMS Global schema binding or code base http://www.imsglobal.org/question. Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation. IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS procedures with respect to rights in IMS specifications can be found at the IMS Global Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf. Copyright (c) IMS Global Learning Consortium 1999-2015. All Rights Reserved. Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html. Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals. The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns. THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTERS OWN RISK, AND NEITHER THE CONSORTIUM NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION. Source UML File Information =========================== The source file information must be supplied as an XMI file (without diagram layout information). The supported UML authoring tools are: (a) Poseidon - v6 (and later) (b) Papyrus - v0.10.2 (and later) Source XSLT File Information ============================ XSL Generator: Specificationv1p0_GenerationToolv1.xsl XSLT Processor: Saxon-PE-9.5.0.2 Release: 1.0 Date: 31st July, 2014 Autogen Engineer: Colin Smythe (IMS Global, UK) Autogen Date: 2015-12-14 IMS Global Auto-generation Binding Tool-kit (I-BAT) =================================================== This file was auto-generated using the IMS Global Binding Auto-generation Tool-kit (I-BAT). While every attempt has been made to ensure that this tool auto-generates the files correctly, users should be aware that this is an experimental tool. Permission is given to make use of this tool. IMS Global makes no claim on the materials created by third party users of this tool. Details on how to use this tool are contained in the IMS Global "I-BAT" documentation available at the IMS Global web-site: http://www.imsglobal.org. Tool Copyright: 2012-2015 (c) IMS Global Learning Consortium Inc. All Rights Reserved. </xs:documentation> </xs:annotation> <!-- Generate Global Attributes (non-assigned) ******************************************************** --> <!-- ================================================================================================== --> <!-- Generate Global Attributes *********************************************************************** --> <!-- ================================================================================================== --> <!-- Generate Global List Types *********************************************************************** --> <!-- ================================================================================================== --> <!-- Generate Namespaced extension Group ************************************************************* --> <!-- ================================================================================================== --> <!-- Generate Special DataTypes ********************************************************************** --> <!-- ================================================================================================== --> <!-- Generate the enumerated simpleType declarations ************************************************** --> <!-- ================================================================================================== --> <!-- Generate the simpleType elements based on IMS data-types (Parameter) ***************************** --> <!-- ================================================================================================== --> <!-- Generate the simpleType elements based on IMS data-types (Derived) ******************************* --> <!-- ================================================================================================== --> <!-- Generate the simpleType elements based on IMS data-types (Union) ********************************* --> <!-- ================================================================================================== --> <!-- Generate the simpleType elements based on IMS data-types (Complex) ******************************* --> <!-- ================================================================================================== --> <!-- Generate the derived data-type elements based upon simpleType ************************************ --> <xs:simpleType name="String256.Type"> <xs:restriction base="xs:string"> <xs:maxLength value="256" /> <xs:whiteSpace value="preserve" /> </xs:restriction> </xs:simpleType> <!-- ================================================================================================== --> <!-- Generate the derived data-type elements based upon derived simpleType **************************** --> <!-- ================================================================================================== --> <!-- Generate the ComplexTypes ************************************************************************ --> <xs:complexType name="QTIMetadata.Type" abstract="false" mixed="false"> <xs:annotation> <xs:documentation source="documentation"> This contains the new category of metadata for the recording of QTI specific information. It is designed to be treated as an additional top-level category to augment the IEEE LOM. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="itemTemplate" type="xs:boolean" minOccurs="0" maxOccurs="1" /> <xs:element name="timeDependent" type="xs:boolean" minOccurs="0" maxOccurs="1" /> <xs:element name="composite" type="xs:boolean" minOccurs="0" maxOccurs="1" /> <xs:element name="interactionType" minOccurs="0" maxOccurs="unbounded"> <xs:simpleType> <xs:annotation> <xs:documentation source="documentation"> The set of enumerations for the type of interaction in the QTI Metadata. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="associateInteraction" /> <xs:enumeration value="choiceInteraction" /> <xs:enumeration value="customInteraction" /> <xs:enumeration value="drawingInteraction" /> <xs:enumeration value="endAttemptInteraction" /> <xs:enumeration value="extendedTextInteraction" /> <xs:enumeration value="gapMatchInteraction" /> <xs:enumeration value="graphicAssociateInteraction" /> <xs:enumeration value="graphicGapMatchInteraction" /> <xs:enumeration value="graphicOrderInteraction" /> <xs:enumeration value="hotspotInteraction" /> <xs:enumeration value="hottextInteraction" /> <xs:enumeration value="inlineChoiceInteraction" /> <xs:enumeration value="matchInteraction" /> <xs:enumeration value="mediaInteraction" /> <xs:enumeration value="orderInteraction" /> <xs:enumeration value="positionObjectInteraction" /> <xs:enumeration value="selectPointInteraction" /> <xs:enumeration value="sliderInteraction" /> <xs:enumeration value="textEntryInteraction" /> <xs:enumeration value="uploadInteraction" /> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="feedbackType" minOccurs="0" maxOccurs="1"> <xs:simpleType> <xs:annotation> <xs:documentation source="documentation"> The set of enumerations for the type of feedback in QTI Metadata. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="adaptive" /> <xs:enumeration value="nonadaptive" /> <xs:enumeration value="none" /> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="solutionAvailable" type="xs:boolean" minOccurs="0" maxOccurs="1" /> <xs:element name="scoringMode" minOccurs="0" maxOccurs="unbounded"> <xs:simpleType> <xs:annotation> <xs:documentation source="documentation"> The set of enumerations for the scoring mode in the QTI Metadata. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="human" /> <xs:enumeration value="externalmachine" /> <xs:enumeration value="responseprocessing" /> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="toolName" type="String256.Type" minOccurs="0" maxOccurs="1" /> <xs:element name="toolVersion" type="String256.Type" minOccurs="0" maxOccurs="1" /> <xs:element name="toolVendor" type="String256.Type" minOccurs="0" maxOccurs="1" /> </xs:sequence> </xs:complexType> <!-- ================================================================================================== --> <!-- Generate the derived ComplexTypes **************************************************************** --> <!-- ================================================================================================== --> <!-- Declaration of the elements (Complex) ************************************************************ --> <!-- ================================================================================================== --> <!-- Declaration of the elements (Derived) ************************************************************ --> <!-- ================================================================================================== --> <!-- Declaration of the root element(s) *************************************************************** --> <xs:element name="qtiMetadata" type="QTIMetadata.Type" /> <!-- ================================================================================================== --> </xs:schema>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]