Though repository federation can apply to a wide range of domains, in the FRED context we limit it to education. In particular, the major stakeholders who have done the most work on federating are in vocational education (LORN, TILIS), although K-12 (Learning Fed) is also represented. The University Higher Ed sector is not currently represented.

For that reason, the scenarios draw on:

These usage scenarios follow a registry model of repository federation (authoritative metadata registered with central federator), as distinct from the federated search model.

(A variant of this is the dropbox model: metadata is still deposited from federatees to federator, and the federator is where discovery is transacted. But there is no guarantee of authority on the federator metadata and no contractual relation between federator and federatee, so the federator is not deemed a registry: it has diminished trustworthiness.)

1. Register Repository with Registry

Boris is the manager of LEARN-ACT, a learning object repository. Boris wishes to start registering his learning objects with Den’s registry of learning object repositories, OmniLearn. He has never registered any content with OmniLearn before. Den sends out a legal team and an SLA contract for Boris to sign. Once agreement has been reached, Den registers LEARN-ACT. This means that, for the credibility and accountability of OmniLearn, Den acquires metadata about LEARN-ACT, and exposes it to his users. Boris supplies his contact details, the location of LEARN-ACT, a description of LEARN-ACT content and the metadata schema for its learning objects, and an authorisation profile for the users of LEARN-ACT. Den enters this repository metadata into OmniLearn, and attaches an identifier to LEARN-ACT. He grants Boris authorisation to services to push item metadata into OmniLearn; Boris in turn grants Den authorisation to services to pull item metadata into OmniLearn.

  1. Local repository makes request to join registry.
  2. Local repository is authenticated by registry
  3. Local repository supplies requisite repository metadata to registry (accountability, location, content description, metadata schema, authorisation profile, SLA)
  4. Local repository metadata is validated and stored in registry
  5. Authentication & Authorisation infrastructure exchanged to allow item metadata in local repository to be shared with registry through defined services

1a. Register Managed Collection with Registry

The LEARN-ACT repository happens to host ISOCert, a managed collection of courses certified by the ISO. Den can just harvest the ISOCert courses undifferentiated from other LEARN-ACT content, as part of his general harvest of LEARN-ACT; but he prefers to retain the integrity of the collection in his registry. To that end, he needs to register the collection as an entity distinct from LEARN-ACT. The metadata he requires includes the collection manager (Dr Zaius), the repositories hosting the collection (LEARN-ACT), any differences between generic LEARN-ACT metadata and the collection’s (an ISO-specific rating schema embedded in the evaluation field; note that managed collection metadata schemas cannot be incompatible with those of the repositories hosting them), and any distinct access policies applying only to the collection (a non-disclosure agreement). Den enters this managed collection metadata into OmniLearn, and attaches an identifier to ISOCert. He does not grant Dr Zaius authorisation to services to push item metadata into OmniLearn: publishing data is the responsibility of the repository manager (Boris), not the collection manager, whose responsibilities are curatorial.

  1. Registry discovers presence of managed collection hosted by federatee, and decides (per policy) to register it.
  2. Local repository is authenticated by registry
  3. Local repository supplies requisite managed collection metadata to registry (accountability, location, content description, metadata schema customisations, authorisation profile)
  4. Managed collection metadata is validated and stored in registry

1b. Update Registration of Repository with Registry

Some changes have taken place with LEARN-ACT that OmniLearn needs to know about. Boris is still LEARN-ACT manager, but the SLA has had to be renegotiated; the LEARN-ACT servers have had to be migrated (and the locations of items updated, as covered in 10: Migrate Repository); the metadata schema for LEARN-ACT has been tweaked; and the authorisation profile has been made less restrictive. Den updates this metadata about LEARN-ACT, and exposes it to his users. The identifier he has attached to LEARN-ACT remains the same, since there has been no institutional change.

  1. Local repository makes request to have its registry record updated.
  2. Local repository is authenticated by registry
  3. Local repository supplies requisite repository metadata to registry (accountability, location, content description, metadata schema, authorisation profile, SLA)
  4. Local repository metadata is validated and replaces current registry record for repository
  5. Authentication & Authorisation infrastructure is updated to allow item metadata in local repository to be shared with registry through defined services

1c. Update Registration of Managed Collection with Registry

Some changes have take place with ISOCert that OmniLearn needs to know about. Dr Zaius has been replaced as collection manager by Dr Cornelius; the ISO-specific rating system has been refined and a Australian Standards compliance rating added; and the collection is now mirrored by the NTALA repository. Following a request by Boris the LEARN-ACT manager (who is co-responsible for the publishing of ISOCert), Den the OmniLearn manager enters this managed collection metadata into OmniLearn, and keeps the same identifier for ISOCert content.

  1. Local repository makes request to have registry record of its managed collection updated.
  2. Local repository is authenticated by registry
  3. Local repository supplies requisite managed collection metadata to registry (accountability, location, content description, metadata schema customisations, authorisation profile)
  4. Managed collection metadata is validated and replaces current metadata in registry

1d. Expose Registry for Harvesting (federation of federations)

OmniLearn, a federation of learning content providers, itself is to join an international federation, InterLearn: InterLearn is thus a federation of federations. Den the OmniLearn manager enters into negotiation with InterLearn; InterLearn sends out a legal team and an SLA contract for Den to sign. Once agreement has been reached, InterLearn registers OmniLearn; the procedure follows 1: Register Repository with Registry. Den adds an interface harvesting to his registry, similar to what his federatees have already put in place in their repositories. InterLearn management and Den authorise each other’s registries to synchronise their metadata records, with InterLearn making the necessary metadata scheme adjustments.

  1. Registry makes request to join registry of registries.
  2. Registry is authenticated by registry of registries
  3. Registry supplies requisite registry metadata to registry of registries (accountability, location, content description, metadata schema, authorisation profile, SLA)
  4. Registry metadata is validated and stored in registry of registries
  5. Authentication & Authorisation infrastructure exchanged to allow item metadata in registry to be shared with registry of registries through defined services
  6. Infrastructure is put in place in registry to allow its content to be pushed or pulled into registry of registries

2. Push Metadata of Item into Registry

Boris the LEARN-ACT Manager wishes to register Vaughan’s learning object on widgets with OmniLearn. He sends the metadata record for his learning object to OmniLearn: this contains a global identifier for the object, a link to two SCORM instances of the same learning object on different servers (resource metadata), a LOM description with keywords, a core competence description, and some reviews of the learning object from e-learning-reviews.com.au (content metadata). OmniLearn authenticates the request, and stores the data that Den has decided it requires from Boris for registration. Den is not interested in third party reviews at this stage, so OmniLearn ignores the e-learning-reviews.com.au reviews.

  1. Local repository sends metadata instance for an item to the registry (leviable data), which the registry selectively ingests (levied data).
  2. Registry validates the metadata submitted
  3. Metadata–content item association is made discoverable through a metadata resolution service
  4. Metadata is associated with content item through their respective identifiers

2a. Register Metadata of Item into Registry

Den the OmniLearn Manager has ingested some metadata on a learning object from LEARN-ACT into OmniLearn: a global identifier for the object, a link to two SCORM instances of the same learning object on different servers (resource metadata), a LOM description with keywords, and a core competence description (content metadata). Den translates the LOM to Dublin Core, which is what OmniLearn uses for searchable. The metadata is associated with the identifier—as is the hyperlink to the SCORM object itself. The object is now searchable and discoverable through OmniLearn, though the authorisation to use it (accessioning) is still LEARN-ACT’s responsibility.

  1. Registry transforms metadata from source schema to its own, if necessary (levied > registration).
  2. Registry selects registration data to be exposed (reexposed data)
  3. Reexposed data is exposed (made discoverable) to end users

2b. Register Metadata of Item from Managed Collection into Registry

Den the OmniLearn Manager has ingested some metadata on a learning object in the ISOCert managed collection, which was included with the other records from LEARN-ACT. Den needs to ensure his registry preserved the information that the learning object belongs to ISOCert: access to ISOCert has a distinct access policy his users need to know about, and the ISO-specific certification applied to the collection is of interest as well. Since the records are on LEARN-ACT, they are not ingested any differently than other LEARN-ACT records. But the ISOCert records need to be registered, as a batch, as belong to ISOCert, as well as being hosted on LEARN-ACT.

  1. Registry transforms metadata from source schema to its own, if necessary (levied > registration).
  2. Registry selects registration data to be exposed (reexposed data)
  3. Registry adds to the reexposed location metadata the managed collections that the record belongs to.
  4. Reexposed data is exposed (made discoverable) to end users

2c. Deposit Metadata into Dropbox (aggregator)

As discussed in the conceptual model, calling a federator a registry implies a degree of metadata trustworthiness: the authority information about the metadata is preserved (including provenance and timestamping), and is open to query in order to verify the reliability of the description. It also implies service trustworthiness: there is an SLA in place between the federate and federator, which guarantees a minimum level of availability and longevity. But it is also possible for a federation to be set up with the federator acting more like a "dropbox". The provenance and authority of metadata is not preserved, and there is no formal SLA involved in the federation. Indeed, the federation may not involve the federatees as parties at all: the federator may simply ingest and retain all metadata openly available for harvesting, without any longterm guarantee that the metadata will be updated or that the federatee local copies will remain available.

  1. Dropbox ingests metadata records openly available for harvesting.
  2. No preliminary establishment of SLA, access profiles, subject matter, metadata schema conformance &c takes place.
  3. Authority metadata relevant to the ingestion, including provenance and time stamp, are not preserved.
  4. There is also no guarantee of metadata updating, since there is no SLA in the federation.
  5. End users interact with the Dropbox federator the same way they would with a registry, but with diminished trustworthiness.

3. Pull Metadata of Item into Registry

OmniLearn does its monthly trawl of learning content repositories. Checking the table of contents of LEARN-ACT against itself, it discovers that Boris has added a new course on widgets by Vaughan since last month. Vaughan’s course is not in the OmniLearn registry. OmniLearn requests the agreed-on metadata (levied data) for this item from Boris (and whatever other metadata Boris has exposed, just in case), including a link to the item itself. There are two servers the metadata is stored at within LEARN-ACT; connections to the first currently time out, but OmniLearn access the metadata through the second. It stores the metadata for further processing.

  1. Registry retrieves metadata instance for an item from the local repository.
  2. Registry validates the metadata submitted
  3. Metadata–content item association is made discoverable through a metadata resolution service
  4. Metadata is associated with content item through their respective identifiers

4. Deactivate Metadata of Item in Registry

Den no longer wishes to provide access to Vaughan’s course on widgets through his registry OmniLearn. However he does not want to delete the Vaughan entry permanently. Den flags the metadata for the item as not publicly accessible. The record is preserved in the registry, and Den can consult it himself; but searches triggered externally will not return Vaughan’s course, and queries involving its identifier will not return metadata records from OmniLearn. Such queries may still be successful on LEARN-ACT; but that is no longer Den’s concern.

  1. Record for item is identified in registry.
  2. Record is flagged as not publicly accessible (not discoverable)

5. Delete Metadata of Item in Registry

Den no longer wishes to retain any record of Vaughan’s course on widgets in his registry OmniLearn. Not only does he no longer wish to provide access to the course, but there is no business reason to retain any historical record (audit trail) of the learning object. Den deactivates the record (to allow the process to be undone, and to finalise any arrangements necessary for a replacement item.) He then deletes the record of the item in the registry permanently. If the item reappears in the registry, it will need to be as a new record.

  1. Record for item is identified in registry.
  2. Record is permanently deleted.
  3. Registry indexes are updated, so that item is no longer discoverable.

6. Update Metadata of Item in Registry

Vaughan has generated a new piece of metadata for his course on widgets, and deposited it with LEARN-ACT. This is a handcrafted Dublin Core description instead of a LOM description: Vaughan wasn’t happy with the automated LOM > DC translation used in OmniLearn’s searches. Wary of Vaughan’s metadata skills, Boris does not want to throw out the original LOM description. So he publishes Vaughan’s Dublin Core as Version 2 of the course metadata in LEARN-ACT, and pushes it up to OmniLearn. He includes the item’s global identifier.

OmniLearn already has two metadata records about the course: Version 1 of the description from Boris, and a list of acceptable prerequisite courses from various regional accreditation boards. Den does not want to treat this new metadata record from LEARN-ACT as separate from the first. Instead, he creates an aggregate digital object, linking to Version 1 and Version 2, and resolving by default to the active version. Currently, it resolves to Vaughan’s DC record; Den may switch it back to his own DC record down the track. Den’s original DC record is kept in the registry, but it is no longer active, and by OmniLearn policy not searchable.

  1. Metadata record targeted by Metadata Manager is identified in registry.
  2. New metadata record is ingested into registry.
  3. New metadata record is associated with item through item identifier.
  4. Digital object is created (if not already extant) linking to both new and old record as versions of the same piece of metadata.
  5. An active version is selected as the default resolution of the versioned digital object.
  6. Access to metadata record is mediated through new versioned object.

6a. Update Metadata of item in Managed Collection in Registry

Modulo changes due to metadata enrichment (updated metadata records need to be identified as belonging to the managed collection, and their collection-specific metadata kept consistent with the registry’s schema), there is no procedural difference from updated a generic item’s metadata.

7. Reuse item and reregister

Barry accesses Vaughan’s course on widgets via OmniLearn. He creates a new derivative course, repurposing the original: he changes the course to refer to the proper disposal of widgets, which means adding some content and concentrating on the biodegradability of widgets. He also localises the compliance references of the course to the more stringent requirements of the Territory. He also generates a metadata description for his new course, based on the description for Vaughan’s course, but with some new keywords. Barry uploads his course to NTALA, the NT repository. Farah, the NTALA manager, wants this course registered in OmniLearn, as a new version of Vaughan’s original. She submits a link to the course on NTALA, a metadata record, and a global identifier to the course which she has already assigned.

Den the OmniLearn Manager takes this information and registers Barry’s course as a new item. The NTALA item is a version of Vaughan’s original on LEARN-ACT. Den associates the two through the National e-Learning Versioning service, which contains a record linking the two. Barry’s course is independently discoverable, but OmniLearn mashing up with National e-Learning Versioning will display a notice, whenever Barry’s course is accessed, that it is based on Vaughan’s course. Likewise accesses to Vaughan’s course through OmniLearn present a link to Barry’s version.

  1. New item is registered with registry, per Events 2 and 2a.
  2. Versioning service is updated to contain versioning relation between new and old item, identified through identifiers.

8. Discover item through registry (Search)

Muriel, tasked with instructing Perth manufacturers on using widgets, uses OmniLearn to find out what resources are already available. She types “widgets use” into the OmniLearn portal. A list of registered courses is displayed, with links to the repositories housing them, and to the metadata descriptions stored in the registry. Each returned course has the string “widget(s) use” occur somewhere in its reexposed data. A second list is presented, under the heading “You may also be interested in…”. This list is retrieved through a thesaurus engine searching the metadata for synonyms, hyponyms and hypernyms of “widgets” + “use”; it returns courses with metadata including such strings as “gadget manipulation”, “capsule operation”, and “thingy doing”.

Muriel browses through the descriptions, and Vaughan’s course strikes her as the most appropriate. Muriel has retrieved the published metadata for Vaughan’s course, and now has an identifier through which she can access the course itself on LEARN-ACT.

  1. Registry receives request from end user for item search, through a well-defined protocol controlled by the registry. The search is parameterised on search words and phrases.
  2. The registry formulates and executes a query of its records, in accordance with the protocol.
  3. The registry presents a listing of matching items, with enough metadata accessible to allow the end user to discriminate between them (browse).
  4. Possibly after several iterations, the end user uses the results returned by the registry to identify a target item as satisfying their requirements.
  5. The registry keeps a log of the user’s attempts at discovery.

8a. Discover item through registry (Search by Field)

Muriel, tasked with instructing Perth manufacturers on widgets make from plastic, uses OmniLearn to find out what resources are already available on perspex. She goes to the OmniLearn portal, and selects Advanced Search. The advanced search lists the various LOM fields for each learning object available for search, including author, sector, and classification. Muriel selects the “plastics” classification and types “perspex”. The classification has a limited vocabulary, and “perspex” is not a recognised type of plastic, so internally the search fails. But the synonyming engine knows that perspex is a type of Polymethyl methacrylate (acrylic glass), and suggests the alternative search for “acrylic”.

A list of registered courses matching “plastic = acrylic” is displayed, with links to the repositories housing them, and to the metadata descriptions stored in the registry. Muriel browses through the descriptions, and Vaughan’s course strikes her as the most appropriate, since it is not specific to one type of acrylic. Muriel has retrieved the published metadata for Vaughan’s course, and now has an identifier through which she can access the course itself on LEARN-ACT.

  1. Registry receives request from end user for item search, through a well-defined protocol controlled by the registry. The search is parameterised on search words and phrases, and field names.
  2. The registry formulates and executes a query of its records, in accordance with the protocol.
  3. The registry presents a listing of matching items, with enough metadata accessible to allow the end user to discriminate between them.
  4. Possibly after several iterations, the end user uses the results returned by the registry to identify a target item as satisfying their requirements.
  5. The registry keeps a log of the user’s attempts at discovery.

8b. Discover item through registry (Browse Category)

Muriel, tasked with instructing Perth manufacturers on widgets made from plastic, uses OmniLearn to find out what resources are already available on perspex. She goes to the OmniLearn portal, and selects Browse by Category. The portal returns a list of classifications of courses derived from the courses’ LOM metadata, such as materials, manufacturing process, and industry. When “materials” are selected, the various recognised types of materials are listed, drawn from the agreed materials vocabulary.

Muriel selects “plastics”, and then “acrylics”. A list of registered courses matching “materials = acrylic” is displayed, with links to the repositories housing them, and to the metadata descriptions stored in the registry. Muriel browses through the descriptions, and Vaughan’s course strikes her as the most appropriate. Muriel has retrieved the published metadata for Vaughan’s course, and now has an identifier through which she can access the course itself on Boris’s repository.

  1. Registry processes request from end user for browse category as a search for all records whose classification matches that category. The search is parameterised on the classification field name and the category as field value.
  2. The registry formulates and executes a query of its records.
  3. The registry presents a listing of matching items, with enough metadata accessible to allow the end user to discriminate between them.
  4. The end user uses the results returned by the registry to identify a target item as satisfying their requirements.
  5. The registry keeps a log of the user’s attempts at discovery.

9. Request registered item

Muriel has discovered Vaughan’s course on widgets made of plastic through OmniLearn: she knows that it has the global identifier 1.2.3.4#von, and it is held at LEARN-ACT. Muriel clicks on the link provided by the OmniLearn portal. She is taken to LEARN-ACT, which asks for a user name and password. On authentication, the repository establishers through its Access Control List whether Muriel has clearance to access the course. She has, and the repository tells her how: Vaughan’s course is available on CD ROM from a Fishwyck PO Box for AUD 200, and a non-disclosure agreement needs to be signed—contact Vaughan Industries by snail mail for more information. Miffed that she wasn’t warned about this by OmniLearn, Muriel writes a letter to Vaughan Industries...

  1. End user requests the item of the repository.
  2. Repository establishes authentication and authorisation for the end user.
  3. The repository delivers the item to the user, according to a well-defined protocol.
  4. The repository logs data about the user’s access to the item.

9a. Request registered item from Managed Collection

Muriel has discovered Vaughan’s course on preparing widgets through OmniLearn: she knows that it has the global identifier 1.2.3.4#von, that it is held at LEARN-ACT, and that is belongs to the ISOCert managed collection. Because OmniLearn knows about the managed collection, it alerts Muriel to the ISOCert non-disclosure agreement. Muriel clicks on the link provided by the OmniLearn portal. She is taken to LEARN-ACT, which asks for a user name and password. On authentication, the repository establishers through its Access Control List whether Muriel has clearance to access the course. She has. Since LEARN-ACT also knows about the managed collection, it then asks Muriel to digitally sign the ISOCert non-disclosure agreement. She then is allowed to download the learning object.

  1. End user requests the item of the repository.
  2. Repository establishes authentication and authorisation for the end user.
  3. Repository establishes any additional authorisation for the end user required by the managed collection.
  4. The repository delivers the item to the user, according to a well-defined protocol.
  5. The repository logs data about the user’s access to the item.

9b. Obtain Metadata for item

Muriel has discovered Vaughan’s course on preparing widgets through OmniLearn: she knows that it has the global identifier 1.2.3.4#von, and it is held at LEARN-ACT. Rather than going to the item on LEARN-ACT, she wishes to explore the available metadata on the item in OmniLearn. By default, OmniLearn displays only a summary metadata record; Muriel browses the course prerequisites for the item (which are not displayed in the summary), and then the complete metadata map of the record. Muriel saves the retrieved metadata to disk using the registry’s packaging service.

  1. User identifies metadata record (typically via identifier for item it describes).
  2. User requests particular parts of the record—which may include the entire record, specific fields, or a specified length.
  3. Specified parts of the record are delivered to the user.
  4. (Optional) The delivered metadata record or subrecord is encoded and/or packaged for the user as a single object, depending on registry capability.

10. Migrate Repository

Boris is getting out of the repository game, and OmniLearn management has agreed to migrate LEARN-ACT content to two other repositories in the federation: NTALA for hospitality industry items, and NTALA2 for everything else. Boris gives Farah and Sarah, the NTALA and NTALA2 managers, full access to his repository; the two repository managers ingest his content. Farah retains Boris’s item identifiers, but translates Boris’s vocabulary of materials, embedded in his metadata, into her own. Sarah mints new identifiers (DSpace forces her to), but has generated a mapping table from LEARN-ACT to NTALA2 identifiers. Both repository managers inform Den the OmniLearn Manager that they have duplicated LEARN-ACT content between them.

When he has heard from both, Den harvests the metadata records exposed by the two new repositories, to ensure that they include all of Boris’s items; he needs the NTALA2 mapping table to do so. Once satisfied, he deactivates all the LEARN-ACT records, and activates the newly ingested metadata records: he knows that the new NTALA metadata will be different to LEARN-ACT’s. Den maintains the original global identifiers for the items, mapping them to NTALA2: that way the metadata records added by third parties, such as course prerequisite listings, will still attach to the re-homed items.

  1. Registry receives and verifies list of new locations for item keyed to item identifiers.
  2. Registry links to new instead of old location as resolution of its item identifier.
  3. Registry pulls in new metadata record(s) for item from new location, through Pull Metadata of Item into Registry.
  4. Registry identifies old metadata record that the new record corresponds to.
  5. Registry deactivates or deletes the old metadata, and activates (exposes) the new.

10a. Disaggregate managed collection

The ISOCert managed collection is disbanded, due to lack of funding for a manager. This does not mean that its content goes anywhere: the objects are still hosted by LEARN-ACT (though the mirroring arrangement with NTALA is cancelled), and still legitimately form part of its content. Of the collection-specific metadata, the ISO-specific rating is deleted, since it cannot be maintained. However, the Australian Standards compliance ratings are considered useful (and do not conflict with the repository’s metadata scheme, by definition), and are retained. Both Den the OmniLearn manager and Boris the LEARN-ACT manager eliminate the record of ISOCert, and any policing of authorisation specific to the collection. (Once disaggregated, the collection may be deleted as a batch if appropriate; this then becomes a special case of Delete Metadata of Item in Registry.)

  1. Authorisation procedures specific to managed collection are removed from local repository.
  2. Metadata in items specific to managed collection may be eliminated, if its ongoing accuracy cannot be guaranteed.
  3. Record of managed collection is deleted from local repository.
  4. Record of managed collection is deleted from registry.

10b. Rehome item (content move location)

A content item is being rehomed: it was hitherto stored at LEARN-ACT, but will henceforth be stored at NTALA instead. The item and its metadata do not change other than in their location, but the OmniLearn registry will treat the two instances of the item as distinct, as they are harvested differently. To guarantee that the registry treats the instances as representing the same work, the two instances need to share the same identifier at least at the FRBR manifestation level; and the registry needs to be aware of that identifier, rather than overriding it.

The default presumption is that metadata and their referent are located in the same local repositories. The case where the metadata record is owned independently of the content item is addressed in 10c: REHOME METADATA OF ITEM. But given how harvesting actually works, it is the location of the metadata rather than of the content item that matters.

  1. The registry ingests a metadata record from repository A. The metadata record is keyed to a content item through a global identifier N.
  2. The metadata record is deleted from repository A, along with its referent content item.
  3. The metadata record is added to repository B, along with its referent content item.
  4. The registry harvests repository A, and notes that the metadata record keyed through N is deleted.
  5. The registry does not permanently delete record N, either because it has been alerted of rehoming by A, or through registry policy.
  6. The registry harvests repository B, and notes that it now includes a metadata record keyed through N, corresponding to a record it had previously deleted.
  7. The registry treats this is a new version of the same metadata record, per 6: UPDATE METADATA OF ITEM IN REGISTRY: even if the records are otherwise identical, the home the record is harvested from counts as harvesting-specific metadata, which goes to metadata authority.

10c. Rehome metadata of item (metadata change ownership)

LEARN-ACT continues to host content items, but transfers all its metadata to be homed at NTALA. This is possible because metadata is indexed to content item through persistent identifiers. As a result, OmniLearn does not need to harvest from LEARN-ACT any more: registries care only about the location of metadata records, which themselves link to content, rather than ingesting content directly. The use scenario is identical to the foregoing (10b: REHOME ITEM); the only fields changing are (1) where the content item persistent identifier happens to map to, which is transparent to the registry; and (2) the access profile for the content item, which the registry needs to alert its users to.

The access profile is contingent on the policies of the content host rather than the metadata host. If metadata hosting and content hosting are uncoupled, the metadata record needs to reveal explicitly (or make discoverable) what the content host is, so the registry can infer the right access profile.

[The issue of ownership of metadata has been raised in conjunction with rehoming: if metadata is rehomed, who is responsible for it? There is no one answer, but this does not affect the use scenario as it stands.]

11. Query Registry

Den the OmniLearn Manager is auditing the registry’s performance for October. He logs in to a manager-only portal, and requests reports from a menu of prefab queries: uptime, throughput, number of repositories and items registered, number of users, most frequent queries, most frequently accessed items. Den cuts and pastes at will, and generates his report for OmniLearn management.

  1. Registry manager makes query of registry system, including its logs and backend database.
  2. System returns query result.

13. Classify item

As a value-added service to their users, Den the OmniLearn manager hires Shemp to go through all the metadata records currently held at OmniLearn, and classify them in order of difficulty, as Beginner, Intermediate, and Advanced. Den has a contract with Shemp to do ongoing updating of the level classifications as new items are ingested, although he adds a disclaimer to OmniLearn that not all items are guaranteed to have a level classification. This value-added metadata is maintained on the registry, and linked to the metadata records ingested for the items they refer to. The classifications are exposed to users, and can be used for discovery, as either search fields or browse categories.

  1. Registry manager creates classification field for an item, as a field of the item’s metadata record.
  2. Metadata provider populates classification field with a value from a given taxonomy.
  3. Classification metadata is exposed to users.

13a. Annotate item

As a value-added service to their users, Den the OmniLearn manager hires Shemp to add annotations to the metadata records currently held at OmniLearn. The annotations have scope over either the entire item content, or particular sections of the content; they mostly consist of cross-references (Annotea “bookmarks”) to related material in the same federation. Den reserves the right to throw annotation open to all registered federation users later on; and he adds an appropriate disclaimer to OmniLearn that the annotations do not necessarily reflect the original author’s thinking. This value-added metadata is maintained on the registry, and linked to the metadata records ingested for the items they refer to. The annotations can be viewed in conjunction with their references through some rendering protocol agreed on between the federatee and federator.

  1. Registry manager creates annotation record for an item, as a field of the item’s metadata record.
  2. Metadata provider populates annotation field with various annotations, potentially anchored to parts of the item.
  3. Annotation metadata is exposed to users.
  4. Optionally, annotations are displayed alongside the retrieved item they refer to.

13b. Recommend item

As a value-added service to their users, Den the OmniLearn manager hires Shemp to add recommendations to the metadata records currently held at OmniLearn. The recommendations are binary evaluations (Recommended/Not Recommended) assigned to an item, optionally accompanied by a domain the recommendation applies to, drawn from an ontology (e.g. Recommended for Vocational Training, Recommended for Course Evaluation). Den has a contract with Shemp to do ongoing updating of the recommendations as new items are ingested, although he adds a disclaimer to OmniLearn that not all items are guaranteed to have a recommendation. This value-added metadata is maintained on the registry, and linked to the metadata records ingested for the items they refer to. The classifications are exposed to users, and can be used for discovery, as either search fields or browse categories.

  1. Registry manager creates recommendation field for an item, as a field of the item’s metadata record.
  2. Metadata provider populates recommendation field with a binary value and optionally a domain value from a given taxonomy.
  3. Recommendation metadata is exposed to users.

13c. Rate item

As a value-added service to their users, Den the OmniLearn manager hires Shemp to add ratings to the metadata records currently held at OmniLearn. The ratings are numerical evaluations assigned to an item. Den has a contract with Shemp to do ongoing updating of the ratings as new items are ingested, although he adds a disclaimer to OmniLearn that not all items are guaranteed to have a recommendation; he reserves the right to throw ratings open to all registered federation users later on, in which case he would display the average rating recorded and the number of raters logged. This value-added metadata is maintained on the registry, and linked to the metadata records ingested for the items they refer to. The ratings are exposed to users, and can be used for discovery, as either search fields or browse categories.

  1. Registry manager creates rating field for an item, as a field of the item’s metadata record.
  2. Metadata provider populates rating field with a numeric valu.
  3. Rating metadata is exposed to users.

14. Change search ranking for item

The search engine the registry uses to retrieve results is periodically tuned according to a search result ranking algorithm. This is based inter alia on what metadata field in the record a keyword occurs in. Calculating relative rankings is an intensive process, and is not done on the fly. Whenever a metadata record is updated, the item search ranking will be out of sync with the calculated ranking for the record, especially if relative rarity of keyword in the corpus is used, or if the functionality of the ranking algorithm itself is adjusted. Moreover, items the register manager deems of high relevance may have their ranking manually adjusted. So the registry manager may occasionally need to manually trigger a run of the ranking procedure for an updated record, for a batch of records (e.g. a managed collection), or for the entire registry.

  1. Registry ingests new metadata record(s) OR ranking algorithm used by registry is changed.
  2. Registry manager reruns search engine ranking procedure for given records, or for entire registry.

15. Identity Management of Registry User

Muriel, a WA-based trainer, wishes to start using OmniLearn. Since the registry is only available to registered users, she submits an application to Den the OmniLearn manager. Den authenticates Muriel through some policy-agreed scheme, and solicits from her metadata relevant to access policy (e.g. membership of trade organization). Depending on policy, Den may take extra steps to verify this metadata. Once Muriel is authenticated and an authorization profile can be constructed for her, a record with identifier is created for her in the registry, and authenticated access is granted to the registry.

  1. User applies to Registry manager to be authorised to use registry.
  2. Registry manager authenticates user.
  3. Registry manager obtains pertinent metadata about user.
  4. Registry manager constructs authorisation profile for user.
  5. Registry manager creates user profile record in registry for user, containing identifier and authorisation profile.
  6. User is granted access to registry through authentication protocol.

15a. Notify/Subscribe Registry User

Muriel, a WA-based trainer, wishes to be notified of any new courses to do with barbecuing added to OmniLearn. She subscribes to a feed offered by OmniLearn relying on an established subject matter taxonomy (which includes plastics manufacturing). As new metadata records are ingested or updated in the registry, users subscribed to feeds that the records fit with are notified of the new records added. When OmniLearn ingests a newly created metadata record about plastics manufacturing from LEARN-ACT, Muriel is sent a notification, consisting of a link to the new item and a metadata summary.

  1. Registry offers subscriptions to notifications based on registry content changes (or status). Content-based subscriptions are differentiated through some metadata-specific ontology.
  2. End user subscribes to a subscription.
  3. An event occurs matching the subscription profile (e.g. ingestion of matching metadata record).
  4. A notification is formulated based on the given event and subscription profile.
  5. The notification is issued to the subscribing user.

16. Archive registry

A registry will periodically need to be archived, for various reasons: periodic backup; escrow (data embargoing, last resort backup); versioning. This involves making a database dump of all the stored metadata records, and all the associated identifier-to-locator mappings.

  1. Registry manager dumps content of all hosted metadata records to registry archive.
  2. Registry manager dumps mappings of all identifiers used as locators which are the responsibility of the registry.

17. Police rights management

1. The course on widgets offered at LEARN-ACT includes an excerpt from Martin Luther King’s “I have a dream” speech. The King family estate collects royalties for uses of the speech. Accesses to the module containing the speech are tracked at the local repository level, and an access count is generated to calculate royalties payment.

2. A derivative course based on the LEARN-ACT course is hosted on NTALA. As part of the terms of reuse, the LEARN-ACT course author sets restrictions on who can access the derivative course: wherever the derivative course is hosted, LEARN-ACT access restrictions must be observed. The NTALA repository accesses the current LEARN-ACT policy restrictions as an XACML profile, and applies them to all instances of course material derived from LEARN-ACT material, as discovered through a relationship server (or through mandatory metadata included in the derivative courses).

In both cases, rights management is policed at the local repository rather than the registry: the registry acts only as a referatory, and since it does not itself publish content, it cannot police content access. It should however alert its consumers as to the policy requirements of the appropriate copies, which are inferred through policy metadata on the local repository record and the content metadata, both stored in the registry.

Appendix: OpenDOAR

We include here usage scenarios in an alternate, looser model of repository federation: the OpenDOAR model. Under this model. Google Custom Search (or equivalent) is used to do full text search of federatee respositories. The federating consists only in the inclusion of the federatee on the Google search site list. While computationally discovery is transacted on only one site (in Mountain View CA), conceptually this is federated search, since there is no formal notion of registration or authoritative metadata, and no adjustment of metadata to conform to a federation profile. The federation is reduced to a roster of repositories on which full text search is transacted. These use cases are prefixed with OD.

OD1. Register Repository with Registry Roster (federated search)

The roster of federated search sites is treated as a registry: authority metadata for the local repository is established, and an SLA is negotiated.

  1. Local repository makes request to join registry.
  2. Local repository is authenticated by registry
  3. Local repository supplies requisite repository metadata to registry (accountability, location, content description, SLA)
  4. Local repository metadata is validated and stored in roster

OD1a. Add Repository to Directory Roster (federated search)

The roster of federated search sites is treated as a directory: the local repository is exclusively a data source, and the local repository manager is not an actor, so there is no contractual relationship underpinning the federation.

  1. Local repository is identified and authenticated by registry
  2. Publicly available local repository metadata is harvested to directory (accountability, location, content description)
  3. Local repository metadata is validated and stored in roster

OD8. Discover item through roster (Full text Federated Search)

  1. Federated search site receives request from end user for item search, through a well-defined protocol controlled by the registry. The search is parametrised on search words and phrases.
  2. The search site formulates a query of the search string as a full text search.
  3. For each repository on the roster, the search site triggers a full text search on the search string over the contents of that repository as exposed on the web.
  4. The search site presents a listing of matching items, from each site on the roster. Absent item metadata, the listing is accompanied with enough repository metadata to allow the end user to discriminate between them according to authority (browse).
  5. Possibly after several iterations, the end user uses the results returned by the search site to identify a target item as satisfying their requirements.
  6. The search site keeps a log of the user’s attempts at discovery.