CC0 Is Lazy and Dangerous.

Much talk, recently, has occured surrounding licensing museum data using a Creative Commons Zero license (CC0).  Said license is characterized almost as an anti-license, This license type is popular for its apparent lack of restriction and “simplicity”.  The Creative Commons folks describe it as:

Using CC0, you can waive all copyrights and related or neighboring rights that you have over your work, such as your moral rights (to the extent waivable), your publicity or privacy rights, rights you have protecting against unfair competition, and database rights and rights protecting the extraction, dissemination and reuse of data.

Keep in mind that you cannot waive rights to a work that you do not own unless you have permission from the owner. To avoid infringing third party rights, you should consult with your legal advisor if you are unsure whether you have all the rights you need to distribute the work.

Please note that this is not a registration process and Creative Commons does not store or save any of the information you enter. This tool guides you through the process of generating HTML with embedded metadata for marking your work as being available under CC0. Your work will not be associated with CC0 or made available under CC0 until you publish it marked as being so.

This is fine and good in many instances, particularly when posting code snippets online.. if you really are posting it to share it with others, what better way to enable easy and hassle-free use?

I Care About Museum Data

CC0 is deceptive.  On the surface, it appears to be maximally permissive: anyone can use it for anything at any time for any reason.  Sounds awesome!  I like Freedom!  Let Freedom Ring! We’re museums, organizations that are notorious for not having resources necessary to serve every audience overstepping copyright boundaries and being big jerks to everyone, particularly an audience of folks who are clamoring for museum data sets and permissively licensed images.

(It should be noted that the estimated number of people clamoring for Museum data has been estimated just north of 12 people this year, an all-time high!)

So, wait, why is CC0 bad?  Oh yeah.  CC0 is maximally permissive from the perspective of the end-user.  For folks that want to use data, this is the best choice, because no one can restrict it, and they are under no obligation to do anything beyond providing the data.  The problem comes with respect to the perspective of the data itself.

Share Alike is More Open Than CC0

With Share-Alike licensed data and data-sets, the number of restrictions placed on the data sets are minimally and maximally 1 restriction.  The only restriction is that it cannot be restricted.  With CC0, there is no obligation to keep data unrestricted, so from first modification onwards, there exists a potential restriction.  As one moves across the generations of the data set in the wild, the Share-Alike data set stays at 1 restriction, while the CC0 licensed work succumbs to a wide variety of potential restrictions, rapidly approaching an unmanageable level after only a few short generations.

If museums are truly committing to Open, we need to commit to it in a big way.  We need to commit to Open as the principle and contract by which we share our data, particularly because it best benefits our users over the long-term, but also because it benefits our collection.  Last I checked, benefitting the collection was also a top priority.  It’s our responsibilities to make the best technology choices to support the institution, and I’m loathe to find a scenario where CC0 ends up being a safer, better, more rewarding decision than a simple share-alike license.  A SA clause clearly indicates that the spirit of openness with museum content is expected to be maintained through others uses, regardless if they be commercial, educational, personal or whatever.

There will surely be partners (cough, Google) who will balk at the thought of using Share-Alike licensed data.  Or there are scenarios where by a share-alike prohibits a specific bit of progress you’re keen to see.  When encountering these scenarios, as a rights holder you maintain the right to separately license certain bits of data to certain entities with different rules.  Perhaps the value proposition of something like the Google Art Project is too great to ignore.  There are still ways of selectively making those deals work while still communicating your obvious intent with respect to collection data and digital surrogates.

In Summary

So, does easy, hassle-free use trump other factors with Museum data?  I would argue: absolutely not.  We have a responsibility to our institutions to make the right decisions for them, and that decision is to include and require a share-alike clause in conjunction with providing open data.  It is our obligation to make the correct long term decision for the items comprising our collection.  Considering the undeniable benefits to object care afforded by cataloging and data, making a strong effort to ensure that data is always as great as it could get.  Is it harder to conceptualize?  Maybe.  Does it have a big enforcement footprint?  Not really, you don’t even have to enforce it, as it isn’t a trademark, and therefore requires no enforcement to affect its legal status.

I’m very curious (and frankly, suspicious) of museum professionals that deem Share-Alike licenses to be harmful.. in what scenarios?  Are there even any?

Oh, and use this insteadhttp://opendatacommons.org/licenses/odbl/

Regarding Confluence

Mia Ridge, as she always does, makes a ton of sense out of a few of the major problems museum tech-folks face today in her post Confluence on digital channels; technologists and organisational change?  As I’m putting the finishing touches on my proposals for Museums and the Web 2013, I find there’s quite a bit of overlap between the topics I’m interested in writing about and what Mia has written about here.  I won’t (yet) comment on the larger themes of the essay, however, I do have a different perspective (coming from the IT side of the house), which I feel differs slightly from Mia’s perspective.

Creative is Still a Service Department

In her post, Mia writes:

In museums there’s often a perception that digital teams are a service department (perhaps because of their roots in IT departments) while digital teams see themselves as creative departments, commissioning content and design, producing innovative experiences and consulting within the museum on digital projects.

Pointing out the tension between the creative side of the house and the IT-rooted technical side of the house is fantastic – this tension is often the 800 pound gorilla in the room.  I think the reality of functioning in a modern organization of any variety, particularly museums, is that there are few (if any) departments who truly have final, absolute say in content and delivery, and for good reason.  If there are any departments like that in your organization, they better be curatorial (put down your pitchforks, open authority folks ;)).

Tech folks can generally all agree, though, that content folks and other stakeholders have traditionally been, and are still today, too close to website implementation; the contract between web teams and stakeholders is too low-level.  As it stands, most work orders sound something like this:

Stakeholder: On the About The Museum Page, we need to bulk up the section on our trustees.  Add a new page under the about menu with a grid of headshots and then the names, and after the names put what committee they are on.

Whereas ideally, the contract would be higher up, and focused more on goals, not on tasks, like so:

Stakeholder: One of the trustees was unhappy about the amount of coverage the board gets on the about page. We would like there to be more information about the trustees on the about section, particularly their names, faces, and committees.  What can be done about that, and how can we show this trustee that the page is doing an appropriate job in educating visitors about the board?

Bingo.  This is what we want.  We get to use our formidable expertise in Problem Solving, SEO, Information Architecture, Page Design, etc.  Stakeholder gets an awesome solution, backed by metrics that directly measure the results.  If it underperforms, we can start split testing different versions until we start getting to one that meets all the requirements.

Why They Need it Bold, Red & Blinky

(And Can We Make Them Stop?)

It seems a surprising percentage of web folks actually believe in their heart of hearts that stakeholders come with strong ideas for implementation to spite them.

Mostly, I reckon it’s because page design is fun.  Many people that make requests for creative development don’t get to do very much of it, and the website in almost every institution was a wild west (where this level of buy-in was encouraged!). As such, it’s very difficult to move that boundary back from task-centric to goal-centric, and to basically tell people to not bother you with their ideas.. it’s a difficult situation for technologists because, well, most of us are better at talking to computers than people.

IT departments generally solve it with process: change requests processes, procedural review of requests by an information architect, and all the hoops and trappings of IT-dom.  This technique can be effective, but result in poor customer satisfaction, and it invites stakeholders to be just interested enough to cover the basics, not interested enough in building the best solution.  Who likes dealing with tech-reaucracy?

The same demoralizing effect can be felt through mandate by executive order.  This can also lead to rebellion: marketing trying to out-source micro sites or other small web things, development angling to get their ‘own’ website, etc.  Particularly in small institutions, these types of behaviors can quickly fracture a cohesive web strategy, and it seems to occur all too often utilizing the mandate approach.

The secret, as it turns out, is held by graphic designers (go figure).

In Ken Reynolds‘ inspirational article There’s No Such Thing As A Bad Client for Smashing Magazine, he writes:

A lot of client conflicts arise from a lack of knowledge. Sometimes the client just doesn’t understand what we do as creative professionals, and this accounts for many of their crazy requests. Our job as designers is to help them with their particular goals. They always have a target in sight; they just don’t know how to hit it. Communication is all-important. You have to understand what the client wants, and the client has to know what you need to do to make it happen.

Every client is different, and each has to be handled a different way. You’ll have to be attentive to some; others will require a standoff-ish approach. The important thing is finding a way to draw clear lines of communication, so that both parties know exactly what they’re getting out of the business transaction. Hopefully, the client will educate you as much as you do them.

Wait, what?  Every client is different?  There’s not a magic solution?  The good news is, as a department, we will deal with the same [2,6,10,20,40] stakeholders time and time again.  That makes it at least a little bit easier.  The ideal solution should leverage stakeholder’s enthusiasm, and utilize our privileged position as web experts to educate, explain and collaborate.

We Need Customer Service!

To enable handling a wide-variety of customers, web teams need customer service staff.  In some institutions this staff can be project management staff, or a central coordinator in smaller institutions.  Some customers will want to be present for the web design process, or at least for regular status updates, some will be content with giving you goals and expecting great delivery.

Kevin Hoffman wrote an outline for the basics of this process in A List Apart, in an article entitled Facilitating Great Design:

  1. Provide clear guidance through a series of steps intended to reach an agreed-upon end result.
  2. Always follow this pattern: allow for divergence of opinion, permit participants to explore those opinions within constraints, and then force ideas to converge.
  3. Provide a real-time representation of what’s going on during the meeting where people can see it.
  4. Keep in mind that everyone in the room, no matter what they say, believes that their recommended action equates to doing the right thing.
There’s a lot more that goes into these processes, and a thorough understanding of the intricacies with dealing with difficult customers can take a real time commitment to master.  It’s not something that happens overnight, cultural change is slow and steady, most times.
It’s easy to just say we should get autonomy, stakeholders should deal with it, and the World will be happy.  In reality, that scenario is rarely possible, and in situations where it is possible, it’s often unwise (due to the issues stated above re: bureaucracy and resentment).  It’s the harder road, but we should slowly, purposefully and permanently move the culture towards thinking about web projects in terms of solving problems with measurable results, not with making the trustee names bold, red and blinky.  This is not to say, however, that the process should be opaque, transparency is a good thing.  Involve stakeholders in the process, for it is through this way, with excellent facilitation and customer service, that your teammates at your institution can begin to see exactly what expertise you bring.

A Meta-taxonomy for Museums

For a secret project I’m working on, I need a taxonomy of types of museums (that narrows it done a bit, doesn’t it?)

Because none really seems to exist, I took a stab at one:

History
	General
	Cultural
	Natural History
	Nature Center
	Transportation
		General
		Aviation
		Automobile
		Railway
	Historic House
	Historic Site
	Military
	Maritime
		Military
		General
		
Arts
	Fine Arts
	Decorative Arts
	Modern Arts
	

Science
	General
	Computers
	Aviation (Air / Space)
		Military
		General 
	Planetarium

Specialized
	Medium
		Photography
		Film
	Object-specific (e.g. Victorian Doll Museum)
	Corporate (e.g. Jell-O museum)
	Personal
	Children's

Natural
	Zoo
	Arboretum
	Botanic Garden
	Aquarium


Any comments would be welcome (I expect the taxonomy to sort-of come live as data gets added to said project, but I’d like to have at least a start!

3 Problems with Google’s Art Project

The Culutral Heritage community is aglow with praise for the Art Project, powered by Google.  I even saw a reddit post calling the project, “The most significant advance in Art History”.  It might be top 20, sure, but it’s entirely not proven what tangible benefits will manifest from the project for the institutions providing the content.

While I applaud Google’s attention to the Museum sector, this project, even at its best, does as much to publicize museums as it does to point out shortcomings in the field.

1. There’s nothing new under the Sun.

What is at the heart of Google’s Art Project?  Zoomify and Quicktime VR.  Quicktime VR has been around since, let’s say ca. 1995, and in use for these exact “state of the art” museum virtual tours since shortly thereafter.  Zoomify became available ca. 1999, and again, was shortly thereafter used for zooming in on museum objects.  In fact, in many instances, Quicktime VR is of higher quality than the street view technology used in these basic virtual gallery tours.

Additionally, reproducing a facsimile of the gallery experience using 3d projects has sort of been done to death, whether via quicktime VR, flash or things like Second Life.  Virtual tours do not provide, as has been claimed, a “contextualized experience” when wall labels aren’t provided in legible quality and fluid 3d navigation isn’t possible.  Even when these things are possible, it has not been conclusively proven to provide a decent experience.

2. Data goes in, but does it come out?

The cross-collection building feature is really neat.  While I will address other concerns in my third point, my first concern is that what happens to the data (comments, organization of collection, etc.) and what are the mechanisms for removing it from Google.  Project like the Flickr Commons provide full access for institutions and users to retrieve their data via the Flickr API, will Google offer the same access?

Furthermore, why is it that the only conditions upon which Museum data interacts is when either a vendor controls the data (Hi, E-Museum Network!) or when a big player like Google steps in.  When we analyze the reasons vendors and big players like Google can do it, I bet we’d soon see they aren’t trying to metadata the problem to death, like MLA’s often do (death to the complicated data standard!)

3. Google plays curator

As any small institution can attest, getting into projects such as Flickr Commons or the Google Art Project, are nearly fruitless.  While I was lucky to get on board the Flickr Commons near ground level, many institutions have expressed frustration that it takes time for the big players to get to them.  Looking at Googles initial selection, I see no surprises there, its a veritable who’s who of large institutions, with a vague TBD for adding additional players.

So, is it all bad?

Not at all!  In fact, in many ways, it advances the state of collections online for many institutions, albeit in a way museums can only benefit from once they’ve been baptized by the Google Almighty.  In many ways, the project strikes a different chord than other opportunities such as Flickr Commons.  With the Commons, the Library of Congress and Flickr spent a lot of time and effort ensuring the project was not only a good fit for MLA’s, but also that the benefits of the project could mutually benefit institutions and Flickr, in fact, in many ways Flickr is getting the raw end of the deal!

Museums should take away the notion that Collections online is about MORE than just serving researchers and other MLA pros.  The polish of the zooming interface is apparent, and raises the bar for Museum interfaces on the web.

Now, it’s up to museums to take these lessons and apply them towards a system that puts the institutions in full control.

A development environment using subdomains and rsync

Since the beginning of my tenure at George Eastman House, I’ve longed for the time to implement an honest-to-goodness development environment.   I’d flirted with purchasing a second hosting package to do development work, but if version of software weren’t sync’d, why bother having a development environment anyways?

Enter rsync.

rsync is an open source utility that provides fast incremental file transfer. rsync is freely available under the GNU General Public License and is currently being maintained by Wayne Davison.

I recently re-organized the files on the host, diving them up to keep library files out of the accessible document root, and to better organize files in general.

The overall layout is very similar to java source package layouts.  The home directory for the host contains directories that correspond with domain names, and each sub-domain (including www) is labeled as such inside the domain folder.  There is a mirror of this structure for any website files I wish to not ever directly serve (php libs, config files, etc.).

This yields a directory structure similar to the one depicted below:


/example.org/
/example.org/www/
/example.org/www/index.php
/example.org/dev/
/example.org/dev/index.php
/example.org/static
/example.org/image
...

www is, of course, mapped to www.eastmanhouse.org, and dev mapped to dev.eastmanhouse.org.

When I make a change, I make it to the files in the dev domain, and send a link to the user requesting the change. Upon their confirmation that the change is made to their liking, the result is pushed to production by calling rsync -auv, which is actually triggered by a web facing admin function (to save me from having to ssh in every time I have to make a small change.

So far, its working wonders.

An Adventure in arbitrary PHP in WordPress.

One of the finishing touches I wanted to add to this blog theme was a copyright
statement in roman numerals. Inserting arbitrary PHP into WordPress isn’t as straightforward as it should be, so I’ve outlined instructions below:

1. Edit the functions.php file of your theme to add the following code (courtesy Pradeep S).

// A function to return the Roman Numeral, given an integer
  function numberToRoman($num){
    // use int value
    $n = intval($num);
    $result = '';
    $lookup = array(
      'M' => 1000, 
      'CM' => 900, 
      'D' => 500, 
      'CD' => 400,
      'C' => 100, 
      'XC' => 90, 
      'L' => 50, 
      'XL' => 40,
      'X' => 10, 
      'IX' => 9, 
      'V' => 5, 
      'IV' => 4, 
      'I' => 1
     );
 
    foreach ($lookup as $roman => $value){
      $matches = intval($n / $value);
      $result .= str_repeat($roman, $matches);
      $n = $n % $value;
  }
  return $result;
}

2. Edit the footer.php file in the theme to add a reference to the new function in the copyright block.

    <div id="footer" class="grid_12">
      <p>&copy; <?php echo numberToRoman(date("Y")); ?></p>
    </div>
  <?php wp_footer(); ?>
</body>

3. You’re done!

Culture + Technology