Skip to content
tomkralidis edited this page Jun 21, 2012 · 2 revisions

CSW allows for the implementation of profiles to the core standard. Profiles allow specification of additional metadata format types (i.e. ISO 19139:2007, DIF, Inspire etc.) to the repository, which can be queried and presented to the client.

For a profile to exist in pycsw, the following principles are realized:

  • additional typename(s)
  • additional outputschema(s)
  • extension of config.MODEL
  • mapping from profile's information to the core queryables
  • declaring other profile queryables
  • GetRecords output
  • Extended Capabilities configuration (if needed)
  • Extra profile configuration file that overloads sections like Repository, Service Metadata and CoreQueryables, if required (TK: not sure if overloading is needed as opposed to extending)

Repository issues

  • pycsw can use different database schemas for each profile, since each typename can be queried against
    • will need cross mapping on output, however (UC: user queries gmd:MD_Metadata, asks for outputschema DC)
  • Profile queryables are stored on a db table plus a column for the actual XML document
  • Queryables are stored in the profile configuration file and automatically loaded

Implementation

A plugin framework is required to support profiles at runtime based on user developed code.

In the codebase:

pycsw/
 server/profile.py # defines abstract profile object (properties and methods) and functions to load plugins
 profiles/ # directory to store profiles
 profiles/__init__.py # empty
 profiles/apiso/ # profile directory
 profiles/__init__.py # empty
 profiles/apiso/apiso.py # profile code

Profile Abstract Base Class

Profile code will be located in pycsw/profiles/. All profiles will have the following properties and methods):

A main profile class will have to be implemented (eg Iso):

  • __init__(self,configfile) will have to:
  • read the profile configuration,
  • set the typename,
  • create a mapping object (self.dcqueryables) to the core ogc queryables
  • declare if !ExtendedCapabilities are needed (self.has_extended_capabilities)
  • check_extended_capabilities(self, request) will have to be implemented in order to check the incoming request for extra parameters. When those are not valid, the method should return an empty dictionary
  • write_extended_capabilities(self, operationsmetadata) will have to be implemented to change the operationsmetadata section of the Capabilities document.
  • A MODEL dictionary will have to be added to represent the additional capabilities elements needed for this profile.
  • Extra namespaces will have to be added in the NAMESPACES dictionary, to be merged with existing namespaces from core profile

An additional DCMapping class will store the mappings from the profiles queryables to the queryables needed for the core CSW functionality, in case it is asked from the client.

Additionally for each profile a segment of code must be added in server/server.py to initialize the additional profile object under the sub-object self.profile. Also a merge between the core properties and the profile MODEL, namespaces and configuration file has to be done.

In general, a profile should extend the core configuration within Csw.__init__. Anything after that should be normal processing

Testing

Profiles shall implement test as per the Application Profile's abstract test suite (if one exists). Profiles shall also provide a tester application (same as tester/index.html, with requests specific to the profile.