I have often thought the same thing that Frances McNamara suggests below. Why can't OCLC simply develop a local holdings module that each library could use to customize their local information.
Rhonda
Colorado State University - Pueblo
-----Original Message-----
From: Next generation catalogs for libraries [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Automatic digest processor
Sent: Tuesday, October 23, 2007 9:04 PM
To: Recipients of NGC4LIB digests
Subject: NGC4LIB Digest - 22 Oct 2007 to 23 Oct 2007 (#2007-227)
There are 9 messages totalling 663 lines in this issue.
Topics of the day:
1. NGLMS4LIB? (8)
2. Inventory of Web OPAC Replacements
----------------------------------------------------------------------
Date: Tue, 23 Oct 2007 10:23:31 -0500
From: Frances Dean McNamara <fdmcnama_at_UCHICAGO.EDU>
Subject: Re: NGLMS4LIB?
I think an alternate suggestion is not to have a cataloging module at
all and to only use OCLC. Why create a standalone cataloging module
when that is what OCLC specializes in?
So, can you have a "disintegrated library system" (DLS instead of ILS?)
where there is no cataloging module, all cataloging is done on OCLC?
Frances McNamara
University of Chicago
-----Original Message-----
From: Next generation catalogs for libraries
[mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Stephens, Owen
Sent: Monday, October 22, 2007 10:39 AM
To: NGC4LIB_at_listserv.nd.edu
Subject: Re: [NGC4LIB] NGLMS4LIB?
Mark wrote
> So why not? I'm not a database guy, but it seems to me that if a
> standard database scheme was created to store all the types of data an
> ILS needed, wouldn't that solve 99% of the problem? Couldn't we tack
> on any company's circ software, assuming it knew how to read and write
> to our database? In terms of what the user wants to accomplish,
> aren't the basic tasks pretty much predictable?
>
I'm not sure you need to go as far as a standard database. Considering
the small number of large LMS suppliers in the market, actually even
building an interface to each one is a minimal amount of work (6 major
systems, 4 major suppliers?) - if only they all had published API to
work with...
In some cases standard APIs already exist. For Circulation SIP2 or NCIP
would surely cover the vast majority of tasks you want to carry out. In
my previous employment we implemented Self Issue using RFID and we were
achieving >90% of loan transactions at the self service machines. These
had their own client s/w which the user interacted with, with the
communication back to the LMS by SIP2.
There might be some circ stuff ('supervisory' functions?) that isn't
covered here, but this should be a minimal number of transactions.
To pick up Mark's example of a cataloguing client, an easy approach
would be simply to create MARC records in a stand alone client that
could then be imported into one or more LMS (solving Mark's problem of
cataloguing over several different LMS systems). As Karen noted, Mark
isn't asking for the world - the stuff he suggests is relatively
straightforward I think. There are questions about where the data comes
from perhaps, but if things such as the Authority files and encoded
field lists could be supplied via a web service, then the client itself
would be quite 'lite'.
Are there any good standalone cataloguing clients already? What are
there drawbacks compared to the LMS? (I guess you lose some workflow
benefits?)
Owen
------------------------------
Date: Tue, 23 Oct 2007 09:39:10 -0600
From: Lynn Reynish <lreynish_at_REGINALIBRARY.CA>
Subject: Re: NGLMS4LIB?
That, of course, presumes that one can afford the fees to belong to OCLC. I've worked with or assisted 29 libraries in my career (school, public, academic and special) and only 2 were able to afford joining OCLC. A standalone client that could act as a front end to both OCLC and the LMS might be a reasonable compromise.
Lynn
---
Lynn Reynish
ILS Librarian
Regina Public Library
lreynish_at_reginalibrary.ca
-----Original Message-----
From: Next generation catalogs for libraries [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Frances Dean McNamara
Sent: Tuesday, October 23, 2007 9:24 AM
To: NGC4LIB_at_listserv.nd.edu
Subject: Re: [NGC4LIB] NGLMS4LIB?
I think an alternate suggestion is not to have a cataloging module at all and to only use OCLC. Why create a standalone cataloging module when that is what OCLC specializes in?
So, can you have a "disintegrated library system" (DLS instead of ILS?) where there is no cataloging module, all cataloging is done on OCLC?
Frances McNamara
University of Chicago
-----Original Message-----
From: Next generation catalogs for libraries [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Stephens, Owen
Sent: Monday, October 22, 2007 10:39 AM
To: NGC4LIB_at_listserv.nd.edu
Subject: Re: [NGC4LIB] NGLMS4LIB?
Mark wrote
> So why not? I'm not a database guy, but it seems to me that if a
> standard database scheme was created to store all the types of data an
> ILS needed, wouldn't that solve 99% of the problem? Couldn't we tack
> on any company's circ software, assuming it knew how to read and write
> to our database? In terms of what the user wants to accomplish,
> aren't the basic tasks pretty much predictable?
>
I'm not sure you need to go as far as a standard database. Considering the small number of large LMS suppliers in the market, actually even building an interface to each one is a minimal amount of work (6 major systems, 4 major suppliers?) - if only they all had published API to work with...
In some cases standard APIs already exist. For Circulation SIP2 or NCIP would surely cover the vast majority of tasks you want to carry out. In my previous employment we implemented Self Issue using RFID and we were achieving >90% of loan transactions at the self service machines. These had their own client s/w which the user interacted with, with the communication back to the LMS by SIP2.
There might be some circ stuff ('supervisory' functions?) that isn't covered here, but this should be a minimal number of transactions.
To pick up Mark's example of a cataloguing client, an easy approach would be simply to create MARC records in a stand alone client that could then be imported into one or more LMS (solving Mark's problem of cataloguing over several different LMS systems). As Karen noted, Mark isn't asking for the world - the stuff he suggests is relatively straightforward I think. There are questions about where the data comes from perhaps, but if things such as the Authority files and encoded field lists could be supplied via a web service, then the client itself would be quite 'lite'.
Are there any good standalone cataloguing clients already? What are there drawbacks compared to the LMS? (I guess you lose some workflow
benefits?)
Owen
------------------------------
Date: Tue, 23 Oct 2007 11:45:02 -0400
From: Mark Sandford <sandfordm1_at_WPUNJ.EDU>
Subject: Re: NGLMS4LIB?
If OCLC can create a client that integrates with my local catalog and
authorities, then I'm all for it. One of the problems I have with all
cataloging modules is that they're tacked on, but not very well
integrated. Can OCLC provide me with auto-completion for locally
created subject headings? Can it automatically check my shelflist to
verify, or better still, assign, cutters?
Since we're speaking about a theoretical new piece of software, then
we can assume that yes, they can do that. They don't currently--at
least not with the level of seamlessness that software is perfectly
capable of providing using current technology and coding practices. I
don't care who creates the software, just that it's integrated
properly, and without regard to what webpac, circ, database, etc,
you're using.
Karen used the term "no brainer" and that's really what all of this
is. Here, I'm being greedy, wanting instant gratification. I don't
want to click three times to get a subject heading, I want it there as
soon as I start typing. Same thing for cutters. As soon as I put in
an LC number, I want the cutter created automatically. Pull the main
entry, check the shelflist, and insert the cutter at the end without
me having to do anything.
The frustrating part here is that this kind of stuff is already taken
for granted in other types of software. In terms of software design,
I'm not asking for anything new or innovative... I just want our
incredibly expensive software to catch up to free webapps that
hobbyists bang out for fun. The hard part--creating a rich database
of values for the software to pick through, along with detailed rules
for how stuff like cutter numbers are created, or punctuation is
assigned--was done decades ago.
--
Mark Sandford
Special Formats Cataloger
William Paterson University
(973)270-2437
sandfordm1_at_wpunj.edu
On 10/23/07, Frances Dean McNamara <fdmcnama_at_uchicago.edu> wrote:
> I think an alternate suggestion is not to have a cataloging module at
> all and to only use OCLC. Why create a standalone cataloging module
> when that is what OCLC specializes in?
>
> So, can you have a "disintegrated library system" (DLS instead of ILS?)
> where there is no cataloging module, all cataloging is done on OCLC?
>
> Frances McNamara
> University of Chicago
>
------------------------------
Date: Tue, 23 Oct 2007 12:18:56 -0400
From: Jonathan Rochkind <rochkind_at_JHU.EDU>
Subject: Re: NGLMS4LIB?
OCLC has to find a fee structure that is viable for smaller libraries
(if you can actually replace some/much of your ILS cost with OCLC, does
that make it more viable? That's a big IF, but that's what this thread
is hoping for). OR, an alternative cooperative to OCLC has to arise
which has a different fee/service model, and works for smaller libraries.
One or the other is absolutely neccesary. In the 21st century, the
success of libraries absolutely depends on the availability of networked
sharing of data and services, and that's the role OCLC is filling. If
smaller libraries don't have access to this, this is a big problem.
Jonathan
Lynn Reynish wrote:
> That, of course, presumes that one can afford the fees to belong to OCLC. I've worked with or assisted 29 libraries in my career (school, public, academic and special) and only 2 were able to afford joining OCLC. A standalone client that could act as a front end to both OCLC and the LMS might be a reasonable compromise.
>
> Lynn
>
>
> ---
> Lynn Reynish
> ILS Librarian
> Regina Public Library
> lreynish_at_reginalibrary.ca
> -----Original Message-----
> From: Next generation catalogs for libraries [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Frances Dean McNamara
> Sent: Tuesday, October 23, 2007 9:24 AM
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] NGLMS4LIB?
>
> I think an alternate suggestion is not to have a cataloging module at all and to only use OCLC. Why create a standalone cataloging module when that is what OCLC specializes in?
>
> So, can you have a "disintegrated library system" (DLS instead of ILS?) where there is no cataloging module, all cataloging is done on OCLC?
>
> Frances McNamara
> University of Chicago
>
> -----Original Message-----
> From: Next generation catalogs for libraries [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Stephens, Owen
> Sent: Monday, October 22, 2007 10:39 AM
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] NGLMS4LIB?
>
> Mark wrote
>
>> So why not? I'm not a database guy, but it seems to me that if a
>> standard database scheme was created to store all the types of data an
>> ILS needed, wouldn't that solve 99% of the problem? Couldn't we tack
>> on any company's circ software, assuming it knew how to read and write
>> to our database? In terms of what the user wants to accomplish,
>> aren't the basic tasks pretty much predictable?
>>
>>
>
> I'm not sure you need to go as far as a standard database. Considering the small number of large LMS suppliers in the market, actually even building an interface to each one is a minimal amount of work (6 major systems, 4 major suppliers?) - if only they all had published API to work with...
>
> In some cases standard APIs already exist. For Circulation SIP2 or NCIP would surely cover the vast majority of tasks you want to carry out. In my previous employment we implemented Self Issue using RFID and we were achieving >90% of loan transactions at the self service machines. These had their own client s/w which the user interacted with, with the communication back to the LMS by SIP2.
>
> There might be some circ stuff ('supervisory' functions?) that isn't covered here, but this should be a minimal number of transactions.
>
> To pick up Mark's example of a cataloguing client, an easy approach would be simply to create MARC records in a stand alone client that could then be imported into one or more LMS (solving Mark's problem of cataloguing over several different LMS systems). As Karen noted, Mark isn't asking for the world - the stuff he suggests is relatively straightforward I think. There are questions about where the data comes from perhaps, but if things such as the Authority files and encoded field lists could be supplied via a web service, then the client itself would be quite 'lite'.
>
> Are there any good standalone cataloguing clients already? What are there drawbacks compared to the LMS? (I guess you lose some workflow
> benefits?)
>
> Owen
>
>
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
------------------------------
Date: Tue, 23 Oct 2007 12:21:16 -0400
From: Jonathan Rochkind <rochkind_at_JHU.EDU>
Subject: Re: NGLMS4LIB?
The fact that most cataloging modules don't automatically create cutter
numbers was astounding to me when I first realized this was the case. I
agree with Mark that this is such a 'no brainer' that it's just
astounding. If nobody has managed to pull off even this simple, easy,
and effective feature---we have to understand what about the market
makes this so, and how to change it, if we hope for even more drastic
improvements--and we do.
Jonathan
Mark Sandford wrote:
> If OCLC can create a client that integrates with my local catalog and
> authorities, then I'm all for it. One of the problems I have with all
> cataloging modules is that they're tacked on, but not very well
> integrated. Can OCLC provide me with auto-completion for locally
> created subject headings? Can it automatically check my shelflist to
> verify, or better still, assign, cutters?
>
> Since we're speaking about a theoretical new piece of software, then
> we can assume that yes, they can do that. They don't currently--at
> least not with the level of seamlessness that software is perfectly
> capable of providing using current technology and coding practices. I
> don't care who creates the software, just that it's integrated
> properly, and without regard to what webpac, circ, database, etc,
> you're using.
>
> Karen used the term "no brainer" and that's really what all of this
> is. Here, I'm being greedy, wanting instant gratification. I don't
> want to click three times to get a subject heading, I want it there as
> soon as I start typing. Same thing for cutters. As soon as I put in
> an LC number, I want the cutter created automatically. Pull the main
> entry, check the shelflist, and insert the cutter at the end without
> me having to do anything.
>
> The frustrating part here is that this kind of stuff is already taken
> for granted in other types of software. In terms of software design,
> I'm not asking for anything new or innovative... I just want our
> incredibly expensive software to catch up to free webapps that
> hobbyists bang out for fun. The hard part--creating a rich database
> of values for the software to pick through, along with detailed rules
> for how stuff like cutter numbers are created, or punctuation is
> assigned--was done decades ago.
>
> --
> Mark Sandford
> Special Formats Cataloger
> William Paterson University
> (973)270-2437
> sandfordm1_at_wpunj.edu
>
>
> On 10/23/07, Frances Dean McNamara <fdmcnama_at_uchicago.edu> wrote:
>
>> I think an alternate suggestion is not to have a cataloging module at
>> all and to only use OCLC. Why create a standalone cataloging module
>> when that is what OCLC specializes in?
>>
>> So, can you have a "disintegrated library system" (DLS instead of ILS?)
>> where there is no cataloging module, all cataloging is done on OCLC?
>>
>> Frances McNamara
>> University of Chicago
>>
>>
>
>
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
------------------------------
Date: Tue, 23 Oct 2007 17:35:26 +0100
From: "Stephens, Owen" <o.stephens_at_IMPERIAL.AC.UK>
Subject: Re: NGLMS4LIB?
To answer your second question first, this is exactly what I hope we can
see happening. Given appropriate interfaces, having a DLS but with
cataloguing done via OCLC (or other 3rd party cataloguing client) is a
possibility that this thread is trying to explore.
To go back to your first question - if OCLC can provide a quality,
affordable cataloguing experience, it may well end up dominating the
market in cataloguing, but if we get to a DLS, then we might see better
products competing to provide this excellent cataloguing. As with the
NGC, where 'Local Worldcat' is competing against traditional OPACs and
new style products like VuFind, Fac-Back-OPAC, Endeca, Primo, Encore,
etc.
What I think Mark has started to do is define some of the 'joins' we
would need to see. As well as those things that are missing from the
current clients, we may also need to think about things that exist in
current clients because they are part of an ILS - these would need to be
replicated in a DLS.
Owen Stephens
Assistant Director: e-Strategy and Information Resources
Imperial College London Library
Imperial College London
South Kensington
London SW7 2AZ
Tel: 020 7594 8829
Email: o.stephens_at_imperial.ac.uk
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Frances Dean McNamara
> Sent: 23 October 2007 16:24
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] NGLMS4LIB?
>
> I think an alternate suggestion is not to have a cataloging module at
> all and to only use OCLC. Why create a standalone cataloging module
> when that is what OCLC specializes in?
>
> So, can you have a "disintegrated library system" (DLS
> instead of ILS?)
> where there is no cataloging module, all cataloging is done on OCLC?
>
> Frances McNamara
> University of Chicago
>
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Stephens, Owen
> Sent: Monday, October 22, 2007 10:39 AM
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] NGLMS4LIB?
>
> Mark wrote
> > So why not? I'm not a database guy, but it seems to me that if a
> > standard database scheme was created to store all the types
> of data an
> > ILS needed, wouldn't that solve 99% of the problem?
> Couldn't we tack
> > on any company's circ software, assuming it knew how to
> read and write
> > to our database? In terms of what the user wants to accomplish,
> > aren't the basic tasks pretty much predictable?
> >
>
> I'm not sure you need to go as far as a standard database. Considering
> the small number of large LMS suppliers in the market, actually even
> building an interface to each one is a minimal amount of work (6 major
> systems, 4 major suppliers?) - if only they all had published API to
> work with...
>
> In some cases standard APIs already exist. For Circulation
> SIP2 or NCIP
> would surely cover the vast majority of tasks you want to
> carry out. In
> my previous employment we implemented Self Issue using RFID
> and we were
> achieving >90% of loan transactions at the self service
> machines. These
> had their own client s/w which the user interacted with, with the
> communication back to the LMS by SIP2.
>
> There might be some circ stuff ('supervisory' functions?) that isn't
> covered here, but this should be a minimal number of transactions.
>
> To pick up Mark's example of a cataloguing client, an easy approach
> would be simply to create MARC records in a stand alone client that
> could then be imported into one or more LMS (solving Mark's problem of
> cataloguing over several different LMS systems). As Karen noted, Mark
> isn't asking for the world - the stuff he suggests is relatively
> straightforward I think. There are questions about where the
> data comes
> from perhaps, but if things such as the Authority files and encoded
> field lists could be supplied via a web service, then the
> client itself
> would be quite 'lite'.
>
> Are there any good standalone cataloguing clients already? What are
> there drawbacks compared to the LMS? (I guess you lose some workflow
> benefits?)
>
> Owen
>
------------------------------
Date: Tue, 23 Oct 2007 14:16:37 -0400
From: Sanbornton Public Library <spl_at_METROCAST.NET>
Subject: Inventory of Web OPAC Replacements
First post from a new subscriber --
As a small rural public library in New Hampshire (2.2 FTE's, budget @
$100k), we're looking to automate for the first time, ideally with a hosted
solution that will minimize the workload/ skill-sets demanded from our "sys
admin" (i.e., me).
Given the costs of full-fledged ILS's from the major vendors, I'm thinking
that it may make sense to go with an open source solution such as Koha,
supported by a third party, with a web OPAC replacement to give us the next
gen features that we'd love to have.
(Koha ZOOM has much of the functionality we'd like, but appears to be
cost-prohibitive at this point.)
I've seen the futurelib wiki (http://futurelib.pbwiki.com/), but it does not
seem to have a comprehensive listing of the ILS-independent "overlay"
products that I'm talking about.
Here are the ones I have heard about so far:
Primo (Ex Libris); http://www.exlibrisgroup.com/primo.htm
AquaBrowser (TLC); http://www.tlcdelivers.com/tlc/pdf/aquabrowser.pdf
VuFind (open source); http://www.vufind.org
Scriblio (Casey Bisson/ Plymouth State U.); http://about.scriblio.net/about
Can folks help me fill in the gaps, and/ or comment on our general approach?
Thanks in advance,
Cab Vinton, Director
Sanbornton Public Library
P.O. Box 88
27 Meetinghouse Hill Rd.
Sanbornton, NH 03269
603-286-8288
spl_at_metrocast.net
------------------------------
Date: Tue, 23 Oct 2007 14:46:13 -0500
From: Jean Harden <JHARDEN_at_LIBRARY.UNT.EDU>
Subject: Re: NGLMS4LIB?
That also presumes that once something is cataloged, it never has to be changed. (Updated authority forms? Changed locations? Typos that you see only after the fact? And so forth.)
--
Jean Harden, Music Catalog Librarian
Libraries
University of North Texas
PO Box 305190
Denton, TX 76203-5190
(940) 565-2860
jharden_at_library.unt.edu
>>> On 10/23/2007 at 10:39 AM, in message
<E42A3F65D4A8114DBD3AA327AF33DF2F1606014F29_at_natasha.rpl.local>, Lynn Reynish
<lreynish_at_REGINALIBRARY.CA> wrote:
> That, of course, presumes that one can afford the fees to belong to OCLC.
> I've worked with or assisted 29 libraries in my career (school, public,
> academic and special) and only 2 were able to afford joining OCLC. A
> standalone client that could act as a front end to both OCLC and the LMS
> might be a reasonable compromise.
>
> Lynn
>
>
> ---
> Lynn Reynish
> ILS Librarian
> Regina Public Library
> lreynish_at_reginalibrary.ca
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Frances Dean McNamara
> Sent: Tuesday, October 23, 2007 9:24 AM
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] NGLMS4LIB?
>
> I think an alternate suggestion is not to have a cataloging module at all
> and to only use OCLC. Why create a standalone cataloging module when that is
> what OCLC specializes in?
>
> So, can you have a "disintegrated library system" (DLS instead of ILS?)
> where there is no cataloging module, all cataloging is done on OCLC?
>
> Frances McNamara
> University of Chicago
>
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Stephens, Owen
> Sent: Monday, October 22, 2007 10:39 AM
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] NGLMS4LIB?
>
> Mark wrote
>> So why not? I'm not a database guy, but it seems to me that if a
>> standard database scheme was created to store all the types of data an
>> ILS needed, wouldn't that solve 99% of the problem? Couldn't we tack
>> on any company's circ software, assuming it knew how to read and write
>> to our database? In terms of what the user wants to accomplish,
>> aren't the basic tasks pretty much predictable?
>>
>
> I'm not sure you need to go as far as a standard database. Considering the
> small number of large LMS suppliers in the market, actually even building an
> interface to each one is a minimal amount of work (6 major systems, 4 major
> suppliers?) - if only they all had published API to work with...
>
> In some cases standard APIs already exist. For Circulation SIP2 or NCIP
> would surely cover the vast majority of tasks you want to carry out. In my
> previous employment we implemented Self Issue using RFID and we were
>achieving >90% of loan transactions at the self service machines. These had
> their own client s/w which the user interacted with, with the communication
> back to the LMS by SIP2.
>
> There might be some circ stuff ('supervisory' functions?) that isn't covered
> here, but this should be a minimal number of transactions.
>
> To pick up Mark's example of a cataloguing client, an easy approach would be
> simply to create MARC records in a stand alone client that could then be
> imported into one or more LMS (solving Mark's problem of cataloguing over
> several different LMS systems). As Karen noted, Mark isn't asking for the
> world - the stuff he suggests is relatively straightforward I think. There are
> questions about where the data comes from perhaps, but if things such as the
> Authority files and encoded field lists could be supplied via a web service,
> then the client itself would be quite 'lite'.
>
> Are there any good standalone cataloguing clients already? What are there
> drawbacks compared to the LMS? (I guess you lose some workflow
> benefits?)
>
> Owen
------------------------------
Date: Tue, 23 Oct 2007 23:20:14 +0100
From: Richard Wallis <richard.wallis_at_TALIS.COM>
Subject: Re: NGLMS4LIB?
Owen Wrote:
> I'm not sure you need to go as far as a standard database. Considering
> the small number of large LMS suppliers in the market, actually even
> building an interface to each one is a minimal amount of work (6 major
> systems, 4 major suppliers?) - if only they all had published API to
> work with...
Ah that Standard API Holy Grail again! You only have to have a view
of the processes behind standards like NCIP to realise that the
chances of the ILS vendor community quickly coming up with a useful
workable open standard API definition that will open up their systems
is virtually zero.
So I am supporting the continuance of the monolithic ILS as the
disintegration problem is insolvable you may think? You know me
better than that - bring on the DLS. But if the Vendors will not
agree a standard way to bring this about, it will be up to others to
do it. I am aware of a few early moves in this area that will
hopefully be a useful SOA contribution - watch this space.
......... from a blog posting 'ILS or DLS that is the question' on
Panlibus about this thread [http://blogs.talis.com/panlibus/archives/
2007/10/ils_or_dls_that.php]
Richard Wallis
Technology Evangelist, Talis
------------------------------
End of NGC4LIB Digest - 22 Oct 2007 to 23 Oct 2007 (#2007-227)
**************************************************************
Received on Wed Oct 24 2007 - 10:44:00 EDT