Much has been quiet on the blogging front as the core team for American Social History Online works feverishly to get the new portal ready to show at the upcoming DLF Forum in Philadelphia. The portal is looking good and you can check it out at www.dlfaquifer.org. Be warned that it is still under construction so you may experience some unpredictable results. Try it with Firefox and check out the Zotero integration. Take a look at the integration with the DLF Collections registry by clicking on the collection descriptions link and view the headings for each collection as a tag cloud by selecting "view headings". Our early evaluators asked for more visual approaches to searching and browsing, thus the SIMILEtimeline integration.
Kudos to the core team, Chick Markley, Kat Hagedorn, Susan Harum and Tom Habing for getting this done and to all the members of the Aquifer working groups who have spent countless hours organizing information for the team to use, testing and giving feedback and cheering the core team on through the development process.
Monday, October 29, 2007
Friday, October 5, 2007
New postings on the wiki
Everyone,
I've gone ahead and posted the updated project plan, as well as the initial draft of the architectural spec on the wiki. The project plan needs just a smidge of work, however the spec will need some additional updates, etc.
Alison
I've gone ahead and posted the updated project plan, as well as the initial draft of the architectural spec on the wiki. The project plan needs just a smidge of work, however the spec will need some additional updates, etc.
Alison
Thursday, October 4, 2007
Cyberscholarship, structures for collaboration and sustainability
Reading the recently released NSF/JISC report, The future of scholarly communication just before talking with Emory colleagues Katherine Skinner and Martin Halbert about their new nonprofit, Educopia has rekindled my obsessive thinking about collaboration. Coincidentally, I started a doctoral program in human systems and organizational development at Fielding Graduate University. My first research question for the introductory doctoral competencies course takes an evolutionary psychology perspective and asks, “What hardwired human behavior influences the capacity people have for collaboration in the workplace?”
There are other factors than hardwired human behavior at play in what makes collaboration succeed or fail, of course. The NSF/JISC report mentions competition between universities for students, faculty, outside funding and exposure as an obstacle and suggests a federal level coordinating committee to foster collaboration and make the international links needed for large scale innovation. Skinner and Halbert have approached the problem from a different angle, forming a lightweight not for profit, separate from Emory University where they both work, to "hold the bag" for collaborative ventures. They don't foresee Educopia ever becoming a very large organization, rather expecting the initiatives it fosters (either spawns or hosts) to rest on their own bottoms. Educopia was purposely set up as a not for profit that is not a membership organization with the notion of keeping it as free as possible from members' agendas.
Membership notwithstanding, the Digital Library Federation, where the Aquifer project is now based spawns numerous collaborative activities, many of which have reached beyond the DLF membership. These activities rise and fall, wax and wane as issues are resolved and others come in to take their places. Some initiatives take hold and seem worth sustaining. However, the organizations that catalyze collaboration and innovation are not always prepared to transform into organizations that maintain and sustain. Because we are in a time of tremendous change in the business of scholarly communication, we have many projects and experiments that may merit test runs as production tools or sets of services.
A number of organizations and initiatives are experimenting with organizational and economic models for sustaining innovative systems and services. As we continue to develop DLF Aquifer, we are also looking at the best models for sustaining it if the services it offers to scholars are as useful as we anticipate they will be. Would an existing service provider be interested in incorporating Aquifer into its other offerings? Might Aquifer become a self-sustaining entity within Educopia or one of the participant libraries?
The NSF/JISC report mentions the continued importance of the private sector in stimulating innovation but cautions against putting all faith in entities that are motivated by profit first and foremost. It seems early days to settle on a one-size fits all path from innovation to production level support for cyberscholarship. Fostering a diverse ecology to support innovation and new service development will require collaboration, which can be fostered despite inherently competitive relationships between organizations. I was quite taken a few years ago by a little book called Collaborative entrepreneurship that models a method for competitors to collaborate to innovate. While the book was written for business, with innovation for wealth generation as the goal, the concepts could apply equally to the business of scholarship.
There are other factors than hardwired human behavior at play in what makes collaboration succeed or fail, of course. The NSF/JISC report mentions competition between universities for students, faculty, outside funding and exposure as an obstacle and suggests a federal level coordinating committee to foster collaboration and make the international links needed for large scale innovation. Skinner and Halbert have approached the problem from a different angle, forming a lightweight not for profit, separate from Emory University where they both work, to "hold the bag" for collaborative ventures. They don't foresee Educopia ever becoming a very large organization, rather expecting the initiatives it fosters (either spawns or hosts) to rest on their own bottoms. Educopia was purposely set up as a not for profit that is not a membership organization with the notion of keeping it as free as possible from members' agendas.
Membership notwithstanding, the Digital Library Federation, where the Aquifer project is now based spawns numerous collaborative activities, many of which have reached beyond the DLF membership. These activities rise and fall, wax and wane as issues are resolved and others come in to take their places. Some initiatives take hold and seem worth sustaining. However, the organizations that catalyze collaboration and innovation are not always prepared to transform into organizations that maintain and sustain. Because we are in a time of tremendous change in the business of scholarly communication, we have many projects and experiments that may merit test runs as production tools or sets of services.
A number of organizations and initiatives are experimenting with organizational and economic models for sustaining innovative systems and services. As we continue to develop DLF Aquifer, we are also looking at the best models for sustaining it if the services it offers to scholars are as useful as we anticipate they will be. Would an existing service provider be interested in incorporating Aquifer into its other offerings? Might Aquifer become a self-sustaining entity within Educopia or one of the participant libraries?
The NSF/JISC report mentions the continued importance of the private sector in stimulating innovation but cautions against putting all faith in entities that are motivated by profit first and foremost. It seems early days to settle on a one-size fits all path from innovation to production level support for cyberscholarship. Fostering a diverse ecology to support innovation and new service development will require collaboration, which can be fostered despite inherently competitive relationships between organizations. I was quite taken a few years ago by a little book called Collaborative entrepreneurship that models a method for competitors to collaborate to innovate. While the book was written for business, with innovation for wealth generation as the goal, the concepts could apply equally to the business of scholarship.
Tuesday, October 2, 2007
Getting libxml-ruby working under Windows
Unfortunately the 'gem install libxml-ruby' doesn't seem to work under Windows because of missing dependencies. However, the following web site has a pre-compiled Windows binary:
http://cfis.savagexi.com/articles/2007/02/09/ruby-libxml-and-windows
http://cfis.savagexi.com/files/libxml_so.so
Following is the process I went through to get it working.
Save the libxml_so.so file (which is essentially a windows DLL) into the ruby\lib\ruby\site_ruby\1.8\i386-msvcrt\xml directory. This installs the low-level libxml library wrapper which can be accessed by
require 'xml/libxml_so'
This library defines all of the basic objects and methods needed for libxml.
However, there is also the libxml.rb file. This file can be installed to ruby\lib\ruby\1.8\xml directory. This file itself requires the 'xml/libxml_so', and it can in turn be accessed by
require 'xml/libxml'
The libxml.rb adds some aliases and convenience methods such as enumerators and array accessors [] to the API already defined by the 'xml/libxml_so' library. This is why the classes imported from the 'xml/libxml_so' behave slightly differently from the classes imported from the 'xml/libxml'. This was a bit of a stumbling point until I realized what was happening. Most libraries expect the 'xml/libxml' and not the 'xml/libxml_so'.
You can get the libxml.rb file by downloading the tarball from http://rubyforge.org/frs/download.php/15237/libxml-ruby-0.3.8.4.tar.gz. Or, if you have attempted the
> gem install libxml-ruby --version 0.3.8.4
Even if it fails, the libxml.rb file is in the ruby\lib\ruby\gems\1.8\gems\libxml-ruby-0.3.8.4\ext\xml directory.
The libxml.rb file should then be copied into the ruby\lib\ruby\1.8\xml directory.
Hopefully this will help anyone trying to get libxml working under Windows.
http://cfis.savagexi.com/articles/2007/02/09/ruby-libxml-and-windows
http://cfis.savagexi.com/files/libxml_so.so
Following is the process I went through to get it working.
Save the libxml_so.so file (which is essentially a windows DLL) into the ruby\lib\ruby\site_ruby\1.8\i386-msvcrt\xml directory. This installs the low-level libxml library wrapper which can be accessed by
require 'xml/libxml_so'
This library defines all of the basic objects and methods needed for libxml.
However, there is also the libxml.rb file. This file can be installed to ruby\lib\ruby\1.8\xml directory. This file itself requires the 'xml/libxml_so', and it can in turn be accessed by
require 'xml/libxml'
The libxml.rb adds some aliases and convenience methods such as enumerators and array accessors [] to the API already defined by the 'xml/libxml_so' library. This is why the classes imported from the 'xml/libxml_so' behave slightly differently from the classes imported from the 'xml/libxml'. This was a bit of a stumbling point until I realized what was happening. Most libraries expect the 'xml/libxml' and not the 'xml/libxml_so'.
You can get the libxml.rb file by downloading the tarball from http://rubyforge.org/frs/download.php/15237/libxml-ruby-0.3.8.4.tar.gz. Or, if you have attempted the
> gem install libxml-ruby --version 0.3.8.4
Even if it fails, the libxml.rb file is in the ruby\lib\ruby\gems\1.8\gems\libxml-ruby-0.3.8.4\ext\xml directory.
The libxml.rb file should then be copied into the ruby\lib\ruby\1.8\xml directory.
Hopefully this will help anyone trying to get libxml working under Windows.
Subscribe to:
Posts (Atom)
