I definitely think we’ve hashed out some of the preliminary details, and are ready to move onto to the more substantial work of actually building this thing.

So, let’s talk next steps — ping me offline or leave a comment here about how you’d like to move forward.

Cheers,

Bill

Can you say you agree with me again? I really like the way that sounds.

More seriously, this is amazing, and I wouldn’t mind mapping some of this stuff more specifically, outside of these comments, so that it can be organized accordingly to long and short-term goals. I imagine Patrick could start testing the middleware (if you are so inclined, which I know you are ). While we test a more barebones version of Bill’s Drupal aggregator with some student and course feeds from UMW Blogs.

WRT the “one blog per student” question, as it stands now, students and professors can create as many blogs (and by exten sion as many feeds) as they would like. Making one URL (or feed) highly unlikely over the course of an undergraduate degree. This might be something we need to examine more specifically.

OpenID could be used here to help move this system forward using the OpenID 2.0 spec with attribute exchange. If the university supplied the OpenIDs (ie, served as the identity provider) then any users attributes could potentially include their userid, etc, etc — ie, all the things that can be carried via the attribute exchange spec.

External OpenID’s, to work within this system, would be treated differently, as there would be no guarantee that they would contain the same data as the university-issued OpenID’s.

In this system, the OpenID identifier would probably resolve to a users blog address — this is how many people currently do it (via OpenID delegation) — in some ways, using OpenID replaces the feed URI with the OpenID uri.

Using OpenID also raises the question of how the uni will support the OpenIDs after a student graduates. But that’s a whole ‘nuther issue.

In this instance, OpenID would solve some issues while raising others. If, however, there was going to be blog-based classes between two or more schools, then OpenID becomes a very attractive option.

Cheers,

Bill

Some quick thoughts on this:

Patrick’s middleware/translator between Banner (ot: Banner? Really? Banner? Why, why, why?) or any other system will be the key to the long term viability of this, as for this to scale to any degree it will be essential to have the kind of feed-student-specific course instance mapping we all discuss. This is a big project, and not something that will be coming together quickly. On a fast development timeline, I reckon that a team with dedicated resources and a clean spec could start working now, produce a working version by June, test over the summer, and deploy in the Fall of 08. And that would be working quickly on this, and developing a tool that had flexibility wrt collecting data and clearly defined formats for sharing data. Clearly documented APIs on this tool would be a must.

WRT the pilot, I agree with Jim (and man, it hurts to say that ): create a list of tags with a specific tag for each section of each course. A separate list will need to be compiled that maps each blog feed to a specific student account. In theory, a student could have more than one feed, but (and correct me if I’m wrong here) in this pilot this probably will not be the case.

Within Drupal, we can create a nested taxonomy that positions each course-specific tag within the proper organizational structure — this would be both a good organizational exercise, but could also simplify any transition to a more robust (ie, automated/scalable, aka, the middleware) system later on.

The downside of this approach is that it involves manual effort to perform tasks that can be automated. The upside to this approach is that, by proceeding with the pilot, we will get a better sense of what is essential for the middleware, and eventually build a cleaner, more targeted app.

Cheers,

Bill

We could just as easily come up with a consistent tag for each section, say engl101_03_s08 and have each student and professor enter this accordingly. It may be a bit of overhead at first, but for the pilot stage it may move the experimentation along quicker. Although, this may not be the case if the more centralized warehousing tool is easy to build and plays with Banner, Drupal, and WPMu nicely. Either way, these are all options we need to flesh out and experiment with to see what, indeed, works the best.

I always have my ax to grind, but I am also up for a detente every so often

The attack of “each class decides on a tag” leaves me worried because it introduces a whole bunch of ambiguity, especially in the case of wanting to aggregate across more than one section of the same class. That makes a situation where, at the section level, there are different sections deciding on different tags, but on the class level they should all be able to refer to the same thing. Whatever might do that work would also need to know how to match up different section-defined tags with the over-arching tag for the class, and that would require a good deal of manual labor.

When the cats away the Drupal rats will play

You all are rocking’ out, it took me a few hours to digest these comments for there is so much here. Let me just say for the moment that the more abstract idea of “One Feed Per Child” idea is really interesting to me. I student comes in not so much with a blog or wiki or anything like that, but some kind of OPML-like feed that they can manipulate and add data to in order to make it do their bidding.

I like this idea a lot. And there is project Brian lamb’s group was working on that in many ways addresses part of this OPMl creation on the fly, I have to find the URL for that test project shortly.

Whenever we talk about getting data from the centralized Banners of the world I always cringe a little bit. That said, what info we really need is a course lis that can then become a drop-down menu from which students can choose on a post by post basis.

Yet, even that would be a pain in the ass, with the new tagging functionality in WPMu I imagine a pilot where each class decides on a tag, allowing Drupal to slice, dice, and display these tags or create and OPML file around them. I opt for the potentially more error prone option right now because the pilot is still not “enterprise” and I would be interested to see how effectively we could incorporate not only WPMu blogs, but also blogger, Drupal (God knows why), Typepad, etc. Additionally, the overhead of banging your head against proprietary administrative systems might hinder experimentation that I really believe we would need to do with this before it becomes a fully scalable solution.

The possibility of OpenID in all of this seems extremely forward thinking. Scott Leslie did a presentation recently about OpenId, and I haven;t looked at it yet, but I know I need to. How can we start thinking about a distributed identity management system that may help take some of the pressure off grabbing and filtering all our information about people from centralized systems?

This is amazing stuff, and I do believe we should create a working group to pursue all of these issues more specifically together. Reason being, unless we set up some specific cases to test, all of these ideas may never have the opportunity to be closely examined. And I imagine we will have a pretty rich testing scenario in UMW Blogs next semester. Any takers?

For a different project, I’ve worked a bit on a slice of this–associating a student with course info, as well as info about the course. The project is RDF-based so that’s where my brain is in this sketch, but hopefully some of the ideas and approaches will be general enough to keep the discussion moving in any direction.

Each person has a URI, essentially a UID they choose attached to a namespace for people registered.

Roles, at least in the most general sense are tricky, at least in the most general cases (thankfully, I haven’t yet needed to deal with them). Think of a TA in grad school. In some courses, the role is student. In others, it’s instructor (or grader, or recitation instructor, or slave labo– you get the idea). So as in Bill’s #3, role would have to be a function of the course, not the individual.

Also on #3, course info gets sticky when we deal with more than one semester, and when we deal with more than one section. I handled that by making two distinct types — one for ‘course’ in administrative usage, which I called a “Course”; and one for ‘course’ as in an actual classroom, which I called a “CourseManifestation” (as in an individual real-life manifestation of the abstract, administrative Course. (In RDF terms, the CourseManifestation is a subtype of a foaf:Group).

So a Course can have properties like ‘owner department’, ‘instructional level’, ‘requirements filled’, etc. A CourseManifestation, then, first has the property ‘manifestationOf (a Course)’. Then it has ’semester’, ‘instructor’, ‘location’, and of course ‘foaf:member’s. (Again in RDF terms, the various roles might be subproperties of foaf:member, dunno about that).

It sounds more complicated than is needed up until we get to #4, assigning tags. Tags would have to be to CourseManifestations, not Courses. The separation then also provides a mechanism for aggregating across different sections, instructors, or semesters if ya want.

For the course id’s and related (machine?) tags, the university gives one for administration purposes like registering, but what student (or teacher, for that matter), will remember that? This, I think, will be tricky to sort through if it’s going to be precise enought to work right and be simple enough to be usable.

For the core issue of connecting users to their various blogs (and feeds), it seems like some human-based mechanism for collecting the list of students and their blog URLs (as most teachers now do), would gather the basic data — someone has to manually enter it at this step — then the technology can take over to find the feed URL(s) for the blog.

Just ‘cuz I’m loving diagrams this week, here’s a sketch of parts of what I’m thinking, based on that project I mentioned and on what we’re talking about. Pretend that ‘patrickgmj’ is a student and ‘jimgroom’ is a teacher.

Patrick, it heartened me to no end to see you blogging from a suitable platform.

Cheers,

Bill

As I see it, there are two contexts where identity needs to be addressed: a person’s identity within the university (and this connects with the various mechanisms in place to record/track/assess their progress within the universtity) and a person’s identity outside the university (a blog, an Amazon wishlist, a Facebook account, a blog, etc). These identities come together when content from external sources (ie, the external identity) need to be connected to the user’s internal identity.

So, at the most basic, we need to connect a feed URI to a school-issued userid (or UID).

1. UID –> Feed URI — one UID can be connected to many URI’s

2. Ideally, we could also have info about users: UID –> role (student, teacher, ta, etc) — one uid can be associated with one or more roles.

3. Then, we’d also need info on users and courses: UID –> CrseID — one UID to many courses, with perhaps an optional column to hold data on a user’s role in the course.

4. We’d also need a means of assigning tags to courses: CrseID –> CrseTag

People blogging externally would have a feed registered in the system so all posts coming into the system from their feed would automatically be associated with their URI.

These feeds would contain the course info, in the form of the course tag. In a more tightly managed system (ie, the school issues the blogs) the course data (ie the tag) could be handled via a drop down select list that get’s dynamically populated. In a more open system (ie, one that supported more platforms) this data could be entered manually by the student. More clunky, yes, but it also allows for a lower barrier to entry, and it also creates the potential for anyone, anywhere to participate using the tools they are already using.

RE the rdf mixer and multiple methods of identifying users, and Patrick’s diagram: absolutely, and the key is getting these various forms of identification linked to a person’s UID. So, whether it’s OpenID with attribute exchange, FOAF data, etc, we could look to two final tables:

5. UID –> identifier, identifier type, identifier source; and identifier –> attribute, note

At the core, though, is the basic relation between UID and Feed URI. This is the lightest connection *necessary* for this to work, exposes the least amount of student data to the outside world, and has the fewest barriers to entry.

Cheers,

Bill