4:09am Jun 15, 2010
Draft Technical Specification for Content Types necessary to frame Drupal Learning Taxonomy
High
General Task
1 year 43 weeks ago
In the Drupal Dojo's Training and Curriculum Chat on 10jun14, idcm outlined a potential structure for the definition of competencies Content type notes from the call.
This case/task is to write a technical specification for the content types to be used to collect and manage data related to competencies.
Once defined the content type would be added to drupalkata.com where we would also construct pages for the community to review, add, edit and delete items from a database of Drupal competencies.
#1
Here is the Google spreadsheet where the competencies are being hashed out - anybody can view it by clicking this link -
http://spreadsheets.google.com/ccc?key=0AszsI1TZ0caldG1fOEpWajRJZlRVdFZz...
#2
In our IRC Curriculum Chats we had decided that we wanted a module that would help us to build a doubly linked list of topics/subtopics--doubly links in a chain with multiple levels of topic and sub-topic.
However, there is potential overlap see
and, I gather significant progress has been made regarding vocabulary sets in D7
Perhaps the first question is, are there existing tools for building, maintaining and distributing a 'set list of taxonomy terms'? Does something exist in D6, D7 or from a source that could be made into a useful module?
Does it still make sense to move forward with design and creation of such a module?
Assuming that we move forward, and that what is to be built is a simple prototype, we should still consider both: the prototype and the ultimate tool. Perhaps the following questions will help us to sort that out:
While we can get into future plans for hosting, distributing and maintaining such a set list in the future, it would be helpful to have an idea of where this might be headed.
#3
I'm not exactly sure what this would look like, but I wouldn't be surprised if something like this existed or others were working on this. Possibly this warrants a cross-post of g.d.o. to some of the relevant groups such as...
http://groups.drupal.org/curriculum
http://groups.drupal.org/drupal-education
http://groups.drupal.org/lms-learning-management-system
http://groups.drupal.org/documentation-team
Once we have an idea of the taxonomy, this should be relatively straightforward to build....umm...I think.
#4
Here are my thoughts on defining the competency repository. Another post will explore the competency-to-product mapping process.
Competency Repository
The repository is a space/site dedicated to storing community defined Drupal-related competencies. But what is a competency? How are competencies organized? I have been doing some pondering and tested my thoughts with a google search.
Definitions: According to http://managementhelp.org/staffing/specify/cmptncys/cmptncys.htm, "Job descriptions typically list the tasks or functions and responsibilities for a role, whereas competencies list the abilities needed to conduct those tasks or functions. Consequently, competencies are often used as a basis for training by converting competencies to learning objectives." By definition "A competence is the ability to perform a specific task, action or function successfully."
General Requirement: These search results provide a way to hone what we already have started in such a way that I think many will be able to relate. So for our repository, I propose we need a way to capture 'ability statements' that can be mapped to tasks and their associated processes with the site life-cycle.
Examples: We have this started in our spreadsheet. For instance, the ability to 'Create a new content type.' The task might be 'content type development' and this task is probably associated with the 'build/development process'. Another example might be the ability to 'Create a node.' The task could be 'content development' and the process 'content management'. Another example might be the ability to 'Use the hook_form_alter API to change a form.' The task might be module development and the process might me the build/development process (like the example above).
Model?: We might want to look at how D7 organizes default tasks in Drupal to see if that task organization is a good model. It would certainly help sync up this effort with Drupal going forward.
Requirement Specs: Assuming all are in agreement with my assumptions above, I propose the repository have and do the following.
Competency field - long enough for a sentence (255 chars? or more?). Has a child relationship with the task field. Can have more than one task parent. Needs to be only one sentence/statement with an action verb (e.g., create, define, install, configure, etc).
Task field - should be a shorter statement (255 chars or less). Has a parent relationship with the competency field. Can have multiple children. Ability to have more than one process parent is TBD. Has a child relationship with the process field. The task statement should also include an action verb as tasks are actions. Tasks are broad enough to include multiple competencies but fit well into one of the core processes found in the site life-cycle.
Process field - should be a shorter statement (255 chars or less). Has a parent relationship with the task field. Can have more than one task child. Processes are high level and often represent a phase in a site life-cycle or a major effort within a phase.
Phase field (?optional?) - this might be overkill but it would simply represent work performed pre-launch versus post-launch.
Outbound 'feed' - the repository should allow other sites to pull a copy of the competencies, tasks, and processes into their site. The result of the pull should process something (terms, nodes, whatever), that can be mapped to learning experience nodes in their site. The learning experience nodes can be a registration form, a product description page, a video, whatever.
Inbound 'feed' - the repository could also allow sites to register their competency map/feeds (something part of the module they put on their site). From the repository site, people could look up a competency and see who has registered their learning experience product with that competency.
#5
My thoughts on the competency-to-product mapping process.
Competency Mapping Module
This is the module sites install so that their visitors can see which learning experience product meets the competency.
Requirement Specs: Again, assuming all the repository makes sense, the "user" side of this project would need the following.
Competency map field - a field that is pre-populated with the competencies from the repository. The field could be assigned to any content type. D6 version would require CCK. A D7 version would obviously work differently.
Views integration - the competencies, tasks, process, and phases(?) and their relationships(?) would be available to views so users could present their learning experienced grouped by competency in a block or page.
Inbound feed - pre-defined admin option that allows users of the module to sync their copy of the competency repository with the actual repository.
Outbound feed - pre-defined view feed that pushes the learning experience node(?) info, URL, and competency back to the learning experience list in the repository.
#6
For the purposes of content syndication (in particular, a list of competencies), I highly recommend storing these in a taxonomy vocab. I'm registering the concern because I've seen similar requirements result in custom tables and complex joins, which is an avoidable result. Presentation (taxonomy.module, content_taxonomy.module, etc) is not the issue, it's the storage engine.
#7
Per our discussion yesterday, Cindy posted a wiki in the following places -
http://groups.drupal.org/node/81754
http://drupalkata.com/node/866
In order to maximize community awareness/involvement, I suggested we open up discussion in the comments of the g.d.o. wiki.