Muse Hybrid FAQ
Muse Hybrid
General
CONTENT_TYPE=Journals;STARTING_YEAR_PUBLICATION=2010;
To use any of the above SPs you need an API key from IEEE, to get it follow the steps below:
1) Register for an account on the IEEE Developer website: https://developer.ieee.org/
2) Apply for an API key.
Once you have the API key you must configure it through the Muse Console for Applications Administration (MCAA) in the “Custom Parameters” section, as value for the API_KEY parameter.Muse has the possibility to control the behavior of searches in cases when queries having unsupported limiters are launched. By unsupported limiter, we mean that one wants to search a source for records between 2 dates, even if the native site does not support this (i.e., does not have this option).
The control is done by means of the of the “Stop If Limiter Not Supported” parameter. It is a property of the Search Module and can be set by:
– logging into the MCAA Muse Console;
– selecting the desired application;
– selecting “Application Modules” from the left panel;
– clicking on the “Search Module” link.
The “Stop If Limiter Not Supported:” field appears along with 2 values that can be set:
– “Stop If Limiter Not Supported:” field on YES – if the limiters are not supported, the search will stop and no records will be retrieved;
– “Stop If Limiter Not Supported:” field on NO – if the limiters are not supported the search will bring results (searching by default without any limiter) with the warning “Unsupported limiter(s): …”
Statistics are logged into special log files by Muse. This statistics data is available into the $ICE_HOME/logs/ICECoreStatistics.log files and are available for the following areas of activity:
– User sessions – for gathering overall usage statistics such as number of sessions logged on, length of sessions, IP addresses of sessions, failed login attempts, etc.
– Muse Instructions – for gathering information about the activities within Muse – searches – including queries, databases searched, parameters used. These may be related to logged-on sessions by session id for analysis per user session.
– Muse Modules – more detailed statistics from individual search source or transaction modules including numbers of hits, time taken for query, download and processing time, etc.
– System information – available and used memory.
There is a dedicated monitoring tool in Muse – Muse Statistics Monitor – which extracts the information from the $ICE_HOME/logs/ICECoreStatistics.log files and present various statistics. Note that the Muse Statistics Monitor is a graphical standalone application. Please refer to the documentation of Muse Statistics Monitor for further information – $MUSE_HOME/monitor/doc/Muse Statistics Monitor.pdf.
When using Muse applications, one has the choice to set “strict” or “loose” limits for the searches. With “strict” limits, Muse returns “Unsupported Query” errors if a Source Package which does not support the selected limit is included, while with the “loose” configuration unsupported limits are dropped.
To set one behavior or another, one must login into MCAA > select application > expand "Application Modules" > click "Search Module" > "Stop If Limiter Not Supported" option.
If there is no proxy defined (Proxy Host field) in either the application level or Source Package level, then no proxy will be used, no matter the other proxy related settings (Proxy Port, Proxy PAC also) from either level.
Secondly, if there are proxy settings both at application level and at the Source Package level, then the Source Package ones will have priority over the application level ones.
A Source Package can be added only once in each source group defined in an application. The Source Package name cannot be different – it will have the same name in all the groups it belongs to.
Although ANSI/NISO Z39.50 is a standard for common search and retrieval, it is implemented differently and in different versions by various commercial library catalog software vendors. For this reason MuseGlobal has several vendor/product-specific Source Packages (SPs) all based on the common Z39.50 protocols. These vendor or product-specific SPs are customized to accommodate specific data and query syntaxes maintained by different Z39.50 servers. These Source Packages come with multiple copies so you can use two or more in a single application by simply filling in the necessary profile values for your target server.
In all cases, you should use the Z39.50 Source Package most specific to the vendor or product. For example, to profile a Millennium catalog, you should use the INNOPACZ_0001 Source Package because Millennium and InnoPac both are products with Z39.50 servers from the same vendor. To profile a Voyager catalog, use the Voyager Z39.50 Source Package.
Additionally, there are some specific, but widely known Z39.50 servers. For example, we created the LOCZ (Library of Congress Z39.50 connector) specifically for the Library of Congress’ catalog. So, even though that library currently uses a Voyager catalog system, you should use the more specific LOCZ SP for this catalog.
There is a generic Z39.50 source known simply as Z3950. Generally, this is a “template”. It may work on any given Z39.50 server, but it does not have any specific mapping files for query or data. Even in cases where you get a successful connection or search using this, there may be a data mapping or other problems you are not aware of. This should only be tried if there is not a specific vendor or catalog Z39.50 package available. The better course is to order a new Source Package from MuseGlobal when you need to profile a Z39.50 server which does not already have a working vendor/product-specific SP.
Below is a list of currently available Source Package IDs for commonly used Z39.50 Servers currently available via Source ID in Source Factory:
ALEPH500Z
DynixClassicZ
Horizon73Z
INNOPACZ
SoftlinkZ
UnicornZ
VoyagerZ
VTLSZ
Keep in mind that most of these SPs have several “clones” available in the Source Factory. For example, you’ll find ALEPH500Z_0001, ALEPH500Z_0002, ALEPH500Z_0003, . . . ALEPH500Z_0010. This is in cases where you need to profile more than one catalog using the same Source Package in the same application.
A certificate is a binary file which provides certain information about that site. Such certificates are signed by authorities.
To save a SSL certificate one must follow the below steps:
– using the Internet Explorer browser navigate to site address;
– select File/Properties, and on the General tab select Certificates;
– a window will appear from which select the Details tab;
– in the next step click the Copy to File button (this will open a wizard to be used to export the certificate of the site);
– when prompted for export file format please choose DER encoded binary format;
– specify the name and the location of the certificate to be saved, press Next and then Finish.
This a known/intermittent behavior of some old browsers, like Internet Explorer 6.
By default, Muse HTTP Server closes client sockets as soon as it finishes sending out the response, in order to recycle sockets as soon as possible. However, there are some problems with certain browsers (like IE6) that send data after the socket was closed by the server. Since the socket was already closed by the server, the browser displays the “The page cannot be displayed” error instantly.
To work around this, Muse Http Server was adapted to wait a configurable amount of time after sending all the data back to the browser and before closing the socket. This amount of time is configurable through thesocketCloseDelay parameter for the desired Connector in ${MUSE_HOME}/http/conf/contexts.xml file. The value for socketCloseDelay parameter is specified in milliseconds.
Note: This value represents the time that the server waits before closing down the socket to the client. Setting a too high value for this parameter can degrade performance of the Muse Http Server. In general, this value should never be set higher than 100 milliseconds.
To activate the socket close delay for Muse HTTP Server please follow the next steps:
1. Stop the Muse HTTP Server;
2. Edit the "${MUSE_HOME}/http/conf/contexts.xml" file and add the following line:
after the lines (port 8000 below can be any port that Muse HTTP Server was set to run on):
3. start the Muse HTTP Server.
If the problem still persists, a tunning is necessary till a proper value is found (please consider the note above):
1. Shutdown the Muse HTTP Server;
2. Change the value of the “socketCloseDelay” parameter;
3. Start the Muse HTTP Server;
4. Run new tests.
We now provide generic template Source Packages for NewsBank’s Access World News product, to take full advantage of its flexibility.
*** NOTE: The “America’s Newspapers” database is different than “Access World News”. We already have a dedicated source package for the “America’s Newspapers” database: the NewsBankFTN SP.
The fields that need to be configured via the console for these SPs are:
USER_NAME
USER_PASSWORD
DATABASE_NAME
PROXY_HOST (if applicable)
PROXY_PORT (if applicable)
CUSTOM_PARAMETERS
Please note that are 4 possibilities to configure the NewsBankAWN generic Source Packages:
——————————————————-
1. Search on the entire “Access World News” database:
The NewsBankAWN generic Source Package offers the possibility to search the entire database (the “Access World News” database has the code = AWNB).
*** NOTE: This is equivalent to using the non-generic NewsBankAWN SP.
Example:
http://infoweb.newsbank.com/?p_product=AWNB
Access World News
To search on the entire database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that the CUSTOM_PARAMETERS tag should have empty parameters as you can see below:
——————————————————-
2. Search the entire “America’s News Magazines” sub-database (the “America’s News Magazines” is a sub-database of the “Access World News” database) :
Example:
http://infoweb.newsbank.com/?p_product=AWNB&d_custom=AMNP
America's News Magazines (AMNP)
Access World News >> America’s News Magazines
To search the entire “America’s News Magazines” sub-database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that the CUSTOM_PARAMETERS tag should have empty parameters as you can see below :
——————————————————-
3. Search the regions and journals desired from the “Access World News” database:
The JOURNALS parameter will be filled with the codes of the needed journals separated with commas (“,”), see for example a few journal codes below:
– The Advertizer (from New South Wales) has the code: ZANA.
– Bath Chronicle – has the code:ZNCAB
– Mail Tribune – has the code: ZMEK, etc.
You can determine the code of a needed publication viewing the source of the page with the list of journals and seeing the value assigned to its corresponding checkbox.
If the JOURNALS parameter is null, the connector will search all the journals available in the subscription.
The REGIONS parameter would contain one or more of the following (separated with commas):
* Continents
– Africa
– Asia
– Australia/Oceania
– Europe/UK
– Middle East
– North America
– South America
* Country name
* State postal code or province name
The REGIONS value corresponds to the d_loc parameter of the URL when browsing NewsBank’s locations hierarchy.
REGIONS Example 1 = North America
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=North America&d_place=&f_view=loc&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
REGIONS Example 2 = United States
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=United States&d_place=&f_view=loc&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
REGIONS Example 3 = California
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=CA&d_place=&f_view=src&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
If the REGIONS parameter is left blank the connector will search all regions.
Example of use:
Example:
http://infoweb.newsbank.com/?db=WPIW
Washington Post, The (WPIW)
Access World News – North America » United States » DC
To search the regions and journals desired from the “Access World News” database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that you can search:
– only on one or more regions :
– only on one or more journals :
– on one or more regions and one or more journals at the same time:
——————————————————-
4. Search the desired regions and journals from the “America’s News Magazines” sub-database:
Example:
http://infoweb.newsbank.com/?db=BTKB
Baby Talk (BTKB)
Access World News – North America » United States » Baby Talk
To search the desired regions and journals from the “America’s News Magazines” sub-database you should have configured the NewsBankAWN generic profile with the following tag values:
Also please note that you can search:
– only on one region :
– only on one or more journals :
– on one region and one or more journals at the same time:
——————————————————-
The message “Global InfoBase error: UnknownHostException:factory.museglobal.com” clearly states that the factory.museglobal.com host cannot be solved by the DNS servers configured on the Muse server.
This is not a Muse problem, but a network/server configuration issue. This may lead to other side efects, like populating the Status values of the Source Packages with “Not working” values.
Why am I obtaining different results in two cosecutive for the same search on same Source Packages?
This a normal behavior considering how Muse works and how different sites on Internet respond to consecutive searches.
A search performed in a Muse application starts at the ICE server level a number of connectors, each working on a native data service. Each such connector, as it searches the native data service and obtains records, sends these records to ICE which further sends records to the Muse application to be displayed.
So, the records come and are displayed in the Muse application www interface in the order in which they are received from the native sites and parsed. From one search to another the native sites might have different speeds of response and also the order in which the connectors are launched and run into execution may differ because they are run in parallel as threads.
Considering this, it is possible that at a second search performed in a Muse application, using the same term and on the same sources, to show records in different order.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
– $APPLICATION_HOME/www/application/searchOptions.db file and/or the
– $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml file there are 2 fields that control the maximum sessions:
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS value. Also, when changing the value of MAX_CONCURRENT_SESSIONS one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS value set in the $ICE_HOME/ICECore.xml file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
The Group ID may contain alphabetic, numeric or underscore characters. The first character in an Group ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
Note: A Group ID cannot match any Source ID in the same application.
Elsevier does not permit HTTP access to their resources through federated search products. For federated search Elsevier provides specialized APIs for which we have the following Source Packages: ScienceDirectRESTXML, ScienceDirectRESTXMLBooks, ScienceDirectRESTXMLJournals and ScopusRESTXML.
Arrangements with Elsevier for this access must be handled by you (the partner), or by your customer, following the steps below:
Install Procedure:
1. You (the partner) or your customer must contact the Elsevier E-Helpdesk (for APAC: sginfo@elsevier.com) and tell helpdesk that MuseGlobal federated search or API needs to be enabled.
2. Helpdesk will be able to find the customer’s account (based on C* numbers), API key based on name (MuseGlobal) and generate appropriate instTokens.
3. Confirm with the representative that they have enabled the MuseGlobal federated search or API (not a different federated search product).
4. After Elsevier staff has enabled access for the customer, they will report this back to the customer or to you, the vendor, and will disclose the appropriate instTokens to the customer.
5. Using the Muse Source Console, upload appropriate the ScopusRESTXML or the ScienceDirectRESTXML Source Packages, as covered by your subscription.
6. Configure the Source Package(s), making sure to fill the API_KEY, INST_TOKEN parameters from “Custom Parameters:” at bottom of the page with the two instTokens provided by Elsevier. Contact Muse Support if this is not the case.
7. Test the Source Package while in the Console.
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights
The MNM entries are set:
A) at individual Source Package level
B) at the Application level
To stop the rewriting for a Source Package, one must:
A) Remove the MNM entries at individual Source Package level
The MNM entries can be removed from the individual Source Package level through the Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button next to the Source Package to be edited
– the value for MNM entered in the “Link URLs” field must be empty
B) Removing additional MNM entries from Application level
The MNM entries can be removed from Application level using Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “General Settings” section
– go to “Navigation Management” section
– the value for the MNM at the Application level in the “Link URLs” field sould be empty, or that particular Source Package moved to the exclude section.
Note*: The MNM entries at the Application level are additional to the ones for individual Source Package level. So for each Source Package the the MNM entries set up for that Source Package plus the MNM entries set up at application level (A + B above) will be used.
Note**: in old Muse systems use for rewriting purposes the settings found in ${MUSE_HOME}/web/Users.properties. This method is obsolete now, so all the entries inside it of the form “application_id.navigationManagerMode” should be set to “none” (application_id.navigationManagerMode=none). This operation must be done after the values set here were merged with the ones from application level (see point B above).
Follow these steps to save the list of licensed Source Packages (SPs):
– Login to Source Factory, then go to “Source Factory” > “Source Packages List”;
– Select “All” from “Per Page” drop down from the top right page. This will take a few minutes while it builds a list of several thousand Source IDs;
– Perform a search using no specific keywords but by selecting “Released” (instead of “All Values”) as your search criteria in the “Production Status” drop down near the bottom of the page. This search will result in a display of released SPs. This will take a few minutes while it builds a list of several thousand Source IDs;
– When the Source Package list is complete go to the top right hand side of the list. A button labeled “Export to CSV” is displayed. Select this option, let the export run, and then format the report as needed
If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.
First check the following:
– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.
– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).
– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.
In cases where the target site is working but the communication is slow for some reason the solution is to increase the
If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See FAQ “Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?”
If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.First check the following:
– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.
– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).
– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.
In cases where the target site is working but the communication is slow for some reason the solution is to increase the
If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?
We unify all the information from all the sources into Unicode using UTF-8, and we pass it from ICE and all of our Bridges as UTF-8 and XML-encoded entities. However, we are not limited to extracting data just from UTF-8 bytes, and we should not extract bytes as UTF-8 when it is not appropriate. All our extraction in Muse is to UTF-8 but from a wide range of encodings (including UTF-8).
We accommodate this large number of encodings, detailed in the documentation, when we extract data; only then is it converted into Unicode (with UTF-8 encoding) on our side.
The MNM entries can be set:
A) at the individual Source Package level
B) additional MNM entries can be set at the Application level
A) Setting MNM entries at the individual Source Package level:
The MNM entries can be set at individual Source Package level using the Muse Source Console (MSC) as follows:
– login into the MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button near the Source Package in the list that is to be edited
– the value for MNM must be entered in the “Link URLs” field
B) Setting additional MNM entries at application level
The MNM entries can be set at the Application level using the Muse Source Console (MSC) as follows:
– login into the MSC
– select an Application using the radio button
– select the “General Settings” section
– go to “Navigation Management” section
– the value for the MNM at the Application level must be entered in the “Link URLs” field
Note*: The MNM entries at the Application level are additional to the ones set for individual Source Package level. So for a Source Package the MNM entries set up for that Source Package plus the MNM entries set up at Application level (A + B above) will be used.
Note**: The MNM entries at the Application level are usually used when many sources at the Application level are using a WAM (Web Access Management) software such as ezProxy as this provides a way to add a MNM entry that is to be used by multiple sources. Except in the case of WAM software it is not recommended that MNM entries be set at the Application level.
There are two parameters involved here:
CONNECT_TIME_OUT: specifies the timeout value, in milliseconds, to be used when opening the communication link for each resource (e.g. URL) used by this source.READ_TIME_OUT: specifies the timeout value, in milliseconds, that is involved upon reading on the communication channels.
One can increase the timeout for a given Source Package by increasing the value in the CONNECT_TIME_OUT and READ_TIME_OUT fields (the entry is in milliseconds; 1,000 milliseconds = 1 second). To edit these fields of the source profile one must use the Muse Source Console:
- login into the Muse Source Console
- select the desired application from the list of applications
- go to the “Configure” tab
- click on the “Modify” button for the desired source
- update the “Connect Time Out” and “Read Time Out” inputs with the desired values
- to submit the modifications click on the “Update” button
Note: The values for the “Connect Time Out” and “Read Time Out” fields must be given in milliseconds.
Muse source packages, by default, return only the metadata found in the native source’s list of results. The Ex functionality of a source means that when a search is performed on that source from the Muse interface the information brought back for each record includes information that normally can be found when the link to that record in the native web interface is accessed from the results list.
If this functionality is desired, then the USE_EX_PARSER field from the SP profile must be “yes”(no quotes).
Example:
Please note that even if the source is free and the Ex functionlaity is desired, this field must be filled with “yes”. By default, this field is set to “no”. So such a connector will behave normally if the USE_EX_PARSER field from the profile is missing or has the “no” value, and will have an extended parsing if the USE_EX_PARSER field from the profile has the “yes” value.
The .cpb file describes the search capabilities of a source. The .pmf is the pre-mapping file that allows administrators to map search/index attributes that apply before the Muse ISR stylesheet is used to format the search for the source (thus “Pre”-mapping).
The .cpb file lists all the search indexes and Boolean operators which are supported by the Source (whatever the actual, native syntax of the attribute). It is also a place where other source capabilities could be added later for easy import into the Muse InfoBase. The search limiter sets are one example.
The .pmf file provides a mapping from one attribute in ISR to one attribute in translator. The .pmf mapping is TO an attribute which is handled into the ISR translator. All of the attributes handled (supported) in the ISR translator have been automatically extracted and recorded into the appropriate section in .cpb file.
By default, the PMF files map unsupported attributes to keyword.
MuseGlobal provides the following method for search and retrieval of EBSCOhost content: EBSCO Integration Toolkit (EIT)
This is a SOAP-based Web Service approach which provides the optimal combination of performance and completeness. You can find the EIT Source Packages by searching in your Muse Console’s “Add Sources” section in the “IDs Containing” field for the term EIT. EIT SPs have Source IDs which start with the string EBSCOEIT.
URLs:
The HTTP Source Packages for EBSCO search on the URL
http://search.ebscohost.com/. The EIT Source Packages use
http://eit.ebscohost.com/Services/SearchService.asmx as the Home URL and Search URL.
AUTHENTICATION:
Authentication for the EBSCOEIT Source Packages is two-fold.
1) Authentication for search and retrieval can done by user/pw (with the USER_NAME and USER_PASSWORD fields of the profile) or IP (with the CUSTOM_PARAMETERS field of the profile).
For search/retrieval authentication by IP, a value must be placed in the CUSTOM_PARAMETERS tag from the EBSCOEIT* source profile. Again, this is used to connect to and search a certain database. Using this IP authentication, you may be authenticated to a number of databases.
Example :
where : IP_ADDRESS=your IP which authenticates to EIT.
Please note that your EBSCO account must be specifically enabled in order to use of EIT. The user/pw used for connecting to http://search.ebscohost.com/ will not work for EIT. Also note that the IP_PROFILE will be either eit or eitws; — this string matches the 3rd section of your 3-part EIT authentication string (ex. s123456.main.eit or s123456.main.eitws). Please check with EBSCO if you are not sure which it is.
2) The aforementioned authentication by IP or user/pw gives us access to the EBSCOEIT API, but it does not provide successful link navigation on the record links obtained.
For this, the PROXY_HOST and PROXY_PORT in the profile must be configured. IMPORTANT: authentication to EBSCO for link navigation is only done by IP.
Example :
So, in conclusion, 2 IP authentication settings are needed: one (user/pw or IP) for accessing and searching the EBSCOEIT database desired and the other one (proxy IP) to successfully navigate on the record links obtained.
Questions about your EIT account status should be referred to Gregory Julien [GregoryJulien@ebscohost.com].
Load More
For searching IEEE content we provide Source Packages based on API, currently two are available for download in Muse Source Factory:
1) IEEEXploreAPIXML. This is a generic Source Package retrieving content without any filtering.
2) IEEEASPPXploreAPIXML. This is a Source Package specifically built to retrieve content from IEEE All-Society Periodicals Package. More exactly it has pre-configured the following filters:
CONTENT_TYPE=Journals;STARTING_YEAR_PUBLICATION=2010;
To use any of the above SPs you need an API key from IEEE, to get it follow the steps below:
1) Register for an account on the IEEE Developer website: https://developer.ieee.org/
2) Apply for an API key.
Once you have the API key you must configure it through the Muse Console for Applications Administration (MCAA) in the “Custom Parameters” section, as value for the API_KEY parameter.
Muse has the possibility to control the behavior of searches in cases when queries having unsupported limiters are launched. By unsupported limiter, we mean that one wants to search a source for records between 2 dates, even if the native site does not support this (i.e., does not have this option).
The control is done by means of the of the “Stop If Limiter Not Supported” parameter. It is a property of the Search Module and can be set by:
– logging into the MCAA Muse Console;
– selecting the desired application;
– selecting “Application Modules” from the left panel;
– clicking on the “Search Module” link.
The “Stop If Limiter Not Supported:” field appears along with 2 values that can be set:
– “Stop If Limiter Not Supported:” field on YES – if the limiters are not supported, the search will stop and no records will be retrieved;
– “Stop If Limiter Not Supported:” field on NO – if the limiters are not supported the search will bring results (searching by default without any limiter) with the warning “Unsupported limiter(s): …”
Statistics are logged into special log files by Muse. This statistics data is available into the $ICE_HOME/logs/ICECoreStatistics.log files and are available for the following areas of activity:
– User sessions – for gathering overall usage statistics such as number of sessions logged on, length of sessions, IP addresses of sessions, failed login attempts, etc.
– Muse Instructions – for gathering information about the activities within Muse – searches – including queries, databases searched, parameters used. These may be related to logged-on sessions by session id for analysis per user session.
– Muse Modules – more detailed statistics from individual search source or transaction modules including numbers of hits, time taken for query, download and processing time, etc.
– System information – available and used memory.
There is a dedicated monitoring tool in Muse – Muse Statistics Monitor – which extracts the information from the $ICE_HOME/logs/ICECoreStatistics.log files and present various statistics. Note that the Muse Statistics Monitor is a graphical standalone application. Please refer to the documentation of Muse Statistics Monitor for further information – $MUSE_HOME/monitor/doc/Muse Statistics Monitor.pdf.
When using Muse applications, one has the choice to set “strict” or “loose” limits for the searches. With “strict” limits, Muse returns “Unsupported Query” errors if a Source Package which does not support the selected limit is included, while with the “loose” configuration unsupported limits are dropped.
To set one behavior or another, one must login into MCAA > select application > expand "Application Modules" > click "Search Module" > "Stop If Limiter Not Supported" option.
If there is no proxy defined (Proxy Host field) in either the application level or Source Package level, then no proxy will be used, no matter the other proxy related settings (Proxy Port, Proxy PAC also) from either level.
Secondly, if there are proxy settings both at application level and at the Source Package level, then the Source Package ones will have priority over the application level ones.
A Source Package can be added only once in each source group defined in an application. The Source Package name cannot be different – it will have the same name in all the groups it belongs to.
Although ANSI/NISO Z39.50 is a standard for common search and retrieval, it is implemented differently and in different versions by various commercial library catalog software vendors. For this reason MuseGlobal has several vendor/product-specific Source Packages (SPs) all based on the common Z39.50 protocols. These vendor or product-specific SPs are customized to accommodate specific data and query syntaxes maintained by different Z39.50 servers. These Source Packages come with multiple copies so you can use two or more in a single application by simply filling in the necessary profile values for your target server.
In all cases, you should use the Z39.50 Source Package most specific to the vendor or product. For example, to profile a Millennium catalog, you should use the INNOPACZ_0001 Source Package because Millennium and InnoPac both are products with Z39.50 servers from the same vendor. To profile a Voyager catalog, use the Voyager Z39.50 Source Package.
Additionally, there are some specific, but widely known Z39.50 servers. For example, we created the LOCZ (Library of Congress Z39.50 connector) specifically for the Library of Congress’ catalog. So, even though that library currently uses a Voyager catalog system, you should use the more specific LOCZ SP for this catalog.
There is a generic Z39.50 source known simply as Z3950. Generally, this is a “template”. It may work on any given Z39.50 server, but it does not have any specific mapping files for query or data. Even in cases where you get a successful connection or search using this, there may be a data mapping or other problems you are not aware of. This should only be tried if there is not a specific vendor or catalog Z39.50 package available. The better course is to order a new Source Package from MuseGlobal when you need to profile a Z39.50 server which does not already have a working vendor/product-specific SP.
Below is a list of currently available Source Package IDs for commonly used Z39.50 Servers currently available via Source ID in Source Factory:
ALEPH500Z
DynixClassicZ
Horizon73Z
INNOPACZ
SoftlinkZ
UnicornZ
VoyagerZ
VTLSZ
Keep in mind that most of these SPs have several “clones” available in the Source Factory. For example, you’ll find ALEPH500Z_0001, ALEPH500Z_0002, ALEPH500Z_0003, . . . ALEPH500Z_0010. This is in cases where you need to profile more than one catalog using the same Source Package in the same application.
A certificate is a binary file which provides certain information about that site. Such certificates are signed by authorities.
To save a SSL certificate one must follow the below steps:
– using the Internet Explorer browser navigate to site address;
– select File/Properties, and on the General tab select Certificates;
– a window will appear from which select the Details tab;
– in the next step click the Copy to File button (this will open a wizard to be used to export the certificate of the site);
– when prompted for export file format please choose DER encoded binary format;
– specify the name and the location of the certificate to be saved, press Next and then Finish.
This a known/intermittent behavior of some old browsers, like Internet Explorer 6.
By default, Muse HTTP Server closes client sockets as soon as it finishes sending out the response, in order to recycle sockets as soon as possible. However, there are some problems with certain browsers (like IE6) that send data after the socket was closed by the server. Since the socket was already closed by the server, the browser displays the “The page cannot be displayed” error instantly.
To work around this, Muse Http Server was adapted to wait a configurable amount of time after sending all the data back to the browser and before closing the socket. This amount of time is configurable through thesocketCloseDelay parameter for the desired Connector in ${MUSE_HOME}/http/conf/contexts.xml file. The value for socketCloseDelay parameter is specified in milliseconds.
Note: This value represents the time that the server waits before closing down the socket to the client. Setting a too high value for this parameter can degrade performance of the Muse Http Server. In general, this value should never be set higher than 100 milliseconds.
To activate the socket close delay for Muse HTTP Server please follow the next steps:
1. Stop the Muse HTTP Server;
2. Edit the "${MUSE_HOME}/http/conf/contexts.xml" file and add the following line:
after the lines (port 8000 below can be any port that Muse HTTP Server was set to run on):
3. start the Muse HTTP Server.
If the problem still persists, a tunning is necessary till a proper value is found (please consider the note above):
1. Shutdown the Muse HTTP Server;
2. Change the value of the “socketCloseDelay” parameter;
3. Start the Muse HTTP Server;
4. Run new tests.
We now provide generic template Source Packages for NewsBank’s Access World News product, to take full advantage of its flexibility.
*** NOTE: The “America’s Newspapers” database is different than “Access World News”. We already have a dedicated source package for the “America’s Newspapers” database: the NewsBankFTN SP.
The fields that need to be configured via the console for these SPs are:
USER_NAME
USER_PASSWORD
DATABASE_NAME
PROXY_HOST (if applicable)
PROXY_PORT (if applicable)
CUSTOM_PARAMETERS
Please note that are 4 possibilities to configure the NewsBankAWN generic Source Packages:
——————————————————-
1. Search on the entire “Access World News” database:
The NewsBankAWN generic Source Package offers the possibility to search the entire database (the “Access World News” database has the code = AWNB).
*** NOTE: This is equivalent to using the non-generic NewsBankAWN SP.
Example:
http://infoweb.newsbank.com/?p_product=AWNB
Access World News
To search on the entire database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that the CUSTOM_PARAMETERS tag should have empty parameters as you can see below:
——————————————————-
2. Search the entire “America’s News Magazines” sub-database (the “America’s News Magazines” is a sub-database of the “Access World News” database) :
Example:
http://infoweb.newsbank.com/?p_product=AWNB&d_custom=AMNP
America's News Magazines (AMNP)
Access World News >> America’s News Magazines
To search the entire “America’s News Magazines” sub-database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that the CUSTOM_PARAMETERS tag should have empty parameters as you can see below :
——————————————————-
3. Search the regions and journals desired from the “Access World News” database:
The JOURNALS parameter will be filled with the codes of the needed journals separated with commas (“,”), see for example a few journal codes below:
– The Advertizer (from New South Wales) has the code: ZANA.
– Bath Chronicle – has the code:ZNCAB
– Mail Tribune – has the code: ZMEK, etc.
You can determine the code of a needed publication viewing the source of the page with the list of journals and seeing the value assigned to its corresponding checkbox.
If the JOURNALS parameter is null, the connector will search all the journals available in the subscription.
The REGIONS parameter would contain one or more of the following (separated with commas):
* Continents
– Africa
– Asia
– Australia/Oceania
– Europe/UK
– Middle East
– North America
– South America
* Country name
* State postal code or province name
The REGIONS value corresponds to the d_loc parameter of the URL when browsing NewsBank’s locations hierarchy.
REGIONS Example 1 = North America
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=North America&d_place=&f_view=loc&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
REGIONS Example 2 = United States
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=United States&d_place=&f_view=loc&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
REGIONS Example 3 = California
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=CA&d_place=&f_view=src&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
If the REGIONS parameter is left blank the connector will search all regions.
Example of use:
Example:
http://infoweb.newsbank.com/?db=WPIW
Washington Post, The (WPIW)
Access World News – North America » United States » DC
To search the regions and journals desired from the “Access World News” database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that you can search:
– only on one or more regions :
– only on one or more journals :
– on one or more regions and one or more journals at the same time:
——————————————————-
4. Search the desired regions and journals from the “America’s News Magazines” sub-database:
Example:
http://infoweb.newsbank.com/?db=BTKB
Baby Talk (BTKB)
Access World News – North America » United States » Baby Talk
To search the desired regions and journals from the “America’s News Magazines” sub-database you should have configured the NewsBankAWN generic profile with the following tag values:
Also please note that you can search:
– only on one region :
– only on one or more journals :
– on one region and one or more journals at the same time:
——————————————————-
The message “Global InfoBase error: UnknownHostException:factory.museglobal.com” clearly states that the factory.museglobal.com host cannot be solved by the DNS servers configured on the Muse server.
This is not a Muse problem, but a network/server configuration issue. This may lead to other side efects, like populating the Status values of the Source Packages with “Not working” values.
Why am I obtaining different results in two cosecutive for the same search on same Source Packages?
This a normal behavior considering how Muse works and how different sites on Internet respond to consecutive searches.
A search performed in a Muse application starts at the ICE server level a number of connectors, each working on a native data service. Each such connector, as it searches the native data service and obtains records, sends these records to ICE which further sends records to the Muse application to be displayed.
So, the records come and are displayed in the Muse application www interface in the order in which they are received from the native sites and parsed. From one search to another the native sites might have different speeds of response and also the order in which the connectors are launched and run into execution may differ because they are run in parallel as threads.
Considering this, it is possible that at a second search performed in a Muse application, using the same term and on the same sources, to show records in different order.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
– $APPLICATION_HOME/www/application/searchOptions.db file and/or the
– $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml file there are 2 fields that control the maximum sessions:
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS value. Also, when changing the value of MAX_CONCURRENT_SESSIONS one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS value set in the $ICE_HOME/ICECore.xml file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
The Group ID may contain alphabetic, numeric or underscore characters. The first character in an Group ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
Note: A Group ID cannot match any Source ID in the same application.
Elsevier does not permit HTTP access to their resources through federated search products. For federated search Elsevier provides specialized APIs for which we have the following Source Packages: ScienceDirectRESTXML, ScienceDirectRESTXMLBooks, ScienceDirectRESTXMLJournals and ScopusRESTXML.
Arrangements with Elsevier for this access must be handled by you (the partner), or by your customer, following the steps below:
Install Procedure:
1. You (the partner) or your customer must contact the Elsevier E-Helpdesk (for APAC: sginfo@elsevier.com) and tell helpdesk that MuseGlobal federated search or API needs to be enabled.
2. Helpdesk will be able to find the customer’s account (based on C* numbers), API key based on name (MuseGlobal) and generate appropriate instTokens.
3. Confirm with the representative that they have enabled the MuseGlobal federated search or API (not a different federated search product).
4. After Elsevier staff has enabled access for the customer, they will report this back to the customer or to you, the vendor, and will disclose the appropriate instTokens to the customer.
5. Using the Muse Source Console, upload appropriate the ScopusRESTXML or the ScienceDirectRESTXML Source Packages, as covered by your subscription.
6. Configure the Source Package(s), making sure to fill the API_KEY, INST_TOKEN parameters from “Custom Parameters:” at bottom of the page with the two instTokens provided by Elsevier. Contact Muse Support if this is not the case.
7. Test the Source Package while in the Console.
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights
The MNM entries are set:
A) at individual Source Package level
B) at the Application level
To stop the rewriting for a Source Package, one must:
A) Remove the MNM entries at individual Source Package level
The MNM entries can be removed from the individual Source Package level through the Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button next to the Source Package to be edited
– the value for MNM entered in the “Link URLs” field must be empty
B) Removing additional MNM entries from Application level
The MNM entries can be removed from Application level using Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “General Settings” section
– go to “Navigation Management” section
– the value for the MNM at the Application level in the “Link URLs” field sould be empty, or that particular Source Package moved to the exclude section.
Note*: The MNM entries at the Application level are additional to the ones for individual Source Package level. So for each Source Package the the MNM entries set up for that Source Package plus the MNM entries set up at application level (A + B above) will be used.
Note**: in old Muse systems use for rewriting purposes the settings found in ${MUSE_HOME}/web/Users.properties. This method is obsolete now, so all the entries inside it of the form “application_id.navigationManagerMode” should be set to “none” (application_id.navigationManagerMode=none). This operation must be done after the values set here were merged with the ones from application level (see point B above).
Follow these steps to save the list of licensed Source Packages (SPs):
– Login to Source Factory, then go to “Source Factory” > “Source Packages List”;
– Select “All” from “Per Page” drop down from the top right page. This will take a few minutes while it builds a list of several thousand Source IDs;
– Perform a search using no specific keywords but by selecting “Released” (instead of “All Values”) as your search criteria in the “Production Status” drop down near the bottom of the page. This search will result in a display of released SPs. This will take a few minutes while it builds a list of several thousand Source IDs;
– When the Source Package list is complete go to the top right hand side of the list. A button labeled “Export to CSV” is displayed. Select this option, let the export run, and then format the report as needed
If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.
First check the following:
– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.
– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).
– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.
In cases where the target site is working but the communication is slow for some reason the solution is to increase the
If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See FAQ “Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?”
If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.First check the following:
– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.
– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).
– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.
In cases where the target site is working but the communication is slow for some reason the solution is to increase the
If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?
We unify all the information from all the sources into Unicode using UTF-8, and we pass it from ICE and all of our Bridges as UTF-8 and XML-encoded entities. However, we are not limited to extracting data just from UTF-8 bytes, and we should not extract bytes as UTF-8 when it is not appropriate. All our extraction in Muse is to UTF-8 but from a wide range of encodings (including UTF-8).
We accommodate this large number of encodings, detailed in the documentation, when we extract data; only then is it converted into Unicode (with UTF-8 encoding) on our side.
The MNM entries can be set:
A) at the individual Source Package level
B) additional MNM entries can be set at the Application level
A) Setting MNM entries at the individual Source Package level:
The MNM entries can be set at individual Source Package level using the Muse Source Console (MSC) as follows:
– login into the MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button near the Source Package in the list that is to be edited
– the value for MNM must be entered in the “Link URLs” field
B) Setting additional MNM entries at application level
The MNM entries can be set at the Application level using the Muse Source Console (MSC) as follows:
– login into the MSC
– select an Application using the radio button
– select the “General Settings” section
– go to “Navigation Management” section
– the value for the MNM at the Application level must be entered in the “Link URLs” field
Note*: The MNM entries at the Application level are additional to the ones set for individual Source Package level. So for a Source Package the MNM entries set up for that Source Package plus the MNM entries set up at Application level (A + B above) will be used.
Note**: The MNM entries at the Application level are usually used when many sources at the Application level are using a WAM (Web Access Management) software such as ezProxy as this provides a way to add a MNM entry that is to be used by multiple sources. Except in the case of WAM software it is not recommended that MNM entries be set at the Application level.
There are two parameters involved here:
CONNECT_TIME_OUT: specifies the timeout value, in milliseconds, to be used when opening the communication link for each resource (e.g. URL) used by this source.READ_TIME_OUT: specifies the timeout value, in milliseconds, that is involved upon reading on the communication channels.
One can increase the timeout for a given Source Package by increasing the value in the CONNECT_TIME_OUT and READ_TIME_OUT fields (the entry is in milliseconds; 1,000 milliseconds = 1 second). To edit these fields of the source profile one must use the Muse Source Console:
- login into the Muse Source Console
- select the desired application from the list of applications
- go to the “Configure” tab
- click on the “Modify” button for the desired source
- update the “Connect Time Out” and “Read Time Out” inputs with the desired values
- to submit the modifications click on the “Update” button
Note: The values for the “Connect Time Out” and “Read Time Out” fields must be given in milliseconds.
Muse source packages, by default, return only the metadata found in the native source’s list of results. The Ex functionality of a source means that when a search is performed on that source from the Muse interface the information brought back for each record includes information that normally can be found when the link to that record in the native web interface is accessed from the results list.
If this functionality is desired, then the USE_EX_PARSER field from the SP profile must be “yes”(no quotes).
Example:
Please note that even if the source is free and the Ex functionlaity is desired, this field must be filled with “yes”. By default, this field is set to “no”. So such a connector will behave normally if the USE_EX_PARSER field from the profile is missing or has the “no” value, and will have an extended parsing if the USE_EX_PARSER field from the profile has the “yes” value.
The .cpb file describes the search capabilities of a source. The .pmf is the pre-mapping file that allows administrators to map search/index attributes that apply before the Muse ISR stylesheet is used to format the search for the source (thus “Pre”-mapping).
The .cpb file lists all the search indexes and Boolean operators which are supported by the Source (whatever the actual, native syntax of the attribute). It is also a place where other source capabilities could be added later for easy import into the Muse InfoBase. The search limiter sets are one example.
The .pmf file provides a mapping from one attribute in ISR to one attribute in translator. The .pmf mapping is TO an attribute which is handled into the ISR translator. All of the attributes handled (supported) in the ISR translator have been automatically extracted and recorded into the appropriate section in .cpb file.
By default, the PMF files map unsupported attributes to keyword.
MuseGlobal provides the following method for search and retrieval of EBSCOhost content: EBSCO Integration Toolkit (EIT)
This is a SOAP-based Web Service approach which provides the optimal combination of performance and completeness. You can find the EIT Source Packages by searching in your Muse Console’s “Add Sources” section in the “IDs Containing” field for the term EIT. EIT SPs have Source IDs which start with the string EBSCOEIT.
URLs:
The HTTP Source Packages for EBSCO search on the URL
http://search.ebscohost.com/. The EIT Source Packages use
http://eit.ebscohost.com/Services/SearchService.asmx as the Home URL and Search URL.
AUTHENTICATION:
Authentication for the EBSCOEIT Source Packages is two-fold.
1) Authentication for search and retrieval can done by user/pw (with the USER_NAME and USER_PASSWORD fields of the profile) or IP (with the CUSTOM_PARAMETERS field of the profile).
For search/retrieval authentication by IP, a value must be placed in the CUSTOM_PARAMETERS tag from the EBSCOEIT* source profile. Again, this is used to connect to and search a certain database. Using this IP authentication, you may be authenticated to a number of databases.
Example :
where : IP_ADDRESS=your IP which authenticates to EIT.
Please note that your EBSCO account must be specifically enabled in order to use of EIT. The user/pw used for connecting to http://search.ebscohost.com/ will not work for EIT. Also note that the IP_PROFILE will be either eit or eitws; — this string matches the 3rd section of your 3-part EIT authentication string (ex. s123456.main.eit or s123456.main.eitws). Please check with EBSCO if you are not sure which it is.
2) The aforementioned authentication by IP or user/pw gives us access to the EBSCOEIT API, but it does not provide successful link navigation on the record links obtained.
For this, the PROXY_HOST and PROXY_PORT in the profile must be configured. IMPORTANT: authentication to EBSCO for link navigation is only done by IP.
Example :
So, in conclusion, 2 IP authentication settings are needed: one (user/pw or IP) for accessing and searching the EBSCOEIT database desired and the other one (proxy IP) to successfully navigate on the record links obtained.
Questions about your EIT account status should be referred to Gregory Julien [GregoryJulien@ebscohost.com].