Virtual Collection Registry
For the virtual collection CMDI component, see: http://catalog.clarin.eu/ds/ComponentRegistry?item=clarin.eu:cr1:p_1271859438175
Introduction
A virtual collection (VC) is a collection that is the result of browsing or searching repositories rather than being the result of construction and first-time publication by an organization. Another characterization is that the resources in a VC are already available in other collections, and the VC can be considered a derived collection. 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 individual VC. The VC attributes are the VC’s metadata. VCs can also be created by importing a suitable VC specification. VCs should have two modes: "draft" when things can still change and they kind of remain in the private sphere of the creator and those he shares it with and "final" when the content is frozen and the VC metadat wil be harvested and available in CLARIN joint metadata repository.
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. At a certain moment the VC should be frozen or closed.
(b. 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.) Use case postponed, scenario is not very useful. (If the metadata is not considered reliable, what does that say about the resource: is that reliable? Probably not, so no sense in storing the metadata).
- 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.
- create a dynamic collection (~ query)
( freeze a search snapshot = catalog functionality )
- 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. VCs in the draft stage should be excluded. VC Requirements
- A VC registry is itself identified by a PID/URI
- The individual VCs are world readable, just as any metadata.
- For every registered VC, the VC registry creates a PID and maintains this.
- 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?
