Dashboard > ILS and Discovery Systems > Draft Recommendation > Real Time Search
ILS and Discovery Systems
Real Time Search
Added by Terry Reese, last edited by Emily Lynema on Apr 17, 2008  (view change)
Labels: 
(None)

6. Real-time Search

6.1 Rationale and general issues

While more and more organizations are looking to build discovery tools that make use of locally harvested and indexed content from the ILS, accessing real-time data is a necessary step for organizations looking to integrate these tools with the ILS.  Information such as an item's circulation status or availability are sufficiently ephemeral to require real-time data access to adequately represent an item's current state.  The presence of a real-time data access API will complement large scale data harvesting mechanisms provided by the ILS.  The existence and maintenance of record identifiers that link between the ILS and metadata stored and indexed in external discovery applications will be an important piece of this functionality.

While this real-time access to ephemeral item data is critical to the usefulness of external discovery applications that maintain local indexes, the capacity to perform rich, real-time searches remains an important feature for organizations looking to integrate ILS content into other types of [discovery] applications.  Current generation library tools such as federated search rely on the ability to perform real-time searches against an institution's collections, including the catalog.  Although ILS vendors have provided access to some of this data via Z39.50, the protocol's library-centric nature makes it marginally useful when dealing with non-library groups interested in utilizing ILS data. 

Presently, all library vendors provide one standard binding for providing real-time search: Z39.50.  Developed before the advent of XML or web services, Z39.50 has traditionally provided the library community with a unified method for retrieving data across ILS systems.  However, as the use of XML and XML-based protocols has become more commonplace, the U.S. Library of Congress issued a revision to the Z39.50 protocol commonly known as the SRU/W standard.  Adopted around 2000, the SRU/W protocol replaces the antiquated Z39.50 protocol, providing access to one's bibliographic content via an XML-based query service.  In this specification, we encourage adoption of the newer SRU/W standard, which encompasses the functionality of z39.50. We also recommend that an SRU extension be implemented for OpenSearch, allowing non-library applications comfortable with the increasingly common OpenSearch specification to easily include ILS data.

For most of the real-time search functions, metadata could be returned in multiple formats. While MARC, MARCXML, or MODS may be sufficient for bibliographic information, standards may need to be defined for retrieval of availability information and other item-related data. Dublin Core may be useful, particularly for course reserve records. Where possible, API functions should allow user to request a specific metadata format, and API providers will need to identify the metadata formats they support.

6.2 Sample use cases

Some possible use cases include:

  • Enabling the ILS as a target for metasearching via standard federated search product or other discovery tool.
    • Should include result paging, sorting, a minimum array of query types and limits (should be at least as feature-full as the OPAC)
  • Providing real-time access to requested bibliographic record(s) via record identifier, including holdings, availability, and circulation information as needed. For example, displaying current item availability in an external catalog search tool utilizing a Lucene index.
  • Integrating course reserve lists maintained in the ILS with course management systems by allowing creation of a script or web service that retrieves a list of reserves by course and/or instructor.

6.3 Abstract Functions

6.3.1 GetAvailability (Level 1)

Summary: Given a set of bibliographic or item identifiers, return a list with information about the items associated with the identifiers.

Parameters:

  • id: (type [string]; required):  list of either bibliographic or item identifiers
  • type: (type string; required): defines the type of record identifier being used in the request: item or bibliographic.

Returns:

  • A list of objects that represents all the availability of the items associated with the requested bibliographic / item identifiers. If using a hash, the bibliographic identifier would be the key, and each value would be a list of item availability objects for that identifier.
  • If no items associated with a requested system bibliographic identifier, returns an empty list or RecordNotFound message as the value in the hash for that bibliographic identifier.
  • If no records match any of the requested identifiers, return null or RecordNotFound message.

Exceptional conditions:

  • NotSupported:  The underlying system does not support this type of request.
  • RecordNotFound: Identified record was not found.

Side effects: none

Rationale: Enables external discovery systems that maintain their own index of bibliographic information to create displays that utilize real-time availability of results, rather than availability data that is stale.

Notes:

  • Some bibliographic identifiers may have a large number of items attached (ex: >1,000 volumes with item records for a serial).
  • Data returned from this function for each item must include, where it exists (required):
    • bibliographicIdentifer (required, type string)
    • itemIdentifier (required, type string, most likely a barcode)
    • availability (required, type enum, [available, not available, unknown])
    • dateAvailable (optional, type dateTime) - most likely date due
    • status (optional, type string) - pull from NCIP / ISO holdings vocabulary or define local vocabulary
  • Data returned from this function should include, if possible (optional):
    • location (optional, type string, repeatable) - use case: patron going to the stacks to pick something up
    • call number (optional, type string) - use case: patron going to the stacks to pick something up
    • circulating (optional, type boolean) - whether material generally circulates to the primary user population
    • holdQueueLength (optional, type int) - number of holdings placed on title/item
  • Response format could be achieved using NCIP or ISO Holdings (see Metadata Schemas, section 6.4.1 for more information about these standards).
    • See a possible NCIP example. Mapping of data elements above with NCIP elements:
      • bibliographicIdentifier -> <ncip:LookupItemResponse>/<ncip:ItemOptionalFields>/<ncip:BibliographicRecordDescription>/<ncip:BibliographicRecordId>
      • itemIdentifier -> <ncip:LookupItemResponse>/<ncip:UniqueItemId>
      • availability -> <ncip:LookupItemResponse>/<ncip:ItemOptionalFields>/<ncip:CirculationStatus> - this possible values for this field would need to be mapped by the implementor to the the enumerated [available, not available, unknown]
      • dateAvailable -> no mapping at this point
      • status -> <ncip:LookupItemResponse>/<ncip:ItemOptionalFields>/<ncip:CirculationStatus>
      • location -> <ncip:LookupItemResponse>/<ncip:ItemOptionalFields>/<ncip:Location>
      • call number -> <ncip:LookupItemResponse>/<ncip:ItemOptionalFields>/<ncip:ItemDescription>/<ncip:CallNumber>
      • circulating -> <ncip:LookupItemResponse>/<ncip:ItemOptionalFields>/<ncip:ItemUseRestrictionType> - the possible values for this field (enumerated by NCIP schema) would need to be mapped by the implementor to y/n for circulating
      • holdQueueLength -> <ncip:LookupItemResponse>/<ncip:ItemOptionalFields>/<ncip:HoldQueueLength>
    • See a possible ISO Holdings example. Mapping of data elements above with ISO Holdings elements:
      • bibliographicIdentifier -> <holdings:holdingsSimple>/<holdings:copyInformation>/<holdings:resourceIdentifier>
      • itemIdentifier -> <holdings:holdingsSimple>/<holdings:copyInformation>/<holdings:pieceIdentifier>
      • availability -> <holdings:holdingsSimple>/<holdings:copyInformation>/<holdings:availabilityInformation>/<holdings:availabilityStatus>
      • dateAvailable -> <holdings:holdingsSimple>/<holdings:copyInformation>/<holdings:availabilityInformation>/<holdings:dateTimeAvailable>
      • status -> <holdings:holdingsSimple>/<holdings:copyInformation>/<holdings:sublocation> - there is no direct mapping for this field, but the generic <holdings:sublocation> or <holdings:note> fields could be used.
      • location -> <holdings:holdingsSimple>/<holdings:copyInformation>/<holdings:sublocation> (repeatable element)
      • call number > <holdings:holdingsSimple>/<holdings:copyInformation>/<holdings:shelfLocator>
      • circulating -> <holdings:holdingsSimple>/<holdings:copyInformation>/<holdings:availabilityInformation>/<holdings:availableFor> - the possible values for this field (enumerated in ISO Holdings schema) would need to be mapped by the implementor to y/n for circulating
      • holdQueueLength -> <holdings:holdingsSimple>/<holdings:copiesSummary>/<holdings:reservationQueueLength> - this field is at the title level rather than the copy level

Possible Bindings

  • Recommended Binding: Web Service Call
    • Could be implemented as a web service directly on top of the ILS.
    • Could be written as a wrapper utilizing multiple calls to the NCIP Lookup Item service.
    • RESTful URL template: GET http://myserver.com/availability?id=<identifier>;<identifier>;<identifier>;...&id_type=[item|bib]
    • RESTful URL template: GET http://myserver.com/items/<identifier>;<identifier>;.../availability
    • RESTful URL template: GET http://myserver.com/bibs/<identifier>;<identifier>;.../availability
  • Other Bindings
    • SRU/W:  While SRU/W may not be a perfect match when looking at this functionality -- the ability to define and create context sets for rending data elements should provide a great deal of flexibility, allowing SRU/W to accommodate the requested data.
    • OpenURL: OpenURL requests may be able to define a structured URL to request information, although it does not define a response format for the requested data.
6.3.2 GetRecords (core)

Summary: Given a list of record identifiers, return a list of record objects that contain bibliographic information, as well as associated marc holdings and item information. The caller may request a specific metadata schema for the record objects to be returned. Individual API providers will need to enumerate the supported metadata schemas. This function is similar to those in Data Aggregation, but allows simple, real-time lookup by bibliographic identifier.

Parameters:

  • id: (type string; required) - list of system record identifier[s]
  • schema (type enum; optional) - Defines the metadata schema in which the records are returned (ex: MARC21, MODS, Dublin Core). If not specified, a default will be defined by the API provider.  Dublin Core may serve as a good default schema, since it makes a good compatibility format.

Returns:

  • A list of record objects that represent the bibliographic record and associated holdings and item information for each requested bibliographic identifier. If using a hash, the bibliographic identifier would be the key.
  • If no records match any of the specified identifiers, return an empty list or RecordNotFound message.
  • If no record matches a specific bibliographic identifier, return null or RecordNotFound message as the value in the hash for that bibliographic identifier.

Exceptional conditions:

  • NotSupported:  The underlying system does not support this type of request.
  • UnsupportedSchema: The requested metadata schema is not supported by the underlying system.

Side effects: none

Rationale: There are many possible use cases for this function. For external discovery systems that do not maintain full MARC records in their local indexes, it allows lookup of this information on-the-fly, perhaps for passing from the discovery system to other tools like RefWorks or displaying the MARC record directly to user without handing off to a separate application. Also allows external discovery systems to pull records from the ILS individually as needed to possibly replace data in local indexes, etc.

Notes:

  • Some bibliographic identifiers may have a large number of items attached (ex: >1,000 volumes with item records for a serial).
  • Returned data should include item identifiers and bibliographic identifiers.
  • Maximum number of records that can be requested per query may need to be locally defined.

Possible Bindings

  • SRU/W - searchRetrieve operation
    • record schema used must be able to handle more than just bibliographic information
    • must be able to make a request to search by bibliographic identifier via CQL
  • OAI - PMH - GetRecord function
    • this function retrieves only 1 record with 1 record identifier at a time
  • Web Service Call
    • Could be implemented as a web service directly on top of the ILS.
    • RESTful call: GET http://myserver.com/records?id=<identifier>;<identifier>;<identifier>...[&schema=<x>]
6.3.3 Search (core)

Summary: Function passes a query into the ILS and returns a list of records.

Parameters

  • query (type string; required): Query string; needs to include both index and search terms
  • profile (type enum; required ): Defines the type of query syntax being utilized.  For example, in SRU/W, users might define the profile as CQL. The API provider would need to enumerate supported profile types.
  • schema (type enum; optional): Defines the metadata schema in which the records will be returned (ex: MARC21, MODS, Dublin Core). If not specified, a default will be defined by the API provider.
  • recordType: (type enum; optional): Specifies the type for the returned records.  For example, brief or expanded.  The API provider would need to enumerate supported record types.
  • offset: (type int; optional): First record in a search result list to return.
  • max: (type int: optional): Specifies the maximum number of records to be returned in the query response. The API provider will need to establish a default.
  • sort: (type string; optional): Specifies a sort type (e.g. title, date, relevance, etc.)

Returns:

  • A list of record objects that matched the query. The level of information included in those records is defined by the recordType parameter.
    • When requested, the expanded record type should return records that include all available bibliographic, holdings, and item/circulation information (the same metadata returned for the GetRecords function).
    • When requested, we recommend that the brief record type should return records that include title, author, imprint, isbn/issn, and bibliographic identifier.
  • If no records match query, returns an empty list or a RecordNotFound message.

Exceptional conditions:

  • NotSupported:  The underlying system does not support this type of request.
  • UnsupportedProfile: The requested profile is not supported by the underlying system.
  • UnsupportedSchema: The requested metadata schema is not supported by the underlying system.
  • UnsupportedType: The requested record type is not supported by the underlying system.
  • UnsupportedQuery: The query as requested (index, truncation, etc.) is not supported by the underlying system.
  • RecordsNotFound: No records were found.

Side effects: none

Rationale: Some external discovery applications, metasearch as one example, may want to harvest results from the ILS on the fly for integration, rather than maintaining a separate index of ILS data. Enabling machine-readable access to ILS data on the fly is crucial for sending catalog data out of the catalog. Some external discovery applications (particularly non-library applications) may be able to interact more easily with a real-time search service that provides for a simple query mechanism. Searching and accessing course reserves materials is particularly relevant to integration with campus course management systems at institutions where reserves are managed via the ILS.

Notes:

  • Returned data should include item identifiers and bibliographic identifiers.
  • Maximum number of records that can be requested per query may need to be locally defined.
  • To properly support Unicode searching, the API provider should specify whether the indexed data uses composed or decomposed Unicode characters (provider may support search for both) and whether diacritics have been stripped in indexing process.
  • Optimally, the API provider should perform the same transformation on the incoming query string as used when data is being indexed.
  • In addition to more traditional indexes like title or author, support for instructor and course/section indexes would allow this function to retrieve records by their association with reserves. However, to obtain course reserves records that contain reserves information in addition to bibliographic information, the SearchCourseReserves function is recommended.

Possible Bindings:

  • SRU/W searchRetrieve operation
    • SRU: GET/POST http://myserver.com/sru?operation=searchRetrieve&version=1.2&query=title=science\[&maximumRecords=20&recordSchema=dc\]
    • needs to support instructor/course indexes if ILS supports course reserve functionality
  • OpenSearch with SRU profile
  • Web Service Call
    • Could be implemented as a web service directly on top of the ILS.
    • RESTful call: GET http://myserver.com/search?query=<query>&profile=<x>[&schema=<x>&recordType=(expanded|brief)&sort=<x>&max=<x>&offset=<x>]
6.3.4 Scan (core)

Summary: Given a query, returns the index entries (and number of matching bibliographic records) that are nearest to where the query would appear in the index.

Parameters

  • query (type string; required): query string; needs to include both index and search terms
  • profile (type enum; required): defines the type of query syntax being utilized.  For example, in SRU/W, users would define profile as CQL. The API provider would need to enumerate supported profile types.
  • schema (type enum; optional): Defines the metadata schema for the records to be returned (ex: SRU, <record>, RSS/Atom). If not specified, a default will be defined by the API provider.
  • position: (type int; optional): The position within the list of returned index entries where the requested term(s) should occur. If position = 1, the requested term should be the first term in the list returned. The default value is 1.
  • max: (type int: optional): Maximum number of index entries to be returned. If not specified, a default will be defined by the API provider.

Returns:

  • A list of index entries with number of matching bibliographic records near the user's query term[s]. SRU/W has a pre-defined schema for a Scan response that can be extended through use of the <sru:extraTermData> element. See an example of how this might look

Exceptional conditions:

  • NotSupported:  The underlying system does not support this type of request.
  • UnsupportedQuery: The query as requested (index, etc.) is not supported by the underlying system.
  • UnsupportedProfile: The requested profile is not supported by the underlying system.
  • UnsupportedSchema: The requested metadata schema is not supported by the underlying system.

Side effects: none

Rationale: Sometimes it is desirable to browse a list of possible headings, rather than view a list of individual records. For example, browsing the shelf by call number is a popular feature that can help mimic the physical experience of browsing the shelves without going to the library. Scan can also help support direct lookup of a title or author to help determine for sure whether that title or author is part of a library's collection.

Notes:

  • The API provider must specify which indexes are available to scan. We recommend that a minimum set of indexes would be: title, author, subject, and call number. For the author and subject indexes, this recommendation assumes that the index has been enriched with entries that represent cross-references and see also headings from authority records.
  • To properly support Unicode searching, the API provider should specify whether the indexed data uses composed or decomposed Unicode characters (provider may support search for both) and whether diacritics have been stripped in indexing process.
  • Optimally, the API provider should perform the same transformation on the incoming query string as used when data is being indexed.

Possible Bindings:

  • SRU/W scan operation
    • A pre-defined SRU schema exists for this response. See http://www.loc.gov/standards/sru/specs/scan.html. In this scenario, we would probably want to use the <sru:extraTermData> element combined with MADS elements for each term returned to list an identifier for the authority, and to enable information like 'see also' or 'see related headings'. For example, the <mads:related> element would be included if an index entry represents an authorized subject heading with several 'see also' headings. The <mads:authority> element would be included if an index entry represents an un-authorized 'see' heading that has been included in the index. In that scenario , the <mads:authority> element would recommend the authorized heading that should be used in place of the index entry.
  • OpenSearch with SRU profile
  • Web Service Call
    • Could be implemented as a web service directly on top of the ILS.
    • RESTful call: GET http://myserver.com/scan?query=<query>&profile=<x>[&schema=<x>&max=<x>&position=<x>]
6.3.5 GetAuthorityRecords (core)

Summary: Given a list of authority record identifiers, returns a list of record objects that contain information about the authority headings. The function user may request a specific metadata schema for the record objects. Individual API providers will need to enumerate the schemas supported in that system.

Parameters:

  • id (type [string]; required) - list of identifiers 
  • schema (type enum; optional) - Specifies the metadata schema of records to be returned (ex: MARC21, MARCXML, MADS, Dublin Core). If not specified, a default will be defined by the API provider.

Returns:

  • A list/hash of record objects that represents the full authority record for each requested authority record identifier. If using a hash, the authority record identifier would the key.
  • If no records match any of the specified identifiers, return an empty list or RecordNotFound message.
  • If no record matches a specific authority record identifier, return null or RecordNotFound message as the value in the hash for that identifier (or in the element of the array at the same index as the requested identifier).

Exceptional conditions:

  • NotSupported: The underlying system does not support this type of request.
  • UnsupportedSchema: The requested metadata schema is not supported by the underlying system.
  • RecordNotFound: No records were found for this query.

Side effects: none

Rationale:  Some external discovery tools are built using authority records. This function allows these systems to retrieve the full authority record on-the-fly, even if the full record is not stored locally. It also allows records to be updated on an individual basis.

Notes:

  • Returned data should include authority record identifiers.
  • If possible, it would be very helpful for each authority record to include a list of bibliographic record identifiers associated with this authority record in the local system.

Possible bindings

  • SRU/W - searchRetrieve operation
    • must be able to make a request to search by authority record identifier via CQL
  • Web Service Call
    • Could be implemented as a web service directly on top of the ILS.
    • RESTful call: GET http://myserver.com/authorities?id=<identifier>;<identifier>;<identifier>...[&schema=<x>]
6.3.6 SearchCourseReserves (minimum OPAC alternative)

Summary: Retrieve course reserve materials by specifying instructor and/or course and section. API providers must enumerate the types of course reserves searches supported.  

Parameters:

  • query (type string; required) - Query string; needs to include both index and search terms
  • profile(type enum; required) - Defines the type of query syntax being utilized.  For example, in SRU/W, users would define profile as CQL.
  • recordType: (type enum; optional) - Specifies the type for the returned records.  For example, brief or expanded.  The API provider would need to enumerate supported record types.
  • schema(type enum; optional) - Specifies the metadata schema of records to be returned (ex: Atom, RSS, Dublin Core, MARCXML). If not specified, a default will be defined by the API provider.

Returns

  • A list of course reserve record objects that matched the user's query. The level of information included in those records is defined by the recordType parameter.
    • When requested, the expanded record type should return objects that include all available information about course, section, and instructor, as well as a list of bibliographic records with associated holdings/item information that are associated with those courses.
    • When requested, we recommend that the brief record type should return records that include all available information about course, section, and instructor, and a summary of the number of items on reserve for that course/section/instructor.
  • If no records match query, returns an empty list or a RecordNotFound message.

Exceptional conditions:

  • NotSupported:  The underlying system does not support this type of request.
  • UnsupportedProfile: The requested profile is not supported by the underlying system.
  • UnsupportedQuery: The requested search type is not supported by the underlying system.
  • UnsupportedType: The requested record type is not supported by the underlying system.
  • UnsupportedSchema: The requested metadata schema is not supported by the underlying system.
  • RecordNotFound: No records could be found matching the request.

Side effects: none

Rationale: Searching and accessing course reserves materials is particularly relevant to integration with campus course management systems. While not all course reserves systems are managed through the ILS, this section of the API is relevant for those institutions where it is. It may be possible to utilize course and/or instructor querying via the Search function defined previously, but the records returned in that case will simply be a list of bibliographic records. This function provides the ability to retrieve course and instructor information in combination with bibliographic records.

Notes:

  • It would be preferable to be able to search by course, section, and instructor in combination (combining this with keyword searching would allow even greater flexibility).
  • Course level records should return a system identifier for a course.

Bindings

6.3.7 Explain (robust discovery platform)

Summary: Explain, in machine-readable format, the real-time search functionality that is supported by a given ILS/metadata provider.

Parameters: none

Returns

  • Summary of real-time search functionality supported. This should describe the functions, metadata schemes, character encoding, indexes, and other default parameter values.

Exceptional conditions:

  • NotSupported:  The underlying system does not support this type of request.

Side effects: none

Rationale: Since some API providers may only implement some of the functionality described, this is a standard way of identifying which parts of the functionality are available.

Notes:

Bindings

6.4 Real-Time Search Binding Details:

6.4.1 Metadata Schemas

In the abstract functions specified for the Real Time Search section, there are several different types of metadata that might be transmitted between the ILS and the requesting application. Where possible, it seems most efficient and re-usable to take advantage of pre-existing defined schemas to represent this data. The members of this Task Group are making recommendations for possible schemas that could describe the desired information, however, we do not want to limit API implementors and users to a single metadata schema. In some cases, the method of implementation (ex: SRU vs. OAI-PMH) may impact the data schemas that can be used.

In general, we need to be able to describe bibliographic information, holdings information, item/circulation information, authority information, and course reserves information in a standardized format.

Bibliographic information

Libraries have been exchanging bibliographic information for a long time, so there are many available schemas. Full bibliographic metadata should be returned in the GetRecords and Search (when full record type is specified) functions for Real Time Search. We strongly encourage API implementors to provide access to bibliographic information in an XML format, in addition to (or instead of) the traditional marc21 (z39.2/ISO 2709). Other recommended schemas include:

  1. MARCXML (a schema is also available)
  2. MODS (a schema is available)
  3. Dublin Core (a schema is available)

Marc Holdings information

Marc holdings information has been less frequently included (and in less standardized ways) through common data interchange protocols like z39.50. While there is a stable marc21 holdings format, other XML options for fully describing holdings information are still being standardized. Full holdings information should be returned in the GetRecords and Search (when full record type is specified) functions for Real Time Search. Other recommended schemas include:

  1. MARCXML (a schema is also available)
  2. ISO Holdings (ISO 20775) - schema to be available soon at http://www.loc.gov/isohold/. ([local version] currently available).
  3. MODS - Since MODS only allows for structured enumeration and chronology by bringing in information specified with an external schema, we recommend use of MARCXML or ISO Holdings rather than MODS where possible.

Unstandardized Item / circulation information

  1. ISO Holdings (ISO 20775) - schema to be available soon at http://www.loc.gov/isohold/ (local version currently available)
  2. NCIP Item Element (see the Item Element Type in section 6.3 of the PDF) - an NCIP XML schema is also available (xsd version | dtd version)

Scan information

The Scan function represents a different type of search functionality than provided by the other Real Time Search functions in that it returns index entries, rather than full records. We strongly encourage API implementors to enrich these index entries with related or authorized forms of headings when users are scanning controlled indexes, such as author and subject.  One schema that we recommend is use of the SRU/W Scan record format for returning index entries, with additional term data added to use recording using MADS or MARCXML.

An example of what such a record might look like.

Authority information

Full authority records should be returned in the GetAuthorityRecords function for Real Time Search. Like bibliographic and holdings information, authority information can be expressed using the marc21 authority format. However, we strongly encourage API implementors to make the metadata available in an XML format. Other recommended schemas include:  

  1. MARCXML (a schema is also available)
  2. MADS (a schema is also available)

Course reserves information

As some institutions maintain course reserve records within the ILS, there is a need to access these records as well. While individual items on reserve could be represented with standard bibliographic / item information, course reserves also involve information about courses and instructors. Course reserve records should be returned in the SearchCourses and SearchCourseReserves functions for Real Time Search.

The members of this Task Force have not discovered a previously existing, openly available metadata schema that will handle course reserve information. If you know of a scheme and would like to recommend it, please add a comment on our wiki or write ils-di@googlegroups.com.

A data schema used to describe course reserves information could be hierarchical in nature, based at the course at the root level, and would need to take the following metadata into account. 

  • Course
    • Code (ex: eng221)
    • Department
    • Name (Introduction to Biology)
    • Section (may be multiple Section elements per course)
      • Number (ex: 001)
      • Instructor
      • Time Period (ex: Spring Session 2007-2008) ??
      • Number of reserve materials
      • Record - if recordType=expanded, include 1 or more <record> elements that represent expanded bibliographic records associated with a section

Putting it all together

Since no single metadata schema recommended above specifies all the information we would like to see made available for the GetRecords and Search functions, a technique is needed to combine data elements from multiple schemas. We propose the use of very simple XML elements to help bring these schemas together.

  • <dlf:collection> - use to enclose a group of records
    • <dlf:record> - use to enclose an expanded record including bibliographic, marc holdings, and item/circulation information
      • <dlf:bibliographic> - use to enclose the bibiliographic description in the record (required, minOccurs=1, maxOccurs=1)
      • <dlf:holdings> - use to enclose marc holdings information. If using ISO Holdings schema, it may contain <holdingsSimple> elements to describe individual items, as well as <holdingsStructured> to describe marc holdings information for continuing resources. (optional, minOccurs=0. maxOccurs=1)
      • <dlf:items> - use to enclose non-marc holdings metadata for particular items. This could be expressed via NCIP or via the <holdingsSimple> elements in the ISO Holdings schema. (For NCIP, use the LookupItemResponse enumerated element to describe an item. But that element doesn't ItemDetails (provides due date) and it's not clear whether NCIP provides a place for summary circulation statistics). (optional, minOccurs=0, maxOccurs=1)

Some examples of how this might look (values have been listed for most of the available data elements simply to illustrate their availability; many of these are optional):

6.4.2 OpenSearch + SRU Binding 

[ejl - do we need to specify in a bit more detail how the SRU/W or OpenSearch binding might fit across these functions?]

Defunct Functions

Older definitions of functions that are now defunct are available on an archive page of defunct real-time search functions.

Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.6.0 Build:#913 Sep 27, 2007) - Bug/feature request - Contact Administrators