Virtual Collection Registry

Introduction

A virtual collection (VC) is a collection that is the result of browsing or searching repositories rather than being the result of careful planning and creation. Nevertheless these VCs may need to be citable for future use and should therefore be able to be registered in a register, the VCR.

Use cases

1. VC Creation:

A user authenticates with a VC registry and creates a (initially empty) VC. Required attributes are: creation date, creator, purpose, ???. A PID that is issued by the VC registry identifies every VC. The VC attributes are the VC’s metadata,

2. Adding VC collection members

a A user browses through different (CLARIN compatible) metadata catalogues and identifies interesting resources. He is able to use the PID of the metadata record and add that PID to a VC he controls. This is suitable in case the metadata record persistency is considered reliable.

2. If the metadata record is not considered reliable, the metadata record can be copied into the VC registry, to avoid loosing the metadata and the embedded PID to the resource.

3. A user can also add links to resources directly to the VC (without a metadata record as proxy) but in that case is obliged to provide his own metadata record for the resource.

4. create a dynamic collection (~ query)

( freeze a search snapshot = catalog functionality )

5. store a metadata seach query (or its results) as a virtual collection

3. Searching

The VC supports searching on the basis of all relevant VC attributes: creation date, creator, purpose, ???

4. Retrieval

The VC will deliver an adequate: HTML, JSON, XML (default) representation of the VC’s metadata when presented with the VC’s PID, depending on content negotiation.

5. Other Use Case Issues

Should delete and modification be possible?

All functions should be achievable by webapp GUI and/or WS

VC metadata proliferation

The VC registry also serves as an OAI data provider and the VC metadata is harvested and stored in the CLARIN joint metadata repository. VC Requirements

1. A VC registry is itself identified by a PID/URI
2. The individual VCs are world readable, just as any metadata.
3. For every registered VC, the VC registry creates a PID and maintains this.
4. The VC registry functions are accessible through a REST WS and a GUI

Implementation Issues

Use copy/paste to specify the new VC member PID in the VCR?