[Koha-devel] Re: MyLibrary & Koha

Tue May 20 10:45:09 CEST 2003

Thanks Eric for pulling everyone together to talk about this.  I think
that groups of projects working together are going to go a lot further in
improving the library automation space than we could ever hope to
independently.  I've interspersed my comments below.

On Tue, 20 May 2003, Eric Lease Morgan wrote:

> On 5/15/03 9:47 AM, Nicolas Morin <nicolas.morin at scd.uhp-nancy.fr> wrote:
>
> > How could Koha and MyLibrary come together? ... We have many oss building
> > blocks : there's no way Koha is going to become something like Millenium, but
> > MyLibrary + Koha + DSpace + OpenILL, etc... could soon provide something not
> > too far from it. For that to happen they would have to have the ability to
> > work together perfectly and also, I feel, to appear under one unifying
> > "umbrella" (OSS4LIB?) that would make this "de-centralized" system visible and
> > credible to librarians and library managers. What should we do to achieve
> > these strategic goals? I don't know. Perfect interoperability between the
> > various oss projects I guess. Maybe XML, SOAP and web services are the way
> > forward? Maybe developpers from the various projects could come up with
> > something like a "roadmap for interoperability"?
>

i like this idea ... in fact, i like it so much that i've been trying to
include people outside of Koha in the development of our development
roadmap and in discussions about other issues of interest to the wider
library community.  E.g., On Wed, May 21 at 1900 UTC (1200 here in
Seattle, if you live elsewhere you can deduce your local time) we're going
to be ircing about ILLs in Perl.  I've already invited the Perl4Lib
crowd, but anyone is welcome.  Some of the conversation will be Koha
specific, but I'd like to see a solution that fits everyone.  (not
entirely germane to the rest of the discussion, but what the heck)

>
> On 5/15/03 2:04 PM, Pat Eyler <pate at eylerfamily.org> wrote:
>
> > I'm working on an idea in Koha which might fit well with what you're doing ...
> >
> > I've created an engine to extract data from Koha and syndicate it with RSS
> > (0.91).  It's pretty simple, and very extensible.  You can look at it here:
> > http://www.kohalabs.com/rss/  -- for small values of looking at it
>
> Nicolas and Pat, I think your ideas are very exciting, and I hope you don't
> mind me sharing my reply with wider audiences.
>
> Like other people, I believe the present implementations of integrated
> library systems are overly monolithic and represent "black boxes" when it
> comes to interoperability. For a long time I have thought about "rethinking
> the integrated library system." Now these ideas are being expressed in
> forums such as OSS4Lib as well the smaller OCKHAM group:
>
>   http://ockham.library.emory.edu/
>
> In fact, the OCKHAM group has submitted an NSF proposal to address just
> these issues. Only time will tell whether or not the proposal is accepted.
>
> IMHO, there are three technical ways to make things like Koha and MyLibrary
> (as well as other library-related software) work better together:
>
>   1) common application program interfaces (APIs) - APIs center
>      around particular computer programming languages. There are
>      Perl APIs, Java APIs, PHP APIs, etc. This approach is easy to
>      implement if everybody were to agree on the programming
>      language. Not likely. This approach is also prone to operating
>      system dependences. Sort of limiting.
>
>   2) common file formats - The sharing of common file formats has
>      a proven track record. MARC records are an excellent example.
>      The use of one or more XML vocabularies (RSS/RDF, MARCXML, EAD,
>      etc.) represent the more modern and more flexible formats of
>      today. The sharing of common file formats is not dependent on a
>      network as well as opens the door for storing and archiving
>      data/information. Like the written word, common file formats
>      transcend space and time, but they are not necessarily
>      accessible in the here and now.
>
>   3) common network protocols - Common network protocols have
>      made the Web what it is today. None of what we do would be
>      possible without things like DNS, SMTP, FTP, and HTTP. Network
>      protocols are essentially sharing data via conversations
>      between computers taking place at a specific time and a
>      specific place. They are operating system independent and
>      immediate, but utterly dependent on a fragile, ever-present,
>      working Internet connection.
>
> As Nicolas mentions above, network protocol techniques such as Web services
> seem to offer a lot of potential. As Pat demonstrates RSS version 0.91 files
> can be the content shared via a Web Service, such as a SOAP envelope. This
> is very similar to the framework described in the OCKHAM NSF proposal. In
> this proposal a light-weight reference model will be borrowed, modified
> and/or articulated -- essentially an XML vocabulary -- that will be used as
> the common language for sharing data/information between library services
> and modules. These services will then publicize their availability on a
> peer-to-peer network. Other peers (clients) will identify required services
> by first querying the network. Peers will then exchange data/information via
> some sort of Web Service and the XML vocabulary.
>
> Many of the tools necessary to make these ideas a reality already exist such
> as JXTA for the peer-to-peer networking and SOAP for the Web Service.
>
> What we need to do is two things. First we need to enhance our software so
> it can operate as a Web Service. While not necessarily trivial, this process
> is well documented and supported by lot o' API's.
>
> Second, and more importantly, we need to agree on a file format/XML
> vocabulary to encode our data into. This is the hard part. We need to
> borrow, modify, or articulate a data structure that will hold the
> data/information we want to exchange. Based on my knowledge, I advocate
> using RDF. RSS (RDF Site Summary) 1.0 is a particular implementation of RDF:
>
>   RDF Site Summary (RSS) is a lightweight multipurpose extensible
>   metadata description and syndication format. RSS is an XML
>   application, conforms to the W3C's RDF Specification and is
>   extensible via XML-namespace and/or RDF based modularization.
>
>   http://web.resource.org/rss/1.0/
>
> The nicest things about RDF is it extensibility. By defining any number of
> additional XML namespaces, it is possible to encode many types of
> information into a single XML file/stream. For example, it is possible to
> include Dublin Core, RSS, or a made-up namespace (such as a MyLibrary name
> space as I have done) for the purposes of encoding the necessary
> data/information. I've done this in a minor way as illustrated and briefly
> described here:
>
>   http://dewey.library.nd.edu/mylibrary/rdf/
>
> I think the  things outlined above are entirely possible. Again, the hard
> parts would be integrating a Web Service into our applications and agreeing
> on an XML vocabulary. The Web Services are well documented and can be
> implemented through existing program (PHP, Perl, Java, etc.) libraries.  The
> really hard part would be agreeing on the XML vocabulary. This agreement
> will only come after lots o' discussion and communication.
>
> Comments are desired, and what are our next steps?
>

i think there are a couple of things we can do.  First, recognizing that
this is a very forward looking concept, we can continue to try to
interoperate 'the old fashioned way' (through existing library/collection
related tools and protocols).  The Perl ILL conference tomorrow is a good
example of this.

Second, i think we can start to map out some functional areas to start
collaborating on.  As we get the scope laid out, i think it will be easier
to identify the 'low hanging fruit' that we can knock out and start
building from there.

-pate

> --
> Eric Lease Morgan
> Head, Digital Access and Information Architecture Department
> University Libraries of Notre Dame
>
> (574) 631-8604
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/koha-devel
>