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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel