Provide test mechanisms to demonstrate interoperability with various metadata formats. TODO: need to further clarify
David: thanks for the comments.
1.) Good point. This is where the concept of profiling or rules around what GeoNode's metadata is/will be is important. The current codebase has a detailed metadata entry form which is bound to the underlying repo, written out as ISO and then inserted/updated to the OGC:CSW.
Given the various metadata formats, and required/optional/conditional elements in same, it would be a huge level of effort in GeoNode space to support everything, which I don't think is feasible. Rather, we should have a model that's perhaps more extensive than the current one and build around that.
But still, yes, when a user uploads a given metadata record which has elements that are not part of the GeoNode model, they will be lost as the updated metadata is written out.
Having said this, is it reasonable to assume that a user who uploads their own metadata XML doesn't need to deal with the metadata entry form on upload? Perhaps we could skip this view in this context (why would I want a metadata form if I have my own metadata?), and only update the main contact information, binding from the user profile information in the django db.
2.) on edit/save, the user profile/poc can/will be bound to the django db and pushed to appriopriate records in the OGC:CSW, by finding all applicable metadata uuid's, setting in django db and writing to OGC:CSW
Testing: we would need metadata documents in each format given in the GNIP. Can anyone point to small bundles of ISO/DC/FGDC metadata XML?
..Tom
Date: Tue, 10 Jan 2012 10:40:07 -0500
Subject: GNIP 4 - Accept XML Metadata with Uploaded Layer Data
From: dwin...@opengeo.org
To: geono...@opengeo.org
See proposal on the wiki: https://github.com/GeoNode/geonode/wiki/GNIP-4-----Accept-XML-Metadata-with-Uploaded-Layer-Data
I agree that this would be a desirable addition to GeoNode. However, I think there are some technical barriers to its implementation, and I don't see them discussed in the proposal.
1) Metadata schema:Right now GeoNode has a relatively rigid metadata model (in the sense of a Django model class) where all metadata fields are encoded as SQL columns. All layers therefore have the same set of metadata fields, and the detailed metadata form can only edit fields included in that model. If we allow the addition of arbitrary metadata documents, what should happen when the user goes to edit a metadata document that was uploaded with non-modeled fields? For that matter, will the SQL table have the appropriate values filled in for these uploaded documents?
2) LinkingGeoNode currently links (ie, via foreign key) metadata documents to a "point of contact" table in the database. The idea is that a single "point of contact" may be associated with many layers and updating the contact information for that one point of contact can affect the metadata for many layers. (Ideally, each "point of contact" corresponds to a user profile and can be modified through the profile management tools, although the system allows for "orphaned" contacts which correspond to a metadata document maintained by someone without a user account on GeoNode.) Should/Will measures be taken to avoid duplication of the contact records?