On 6/16/10 4:19 PM, David Winslow wrote: > On 06/16/2010 03:10 PM, Sebastian Benthall wrote: >> >> Agreed, a more constrained extension would be good. I like >> *.geonode.xml, mind the user will have to name the xml file >> accordingly >> (how do they generate them?) >> >> >> Unclear. But it's ISO19139 compatible, so hopefully _something_ >> generates that.
My take on it is that we should allow any of the usual formats GeoNetwork accepts (19115 a'la ESRI, 19115 legacy, vanilla 19139, etc) and somehow convert on the fly to GeoNode's 19139 profile. GeoNetwork comes with XSL transforms to go from one to another, we should take them and make sure there are transformations to GeoNode's profile available. This is like this because I _think_ the most common case (or at least one we should really support) will be importing a bunch of files from ESRI products (eg, as exported by ArcCatalog?). Now, the way things are set up so far kind of forces metadata to be in our profile (which adds almost nothing to 19139 but a couple restrictions). But sooner or later GeoNoders will need/require being able to stick to their own profiles. I think we should devote some time to try out this use case of allowing the incoming metadata records to be in any of the default geonetwork supported formats, and convert them to GeoNode's. An easy (though kind of tricky) way of doing so would be: - insert the record into geonetwork verbatim - get the resulting uuid - ask geonetwork for the record in GeoNode's format - issue an update request using the returned GeoNode profile format I'm not completely sure this would work out of the box though? my 2c gabriel >> >> -- >> Sebastian Benthall >> OpenGeo - http://opengeo.org >> > > This seems like an important point to get straight (basically without it > metadata won't happen.) What do we need to do to get some clarification > on this? > > -d > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers.
