{"id":559,"date":"2011-05-06T09:19:46","date_gmt":"2011-05-06T13:19:46","guid":{"rendered":"http:\/\/www.kralidis.ca\/blog\/?p=559"},"modified":"2011-05-06T09:21:39","modified_gmt":"2011-05-06T13:21:39","slug":"csw-and-repository-thoughts","status":"publish","type":"post","link":"https:\/\/www.kralidis.ca\/blog\/2011\/05\/06\/csw-and-repository-thoughts\/","title":{"rendered":"CSW and repository thoughts"},"content":{"rendered":"

CSW<\/a> allows for querying various metadata models (e.g. Dublin Core, ISO).\u00a0 In pycsw<\/a>, our current model is to manage one repository per metadata model (or ‘typename’ in CSW speak).\u00a0 That said, we setup each repository to have one column per ‘queryable’ (as defined in CSW and application profiles), which we parse when loading metadata.\u00a0 We also store the full metadata record as is (for GetRecords ElementSetName=’full’ requests).<\/p>\n

Complexity increases as we start thinking about support for more information models, and transforming to\/from requested information models (via CSW GetRecords\/GetRecordById ‘outputSchema’ parameter).\u00a0 Having said this, I’ve started to think about a core, agnostic information model which any metadata format could map to (for lowest common denominator).\u00a0 This way, pycsw will always know the core information model queryables, which could be stored in columns as we currently do now.\u00a0 The underlying queries would always query against the queryable columns.\u00a0 Aside: it would be great to have a GDAL for metadata (MDAL anyone?).<\/p>\n

But what about a unified repository where just the metadata is stored in full (GeoNetwork<\/a> does it like this)?\u00a0 In this scenario, we would need heavy use of XPath queries on the full XML document in realtime.\u00a0 The advantage would be a.) less parsing on metadata loading b.) one repository is always loaded\/queried c.) less configuration for the catalog administrator.<\/p>\n

I like the use of XPath, but wonder about how this scales as additional databases are supported.\u00a0 We currently support SQLite, which is great for simplicity (and Python SQLite bindings allow for mapping Python functions).\u00a0 SQLite has no XPath support (but we could support this with Python bindings).\u00a0 PostgreSQL does (if you build with libxml2<\/a>), as does MySQL.\u00a0 As well, I’m not sure about the performance implications (and how deep XPath queries are in the database fetching, i.e. the entire XML document would have to be serialized before XPath queries are executed).<\/p>\n

Thoughts on a Friday morning.\u00a0 Anyone have any advice\/insight?<\/p>\n

 <\/p>\n\n\n