[Siged-l] FW: OhioLINK Seeks Student Applications for Google Summer of Code Projects

Candy Schwartz candy.schwartz at simmons.edu
Mon May 1 09:53:15 EDT 2006


Forwarded on behalf of Peter Murray,
 
Candy
 
-----Original Message-----
From: Peter Murray [mailto:peter at OhioLINK.edu] 
Sent: April 30, 2006 8:10 PM
To: siged-l at asis.org
Subject: OhioLINK Seeks Student Applications for Google Summer of
Code Projects


Please forward this message and/or print-and-post as appropriate.



OhioLINK Seeks Student Applications for Google Summer of Code
Projects


Student applications for the Google Summer of Code
<http://code.google.com/soc/>  program are being accepted
starting on May 1st. In preparation for that date, OhioLINK has
finished up its list of ideas and other supporting documentation.
We welcome student applications seeking to further the
development of information technology in academic libraries in
Ohio and around the world. Questions about the program? Take a
look at Google's participant FAQ
<http://code.google.com/soc/studentfaq.html> . Questions about
the suggested projects or about OhioLINK? Contact Peter Murray
<mailto:peter at OhioLINK.edu> . 


OhioLINK-generated Ideas


This is the list of project ideas so far. Please take a look at
the project ideas page on the
<http://drc-dev.ohiolink.edu/wiki/ProjectIdeas> DRC-Dev wiki for
updates. 


JPIP Streaming Disseminator for Fedora


JPIP is Part 9 <http://www.jpeg.org/jpeg2000/j2kpart9.html>  of
the JPEG 2000 <http://www.jpeg.org/jpeg2000/>  specification and
is used to stream image codestream blocks to a client on demand.
For instance, a JPIP client on a desktop may ask for a certain
quality level and resolution of a region of an image. Using the
JPIP protocol, the client makes such requests to a server and the
server responds with only the image codestream blocks needed by
the client. This saves the overhead of transmitting the entire
image file when, say, only a thumbnail version is required. 

Fedora is the "Flexible Extensible Digital Object Repository
Architecture", an open source digital object repository created
by Cornell University and the University of Virginia. A key
aspect of the Fedora software is its use of "disseminators" to
create derivatives on-demand of datastreams stored in the digital
object package. 

For this project, the idea is have a JPIP client (outside the
scope of this project) request an image of a specified
quality/resolution/clip and have the FEDORA/JPIP plug-in retrieve
and copy out only the precincts/packets directly from an archived
master plus metadata needed for the quality specified. In theory,
no image processing on the server would be required. 

Extensions to this disseminator to enforce XACML policies (a
capability built into Fedora now) to determine maximum quality
available for different end-user types are desired. 

You can imagine how useful a plugin like this would be. There
would be no need to retrieve the full master and create
derivatives, nor stockpile limited sets of derivatives outside of
the archive against possible end-user requests. 


JPIP Image Viewer Applet


In tandem with the "JPIP Streaming Disseminator for Fedora"
proposed above is a JPIP browser applet. Most browser-based JPEG
2000 plugins must be licensed from a software vendor and are not
freely distributable. In order to deliver imagery in JPEG 2000
format to standard browsers, one must use a server-side
transformations of the JPEG 2000 codestreams into JPEG chunks
that are delivered to the browser. Based on the user's requests
-- to pan, zoom, select a new region of the image, etc. -- the
browser must make a new request to the server and the server
render a new JPEG image for the browser. This is an inefficient
use of server resources and forces a less-than-desirable
responsiveness in the user interface. 

In addition, these general-purpose viewers do not have features,
such as the display of metadata boxes, important to the
application of JPEG 2000 in the museum, library and archival
communities. What is desired instead is a cross-platform (Java,
flash, etc.) JPIP <http://www.jpeg.org/jpeg2000/j2kpart9.html>
(streaming JPEG 2000) viewer with these characteristics: 

*	web distributable, browser compliant, and broadly
available 

*	ability to see the entire image and parts of an image
with acceptable performance over narrow-band connections 

*	manipulation functionality such as pan, zoom, rotate,
invert, and mirror 

*	ability to put the image in its context with metadata
that is either textual or in other media and can be made visible
or suppressed 

*	dynamic retrieve the contextual information 

*	meets identified image quality requirements 

*	transformative tools (i.e. the ability to save the image
into a file format selected by the user) 


Video Snapshot Tool


OhioLINK's content repository includes approximately 1,900
educational videos on various topics. These videos range in
length from 20 minutes to 80 minutes, and minimal description is
provided for the video content. We would like to add a capability
for users browsing the collection to see "snapshots" of what the
video contains. In its simplest form, the tool would pull out
frames from the video in equally-spaced increments. In a more
advanced form, the tool would scan the video looking for
characteristics of scene changes and pull out the nth frame after
the scene change. These frames would be stored as individual
images -- or possibly as index pointers into the video itself --
in the object containing the video, and subsequently displayed to
users on the full-record view of the video. 


Bulk Video Conversion Using a Computational Grid


The 1,900 educational videos in OhioLINK's content repository are
in Realmedia format. We would like to have a tool that converts
the Realmedia format into a new streaming format. This tool would
also be used to convert incoming MPEG-2 videos into a streaming
video format. Since OhioLINK does not have a computational grid
set up now, the proposal must include assistance in setting up
that grid (so long as the grid setup is not a substantial part of
the proposal -- it is the Summer of Code after all). Note that
some background research
<http://www.linuxjournal.com/node/7126/print>  has been done
using the University of  <http://www.cs.wisc.edu/condor>
Wisconsin Condor cluster software. 


Prototype Motion JPEG2000 to Flash Video Transcoder / Viewer


OhioLINK is very interested in Motion JPEG2000
<http://www.jpeg.org/jpeg2000/j2kpart3.html>  as an archival
format for moving image objects. We would like to explore the
possibility of transcoding Motion JPEG2000 to Flash Video (FLV)
<http://en.wikipedia.org/wiki/FLV>  -- possibly in realtime,
otherwise in batch -- for access by users through a Flash player.


(Note: OhioLINK is a licensee of the Kakadu toolkit for JPEG2000
<http://www.kakadusoftware.com/> . Although we would prefer an
end-to-end open source solution, Kakadu is available for OhioLINK
JPEG2000-related projects.) 


Sakai-related Projects


On behalf of the Sakai community <http://sakaiproject.org/> ,
OhioLINK is interested in mentoring these projects (culled from a
list provided by Charles Severance through his blog posting
<http://www.dr-chuck.com/csev-blog/000150.html> ) that are
related to our own work of large-scale content management and
services. When considering these project ideas, please note
Chuck's preface: 

Here is a list of projects in Sakai that coudl be done by a
talented individual in a fixed period. All of these efforts are
on Sakai's long-term roadmap but none are on the short-term
roadmap. Generally these are not in the "Sakai core" areas - they
add functionality rather than trying to refactor existing mature
technology so they can be done without requiring much
coordination with the rest of Sakai. 

Each of the tasks would be useful even if partially completed.
Each of the tasks would naturally fit in a Sakai contrib area.
Each of the tasks are relatively simple to describe at a high
level but would require any individual to do a lot of research to
figure things out. That individual should not expect to be "spoon
fed" all the decisions and design - and just sit and code. Part
of the challenge is to truly figure out "what to do" and "how to
do it". 

The individual should expect reasonable mentoring to get high
level questions answered but should expect to be looking at a lot
of code in the beginning of the effort. A key aspect of the sumer
of code is that people taking these tasks cannot be a "drag" on
existing resources executing the short-term roadmap. High level
mentoring can come from me and others and tactical mentoring
should come from the Programmer's Cafe group. 

If folks want more detail - let me know <mailto:csev at umich.edu>
- I am perfectly happy to have an hour-long phone call with
anyone who is ready to spend a sumer or more working on any of
these tasks - but until a resource shows up - these will continue
to sit on the back-burner. 

Please contact us <mailto:peter at ohiolink.edu>  before submitting
a project proposal to Google for an item not on this list. 

*	Build a set of HTTPUnitTests for Sakai Functionality (in
OhioLINK's interest, particularly related to
ContentHostingService.java
<http://source.sakaiproject.org/fisheye/viewrep/Sakai/content/tru
nk/content-api/api/src/java/org/sakaiproject/content/api/ContentH
ostingService.java> ) 

*	Integrate JackRabbit's WebDav in Sakai 

*	Add Pluto to Sakai (JSR-168 Support) 

*	Extend the Sakai JSR-168 portlets to implement delegated
security 

*	A Sakai Portal that does HTTP Proxy (i.e. eliminates
iFrames) 

*	Build support for IMS Tool Interoperability Producer into
Sakai 


Open Source License


OhioLINK prefers
<http://drc-dev.ohiolink.edu/wiki/OpenSourceLicense> to use the
Affero General Public License (in advance of changes anticipated
in GNU GPLv3). Please indicate in your application if you would
prefer to use a different open source license. 


Coding Languages, Standards and Tools


Depending on the particular application, Perl or Java is the
language of choice for particular applications. (Languages are
listed on the project ideas
<http://drc-dev.ohiolink.edu/wiki/ProjectIdeas>  page when it is
strongly encouraged that an implementation use one language over
all others.) In general, proposals that use a language already
supported at OhioLINK will be viewed more favorably than those
that do not. 

OhioLINK does not have strict coding standards. We expect proper
internal documentation and comments, including correctly
formatted JavaDocs where appropriate, following typical coding
conventions. 

We use Eclipse, NetBeans, and good ol' vi as development
environments. Your tastes may vary. 


Source Code Repository


OhioLINK runs a Subversion source code repository for our
projects. You may use that for your Summer of Code project, or
you may use another repository. Be sure to read Google's
<http://code.google.com/soc/studentfaq.html#44> answer to the
question of where coding must be done, though, if you choose to
use another repository. 


Proposal Format


Google has provided some suggestions on writing your application:


"24. What should an application look like? Your application
should include the following: your project proposal, why you'd
like to execute on this particular project, and the reason you're
the best individual to do so. Your proposal should also include
details of your academic, industry, and/or open source
development experience, and other details as you see fit. An
explanation of your development methodology is a good idea, as
well. Note that there is a word limit to proposals, so be
prepared to supplement your proposal text with links to an
external site. However, you should still plan to provide an
abstract of your proposal, including a brief list of
deliverables, via the Summer of Code site to ensure that your
work receives sufficient review; terse applications tend to look
like incomplete applications during the review process."
http://code.google.com/soc/studentfaq.html#24 

We suggest a proposal format that mirrors that of the Perl
<http://www.perl.org/advocacy/summerofcode/proposals.html>  and
PostgreSQL
<http://www.postgresql.org/developer/summerofcode#proposals>
foundations: 

Name 

Email 

Where can we contact you? 

Project Title 

Synopsis 

A short description. 

Benefits to the OhioLINK and higher education community 

Deliverables 

Quantifiable results e.g. "Improve X modules in ways Y and Z" or
"Add capability X to function Y" 

Project Details 

A more detailed description. You can't be too detailed. 

Project Schedule 

How long do you think the project will take? (No longer than
three months, of course.) What are the milestones? 

Bio 

Who are you? What makes you the best person to work on this
project? 

Remember that all proposals must be submitted through the Google
Summer of Code website to be counted as part of Google's program.


If you correspond with us about an idea and we think you intend
to apply to the Summer of Code program, we'll remind you that
your proposal must be submitted through Google's website from May
1st to May 8th, and we cannot take responsibility for your
submission if you don't follow Google's processes. Don't be too
concerned if the technical details are not all worked out; if
your proposal is selected we can do that in the early days of the
project. But remember that all Summer of Code projects should be
large enough for you to work on full time for almost three
months. 





-- 

Peter Murray
http://www.pandc.org/peter/work/

Assistant Director, Multimedia Systems
tel:+1-614-728-3600;ext=338

OhioLINK: the Ohio Library and Information Network   Columbus,
Ohio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.asis.org/pipermail/siged-l/attachments/20060501/e253da8b/attachment.html 


More information about the Siged-l mailing list