Comments on: Response to OpenTranslators post http://federatedsearchblog.com/2008/01/20/response-to-opentranslators-post/ Covers topics in the federated search field. Fri, 08 Aug 2008 19:26:10 +0000 http://wordpress.org/?v=2.3.1 By: aarti http://federatedsearchblog.com/2008/01/20/response-to-opentranslators-post/#comment-1683 aarti Tue, 20 May 2008 07:26:36 +0000 http://federatedsearchblog.com/2008/01/20/response-to-opentranslators-post/#comment-1683 i have the problem in developing a connector for BIOONE in mapping plz do reply..... i have the problem in developing a connector for BIOONE in mapping plz do reply…..

]]> By: Abe Lederman http://federatedsearchblog.com/2008/01/20/response-to-opentranslators-post/#comment-109 Abe Lederman Thu, 24 Jan 2008 04:38:29 +0000 http://federatedsearchblog.com/2008/01/20/response-to-opentranslators-post/#comment-109 I’m really heartened to see the comments that the recent posts on the CARE announcement and the questions raised by Sol have gathered. I hope that in the future this blog does become the place where all of us interested in federated search can come and have a good exchange of ideas. In response to the comment that Sebastian Hammer from IndexData made I want to say that I had a good discussion with one of your colleagues, David Dorman, at ALA and understand that OpenTranslators refers to the translators being accessible through open standard protocols (i.e. Z39.50 and SR/W). We at Deep Web Technologies are big believers in open standards and have built our federated search engine so that it is accessible through standards-based web services. I believe that if IndexData were able to make the connectors themselves available as open source it would do so. At ALA I listened to a good presentation by David Dorman and I’m intrigued by his idea of creating a clearinghouse for connectors that could be shared among federated search vendors. We would welcome a post by David expanding on this concept of his. Let me also say that as Sol indicated in his original post I believe that the CARE announcement is significant and will be overall good for our industry. Finally, I’d like to welcome Peter Noerr to our blog, someone that I met in Santa Fe, not long after he and Kate started MuseGlobal. I find it pretty amazing that two federated search companies were started in Northern New Mexico. I’m really heartened to see the comments that the recent posts on the CARE announcement and the questions raised by Sol have gathered. I hope that in the future this blog does become the place where all of us interested in federated search can come and have a good exchange of ideas.

In response to the comment that Sebastian Hammer from IndexData made I want to say that I had a good discussion with one of your colleagues, David Dorman, at ALA and understand that OpenTranslators refers to the translators being accessible through open standard protocols (i.e. Z39.50 and SR/W). We at Deep Web Technologies are big believers in open standards and have built our federated search engine so that it is accessible through standards-based web services.

I believe that if IndexData were able to make the connectors themselves available as open source it would do so. At ALA I listened to a good presentation by David Dorman and I’m intrigued by his idea of creating a clearinghouse for connectors that could be shared among federated search vendors. We would welcome a post by David expanding on this concept of his.

Let me also say that as Sol indicated in his original post I believe that the CARE announcement is significant and will be overall good for our industry.

Finally, I’d like to welcome Peter Noerr to our blog, someone that I met in Santa Fe, not long after he and Kate started MuseGlobal. I find it pretty amazing that two federated search companies were started in Northern New Mexico.

]]> By: Peter Noerr http://federatedsearchblog.com/2008/01/20/response-to-opentranslators-post/#comment-98 Peter Noerr Tue, 22 Jan 2008 02:31:34 +0000 http://federatedsearchblog.com/2008/01/20/response-to-opentranslators-post/#comment-98 As another of the federated search developers I would like to add to this that I think the service CARE/ID/Webfeat are planning to offer is a very valid one. Even if they are competitors. From years of experience in this industry I appreciate the historical timeline Carl gave, viewing the introduction and evolution of federated search as a way to insulate the user from the vagaries of the interface and search language of the content vendor, then from those of the federated search engine, so that with this sort of service the customer can use a front end system of their choice to provide a user interface of their choice, whether it be "google-like" or an OPAC or a "power searcher" or some other form. This modular, 'plumbing', standards based, architecture does promote an openness of choice for the people who matter - the users. (An aside for those who care about these things; this is another use of the term 'open' to those mentioned by Sebastian. all valid and all part of the modern experience - open choice.) I would like to say that I believe this sort of service will work very well. I feel I can say this with some confidence as we at MuseGlobal have been offering just this division of labor from day one when Muse was launched to the world nearly 7 years ago now. In fact one reason why the Muse name is not well recognised in the federated search world is that all our user interfaces are designed and branded by our partners. So interfaces as diverse as those from III(research pro), SirsiDynix (singlesearch), Swets(Swetssearcher), and Ovid (searchsolver) through to mainstream media products with no user interface at all are possible with this architecture. We welcome this new entrant to the world of the front-middle-back information delivery architecture and wish them well. As another of the federated search developers I would like to add to this that I think the service CARE/ID/Webfeat are planning to offer is a very valid one. Even if they are competitors.

From years of experience in this industry I appreciate the historical timeline Carl gave, viewing the introduction and evolution of federated search as a way to insulate the user from the vagaries of the interface and search language of the content vendor, then from those of the federated search engine, so that with this sort of service the customer can use a front end system of their choice to provide a user interface of their choice, whether it be “google-like” or an OPAC or a “power searcher” or some other form. This modular, ‘plumbing’, standards based, architecture does promote an openness of choice for the people who matter - the users. (An aside for those who care about these things; this is another use of the term ‘open’ to those mentioned by Sebastian. all valid and all part of the modern experience - open choice.)

I would like to say that I believe this sort of service will work very well. I feel I can say this with some confidence as we at MuseGlobal have been offering just this division of labor from day one when Muse was launched to the world nearly 7 years ago now. In fact one reason why the Muse name is not well recognised in the federated search world is that all our user interfaces are designed and branded by our partners. So interfaces as diverse as those from III(research pro), SirsiDynix (singlesearch), Swets(Swetssearcher), and Ovid (searchsolver) through to mainstream media products with no user interface at all are possible with this architecture.

We welcome this new entrant to the world of the front-middle-back information delivery architecture and wish them well.

]]> By: Sebastian Hammer http://federatedsearchblog.com/2008/01/20/response-to-opentranslators-post/#comment-89 Sebastian Hammer Sun, 20 Jan 2008 23:03:09 +0000 http://federatedsearchblog.com/2008/01/20/response-to-opentranslators-post/#comment-89 Actually, in my mind, the 'open' refers both to 'open systems' in the old, revered ISO sense of the word, as software systems that support well-defined, portable interfaces, and 'open standards', generally taken to mean vendor-neutral specifications, again meant to support portability and vendor neutrality. At Index Data, we have based our entire business model upon these concepts for the past 14 years or so, leveraging open source software to support the uptake of open standards and vice versa. To me, these are all pieces of the same puzzle, and the very selfish goal for Index Data is to help foster a dynamic business environment where small companies can compete and play on an even footing (actually often with an advantage) with the older, established companies. I feel quite strongly about this, and one of my biggest regrets is that I didn't find some way to make 'open' a part of our company name when we started. Even as a dedicated open source developer, with more code lines released than many, I find it ridiculous and a little offensive to see the word 'open' co-opted into such a narrow interpretation. Actually, in my mind, the ‘open’ refers both to ‘open systems’ in the old, revered ISO sense of the word, as software systems that support well-defined, portable interfaces, and ‘open standards’, generally taken to mean vendor-neutral specifications, again meant to support portability and vendor neutrality. At Index Data, we have based our entire business model upon these concepts for the past 14 years or so, leveraging open source software to support the uptake of open standards and vice versa. To me, these are all pieces of the same puzzle, and the very selfish goal for Index Data is to help foster a dynamic business environment where small companies can compete and play on an even footing (actually often with an advantage) with the older, established companies. I feel quite strongly about this, and one of my biggest regrets is that I didn’t find some way to make ‘open’ a part of our company name when we started. Even as a dedicated open source developer, with more code lines released than many, I find it ridiculous and a little offensive to see the word ‘open’ co-opted into such a narrow interpretation.

]]>