We are working on creating local question banks for several of our courses this summer, for use beginning in the fall. Once the problems go live, I'd like instructors to have an easy way of browsing the problems for their course.
Right now, I know how to create a button in the library browser that gives direct access to our problems. (I created a new folder in /opt/webwork/libraries with our problems, added a symlink in the templates folder of relevant courses, and then added the button in localOverrides.conf.)
This is all right, especially if the directory tree is organized carefully, but ideally, we'd like to be able to browse our local problems using the same Subject --> Chapter --> Section interface that we get using the OPL.
I could try changing the line in localOverrides.conf that makes the OPL the main library, and replace the OPL with our local library, but it would be better if we could do this while retaining access to the OPL as usual.
Libraries with problems in languages other than English cause similar needs. I discussed this issue with Nathan Wallach and John Jones in the context of problem libraries in other languages. My idea was to introduce one more "layer" above "subject" in the OPL taxonomy, which could be called "language". I think they agree that this would be a reasonable way to go. Maybe one could use a more generic name, such as "library", instead of "language". This would allow you to add an additional library of local problems. Would this suit your needs?
If this should be implemented, it would probably be reasonable to remove the string "OPL" from the corresponding tables in the SQL database, as they would no longer be restricted to the OPL.
If this should be implemented, it would probably be reasonable to remove the string "OPL" from the corresponding tables in the SQL database, as they would no longer be restricted to the OPL.
My solution to this was to just create a folder in the OPL directory for all of the problems created here. That way OPL-update indexes them, and they show up in the Library Browser. The downside is that there is no way to distinguish these problems from OPL problems in the Library Browser. It's perfectly safe to add a new folder in /opt/webwork/libraries/webwork-open-problem-library/OpenProblemLibrary and add problems to it, as long as the name of your folder isn't something that will end up appearing in the OPL.
If the goal is to be able to browse locally created problems outside of the OPL using the same taxonomy, then adding another (higher) level to the taxonomy doesn't seem like the right approach. Instead I would suggest using a separate tag to differentiate these problem collections. Sean's request could be met by making the Institution tag searchable (or filterable) in the Library Browser, so instructors could restrict to only problems authored at their institution. Florian's suggestions about languages could be handled by a language tag.
The problem I have with a "library" tag is that you are then forced to sort your problems by only one attribute (language, source university, etc). The place where I see this adding value is if the taxonomy for the custom library differed in structure from the taxonomy of the OPL. In this case if you selected a different library, the drop-down menus for subject, course, topic would be different from those in the OPL (though I don't immediately see a use case for this, since we could simply add more subjects).
Another thing to note is that the indexing of OPL problems for the Library Browser happens globally, meaning there is one database of problem metadata for the whole WeBWorK installation. The implication is that if we wanted to have the Library Browser browse problems that are local to a course by topic, we would have to modify the structure of the OPL database so that it had information about the problems living in each course (either additional data to capture in which course(s) each problem is available, or a separate set of data for each course).
I think filtering by tag would be a good solution here. We've found the existing keyword option in the advanced search is a little awkward to use at times, and instructors are never quite sure how it's going to affect the search results.
Without filtering, I think our local problems would get lost among the many already in the OPL.
The only trouble we'd run into with this (which Danny identified in his last paragraph) is that browsing by course could be a challenge. For calculus, this isn't an issue. But we are, for example, developing for a computer science course that covers various areas of math of relevance to CS, so it would have problems landing in several different subject headings.
Actually, I think what would be good enough is if we could go to a non-OPL library and browse using a directory tree instead of a drop-down list. We are organizing all of our problems in folders with a /course/chapter/section/ scheme and (5 courses)x(5-6 chapters per course)x(4-8 sections per chapter) puts an awful lot of lines into that drop-down.
Without filtering, I think our local problems would get lost among the many already in the OPL.
The only trouble we'd run into with this (which Danny identified in his last paragraph) is that browsing by course could be a challenge. For calculus, this isn't an issue. But we are, for example, developing for a computer science course that covers various areas of math of relevance to CS, so it would have problems landing in several different subject headings.
Actually, I think what would be good enough is if we could go to a non-OPL library and browse using a directory tree instead of a drop-down list. We are organizing all of our problems in folders with a /course/chapter/section/ scheme and (5 courses)x(5-6 chapters per course)x(4-8 sections per chapter) puts an awful lot of lines into that drop-down.
"We are organizing all of our problems in folders with a /course/chapter/section/ scheme and (5 courses)x(5-6 chapters per course)x(4-8 sections per chapter) puts an awful lot of lines into that drop-down."
I can suggest a good small project for improving the Library UI. The drop down menu in LibraryBrowser for browsing a directory structure flattens out the directory structure, resulting in a rather long list. A linear dropdown method was all that was easily available at the time. I would guess that now there are probably several javaScript solutions available which provide hierarchical menus which could be plugged in to replace the current dropdown. The project would be almost all javaScript programming, perhaps with a little perl programming on the back end if it became necessary to cache the directory tree for performance speed.
Great idea. As the number of disciplines and topic areas have increased, this will be very helpful.
I put up a beta version of multi-library support in GitHub pull request 874 which adds a "Library" selector above the Subject selector.
The current version allows for each local library to extend the OPL (or main) Taxonomy, and searches can be done on a specific library or on all libraries using a "merged" Taxonomy.
The focus so far was on the basic search and not the advanced search. No work was done yet on adding the directory browsing to the additional libraries yet. I have some initial idea for a more convenient directory browser, and will see when I can put some time into it.
Most of the meta-data tables are shared by all libraries, and the structure is shared among all libraries, so some selections will get no results.
In the future, I hope to set up a manner in which the Taxonomy categories can be pruned "live" for each library, so only relevant choices will be shown.
I have done testing only with small test libraries using Docker, and the configuration settings and installation process (library locations, symlinks in course template directory, manner of running OPL-update for multiple libraries) need to be better documented.
I would be happy to hear some feedback.
Nathan
This sounds great! Now to carve out some time to install and test it...
First I need to get around to upgrading to ww 2.14!