deegree3 catalogueService (AKA CSW) Requirements
The following table gives a revised and complete overview of all catalogueService requirements. ID scheme is "csw-[g|h|q]-##" where "g" is for general requirements, "h" for harvesting specifics and "q" for query-related features.
ID |
Feature |
Minispec |
Status |
Priority (M-S-C-W)(*) |
Discussion |
csw-g01 |
Support CSW 2.0.0, ISO AP 0.9.3 |
Support CSW 2.0.0, ISO AP 0.9.3 according to OGC specs. |
Not started yet |
C |
- |
csw-g02 |
Support CSW 2.0.1 |
This was an intermediate CSW version. |
Don't start |
W |
- |
csw-g03 |
Support CSW 2.0.2, ISO AP 1.0 |
Support CSW 2.0.2, ISO AP 1.0 according to OGC specs. |
Not started yet |
M |
- |
csw-g04 |
Check CSW 3.0 draft for potential future requirements |
Do not implement CSW 3.0 draft, but check the spec for any potential future requirements (to be documented here, below). |
Not started yet |
M |
- |
csw-g05 |
Check INSPIRE Discovery Service for additional requirements |
Check the spec (and the SOAP framework) for any other requirements (to be documented here, below). |
Not started yet |
M |
It is supposed that the INSPIRE DS has to be available pretty soon. |
csw-g06 |
Support ebRIM profile |
Out of scope of CSW. |
Don't start |
W |
ebRIM experiments were not successful. Lots of problems. Specs and usage to be clarified by standardization bodies. |
csw-g07 |
Support Dublin Core |
Support Dublic Core metadata according to the specs. |
Not started yet |
M |
- |
csw-g08 |
Support FGDC |
FGDC metadata format is used in a variety of products and SDIs. That's why supporting this format could be useful. |
Not started yet |
C |
- |
csw-g09 |
Avoid object-relational mapping |
Do not use any kind of object-relational mapping for data access. Experience with deegree 2 CSW implemenation shows quite some disadvantages: Lack of flexibility, performance problems in queries and transactions |
Not started yet |
M |
- |
csw-g10 |
Avoid WFS usage as data access component |
(As above:) CSW implementation based on WFS as a data access component has shown to be too complex and less flexible. |
Not started yet |
M |
- |
csw-g11 |
Allow for a high degree of flexibility |
Extensions to the ISO metadata schema (and support of any other proprietary metadata schemas) shall be implementable as easy as possible. |
Not started yet |
M |
It is assumed that complete metadata sets are stored as one artefact. Experience shows that a redundancy-free metadata storage within or behind the CSW is not desireable. Only those elements which have to be used within queries are extracted to specific data elements – and those to be used for the GetDomain operation??? (see csw-g15) |
csw-g12 |
Improve Performance |
Experience with deegree 2 implemenation was that e.g. updates of already harvested datasets were very slow. This shall be improved. |
Not started yet |
M |
It is assumed that performance will be much better with a different data storage concept. |
csw-g13 |
Support cascading access to remote CSW instances |
- |
Not started yet |
S |
- |
csw-g14 |
Validate metadata records |
The CSW shall support a configurable validator component which can be switched on and off by configuration (and upon request) |
Not started yet |
S |
need perhaps a vendor specific parameter? |
csw-g15 |
Support the GetDomain operation |
- |
Not started yet |
C |
Might make data storage more difficult (cf. csw-g11) |
csw-g16 |
Allow for access constraints |
Metadata records shall be accessible for different user groups and for different operations (read/write). |
Not started yet |
S |
Is this a catalogueService feature or shall owsProxy be used? |
csw-g17 |
Allow for easy thesaurus usage |
Thesaurus usage in general shall be improved. |
Not started yet |
S |
What is meant here? |
csw-g18 |
Ship with easy-to-use editing and retrieval application |
The CSW package shall include a ready- and easy-to-use web application for metadata editing and retrieval. |
Not started yet |
S |
- |
csw-h01 |
Support Harvesting |
Support harvesting of full CSW instances, single CSW records, single files (via URL) |
Not started yet |
M |
Anything else – harvest OWS capabilities? What has to be supported according to CSW specs? |
csw-h02 |
Improve harvesting control |
It should be possible to remove harvest jobs and to request harvesting states |
Not started yet |
C |
Control interface to be added to web application which ships with the service? |
csw-q01 |
Allow for queries using a keyword of a specific thesaurus |
It is assumed that the CSW spec (or Filter Encoding) is not very clear when it comes to AND-combined filter conditions. For keywords it is though important that they can explicitly bound to a certain thesaurus. |
Not started yet |
M |
- |
csw-q02 |
Support stored queries |
Stored queries are defined in the CSW ebRIM profile. It is supposed that they are a nice vendor-specific enhancement of the service. |
Not started yet |
C |
- |
csw-q03 |
Improve support for Xpath expressions |
- |
Not started yet |
W? |
Probably a contradictory requirement to csw-g11 (flexibility) |
csw-q04 |
Support user-defined element sets |
Like for WFS it should be possible to return selected elements in GetRecord responses |
Not started yet |
W? |
Probably a contradictory requirement to csw-g11 (flexibility) |
(*) M-S-C-W: Must have, Should have, Could have, Won't have