Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas

[Riley, Jenn]

(Sorry for the late weigh-in...)

>From Ross Singer:
 
> I totally agree we're
> past the point of hand waviness and just need to model this stuff
> /pragmatically/ (i.e. in a manner we think we could actually use), at
> scale, and have something to point to.
> 
> And then release whatever comes out of it so other can do the same
> thing.  Honestly, I believe we're at a stage of librarian-exhaustion
> over RDA and FRBR that the first decent working example of this,
> however removed from the actual specs, will become the defacto
> standard.

A concrete FBR implementation at not truly but something starting to look a bit 
like scale (80K sound recordings, 105K scores) is one of the most important 
goals of the Variations/FRBR project at Indiana. Stay tuned - we should have a 
first beta search system for folks to look at really soon now! I couldn't agree 
more the only way we're going to move forward at this point is to really put 
this thing into practice.

Jenn



Jenn Riley
Metadata Librarian
Digital Library Program
Indiana University - Bloomington
Wells Library W501
(812) 856-5759
www.dlib.indiana.edu

Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com

Re: [CODE4LIB] need a plan for what to code

[Samip Mallick]

Although Drupal isn't specifically tailored to libraries, archives or
museums, has it been adopted for use as a CMS?  It would, of course,
need customization and modification to do what one of the other
library-specific CMSes can do out of the box, but it seems like Drupal
offers a lot of flexibility.

Does anyone have thoughts about Drupal for digital libraries/archives?

Samip

On Mon, Mar 29, 2010 at 3:16 PM, Adam Wead  wrote:
> I second that.  I've been talking with a lot of museums and there seems to be 
> a pretty big gap between what systems there are for museums and what there 
> are for libraries and archives.  The museum here uses TMS (The Museum System) 
> which is proprietary.  I did look at getting that data into our discovery 
> interface as well with Coboat and OAICat Museum to better broadcast the 
> museum's holdings, but that isn't something the curatorial folks are 
> interested in doing at the moment.
>
> Thanks, Carol, for those links.  I've come across Omeka before.  It seems 
> like it's more geared towards image data.  Are you all planning to use it for 
> other content as well?  I'll definitely check out CollectiveAccess
>
> -Original Message-
> From: Code for Libraries on behalf of Ethan Gruber
> Sent: Mon 3/29/2010 5:01 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] need a plan for what to code
>
> That's a little difficult to make out, but I feel you are comparing apples
> to oranges by comparing Blacklight to Omeka or CollectiveAccess.  From what
> I've seen, I think CollectiveAccess is a great system.  Omeka is not, nor
> designed to be, digital repository software.  I'm not sure it's a good fit
> for Adam's requirements.  CollectiveAccess is worth looking into.  It's a
> shame more museums don't take open source solutions and CollectiveAccess
> more seriously.
>
> Ethan
>
> On Mon, Mar 29, 2010 at 4:48 PM, Carol Bean 
> wrote:
>
>> Adam,
>>
>> Oddly enough, I'm evaluating tools and DAM's this week.  I charted the
>> Open Source ones that looked possible,  I don't know how this is going to
>> come through on email, but this is what I've got:
>>
>
>
> Rock & Roll: (noun) African American slang dating back to the early 20th 
> Century. In the early 1950s, the term came to be used to describe a new form 
> of music, steeped in the blues, rhythm & blues, country and gospel. Today, it 
> refers to a wide variety of popular music -- frequently music with an edge 
> and attitude, music with a good beat and --- often --- loud guitars.© 2005 
> Rock and Roll Hall of Fame and Museum.
>
> This communication is a confidential and proprietary business communication. 
> It is intended solely for the use of the designated recipient(s). If this 
> communication is received in error, please contact the sender and delete this 
> communication.
>

Re: [CODE4LIB] need a plan for what to code

[Adam Wead]

I second that.  I've been talking with a lot of museums and there seems to be a 
pretty big gap between what systems there are for museums and what there are 
for libraries and archives.  The museum here uses TMS (The Museum System) which 
is proprietary.  I did look at getting that data into our discovery interface 
as well with Coboat and OAICat Museum to better broadcast the museum's 
holdings, but that isn't something the curatorial folks are interested in doing 
at the moment.

Thanks, Carol, for those links.  I've come across Omeka before.  It seems like 
it's more geared towards image data.  Are you all planning to use it for other 
content as well?  I'll definitely check out CollectiveAccess

-Original Message-
From: Code for Libraries on behalf of Ethan Gruber
Sent: Mon 3/29/2010 5:01 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] need a plan for what to code
 
That's a little difficult to make out, but I feel you are comparing apples
to oranges by comparing Blacklight to Omeka or CollectiveAccess.  From what
I've seen, I think CollectiveAccess is a great system.  Omeka is not, nor
designed to be, digital repository software.  I'm not sure it's a good fit
for Adam's requirements.  CollectiveAccess is worth looking into.  It's a
shame more museums don't take open source solutions and CollectiveAccess
more seriously.

Ethan

On Mon, Mar 29, 2010 at 4:48 PM, Carol Bean wrote:

> Adam,
>
> Oddly enough, I'm evaluating tools and DAM's this week.  I charted the
> Open Source ones that looked possible,  I don't know how this is going to
> come through on email, but this is what I've got:
>

 
Rock & Roll: (noun) African American slang dating back to the early 20th 
Century. In the early 1950s, the term came to be used to describe a new form of 
music, steeped in the blues, rhythm & blues, country and gospel. Today, it 
refers to a wide variety of popular music -- frequently music with an edge and 
attitude, music with a good beat and --- often --- loud guitars.© 2005 Rock and 
Roll Hall of Fame and Museum.
 
This communication is a confidential and proprietary business communication. It 
is intended solely for the use of the designated recipient(s). If this 
communication is received in error, please contact the sender and delete this 
communication.

Re: [CODE4LIB] need a plan for what to code

[Carol Bean]

Yeah, sorry about that.  I wish I could've pointed to it, but it's behind 
a firewall.  You're right that Blacklight isn't really in the same 
category as the others.


Carol Bean
Electronic Resources Librarian
Federal Courts Library
936 Federal Justice Building
99 NE 4th Street
Miami, FL  33132
305-523-5958
305-523-5962 (FAX)
carol_b...@ca11.uscourts.gov



From:
Ethan Gruber 
To:
CODE4LIB@LISTSERV.ND.EDU
Date:
03/29/2010 05:02 PM
Subject:
Re: [CODE4LIB] need a plan for what to code
Sent by:
Code for Libraries 



That's a little difficult to make out, but I feel you are comparing apples
to oranges by comparing Blacklight to Omeka or CollectiveAccess.  From 
what
I've seen, I think CollectiveAccess is a great system.  Omeka is not, nor
designed to be, digital repository software.  I'm not sure it's a good fit
for Adam's requirements.  CollectiveAccess is worth looking into.  It's a
shame more museums don't take open source solutions and CollectiveAccess
more seriously.

Ethan

On Mon, Mar 29, 2010 at 4:48 PM, Carol Bean 
wrote:

> Adam,
>
> Oddly enough, I'm evaluating tools and DAM's this week.  I charted the
> Open Source ones that looked possible,  I don't know how this is going 
to
> come through on email, but this is what I've got:
>
>
>
>
>
>
>
> Software
> Source location
> Platform
> Web
> Based
> MODS/
> METS/
> DC
> Language
> Database
> Includes
> Rep?
> Multiple
> Schemas
> Primary
> Audience
> /Users
> Support
> Omeka
> http://omeka.org/
> Linux
> Y
> DC
> PHP
> MySQL
> Y
> ?
> Staff/
> Public
> Forums/
> List
> Blacklight
> http://projectblacklight.org/
> Any
> Y
> Any
> Ruby
> N
> N
> Y
> Public
> List
> Greenstone
> http://www.greenstone.org
> Any
> Y
> DC
> Java,
> Perl
> ?
> Y
> Configu-
> rable
> Staff/
> Public
> List
> DSpace
> http://www.dspace.org
> Any
> Y
> Any
> Java,
> Perl
> PostGres,
> Oracle
> Y
> Y
> Staff/
> Public
> Forum/
> Lists
> CollectiveAccess
> http://www.collectiveaccess.org
> Any
> Y
> Any
> PHP
> MySQL
> N
> Y
> Staff/
> Public
> Forum/
> Consult.
>
>
>
>
> These are just the preliminary things I was looking at, but in the 
process
> of getting the chart filled in.  I'm leaning towards Omeka (there's a 
good
> article on it in D-Lib,
> http://www.dlib.org/dlib/march10/kucsma/03kucsma.html this month), or
> CollectiveAccess.  They look like they will require the least amount of
> work getting it set up, and I'm already familiar with PHP/MySQL. :-)
> (Includes Rep == includes repository)
>
> Hope this helps a little. :-)
>
>
> Carol Bean
> Electronic Resources Librarian
> Federal Courts Library
> 936 Federal Justice Building
> 99 NE 4th Street
> Miami, FL  33132
> 305-523-5958
> 305-523-5962 (FAX)
> carol_b...@ca11.uscourts.gov
>
>
>
> From:
> Adam Wead 
> To:
> CODE4LIB@LISTSERV.ND.EDU
> Date:
> 03/29/2010 03:38 PM
> Subject:
> Re: [CODE4LIB] need a plan for what to code
> Sent by:
> Code for Libraries 
>
>
>
> Ethan,
>
> Thanks, yes, I did take a look at this.  I have to pick my battles here. 
A
> discovery interface is one of the things that we could buy "off the 
shelf"
> and get a lot of good mileage out of.  I'm devoted to open source and I
> would love nothing more than to roll our own with Blacklight, but that's
> more work on top of the DAM issue.  I chose not to delve into the
> Blacklight option to save myself more time to focus on the asset manager
> issue, which is where I *think* I'll be having to work the most.
>
> Of course, I'm open to suggestions.  Does anyone think it's easier to do
> your own discovery layer than a DAM? Potentially, the money we save not
> buying a discovery layer could go towards buying a DAM.  However, the
> products we're looking have some really great interfaces.  I think I'd 
be
> looking at an equally difficult challenge trying to emulate some of 
those
> features on my own.
>
> thoughts?
>
> -Original Message-
> From: Code for Libraries on behalf of Ethan Gruber
> Sent: Mon 3/29/2010 3:00 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] need a plan for what to code
>
> Instead of purchasing a discovery system, I recommend using
> blacklight
>
> Ethan
>
>
>
>
> Rock & Roll: (noun) African American slang dating back to the early 20th
> Century. In the early 1950s, the term came to be used to describe a new
> form of music, steeped in the blues, rhythm & blues, country and gospel.
> Today, it refers to a wide variety of popular music -- frequently music
> with an edge and attitude, music with a good beat and --- often --- loud
> guitars.© 2005 Rock and Roll Hall of Fame and Museum.
>
> This communication is a confidential and proprietary business
> communication. It is intended solely for the use of the designated
> recipient(s). If this communication is received in error, please contact
> the sender and delete this communication.
>

Re: [CODE4LIB] need a plan for what to code

[Adam Wead]

Ha, that's really funny.  I had no idea stuff like that was happening.  
Although, there was new website launched this month, and no one tried to 
maintain any links from the old site, so most of those are broken.  I wasn't 
involved with that.

Our library is physically and technically separate from the main Rockhall's 
website which is really the public interface to the museum.  While we will have 
some content about the library and its collections in the Rockhall.com website, 
most of the metadata about the our collections will come from the libary 
catalog and other systems.  We intend the library to be an academic, education 
and research-oriented library that extends the museum's mission.  However, this 
example that you're showing highlights one of the key differences between the 
main site's more commercial targeted audience and our interface which will be 
targeting the more academically inclined user as well as the "wikipedians," not 
that they aren't synonymous!

Ideally, when the library catalog is full swing, those wikipedia links could 
point to information via persistent identifiers in our databases, such as 
archival finding aids, books and journals via WorldCat, and digital content.  
Although, we have yet to determine what, if any, of our digital content would 
be available on the public internet.  Hopefully some of it, but certainly not 
all.


-Original Message-
From: Code for Libraries on behalf of Lars Aronsson
Sent: Mon 3/29/2010 3:45 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] need a plan for what to code

Great fun! I have no ideas about which system to use.
But I suggest you begin from the other end: Who will
find your website useful, why and how? There is
already a website for the Rock and Roll Hall of Fame,
so what exactly will the digital collections of the
library and archive add to that?

Wikipedia has 720 links to www.rockhall.com,
which is a dream for any website,
http://en.wikipedia.org/wiki/Special:LinkSearch/www.rockhall.com

 
Rock & Roll: (noun) African American slang dating back to the early 20th 
Century. In the early 1950s, the term came to be used to describe a new form of 
music, steeped in the blues, rhythm & blues, country and gospel. Today, it 
refers to a wide variety of popular music -- frequently music with an edge and 
attitude, music with a good beat and --- often --- loud guitars.© 2005 Rock and 
Roll Hall of Fame and Museum.
 
This communication is a confidential and proprietary business communication. It 
is intended solely for the use of the designated recipient(s). If this 
communication is received in error, please contact the sender and delete this 
communication.

Re: [CODE4LIB] wikipedia external links and linked data

[Lars Aronsson]

Jonathan Rochkind wrote:
Hmm, just because a given page is linked to from a wikipedia page, can 
one assume that the target of the link is about the same thing as the 
original page?   I'm not sure how often this assumption would be 
violated?


You can encourage wikipedians to use a
descriptive link text. For example, the article
http://en.wikipedia.org/wiki/Archbishop_of_Uppsala
contains these three links to my website:

[http://runeberg.org/nfcj/0700.html page 1271, article ''Uppsala 
ärkestift''], [[Nordisk familjebok]] (1920)
[http://runeberg.org/nfcm/0678.html page 1264 article ''Ärkebiskop''], 
[[Nordisk familjebok]]  (1922).

[http://runeberg.org/nfap/0745.html Uppsala stift], [[Nordisk familjebok]]

Which are three articles in different volumes of
the old digitized encyclopedia "Nordisk familjebok".
You'll note that "Uppsala stift" is a headword
on the page http://runeberg.org/nfap/0745.html

Runeberg.org has 2000 links from the
English Wikipedia, which puts it between
catalog.loc.gov and nobelprize.org.
If you want many links from Wikipedia, try
to digitize an old encyclopedia and make
one plain HTML page for each book page.


--
 Lars Aronsson (l...@aronsson.se)
 Aronsson Datateknik - http://aronsson.se

 Project Runeberg - free Nordic literature - http://runeberg.org/

Re: [CODE4LIB] need a plan for what to code

[Ethan Gruber]

That's a little difficult to make out, but I feel you are comparing apples
to oranges by comparing Blacklight to Omeka or CollectiveAccess.  From what
I've seen, I think CollectiveAccess is a great system.  Omeka is not, nor
designed to be, digital repository software.  I'm not sure it's a good fit
for Adam's requirements.  CollectiveAccess is worth looking into.  It's a
shame more museums don't take open source solutions and CollectiveAccess
more seriously.

Ethan

On Mon, Mar 29, 2010 at 4:48 PM, Carol Bean wrote:

> Adam,
>
> Oddly enough, I'm evaluating tools and DAM's this week.  I charted the
> Open Source ones that looked possible,  I don't know how this is going to
> come through on email, but this is what I've got:
>
>
>
>
>
>
>
> Software
> Source location
> Platform
> Web
> Based
> MODS/
> METS/
> DC
> Language
> Database
> Includes
> Rep?
> Multiple
> Schemas
> Primary
> Audience
> /Users
> Support
> Omeka
> http://omeka.org/
> Linux
> Y
> DC
> PHP
> MySQL
> Y
> ?
> Staff/
> Public
> Forums/
> List
> Blacklight
> http://projectblacklight.org/
> Any
> Y
> Any
> Ruby
> N
> N
> Y
> Public
> List
> Greenstone
> http://www.greenstone.org
> Any
> Y
> DC
> Java,
> Perl
> ?
> Y
> Configu-
> rable
> Staff/
> Public
> List
> DSpace
> http://www.dspace.org
> Any
> Y
> Any
> Java,
> Perl
> PostGres,
> Oracle
> Y
> Y
> Staff/
> Public
> Forum/
> Lists
> CollectiveAccess
> http://www.collectiveaccess.org
> Any
> Y
> Any
> PHP
> MySQL
> N
> Y
> Staff/
> Public
> Forum/
> Consult.
>
>
>
>
> These are just the preliminary things I was looking at, but in the process
> of getting the chart filled in.  I'm leaning towards Omeka (there's a good
> article on it in D-Lib,
> http://www.dlib.org/dlib/march10/kucsma/03kucsma.html this month), or
> CollectiveAccess.  They look like they will require the least amount of
> work getting it set up, and I'm already familiar with PHP/MySQL. :-)
> (Includes Rep == includes repository)
>
> Hope this helps a little. :-)
>
>
> Carol Bean
> Electronic Resources Librarian
> Federal Courts Library
> 936 Federal Justice Building
> 99 NE 4th Street
> Miami, FL  33132
> 305-523-5958
> 305-523-5962 (FAX)
> carol_b...@ca11.uscourts.gov
>
>
>
> From:
> Adam Wead 
> To:
> CODE4LIB@LISTSERV.ND.EDU
> Date:
> 03/29/2010 03:38 PM
> Subject:
> Re: [CODE4LIB] need a plan for what to code
> Sent by:
> Code for Libraries 
>
>
>
> Ethan,
>
> Thanks, yes, I did take a look at this.  I have to pick my battles here. A
> discovery interface is one of the things that we could buy "off the shelf"
> and get a lot of good mileage out of.  I'm devoted to open source and I
> would love nothing more than to roll our own with Blacklight, but that's
> more work on top of the DAM issue.  I chose not to delve into the
> Blacklight option to save myself more time to focus on the asset manager
> issue, which is where I *think* I'll be having to work the most.
>
> Of course, I'm open to suggestions.  Does anyone think it's easier to do
> your own discovery layer than a DAM? Potentially, the money we save not
> buying a discovery layer could go towards buying a DAM.  However, the
> products we're looking have some really great interfaces.  I think I'd be
> looking at an equally difficult challenge trying to emulate some of those
> features on my own.
>
> thoughts?
>
> -Original Message-
> From: Code for Libraries on behalf of Ethan Gruber
> Sent: Mon 3/29/2010 3:00 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] need a plan for what to code
>
> Instead of purchasing a discovery system, I recommend using
> blacklight
>
> Ethan
>
>
>
>
> Rock & Roll: (noun) African American slang dating back to the early 20th
> Century. In the early 1950s, the term came to be used to describe a new
> form of music, steeped in the blues, rhythm & blues, country and gospel.
> Today, it refers to a wide variety of popular music -- frequently music
> with an edge and attitude, music with a good beat and --- often --- loud
> guitars.© 2005 Rock and Roll Hall of Fame and Museum.
>
> This communication is a confidential and proprietary business
> communication. It is intended solely for the use of the designated
> recipient(s). If this communication is received in error, please contact
> the sender and delete this communication.
>

Re: [CODE4LIB] wikipedia external links and linked data

[Ed Summers]

On Mon, Mar 29, 2010 at 4:34 PM, Jonathan Rochkind  wrote:
> Hmm, just because a given page is linked to from a wikipedia page, can one
> assume that the target of the link is about the same thing as the original
> page?   I'm not sure how often this assumption would be violated?

Yeah, unfortunately the nature of the link is kind of hazy. I imagine
some heuristics looking at the hyperlink text, and where it appears in
the page could help somewhat.

//Ed

Re: [CODE4LIB] need a plan for what to code

[Carol Bean]

Adam,

Oddly enough, I'm evaluating tools and DAM's this week.  I charted the 
Open Source ones that looked possible,  I don't know how this is going to 
come through on email, but this is what I've got:







Software
Source location
Platform
Web
Based
MODS/
METS/
DC
Language
Database
Includes
Rep?
Multiple
Schemas
Primary
Audience
/Users
Support
Omeka
http://omeka.org/
Linux
Y
DC
PHP
MySQL
Y
?
Staff/
Public
Forums/
List
Blacklight
http://projectblacklight.org/
Any
Y
Any
Ruby
N
N
Y
Public
List
Greenstone
http://www.greenstone.org
Any
Y
DC
Java,
Perl
?
Y
Configu-
rable
Staff/
Public
List
DSpace
http://www.dspace.org
Any
Y
Any
Java,
Perl
PostGres,
Oracle
Y
Y
Staff/
Public
Forum/
Lists
CollectiveAccess
http://www.collectiveaccess.org
Any
Y
Any
PHP
MySQL
N
Y
Staff/
Public
Forum/
Consult.




These are just the preliminary things I was looking at, but in the process 
of getting the chart filled in.  I'm leaning towards Omeka (there's a good 
article on it in D-Lib, 
http://www.dlib.org/dlib/march10/kucsma/03kucsma.html this month), or 
CollectiveAccess.  They look like they will require the least amount of 
work getting it set up, and I'm already familiar with PHP/MySQL. :-)
(Includes Rep == includes repository)

Hope this helps a little. :-)


Carol Bean
Electronic Resources Librarian
Federal Courts Library
936 Federal Justice Building
99 NE 4th Street
Miami, FL  33132
305-523-5958
305-523-5962 (FAX)
carol_b...@ca11.uscourts.gov



From:
Adam Wead 
To:
CODE4LIB@LISTSERV.ND.EDU
Date:
03/29/2010 03:38 PM
Subject:
Re: [CODE4LIB] need a plan for what to code
Sent by:
Code for Libraries 



Ethan,

Thanks, yes, I did take a look at this.  I have to pick my battles here. A 
discovery interface is one of the things that we could buy "off the shelf" 
and get a lot of good mileage out of.  I'm devoted to open source and I 
would love nothing more than to roll our own with Blacklight, but that's 
more work on top of the DAM issue.  I chose not to delve into the 
Blacklight option to save myself more time to focus on the asset manager 
issue, which is where I *think* I'll be having to work the most.

Of course, I'm open to suggestions.  Does anyone think it's easier to do 
your own discovery layer than a DAM? Potentially, the money we save not 
buying a discovery layer could go towards buying a DAM.  However, the 
products we're looking have some really great interfaces.  I think I'd be 
looking at an equally difficult challenge trying to emulate some of those 
features on my own.

thoughts?

-Original Message-
From: Code for Libraries on behalf of Ethan Gruber
Sent: Mon 3/29/2010 3:00 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] need a plan for what to code
 
Instead of purchasing a discovery system, I recommend using
blacklight

Ethan



 
Rock & Roll: (noun) African American slang dating back to the early 20th 
Century. In the early 1950s, the term came to be used to describe a new 
form of music, steeped in the blues, rhythm & blues, country and gospel. 
Today, it refers to a wide variety of popular music -- frequently music 
with an edge and attitude, music with a good beat and --- often --- loud 
guitars.© 2005 Rock and Roll Hall of Fame and Museum.
 
This communication is a confidential and proprietary business 
communication. It is intended solely for the use of the designated 
recipient(s). If this communication is received in error, please contact 
the sender and delete this communication.

Re: [CODE4LIB] need a plan for what to code

[Tom Cramer]

Adam,

Just over a year ago, we were in a similar position to yours, and wanted both a 
discovery layer and a Fedora-based digital asset management system for 
Stanford. 

We ended up adopting Blacklight for both our next generation catalog [1] and as 
the UI providing discovery / viewing component of our repository. To complement 
BL's strong searching / browsing / multi-format object viewing capabilities, we 
are building a Ruby-on-Rails-based repository front end application to provide 
the deposit / editing / object management capabilities. 

This architecture and overall approach is a multi-institutional project called 
Hydra [2], with Stanford, University of Virginia and University of Hull being 
the primary contributors at this point. The app makes use of ActiveFedora [3] 
as the bridge between the Fedora and the Rails apps. 

By our calculations, this gave us the best of three worlds--Blacklight provides 
a single platform both for discovery and part of our repository front end, we 
leverage Fedora for its asset management capabilities, and the Hydra / 
ActiveFedora components let us do rapid application and flexible application 
development for our DAM needs. 

The project is still young, but all the project code is open source, and 
adopters/contributors/partners are welcome. 

- Tom

  | Tom Cramer
  | Stanford University 
  | tcra...@stanford.edu


[1] http://searchworks.stanford.edu
[2] www.fedora-commons.org/confluence/display/hydra
[3] www.yourmediashelf.com/activefedora/





On Mar 29, 2010, at 12:37 PM, Adam Wead wrote:

> Ethan,
> 
> Thanks, yes, I did take a look at this.  I have to pick my battles here.  A 
> discovery interface is one of the things that we could buy "off the shelf" 
> and get a lot of good mileage out of.  I'm devoted to open source and I would 
> love nothing more than to roll our own with Blacklight, but that's more work 
> on top of the DAM issue.  I chose not to delve into the Blacklight option to 
> save myself more time to focus on the asset manager issue, which is where I 
> *think* I'll be having to work the most.
> 
> Of course, I'm open to suggestions.  Does anyone think it's easier to do your 
> own discovery layer than a DAM? Potentially, the money we save not buying a 
> discovery layer could go towards buying a DAM.  However, the products we're 
> looking have some really great interfaces.  I think I'd be looking at an 
> equally difficult challenge trying to emulate some of those features on my 
> own.
> 
> thoughts?
> 
> -Original Message-
> From: Code for Libraries on behalf of Ethan Gruber
> Sent: Mon 3/29/2010 3:00 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] need a plan for what to code
> 
> Instead of purchasing a discovery system, I recommend using
> blacklight
> 
> Ethan
> 
> 
> 
>  
> Rock & Roll: (noun) African American slang dating back to the early 20th 
> Century. In the early 1950s, the term came to be used to describe a new form 
> of music, steeped in the blues, rhythm & blues, country and gospel. Today, it 
> refers to a wide variety of popular music -- frequently music with an edge 
> and attitude, music with a good beat and --- often --- loud guitars.© 2005 
> Rock and Roll Hall of Fame and Museum.
>  
> This communication is a confidential and proprietary business communication. 
> It is intended solely for the use of the designated recipient(s). If this 
> communication is received in error, please contact the sender and delete this 
> communication.

Re: [CODE4LIB] wikipedia external links and linked data

[Jonathan Rochkind]

Hmm, just because a given page is linked to from a wikipedia page, can 
one assume that the target of the link is about the same thing as the 
original page?   I'm not sure how often this assumption would be violated?


Ed Summers wrote:

On Mon, Mar 29, 2010 at 3:45 PM, Lars Aronsson  wrote:
  

Wikipedia has 720 links to www.rockhall.com,
which is a dream for any website,
http://en.wikipedia.org/wiki/Special:LinkSearch/www.rockhall.com



I had no idea that Wikipedia provided a live search of external links.
Up until now I have been pulling those relations from our referrer in
our web server logs.

If you squint right (with your Linked Data tinted glasses on)
wikipedians sure look like catalogers, describing the resources that
libraries and museums put on the web.

For example from
http://en.wikipedia.org/w/index.php?title=Special:LinkSearch&target=http://chroniclingamerica.loc.gov&limit=500&offset=0
it's possible to infer:


dcterms:subject  .

Since we don't have page level metadata for the 2 millions pages of
newspaper content in Chronicling America, this is pretty valuable
information.

//Ed

  

[CODE4LIB] wikipedia external links and linked data

[Ed Summers]

On Mon, Mar 29, 2010 at 3:45 PM, Lars Aronsson  wrote:
> Wikipedia has 720 links to www.rockhall.com,
> which is a dream for any website,
> http://en.wikipedia.org/wiki/Special:LinkSearch/www.rockhall.com

I had no idea that Wikipedia provided a live search of external links.
Up until now I have been pulling those relations from our referrer in
our web server logs.

If you squint right (with your Linked Data tinted glasses on)
wikipedians sure look like catalogers, describing the resources that
libraries and museums put on the web.

For example from
http://en.wikipedia.org/w/index.php?title=Special:LinkSearch&target=http://chroniclingamerica.loc.gov&limit=500&offset=0
it's possible to infer:


dcterms:subject  .

Since we don't have page level metadata for the 2 millions pages of
newspaper content in Chronicling America, this is pretty valuable
information.

//Ed

Re: [CODE4LIB] need a plan for what to code

[Lars Aronsson]

Adam Wead wrote:

I'm the new systems and digital collections librarian for the Rock and Roll 
Hall of Fame Library and Archives.


Great fun! I have no ideas about which system to use.
But I suggest you begin from the other end: Who will
find your website useful, why and how? There is
already a website for the Rock and Roll Hall of Fame,
so what exactly will the digital collections of the
library and archive add to that?

Wikipedia has 720 links to www.rockhall.com,
which is a dream for any website,
http://en.wikipedia.org/wiki/Special:LinkSearch/www.rockhall.com

But there are 1300 links to catalog.loc.gov,
http://en.wikipedia.org/wiki/Special:LinkSearch/catalog.loc.gov

more than 5000 links to nobelprize.org,
which is kind of similar to rockhall.com,
http://en.wikipedia.org/wiki/Special:LinkSearch/nobelprize.org

and more than 16,000 links to worldcat.org,
http://en.wikipedia.org/wiki/Special:LinkSearch/worldcat.org

If Wikipedia were to add 3000 links to your digital
collections, what should those URLs be? I think they
must be 1) short, 2) long-term stable, 3) provide
useful information that is not already available at
Worldcat.org, Allmusic.com, IMDb.com or some other
website.


--
 Lars Aronsson (l...@aronsson.se)
 Aronsson Datateknik - http://aronsson.se

Re: [CODE4LIB] need a plan for what to code

[Adam Wead]

Ethan,

Thanks, yes, I did take a look at this.  I have to pick my battles here.  A 
discovery interface is one of the things that we could buy "off the shelf" and 
get a lot of good mileage out of.  I'm devoted to open source and I would love 
nothing more than to roll our own with Blacklight, but that's more work on top 
of the DAM issue.  I chose not to delve into the Blacklight option to save 
myself more time to focus on the asset manager issue, which is where I *think* 
I'll be having to work the most.

Of course, I'm open to suggestions.  Does anyone think it's easier to do your 
own discovery layer than a DAM? Potentially, the money we save not buying a 
discovery layer could go towards buying a DAM.  However, the products we're 
looking have some really great interfaces.  I think I'd be looking at an 
equally difficult challenge trying to emulate some of those features on my own.

thoughts?

-Original Message-
From: Code for Libraries on behalf of Ethan Gruber
Sent: Mon 3/29/2010 3:00 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] need a plan for what to code
 
Instead of purchasing a discovery system, I recommend using
blacklight

Ethan



 
Rock & Roll: (noun) African American slang dating back to the early 20th 
Century. In the early 1950s, the term came to be used to describe a new form of 
music, steeped in the blues, rhythm & blues, country and gospel. Today, it 
refers to a wide variety of popular music -- frequently music with an edge and 
attitude, music with a good beat and --- often --- loud guitars.© 2005 Rock and 
Roll Hall of Fame and Museum.
 
This communication is a confidential and proprietary business communication. It 
is intended solely for the use of the designated recipient(s). If this 
communication is received in error, please contact the sender and delete this 
communication.

Re: [CODE4LIB] need a plan for what to code

[Ethan Gruber]

Instead of purchasing a discovery system, I recommend using
blacklight

Ethan

On Mon, Mar 29, 2010 at 2:49 PM, Adam Wead  wrote:

> Hello All,
>
> This is my first post to the list so I thought I'd share my current dilemma
> and put it to you all to see what you might do if you were in my place.
>  I've really tried to keep this message as short as possible, but it's still
> too long.  I apologize in advance for that.  I can fill in more detail as
> the discussion progresses.
>
> I'm the new systems and digital collections librarian for the Rock and Roll
> Hall of Fame Library and Archives.  I've been in the job for about two
> months now and have been gathering lots of information on requirements. The
> Rockhall library will open to the public for the first time at the end of
> this year and one of the things we're going to need is a digital asset
> manger. I'll briefly give you a list of some of the requirements that we're
> looking for, then a list of what possible solutions I've come up with, and
> close with problems I currently face.
>
> -- DAM requirements --
>
> Currently, we have no digital content, but will be building the
> infrastructure and workflows necessary to deal with the following:
>
> Video: manage archival JPEG2000 and MPEG4 files created from a variety of
> analog sources, stream derivatives, handle descriptive metadata as well as
> text annotations and transcriptions of video segments, and manage new
> archival and access video objects created from edits of MPEG4 sources.
>
> Audio: manage archival 24/96 broadcast wav files and stream mp3 or
> equivalent derivatives, handle catalog metadata
>
> Images and Documents: same as audio, but with hi-res tiff images and
> jpeg/pdf, or similar derivatives
>
> -- Possible solutions (and their drawbacks) --
>
> DSpace: great for images and documents, not so good with video or audio?
> Also, complexity of video datastreams suggests another solution...
>
> Fedora: flexible enough to handle both JPEG2000 and MPEG4 formats for a
> single archival video, as well as the text objects and future creation of
> edited videos from multiple archival sources, similar to WGBH's OpenVault.
> Downside: Extremely complex and code-intensive to develop and manage.
>
> Proprietary options, ex. ContentDM, DigiTool, and others: I am unaware of
> their video capabilities at the moment. Image and document data seems to
> work best. Downside: will likely be cost-prohibitive.
>
> -- Problems --
>
> I need to come up with a realistic goal.  I'm a one-person show here...
>  While we probably won't be able to afford a nice vendor solution--assuming
> one exists that fits all of our needs--it would be just as costly in terms
> of time for me to learn, code and deploy a complete solution using the open
> source alternatives I've listed above, and I know I've missed some.
>
> I have a lot of catching-up to do. I'm great with unix systems, databases,
> PHP and Perl; Java and XSLT, not so much. I'm taking a look at Python and
> Ruby because I can build and deploy things faster with them than PHP or
> Perl, they already have some Fedora libraries for them, and they are easier
> for me to wrap my head around than Java, but it will take a while to get
> fluent in either of them.
>
> So, what would you do?
>
> The idea I have in mind at the moment goes something like this:
> First, we're going to purchase a discovery system that will harvest records
> from our soon-to-be-created MARC library catalog, and soon-to-be-populated
> archival manager, Archon.  Using that discovery service, we could harvest
> from one or more DAMs such as DSpace for images and documents, and maybe
> even audio; and Fedora or some such other system for video.  Fedora would be
> ideal for our video collection, and everything else for that matter, but
> very, very time consuming to construct.  Assuming I could build the back-end
> of fedora enough to allow some rudimentary ingestion of objects, the
> discovery interface could at least serve those objects out in some way by
> letting users know that they exist.  Actually streaming the video or audio
> is another story... but, if the discovery layer is there, I could build a
> nicer interface for deployment at a later date.
>
> Since we don't open for another 9 months, and have no data to manage yet,
> that's time to start working on a Fedora backend, or research and create
> another solution.  I've looked at Fedora front-ends like Fez, Islandora, and
> Active-fedora, but they are limited to which version of Fedora they can use,
> and I can't get a feel yet for how they would deal with our requirements.
>
> If we can coast by on a discovery-only type solution, that could give me a
> year (?) to build a nice interface or retool an existing one for our use.
>  So, 9 months for a repository, one year for a full interface.  Given my
> above limitations and desire not to work 80 hours a week, is something like
> that feasible, slightl

[CODE4LIB] need a plan for what to code

[Adam Wead]

Hello All,

This is my first post to the list so I thought I'd share my current dilemma and 
put it to you all to see what you might do if you were in my place.  I've 
really tried to keep this message as short as possible, but it's still too 
long.  I apologize in advance for that.  I can fill in more detail as the 
discussion progresses.

I'm the new systems and digital collections librarian for the Rock and Roll 
Hall of Fame Library and Archives.  I've been in the job for about two months 
now and have been gathering lots of information on requirements. The Rockhall 
library will open to the public for the first time at the end of this year and 
one of the things we're going to need is a digital asset manger. I'll briefly 
give you a list of some of the requirements that we're looking for, then a list 
of what possible solutions I've come up with, and close with problems I 
currently face.

-- DAM requirements --

Currently, we have no digital content, but will be building the infrastructure 
and workflows necessary to deal with the following:

Video: manage archival JPEG2000 and MPEG4 files created from a variety of 
analog sources, stream derivatives, handle descriptive metadata as well as text 
annotations and transcriptions of video segments, and manage new archival and 
access video objects created from edits of MPEG4 sources.

Audio: manage archival 24/96 broadcast wav files and stream mp3 or equivalent 
derivatives, handle catalog metadata

Images and Documents: same as audio, but with hi-res tiff images and jpeg/pdf, 
or similar derivatives

-- Possible solutions (and their drawbacks) --

DSpace: great for images and documents, not so good with video or audio? Also, 
complexity of video datastreams suggests another solution...

Fedora: flexible enough to handle both JPEG2000 and MPEG4 formats for a single 
archival video, as well as the text objects and future creation of edited 
videos from multiple archival sources, similar to WGBH's OpenVault. Downside: 
Extremely complex and code-intensive to develop and manage.

Proprietary options, ex. ContentDM, DigiTool, and others: I am unaware of their 
video capabilities at the moment. Image and document data seems to work best. 
Downside: will likely be cost-prohibitive.

-- Problems --

I need to come up with a realistic goal.  I'm a one-person show here...  While 
we probably won't be able to afford a nice vendor solution--assuming one exists 
that fits all of our needs--it would be just as costly in terms of time for me 
to learn, code and deploy a complete solution using the open source 
alternatives I've listed above, and I know I've missed some.

I have a lot of catching-up to do. I'm great with unix systems, databases, PHP 
and Perl; Java and XSLT, not so much. I'm taking a look at Python and Ruby 
because I can build and deploy things faster with them than PHP or Perl, they 
already have some Fedora libraries for them, and they are easier for me to wrap 
my head around than Java, but it will take a while to get fluent in either of 
them.

So, what would you do?

The idea I have in mind at the moment goes something like this:
First, we're going to purchase a discovery system that will harvest records 
from our soon-to-be-created MARC library catalog, and soon-to-be-populated 
archival manager, Archon.  Using that discovery service, we could harvest from 
one or more DAMs such as DSpace for images and documents, and maybe even audio; 
and Fedora or some such other system for video.  Fedora would be ideal for our 
video collection, and everything else for that matter, but very, very time 
consuming to construct.  Assuming I could build the back-end of fedora enough 
to allow some rudimentary ingestion of objects, the discovery interface could 
at least serve those objects out in some way by letting users know that they 
exist.  Actually streaming the video or audio is another story... but, if the 
discovery layer is there, I could build a nicer interface for deployment at a 
later date.

Since we don't open for another 9 months, and have no data to manage yet, 
that's time to start working on a Fedora backend, or research and create 
another solution.  I've looked at Fedora front-ends like Fez, Islandora, and 
Active-fedora, but they are limited to which version of Fedora they can use, 
and I can't get a feel yet for how they would deal with our requirements.

If we can coast by on a discovery-only type solution, that could give me a year 
(?) to build a nice interface or retool an existing one for our use.  So, 9 
months for a repository, one year for a full interface.  Given my above 
limitations and desire not to work 80 hours a week, is something like that 
feasible, slightly ludicrous or completely insane?

If it's not really feasible, then I might be looking at a collaboration with 
one or more of you fine people, or finding some money from my organization or a 
grant to help pay one or more of you fine people for help.

So, I close this 

Re: [CODE4LIB] planet code4lib code

[Galen Charlton]

Hi,

On Mon, Mar 29, 2010 at 12:37 PM, Jonathan Rochkind  wrote:
> Ah, I hadn't known about Oloh, that looks pretty nice thanks Galen.  What
> sorts of repos can oloh work with? Or does oloh not even get into the repo
> level, it's just a registration of projects or something?

Ohloh can snarf code for various statistical and analysis purposes.
Currently it can process Bazaar, CVS, Git, Mercurial, and Subversion
repos.

Regards,

Galen
-- 
Galen Charlton
gmcha...@gmail.com

Re: [CODE4LIB] planet code4lib code

[Jonathan Rochkind]

Ah, I hadn't known about Oloh, that looks pretty nice thanks Galen.  
What sorts of repos can oloh work with? Or does oloh not even get into 
the repo level, it's just a registration of projects or something? 


Galen Charlton wrote:

Hi,

On Sun, Mar 28, 2010 at 6:08 PM, Jonathan Rochkind  wrote:
  

Plus'ing it is one thing, but I have no idea what such a thing would actually 
look like (interface-wise), or how it would be accomplished. I'm not sure what 
it means exactly. It's an interesting idea, but anyone have any idea what it 
would actually look like?



Perhaps as a sideways start we could use use the 'code4lib' tag on
Ohloh to link projects together?

Regards,

Galen
  

Re: [CODE4LIB] planet code4lib code

[Aaron Rubinstein]

GitHub does something like this, e.g. http://github.com/jeresig.  See 
the "Public Activity" section on the right.


Aaron

On 3/28/2010 8:24 PM, Bill Dueber wrote:

I know some systems (I'm thinking of CPAN and Gemcutter in particular) have
feeds of new releases -- maybe we could tap into those and note when
registered projects have new releases? I don't know if that's fine-grained
enough information for what folks want.

On Sun, Mar 28, 2010 at 6:44 PM, Jonathan Rochkind  wrote:


Good point Aaron. Maybe that's possible, but I'm not seeing exactly what
the interface would look like. Without worrying about how to implement it,
can you say more about what you'd actually want to see as a user?  Expand on
what you mean by "listens for feeds of specific types," I'm not sure what
that means.  You'd like to see, what? Just initial commits by certain users,
and new stable releases on certain projects (or by certain users?).   Or you
want to have an interface that gives you the ability to choose/search
exactly what you want to see from categories like these, accross a wide
swatch of projects chosen as of interest?

From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Aaron
Rubinstein [arubi...@library.umass.edu]
Sent: Sunday, March 28, 2010 6:33 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] planet code4lib code (was: newbie)

Quoting Jonathan Rochkind:


Hmm, an aggregated feed of the commit logs (from repos that offer
feeds, as most do), of "open source projects of interest to the
code4lib community."  Would that be at all useful?


I think that's a start but I'd imagine that just a feed of the commit
logs would contain a lot of noise that would drown out what might
actually be interesting, like newly published gists, initial commits
of projects, new project releases, etc...  I'm most familiar with
GitHub, which indicates the type of event being published, but I'm
sure other code repos do something similar.  Would it be possible to
put something together using Views that listens for feeds of specific
types published by users in the code4lib community?

Aaron







--
Aaron Rubinstein
Digital Project Manager
W.E.B. Du Bois - Verizon Digitization Project
Special Collections and University Archives
University of Massachusetts, Amherst
Tel: (413)545-9637
Email: arubi...@library.umass.edu
Web: http://www.library.umass.edu/spcoll/

Re: [CODE4LIB] planet code4lib code (was: newbie)

[Galen Charlton]

Hi,

On Sun, Mar 28, 2010 at 6:08 PM, Jonathan Rochkind  wrote:
> Plus'ing it is one thing, but I have no idea what such a thing would actually 
> look like (interface-wise), or how it would be accomplished. I'm not sure 
> what it means exactly. It's an interesting idea, but anyone have any idea 
> what it would actually look like?

Perhaps as a sideways start we could use use the 'code4lib' tag on
Ohloh to link projects together?

Regards,

Galen
-- 
Galen Charlton
gmcha...@gmail.com

[CODE4LIB] EADitor: XForms for EAD 0.4 beta released

[Ethan Gruber]

Sorry for crossposting

-

Hi all,

Over the last six months I have been working on and off on a different
system for producing and manipulating EAD finding aids using XForms, which
is a W3C specification for next-generation web forms, designed specifically
with the creation of complex, hierarchical XML in mind.  The project is
called EADitor and has moved from alpha "proof of concept" phase to beta.  I
am releasing a beta that works on Linux/Mac servers and workstations, but
since it is a java-based server application, it can run in Windows also
(although I have not yet tested it).  The version number is 0.4 to coincide
with the month of April.  EADitor is open source and freely available.

Since this is a beta, I will admit that there are bugs and much work left to
do.

FEATURES

* Create ead header, archdesc, and components.  Most elements are handled,
but mixed content at the paragraph level is not.  It is possible to use a
WYSIWYG editor to create rich metadata at the paragraph level, so look for
that in a future version of EADitor.
* Nearly 400,000 LCSH authority terms are integrated into the form for
autosuggestion for 
* Languages are autosuggested from LOC authority file
* Corpname, famname, genreform, geogname, persname, and subject can be
scraped from EAD files already in the system to provide for localized
controlled vocabulary.
* EAD uploading: Almost all EAD 2002 compliant XML files can be preprocessed
to correct inconsistencies in encoding to be loaded into the system for
editing or publication.  Transformation is minor and there is no loss of
data.
* Deletion: Delete files with an easy to use web interface
* Publication: Publish/unpublish selected files via a Solr search index.  A
variety of search facets are preselected in the publication process.  The
interface for searching and browsing the collection is not yet complete.
Look for that by the end of April.
* View the XML or HTML version of the finding aid.  Useful for looking at
the visual presentation of a collection as it is being processed by
archivists

FUTURE GOALS
* Complete the ultimate hurdle of mixed content XML.  Subject specialists
contributing context to a collection is vital to researchers, and a simple
javascript-based editor embedded in the browser can allow for the creation
of robust EAD without technical barriers usually associated with the
creation of XML
* Tap into more controlled vocabulary indices
* Create a metaform which defines the EAD template (the default template is
as minimalistic as EAD allows)
* Finish the public interface, for institutions that want a single
application for creating, editing, and disseminating EAD finding aids
online.
* Allow for the reordering of components
* Allow for optional automatic container numbering in a reversible
post-process

The project has come a long way in the last two months, and I look forward
to improving it based on criticism and feedback from the archival community
at large.

Google code site (for downloads): http://code.google.com/p/eaditor/
Technical list, geared toward XForms developers in libraries:
https://list.mail.virginia.edu/mailman/listinfo/xforms4lib
Non-technical list, for librarians and archivists interested in EADitor
specifically: http://groups.google.com/group/eaditor

A test of the software is accessible at the URL
http://eaditor.scholarslab.org:8080/orbeon/ead/admin/ .  Please note that
this is a virtual instance with only 1 GB of RAM, so it runs slower than
many newer computers.  The performance of EADitor is directly proportional
to the specs of the server it is running on.

I will be demonstrating EADitor at the Mid-Atlantic Regional Archives
Conference in the end of April.  I am designing EADitor to be a useful tool
for the community it is designed to serve.  Feedback can help me refine it
further.

Thanks,
Ethan Gruber
Digital Research and Development, University of Virginia Library

Re: [CODE4LIB] planet code4lib code (was: newbie)

[Király Péter]

- Original Message - 
From: "Aaron Rubinstein" 

I would like to see:

1.  Code snippets/gists.


For the interface I can imagine a similar something as http://pastebin.com/,
like http://drupal.pastebin.com/41WtCpTY, maybe with library-tech related
categories (UI, search, circ, admin UI, DB, XML, ...)

Péter
http://eXtensibleCatalog.org