| | |
| | |
| | h2.Section VI: Vocabulary Definitions for the OCKHAM Reference Model |
| | |
| | *Alerting Service* - An alerting service is a proactive service bringing to a patron's attention new and important information. In the context of OCKHAM, alerting regularly or on demand enumerates to a patron items that have been recently acquisitioned by an OCKHAM Network participating institution. These items have been flagged as "new" and match a patron's profile describing their information need. On a regular basis these customizable profiles are applied against sets of "new" items and search results are sent to a patron. Alerting is synonymous with "current contents" or "selective dissemination of information (SDI)" services. |
| | |
| | *Browsing* - Browsing is an information seeking process emphasizing serendipity. Such a process assumes sets of information is organized into like "bins". All the information about one topic is organized here. All the information on another topic or in a particular format is organized there. Patrons are given the opportunity to browse these collections seeking useful or interesting items. The technique is very useful if a patron does not know exactly what they are seeking and works very well when it comes to browsing books in a library. In the context of OCKHAM, browsing also means "find me more like this one" -- where a person identifies an item of interest, the system queries the patron about the qualities of the item that are desirable, and then the system returns similar items based on those qualities. It is like dynamically creating a browsable shelf of books. |
| | |
| | *Cataloging* - The formation and assembly of descriptive metadata, and the practice of doing so. Cataloging could be for physical objects (such as books in a traditional library) or digital resources online (such as is typical in digital libraries). Cataloging produces _a catalog_, which can be searched or browsed to find cataloged objects (and typically, to retrieve them). |
| | |
| | *Content Discovery* - The process of finding the objects that fulfill an information need. The information need is typically anchored by some topic, context, or incomplete metadata (i.e., "give me books with a title like ..."). |
| | |
| | *Content Metadata* - \[is structural metadata what is meant here? or metadata about content? I don't think we really need this one. -- APK\] |
| | |
| | *Conversion* - See _metadata conversion_. |
| | |
| | *Digital Library* - The term digital library can be defined from many different perspectives. In the context of the OCKHAM Reference Model, a Digital Library is a collection of content and services which work together to provide users the ability to find and use information. |
| | |
| | *Dissemination* - The distribution of content (typically objects referred to by metadata records). For example, the downloading of a PDF journal paper after it is discovered in an on-line [digital] library catalog. |
| | |
| | *Exporting* - The copying of data or records from the local environment to a remote actor. For example, the provision of metadata via an OAI provider. |
| | |
| | *Importing* - The copying of data or records from a remote actor to the local environment. For example, metadata harvesting via OAI-PMH. |
| | |
| | *Interoperation* - The functional connection of information systems. In the context of OCKHAM, this means that individual services are provided with a consistent format (web services), comprehensible by all, and advertised and shared through a common mechanism (the OCKHAM registry service), accessible by all. |
| | |
| | *Metadata* - Metadata is "data about data". Analogous to a card catalog, _descriptive metadata_ is information which refers to the properties of some object, physical or digital. _Structural metadata_ refers to sequencing and arrangement of the "atomic" parts of an object (for example, byte order, arrangement of chunks of text into sections and chapters, etc.). Metadata follows a _schema_, a document which lays out the composition of metadata elements and their meaning in relation to the objects being described. All metadata which follows the same scheme is said to be in that _metadata format_. These days, metadata is usually in XML, and metadata schema are written in XML Schema (XSD) or Document Type Definition (DTD). A popular and basic metadata format is Dublin Core (DC). |
| | |
| | *Metadata Conversion (alt. Metadata Translation)* - Metadata Conversion is the re-casting of metadata in one format to another, while preserving as much as the information as is possible. This may involve re-labeling _metadata elements_, mapping nested structures to other structures, and parsing and transforming the contents of metadata elements. |
| | |
| | *Metadata Enhancement* - The augmentation of metadata with additional relevant information. For example, this may be automatically adding a categorization based on the text in an abstract. It could also be something as simple as labelling a whole collection of records with something known about all of them, such as their intended audience. |
| | |
| | *Metadata Elements* - Portions of metadata which refer to distinct properties of an object. These are usually named tags in XML metadata. In MARC these would be values coupled with MARC codes. In a table, these would be labelled columns, along with their semantics. |
| | |
| | *MyLibrary* - MyLibrary originally denoted a specific piece of open source software distributed by the North Carolina State University Libraries. The primary function of the application allowed patrons to customize the content and appearance of a library Web page similar to the functionality of My Yahoo or My Netscape. Over time the term MyLibrary has become less about a specific piece of software and more about the underlying functionality of the original application. MyLibrary is not about providing lowest common denominator interfaces but instead interfaces tailored to meet individual needs. |
| | |
| | *NSDL* - The National Science Digital Library (United States); an NSF-piloted nation-wide consortium of science, technology, engineering, and mathematics digital libraries, homed at Cornell University. Federation of these participants is primarily done via the Open Archives Protocol for Metadata Harvesting, which in turn rests on the Dublin Core metadata standard. |
| | |
| | *OCKHAM Network* - The set of all OCKHAM nodes and clients connected from a particular client or node. |
| | |
| | *OCKHAM Node* - See _OCKHAM peer_. |
| | |
| | *OCKHAM Client* - A user (software agent or human) which makes use of an OCKHAM service. An OCKHAM Client is not registered on the network and has advertised no services. |
| | |
| | *OCKHAM Peer* - A member of an OCKHAM network which has advertised itsself (one or more services) in the network's registry. An OCKHAM peer may also be a client (but the converse is not true). |
| | |
| | *OCKHAM Node Administrator* - The person responsible for the initiation, operation, and maintenance of an OCKHAM node. |
| | |
| | *OCKHAM Service* - An OCKHAM service is a _web service_ advertised on an OCKHAM network. The service may (and optimally, should) be accessible directly, by clients unaware of the OCKHAM network, but who are versed in web services. |
| | |
| | *OCKHAM Service Definition* - An OCKHAM service definition is a computer-readable document which defines the interface (inputs, outputs) to an OCKHAM service. Optimally, the service definition also provides human-comprehensible semantics of the service. Examples of specific standards that fill this role are WSDL and UDDI. |
| | |
| | *OCKHAM Service Class* - An OCKHAM service class is the set of all OCKHAM service instances that share the same _OCKHAM service definition_ and have the same _OCKHAM service class handle_. |
| | |
| | *OCKHAM Service Class Handle* - An element of a vocabulary, global for a particular OCKHAM network, which allows consistent named references to a service class. This vocabulary may be consist of numerical or alphabetic elements. Example handles could be "PathFinderService", "ConversionService", "CatalogingService", "WhatsNewService", etc, or "1", "2", "3", "4", respectively. Optimally, this is defined in the _OCKHAM service class metadata_. |
| | |
| | *OCKHAM Service Instance* - See _OCKHAM Service_. |
| | |
| | *OCKHAM Service Class Metadata* - Metadata which, at the minimum, defines the vocabulary of OCKHAM service class handles. As much information as is possible and convenient should be provided to gives clues as to the semantics of the service classes. |
| | |
| | *OCKHAM System* - See _OCKHAM Network_. |
| | |
| | *ORM-Compliant* - An _OCKHAM system_ is labeled _ORM-Compliant_ if it is in concordance with the OCKHAM Reference Model. This does not necessarily mean it is _compatible_ with the _Pilot OCKHAM network_. |
| | |
| | *Pathfinder* - A pathfinder is an intellectual resource which guides investigation of a topic through other available resources. |
| | |
| | *Peer-to-Peer Network* - A Peer-to-peer network (also "P2P network") is a network in which the members (peers) are the disseminators of content and provisioners of services. This contrasts with a client-server network, where one server typically provides content or services to multiple clients. In a P2P network, the notion of "server" may completely vanish, melding with "client" into the notion of "peer". This model emphasizes decentralization, collaboration, and sharing of power and responsibility. At the minimum, a P2P network must have a registry service, through which peers can advertise themselves and find other peers. In the context of OCKHAM, an OCKHAM network could be said to be a peer-to-peer network, consisting of (for example) libraries and digital libraries. This is optimal because libraries are already "intellectual peers" who collaborate and share work. |
| | |
| | *Pilot OCKHAM Network* - The first OCKHAM network, developed as a home for the initial test-bed services. \[Other names: NSDLNet ? NOCKHAM? Want to emphasize it as an _instance_ of OCKHAM, not _identical_ with OCKHAM --APK\]. |
| | |
| | *Repository* - A repository is a system in which |
| | |
| | *REST* - Representational State Transfer (REST) works on top of HTTP and takes advantage of URLs as a sort of "command line interface". In such an environment, one computer creates a URL defining a request from a second program or computer. Once received the second computer treats the URL as a command, processes it, and returns the results as an XML stream. REST does not dictate the shape of URLs beyond their existing specification, nor does REST define the format of the returned XML, as long as it is well-formed. Many people advocate the use of REST-ful Web Services, as they insure that services are "part of" the web, rather than "behind it" (simply put, they are always linkable). |
| | |
| | *Service Metadata* - See _OCKHAM service definition_. |
| | |
| | *Service Discovery* - The process of finding a service provider (or providers) to fulfill an information need. In the context of OCKHAM, this means a query to an OCKHAM network's registry service, specifying the service class, and potentially other filtering information (topic, identifying information of a specific object sought, etc.). |
| | |
| | *SOAP* - SOAP is an acronym for Simple Object Access Protocol. SOAP requests must be encoded as XML streams, streams much more complex (more "expressive") than XML-RPC streams. They consist of "envelopes", optional "headers" and "bodies". Unlike XML-RPC and REST, transmitting SOAP messages is not limited to HTTP. Responses to SOAP requests must be wrapped in SOAP envelopes, but the actual structure of the data returned is not necessarily defined by SOAP. Many people think SOAP is the most robust of the three implementations and at the same time overly complicated. |
| | |
| | *Web Service* - Web Services is the name of a computing technique exploiting the use of XML to exchange data/information between computers and computer programs. In a Web Services environment one computer sends another computer (or computer program) a command. The second computer processes the command, formats the results as a stream of XML, and returns the XML to the first computer. Web Service implementations fall into three camps: XML-RPC, REST and SOAP. The results of each is an XML stream. The method used to acquire the stream and the shape of the stream differ. OCKHAM advocates the use of Web Services approaches to sharing data and information because of the interoperable nature of XML streams. |
| | |
| | *XML-RPC* - XML-RPC defines an XML syntax for marking up data types (integers, strings, arrays, etc.) as well as a number of markups used to denote parameters and returned values. "Commands" are marked up accordingly, sent to other processes (other computer programs) via the Hypertext Transfer Protocol (HTTP) PUT method. Once received the command is interpreted, executed, and returned as an XML-RPC defined data stream. The implementation is sometimes described as too simple but straight-forward. |
