Plans for Exporting and Licensing?

I made the trip to Philly for EduCon a few weeks ago and saw a demo of the Sally Drupal distribution Funny Monkey has been working on. I'm not sure if that site is ready to be shared with the world without some kind of introduction, so I'll leave it to Bill to share the link and/or code when he and his team are ready. I like the publishing workflow they've created, but I got hung up on the exportability of course material since that's something I need for a project. I've spent several years working with community media groups who produce a lot of Creative Commons licensed content. I love sitting in on community media youth programs where the kids have to be taught the way content is now licensed and that it has only been this way since Mickey Mouse should have become public domain. In their world, everything is fair game for a remix. This gives me hope that the perpetual extension of copyright that's been going on for the last 50 years will eventually be seen as a short period of insanity.

For me, the most exciting aspect of designing new, open systems for authoring content is the potential to remix. Most instructors already remix content from several sources to create their course, but they don't call it remixing. They just call it teaching.

One technical challenge to remixing comes when you include links to other content. In Sally, they are creating everything as relative links. When you export, you'd have to figure out whether the link was supposed to link back to the original site or the link will work once imported into the new site. Another challenge with links are the intended display. With the Media module in D7, we introduced PHP stream wrappers as a way to abstract how a media is displayed from where it is located.

If you add a URL like http://archive.org/details/WorkingWithMediaInD7 to your node, Media looks for a media_[PROVIDER] module that handles that URI pattern. If media_archive is enabled, the URI for the video is converted to archive://WorkingWithMediaInD7. With just that information, the media_archive module knows how to retrieve and render any derivative Archive.org provides for that asset. When inserted into the body of a node, instead of the old HTML for an embed, we use JSON that looks something like...
{"fid":"4","view_mode":"default","type":"media","attributes":{"height":110,"width":160,"alt":"WorkingWithMediaInD7","class":"media-element file-default"}}

When looking at exportability, I think we made a fundamental mistake using "fid":"4". That reference only works on an install where the file id of the media entity is 4. We should have used "uri":"archive://WorkingWithMediaInD7" since both Drupal and the provider are already treating that as a unique id. I'm guessing this was a decision based on performance and the fact that designers could control the display of content users added was so impressive, no one thought this through to export. Including the URI in the JSON would allow nodes exported from one site to be imported into another and display the video as the new site intended... successfully separating the location of content from the display. While we could export the rendered HTML (the embed code or HTML5 video tag), that removes the flexibility we've spent years developing from the site the content is imported into.

Of course I'm guilty of naval gazing here. I assuming that all other sites importing this content would be able to understand Drupal specific JSON. After watching John Fallsopp's In Defense of HTML Presentation, I feel like I'm contributing to breaking the simple standards that made the web so powerful. That said, hyperlinking was designed to link content in environments that expected static, directory style paths to resources. For better or worse, I can't change the fact that today's links often require unique ids specific to that target system/service, authentication, and display instructions.

I have a project that will require an LCAS. This site will certify community media producers on some basic skills and will be integrated with http://drupal.org/project/civicrm_certify. That certification then allows the producer to reserve equipment using http://drupal.org/project/reservations. It's like gamification, but your education earns you rewards IRL :)

I could just build a well configured Drupal site, add the Quiz module, some custom CiviCRM integration, and call it done... but that's not how I roll. I'd like these organizations to be able to share their course material and certification process in a way that allows another organization to easily spin up a new LCAS instance, import the course material, and start customizing and improving the content.

I can put some development time towards this effort, but since export, OERs, and Creative Commons weren't mentioned in the goals of this group I wanted to make sure your vision of a LCAS will support what I want to do with it.

I should also mention that courses/content trees created for community media will rely heavily on Popcorn.js. I've reworked the initial field collection approach we took with http://drupal.org/project/cue_builder into an entity based approach with http://drupal.org/project/media_event. I've been very focused on how import/export will work with Media Events. Because a basic use of Popcorn.js can be subtitles/closed captioning and there are already standards for that, we needed to be able to import and export those standards in a way that relates the events to the media entity on the system doing the import. More sophisticated Popcorn content will require defining the http://drupal.org/project/popcorn_blocks on the site that is importing the content. Since Popcorn events target divs and expecting them to be a specific size and/or location, that would fall to the people in the role of instructional designer or system administrator to create a layout capable of displaying the Popcorn events, but exporting and importing will still be possible.

What are your plans for being able to export all or part of a content tree?

At what level is licensing applied?

Are there good examples of exports that work well we should be looking at?