[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-learningspec] learning maps questions
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]