Chapter 13. Adding a Located URI to the Record

Table of Contents

Located URI Example 1
Located URI Example 2

A Located URI allows you to add the short name for the owning library to the 856 field to indicate which organizational units should be able to find the resource. The owning organizational unit can be a branch, system, or consortium.

A global flag called When enabled, Located URIs will provide visibility behavior identical to copies will determine where these resources will appear in search results. This flag is available through AdminServer AdministrationGlobal Flags.

If the When enabled, Located URIs will provide visibility behavior identical to copies flag is set to False (default behavior):

If the When enabled, Located URIs will provide visibility behavior identical to copies flag is set to True:

To add a located URI to the record:

  1. Open the record in MARC Edit
  2. Add a subfield 9 to the 856 field of the record and enter the short name of the organizational unit for the value. Make sure there is a 4 entered as the first indicator and a 0 entered as the second indicator. For example:

    856 40 $u http://lwn.net $y Linux Weekly News $9 BR1

    would make this item visible to people searching in a library scope of BR1 or to logged-in users who have set BR1 as their preferred search library.

    Note

    If multiple organizational units own the resource, you can enter more than one subfield 9 to the 856 field or you can enter multiple 856 fields with a subfield 9 to the record

  3. Save the record

Located URI Example 1

The When enabled, Located URIs will provide visibility behavior identical to copies flag is set to False (default behavior)

The Record has two 856 fields: one with SYS1 in subfield 9 and the other with BR4 in subfield 9

  • Any user searching SYS1 or any of its children (BR1, BR2, SL1) will find the record. These users will only see the URL belonging to SYS1.
  • Any user searching BR4 will find the record. These users will only see the URL belonging to BR4.
  • A user searching SYS2 will NOT find the record because SYS2 is a parent of an owning org unit, not a child. The same thing happens if the user is searching the consortium. In this case, the system assumes the user is unlikely to have access to this resource and therefore does not retrieve it.
  • A logged-in user with a preferred search library of BR4 will find the record at any search scope. This user will see the URL belonging to BR4. Because this user previously identified a preference for using this library, the system assumes the user is likely to have access to this resource.
  • A logged-in user with a preferred search library of BR4 who is searching SYS1 or any of its children will also retrieve the record. In this case, the user will see both URLs, the one belonging to SYS1 because the search library matches or is a child of the owning organizational unit and the one belonging to BR4 because it matches or is a child of the preferred search library. The URL belonging to the search library (if it is an exact match, not a child) will sort to the top.