Re: Whose elephant is it, anyway? (the OLE project)

Agreed. Here's one example:

I would really like my interfaces to be able to take a specific journal 
article citation, and determine if we have a physical print journal 
issue containing that article on our stacks. This is kind of important 
functionality for our users, really!

To do this, I need to find out if we have a specific volume/issue of a 
specific journal in our ILS.  Now our ILS will theoretically tell you 
this, but not in any machine-parseable machine-actionable way. So I 
can't have my software figure this out for someone, I just need to 
present the user with a whole bunch of different holding statements 
notes, and have them figure it out for themselves.

This is an unfortunate example of how lack of proper functionality in 
the 'back end' constrains 'front end' functionality.

Jonathan

Popp, Mary Pagliero wrote:
> That is indeed true for back room functions.  However, those back room functions need to be developed in such a way that they can provide needed data to inform a public interface.   If a public interface calls for certain pieces of information and the back room functions cannot supply that information or  cannot supply it in a way that allows a user interface to incorporate the data, then we have a problem.   
>
> When I taught a library school class on library automation, I spent time talking about the development of library systems because that history is key to understanding current systems.  Throughout the history of the development of automated library systems, the back room activities were the driving factors in development. We started with circulation and added back room cataloging.  But a 21st century ILS system has two purposes--providing information to real people and providing information to maintain the library's processes--and they are both important.  We should be talking about the concepts that underlie both as we move toward consensus for what new systems should be and do.  Catalog data also needs to be made available in such a way that it can be reused in other library products and services, as this list has said on more than one occasion.
>
> I believe we need to specify clearly what data needs to be available to the user interface and how it should be presented to that interface in addition to developing an idea of how the back room data needs to be presented for library technical purposes.   We create a great deal of data in the back room modules that has no use to either librarians or the average user (even if that user is a well-known scholar).  
>
> I think the issues in this argument would be helped if we could come to a consensus on what data needs to be available to the user.  I know the work on the Xtensible Catalog has dealt with this.   Is there anyone on the list who could speak to the ways the XC user interface and the back room processes could come together?
>
> Mary
> -----------------------------------------------
> Mary Pagliero Popp, Public Services Librarian 
> Library Information Technology, 
> Wells Library W501, Indiana University, 
> 1320 E. 10th Street, Bloomington, IN  47405
> popp_at_indiana.edu  812-855-8170   FAX: 812-856-4979
>
>
> -----Original Message-----
> From: Next generation catalogs for libraries [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Sharon Foster
> Sent: Tuesday, March 10, 2009 9:11 PM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] Whose elephant is it, anyway? (the OLE project)
>
> I think it's perfectly appropriate to design back room functions for the people who are going to use them. Whether those modules support the user interfaces depends on how well the interfaces between modules are defined. In conjunction with the design specs, there has to be an interface specification (probably several) defining the external interface that each module presents to the outside world. Then you could...theoretically...some day...select the acquisitions module from one package, the cataloging module from a second package, the serials module from another package, and the OPAC from yet another package, and plug them all together into your own custom ILS.
>
> Sharon M. Foster, 91.7% Librarian
> Speaker-to-Computers
> http://www.vsa-software.com/mlsportfolio/
>
>
>
>
>
>
> On Tue, Mar 10, 2009 at 8:49 PM, B.G. Sloan <bgsloan2_at_yahoo.com> wrote:
>   
>> Jonathan Rochkind mentions the OLE project (http://oleproject.org).
>>
>> I'm encouraged by OLE's stated goal:
>>
>> "The goal is to produce a design document to inform open source library system development efforts, to guide future library system implementations, and to influence current Integrated Library System vendor products."
>>
>> But I get a little nervous when I read that specifying a design for a public user interface is not within the scope of the project.
>>
>> The "project scope" web page says: "The OLE framework supports user and administrative interfaces of various types." Section 4 of this web page lists "Basic ILS Functions". They are all "back room" functions.
>>
>> I think it's maybe a little dangerous to design "back room" functions in isolation, assuming they will support some unspecified "user interfaces of various types".
>>
>> I think it's really great the OLE folks want to improve "back room" systems design, and the open architecture may well will be a boon to those designing user interfaces. But I once again worry that it's a case of library systems being designed BY librarians FOR librarians.
>>
>> Shouldn't the library community take at least some responsibility for designing systems to help library users?
>>
>> Bernie Sloan
>> Sora Associates
>> Bloomington, IN
>>
>> --- On Mon, 3/9/09, Jonathan Rochkind <rochkind_at_JHU.EDU> wrote:
>>
>>     
>>> From: Jonathan Rochkind <rochkind_at_JHU.EDU>
>>> Subject: Re: [NGC4LIB] Whose elephant is it, anyway? : was : Three 
>>> years of NGC4LIB - reflections? -- LONG
>>> To: NGC4LIB_at_LISTSERV.ND.EDU
>>> Date: Monday, March 9, 2009, 10:54 AM Diane I. Hillmann wrote:
>>>       
>>>> It'd be great if we could articulate better what
>>>>         
>>> the backroom will need
>>>       
>>>> in the "new" library, because until we do
>>>>         
>>> that, it's hard to figure out
>>>       
>>>> how the transition can happen.
>>>>
>>>>         
>>> Which of course is the goal of the OLE project, which is why it's 
>>> good that the OLE project is doing what they're doing. It's not an 
>>> easy task, I'm glad someone is tackling it.
>>>
>>> Jonathan
>>>       
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     
>
>