Programms - Courses - Sections [#2096625]

How are courses and sections connected to each other. I tried to figure that out, but so far I could not see any connection. There is a field group in courses that has an open field for sections - and there is a content type for section.

and how are students enrolled to the whole thing... - I mentioned groups in the earlier post - but we need to see, how that can be handled batch by batch - section by section...

I tried subgroups - but unfortunatly this module is still in DEV - and it did not work for me at all.. - that would have been a good solution - have a batch as a subgroup of a program - a section as a subgroup of a batch....

just some ideas

Comments

Comment #1

btopro CreditAttribution: btopro commented 24 September 2013 at 21:08

http://elms.psu.edu/blog/post/elmsln-state-screencast may have some clues as I talk through it.

Basically, the data structure is this:
Course (node)
-- has offerings (field collection)
---- has sections (field collection)

So if you haven't used field collections, basically all the section info is directly part of the course content type as it's just a complex content type. The way this relates to being distributed across the many systems is like this...

Course causes a drupal site to be built (like courses.address/name) and then an organic group is created in courses.address/name that relates to the IDs provided by the section_id field in the course. This way there's basically a primary key of the "section id" which can be found across other services. This also can be used for syncing access whether that's between CIS and MOOC or MOOC and an external data-source. Internally, I use this to get data from ANGEL our LMS as to the roster.

If an LTI launch is captured it essentially populates that section id field. It allows for multiple just for additional flexibility but I've never used more then 1 (yet).

In the cis_connector cis_section feature, there's an API for how the section ID (a field on the group node in the MOOC / tool distros) can be used to build a roster. The API basically is expecting to get roster as an array of users and roles for that group (where that comes from it doesn't care, code needs to be written for that integration whatever that source is). I've thought of making a roster service / system that's a helper system to CIS to keep that logistical stuff out of the way but that doesn't exist and won't without desire to make happen (I don't need that).

I think what you're talking about is having people register in the CIS so the CIS is the authority for enrollments for a course / section in some way. You can then take that registration data and should (should I don't know for sure, assumption here) be able to get an xml / json feed of all the users that have registered for that section/course via the restws module. I think this would be possible because restWS works with any entity and registration provides a registration/{id} style path. If this works, you could then perform roster syncronization queries against {cissite}.com/registration.json?uuid={the identifier associated with the section} which would then return the entities of all users that have signed up for that course.

Thinking outloud here but that seems like a likely course of action.

Comment #2

ChrisZZ CreditAttribution: ChrisZZ commented 25 September 2013 at 05:34

Yes, I saw, that you have section as part of the field collection and I have used field collections before. But there also is a content type section. And basically, when I think about a section, than I think about a group of students. So I tried to figure out, how you interconnect those things to the student - without the help of external systems. And in my case - as I did not yet activate the LTI - no drupal site is built for a course. So I guess I need to set this up.

Yes - I am thinking about having people register in CIS - or being registered in CIS through other systems - but in the end, the information and relation-architecture needs to be visible in CIS. As I said, I am trying to use CIS as the root system. So I am basically thinking about: Where does the array of users come from - or how can it be build into the CIS - and what is the workflow of bringing this data into the CIS - starting from a paper based registration - that we have here. So I do not have another system above, where I could collect information about student/section/program relationships - this information has to be entered into the CIS/SIS System as the first system in the line.

Then after the automatised processes of registration of students in subsystems becomes relevant...

Now I was thinking about the information architecture - and I at the moment, I am at the following conclusion:

Students Accounts are just accounts like any accounts. So no specific student profile required.

An account becomes a student through a membership in a programme - the membership in the programm will have fields regarding batch and section (we have several sections for almost all programmes) and other student-programm related information.

Once a student enrols for a module he/she becomes member of the module group and the membership holds student-module related information - such as the semester etc...

So basically I think about shifting student related data from the profile to membership in the group - because this is what it is - information that is part of the relation of the person and a program or a modules.

hope that makes sense...

Comment #3

btopro CreditAttribution: btopro commented 25 September 2013 at 14:52

Ahh ok I see where the confusion is. the section content type you are referring to is part of the cis_connector library. That's currently only intended to be applied to the tools used to connect / bridge back to the CIS data-source. So think of it as a network of organic groups that are related back to a field collection item. This keeps the section more deeply related in the CIS to the course / offering itself in case additional data fields need to be added to those parts, while still giving consistency and simplicity out across the tool-network.

A "full" course then logistics / SIS / Course content then can be expressed like this:

A unique value for the point in time this section is happening for Course "drupal" would be:
drupal-201314-Fall-001 - Drupal course, 2013-14 running year, in the Fall, section 1. While this can be anything and we use a different model internally, it just has to be unique to be relational (the section id field in CIS that is).

This then extends out to the rest of the network based on that value. So the field_section_id value of a node (which is an organic group) in each tool will be set to drupal-201314-Fall-001. This allows the tool to ask questions to the CIS/SIS about the section's logistics (syllabus, directions, help info, future considerations, etc).

As for your enrollment question then, I think I was trying to answer it above (or in the other thread we are having this convo on) but might not have been clear.

You could associate a registration to a section (because reg works with entities) so that students would be enrolling (manually or by someone else creating the account / populating) directly to a section. This keeps the registrations in a separate place which is easily relatable. You could then have tools (the course content being the only one we are talking about today) ask the CIS/SIS for a roster. We do this nightly as the LTI stuff you mention is still a "down the road" type of piece of functionality (so please don't think it's a requirement cause it's not, it's just liberating to workflows).

So. nightly, you could have the course-content service ping the CIS service for a list of students that should be enrolled in the course for that section / offering of the course. The registration module is RestWS aware (I believe) so you could query that list via webservices using the structured calls made available in the cis_connector library. This would provide the CIS as SIS relationship you are mentioning.

Eventually, I am thinking along the same lines that we can disconnect ourselves from current authorities and become the authority. You are not miard in the political systems and decades of crufty solutions of yester-year that I am, so you are further ahead then me if you make CIS into an SIS :). Let's help make that happen!