This is a special guest post by John Bishop of John Bishop Images.
Prior to Adobe’s Creative Suite 4, adding Creative Commons license metadata via the FileInfo… dialog (found in Photoshop, Illustrator, InDesign and more) meant coding a relatively simple text based XML panel definition and has been available from the Creative Commons Wiki since 2007.
Starting with Creative Suite 4 Adobe migrated the XMP FileInfo panel to a Flash based application, meaning that adding Creative Commons metadata became much more complex, requiring Adobe’s XMP SDK and the ability to develop applications in Flash, C++ or Java.
After significant development and testing john bishop images is pleased to announce the availability of a custom Creative Commons XMP FileInfo Panel for Creative Suite 4 and Creative Suite 5 – free of charge.
This comprehensive package offers the ability to specify Creative Commons license metadata directly in first class, industry standard tools and places Creative Commons licensing metadata on the same footing as the standardized, commercial metadata sets like Dublin Core (DC), IPTC and usePLUS and tightly integrates all the metadata fields required for a Creative Commons license in one panel.
Also included is a metadata panel definition that exposes the Creative Commons license metadata in the mini metadata panels found in Bridge, Premiere Pro, etc. And finally a set of templates that can be customized for the various license types and more is also included; these templates can be accessed from Acrobat.
For more information and to download the Creative Commons XMP FileInfo panel visit john bishop images’ Creative Commons page.
Note: The panels are localized and a English-US language file is supplied. To contribute localization files in other languages please contact john bishop images.1 Comment »
So maybe you’re already familiar with the problem. You’re collaborating with other people, and especially if you’re in a free software environment (but maybe even some install at your work) you have some bugtracker, and that’s where everyone collaborates. But on the other hand, you have a life, your own todo systems, your own notes, etc. Even for the tasks that are on the bugtracker, you might keep your own local copy of that task and notes on that task. Eventually things start to get out of sync. Chaos!
Wouldn’t it be great if you could sync both worlds? Keep the notes that are relevant to being public on the public bugtracker, but keep private notes that would just clutter up the ticket/issue/bugreport private. Mesh the public task system with your private task system. Well, why not?
There are a lot of things I like about org-mode. It’s in emacs (though there’s apparently a lean vim port in the works), it’s plaintext (which means I can sync across all my machines with git… which I do!), tasks are nested trees / outlines (I really tend to break down tasks in very granular fashions as I go so I don’t get lost), notes are integrated directly with tasks (I take a lot of notes), and it’s as simple as you need it or as complex as you want to get (I started out very simple, now my usage of org-mode is fairly intricate). It also does a good job of spanning across multiple files while still retraining the ability to pull everything together with its agenda, which is useful since I like to keep things semi-organized.
And of course, the relevant file here is all my Creative Commons stuff, which I keep in a file called ccommons.org. There’s a lot of private data in here, but I’ve uploaded a minimalist version of my ccommons.org file.
So! Syncing things. If you open the file in an emacs version with org-mode installed, you’ll notice 4 sections. Two of these are crucial to my setup, but we won’t be using them today: “Events” holds say, meeting at X time, traveling on certain days; “Various Tasks” contains not roundup-related tasks. Then there’s the other two: “Roundup” will collect all the tasks we need to work on, and “Supporting funcs” has a couple of org-babel blocks in Python and emacs-lisp.
Anyway, enough talk, let’s give it a spin. You’ll need a recent version org-mode and a copy of emacs. Make sure that newer org-mode is on your load-path and then evaluate:
(require 'org) (require 'org-install) (require 'ob-python) (setq org-confirm-babel-evaluate nil) (setq org-src-fontify-natively t) (setq org-src-tab-acts-natively t)
Next open up the relevant org-mode file. Move to the “Roundup” line, hit Tab to cycle its visibility, and move to the line that starts with “#+call:”
Now press “Ctrl+c Ctrl+c”. You’ll see it populate with issues from my issues list:
What’s happening here? So we’re executing an org-babel block at point. Org-babel is an org-mode extension that allows you to make blocks of code executable, and even chain from one language to another (it also has some stuff relevant to Donald Knuth’s “literate programming” which is cool but I’m not using here). If we look at the code blocks:
Anyway, there are three code blocks here.
- ccommons-roundup-parse: uses python to read the CSV file generated by roundup which is relevant to my task list, converts it into a list of two-item lists (task id, task title)
- ccommons-roundup-insert-func: the function that actually inserts items into our “* Roundup” heading. It checks the ROUNDUPID property to see if that task is already inserted or not. If not, it inserts the task with the appropriate title and ROUNDUPID.
- ccommons-roundup-insert the actual block we end up invoking. It binds together the data from ccommons-roundup-parse with a function call to the function defined in ccommons-roundup-insert-func.
You can evaluate it multiple times. It’ll only insert new tasks that aren’t on your list currently. Now you can take notes on your tasks, schedule them for various dates, make subtasks, etc. When you’re ready to close out a task close it out both on the ticket and in org-mode. If you want to use a similar setup for org-mode, I think it’s easy enough to borrow these methods and just change the CSV URL to whatever URL is appropriate for your user’s tasks.
Now admittedly this still isn’t even the best setup. It would be good if it told you when some tasks are marked as closed in your org-mode and open in roundup and vice versa. Org-babel still feels a bit hacky… I probably wouldn’t use it on anything other than scripts-I-want-to-embed-in-my-orgmode-files (for now at least). I even had to strip out quotes from the titles because org-babel python doesn’t escape quotations from strings correctly currently (but that’s a bug, one that will hopefully be fixed). Even so, I’ve been trying to close out a lot of roundup tasks lately, and it’s really helped me to bridge both worlds.
Edit: And in case you’re wondering why I didn’t use url.el instead of piping to python, the reason is because of CSV support… there’s none builtin to emacs as far as I know, and splitting on commas doesn’t handle all of the escaping intricacies… and org-babel makes it pretty easy to be lazy and simply use python for what python already handles well.5 Comments »
When we rolled out Hudson for CC code last month, I already knew that I wanted to have test coverage reporting. There’s simply no reason not to: it provides a way to understand how complete your tests are, and when combined with branch testing, gives you an easy way to figure out what tests need to be written (or where to target your test writing efforts).
When I first tried to add coverage support to our Python code, I encountered an issue between coverage and Jinja2. Ned quickly committed a fix, and today I finished instrumenting our core Python projects for coverage reporting. This includes the license engine (cc.engine), the API (cc.api), the underlying license library (cc.license), and the structured data scraper used by the deeds (deedscraper).
A pleasant surprise after instrumenting is the current state of coverage. With the exception of cc.engine, we’re at greater than 90% coverage for our core code (it appears that there are lots of branches/conditionals we don’t test adequately in cc.engine right now). Looking forward to seeing 100′s across the board.Comments Off
Finding CC licensed images and using them properly is something many people seem to struggle with: finding them can be straight-forward, but many sites don’t provide copy and paste reuse code that complies with the license. Xpert, a project of University of Nottingham, has launched an image search tool that helps with this. Xpert Attribution tool searches Wikimedia Commons and Flickr and provides an easy way to get the image with the attribution information overlaid, or (even better, in my opinion) with RDFa suitable for embedding. I’ve combined the two below (downloading the image with attribution, and adding the structured-data enriched embed code below it).
The inclusion of structured data with the HTML means you can click the license link above and the license deed will display the attribution information, as well as our generated attribution HTML.2 Comments »
We’ve been working over the past year on improving our tooling and processes for the CC website software, and we’re starting to see the results. We’ve moved our translations to Transifex, where updates are committed directly to our git repository. We’ve rolled out a new version of the license engine with different (better!) caching. And our API now uses the same license definition as the license chooser and the partner interface. While this has been great in terms of agility and deployment speed, it also means that if a single piece breaks, other things are more likely to depend on that piece.
Earlier this week I spent a little time installing Hudson on our development server. By looking at the dashboard, you can easily see the build status of CC projects, including the aforementioned license components, and DiscoverEd, our linked data search prototype.
Hudson is already proving itself worth the time to deploy and configure. After installation, I saw that a test for the API was failing. I pinged John, and was happy to see the build go green a few minutes later when he checked in a fix and Hudson rebuilt the package. Graphs like the testing trend for discovered also help quantify the progress being made. Overall, it already feels like we have better visibility into the state of our infrastructure.2 Comments »
Who I am
I’m Nils Dagsson Moskopp, a 22 year old student of philosophy and computer science, living in Berlin (German speakers may check out my blog). I dislike the act of programming, but love the results, so I seem to have no other choice than to do it from time to time.
Recently, after submitting a proposal, I got accepted into the Google Summer of Code program, being mentored by Nathan Kinkade. In the rest of this entry, I will do my best to explain how it came to that and what kind of software I intend to create.
As far as I know, there currently is no automated, easy way to have human- and machine-readable markup for specific subsections of a blog post in the blogging software WordPress; it is only possible to have an entire page licensed under one specific license. Further complicating the issue is the fact that the WordPress media manager actually does not know about licenses accociated with specific content. This poses a problem for the not-so-uncommon use case of embedding CC-licensed media, mainly photos.
I was first confronted with the idea of having an automated way to markup media with Creative Commons licensing information when reading Matthias Mehldau‘s post More precise Creative Commons HTML-Codes. He envisioned an annotation containing not only the well-known CC license symbols, but also the jurisdiction and a button to show the markup used, for easy re-embedding. Well versed in graphics design, he also created a mockup:
Matthias Mehldau’s Mockup
Shortly after that, Julia Seeliger posted a suggestion how a Creative Commons plugin backend for WordPress could look like. She suggested integrating the official license chooser or a drop down list within the WordPress upload form.
We three chatted about these ideas, me even actually implementing some parts (see next section), but nothing qualifying as currently usable came from that. When approximately one year later, I did come upon the CC wiki site describing the developer challenge titled Support for CC licenses in WordPress Media Manager, I chose to apply for that with Google Summer of Code.
As mentioned in the introduction to the last section, a tool that provides easy licensing management for WordPress media content, automating subsequent insertion, currently does not exist. Several existing projects, however, have features related to this goal; code re-use may be possible.
In 2006, George Notaras created the Creative-Commons-Configurator WordPress Plugin. It allows the user to choose a global license for his or her blog, using
the web-based license selection engine from CreativeCommons.org and adds localized machine- and human-readable license information to pages and feeds. Similar plugins, putting global licensing information into footer and sidebars, exist.
For GSoC 2009, Dinishika Nuwangi made a WordPress plugin called wprdfa (not to confuse with wp-rdfa). Unfortunately, the project has an empty README file. Judging from a quick glance at the source code, part of its intended purpose is to add buttons to the TinyMCE editor integrated into WordPress, although on installation I was unable to see this functionality. The related developer challenge still seems to be open, on the page the plugin is described as
Also in 2009, I created two pieces of software, inspired by a post on the WHATWG mailing list. First, a web application generating HTML5 license markup (enriched with Microdata, see next section), second a WordPress plugin capable of generating similar markup using both Microdata and RDFa. And there was much rejoicing.
It is important to note that since then the HTML5 standard has changed and the generated markup is no longer valid.
On a less technical note, the German blog Spreeblick has a unique way of presenting the license information, only showing a small “cc” in the bottom left corner; on hovering, author name and a link to the source are presented (live example). However, while Spreeblick is using WordPress, the folks behind it have no intention of releasing their plugin: As Max Winde told me in April 2009, it is tightly entangled with their image layout functionality and would require complex cleanup.
I plan to implement the presentation part using the new HTML5 elements figure and figcaption. Together, they can be used to denote content
with a caption […] that is self-contained and is typically referenced as a single unit from the main flow of the document. A code example shows how markup using the figure element may looks like:
<!-- content goes here -->
Naturally, as a rather general markup language HTML5 does not contain any elements to give this construct more specific meaning, such as marking up which license applies to said content. However, two markup extensions provide this capability at the attribute level, the complex and established RDFa and the simpler, newer Microdata proposal, part of HTML5. While both standards are sufficiently open, RDFa is endorsed by Creative Commons; for this reason I will not stray into Microdata territory unless I have time to spare at the end of GSoC.
To this point, I have been only accounting for machine readability. Nevertheless, with CSS it is easily possible to beautify the visual presentation in nearly any way imaginable. The following two screenshots, taken with the now-defunct WordPress plugin I created in 2009, exemplify this — both are based on the same markup.
On the author side, I plan to have the plugin look like the Spreeblick one (screenshot), which will mean adding options to the WordPress media uploader:
- an additional drop down list, for choosing one of the six main CC licenses
- an additional text input for the author or rights holder
- an additional text input for specifying the source URI
Media could then be inserted the usual way, with the RDFa annotation automatically generated.10 Comments »
This past year was my last at the University of Toronto, making this summer my last chance to participate in the Google Summer of Code. I searched hard for a project and mentor organization that would suit my interests, and when I noticed that the Creative Commons Drupal module was in need of some developer love, I knew exactly what I wanted to spend my summer doing. With John Doig as my CC mentor, and Kevin Reynen (the module’s maintainer and initial author) as an unofficial Drupal mentor, I’ve been privileged to have spent the past few months updating and extending the module.
A couple years ago, development for Drupal 4.7 was begun, but it was never quite completed. CC Lite came to be the reliable choice for Drupal 6. However, CC Lite’s scope is limited — it allows you to attach a license to content in Drupal, but that’s about it. The main CC module’s vision is broader — to fully integrate CC technology with the Drupal platform — and I hope I’ve helped to realize that just a little.
Some of the module’s features:
- it uses the CC API for license selection and information (so, for example, when new license versions are released, they become available on your Drupal site automatically)
- you can set a site-wide default license/jurisdictoin, and user’s can set their own default license/jurisdiction
- ccREL metadata is supported, output in RDFa (and, optionally, RDF/XML for legacy systems)
- supports CC0, along with the 6 standard licenses and the Public Domain Certification tool
- you can control which licenses and metadata fields are available to users
- basic support for the Views API has been added (including a default /creativecommons view)
- there’s a CC site search option
The module is still listed as a beta release, as some folks have been submitting bug fixes and patches over the past few weeks, though it’s quite usable. Special thanks to Turadg Aleahmad, who’s helped with a lot of the recent bug fixes towards the end of the GSoC term, and committed to being active in future development. If you’re into Drupal development, we could use help with testing, and any translations would be greatly appreciated too.
Right now, the focus is on getting to a stable release, but we’ve got lots of ideas for the future too. Thanks to John and Kevin for their support through the summer, and to Turadg for his recent help. I look forward to seeing the module put to good use!
I’m a musician, writer, software developer, free culture / free software advocate and recent graduate of the University of Toronto — get in touch at http://blaise.ca/Comments Off
Last week Kinkade asked me for a brief overview of how the license engine, web services and other bits of code all fit together to create the joy that is creativecommons.org. “Sure,” I thought; “that’s simple!”
Er, maybe not. Fourty-five minutes, five marker colors and multiple digressions later, I had the following diagram of life as it is today.
Asheesh joined us and we started talking about how we can make this better. The above, while eminently sucky, has grown up during my time at Creative Commons. All those decisions made sense at the time, but in aggregate we’ve got lots of duplicated code, a branch of code named the
gradually-increasing-sanity-branch which doesn’t (I take the blame for that one), and plenty of unnecessary complexity. Half an hour later, we had mapped out The Glorious Future®:
A little simpler, huh? And the “future” diagram shows all the functionality of the present, plus three packages not displayed on the original diagram. Our immediate goal in moving in this direction is the completion of
cc.license (labeled as “cc.licenze” in the diagrams to distinguish it from the existing implementation) which will replace the existing XSLT processing using for issuing licenses and wraps the RDF (which is the canonical representation of the licenses anyway). We’ll also manage to dramatically reduce the number of
svn:externals we use, which is good since we’re moving away from Subversion for some projects. My goal is to get this upgrade done as soon as possible so we can focus on things that are actually interesting instead of our own infrastructure.