Changes between Version 22 and Version 23 of ComposedMetadataRecords

Timestamp:

Aug 31, 2009, 11:27:40 PM (15 years ago)

Author:

simonp

Comment:

--

ComposedMetadataRecords

@@ -35 +35 @@
 The two components to be added by this proposal (in more detail):
 
- * WFS fragment harvester - this is a harvester that accepts (along with the usual harvester parameters) a WFS GetFeature query, a template 
+ * WFS fragment harvester - this is a harvester that accepts (along with the usual harvester parameters) a WFS GetFeature query, a template which will be for each feature and linked to metadata fragments (more than one fragment can be returned from a feature) plus permissions and categories for fragments and records created. Note: the template is only used to create records on the first run of the harvester. The WFS response to the GetFeature request is assumed to be in the form of fragments.
 
- * XLink resolver and cache - the geocat.ch sandbox uses and is developing an XLink resolver and cache mechanism. The implementation in the BlueNetMEST sandbox uses the same cache mechanism (based on Apache JCS) but has modified the resolver links
+ * XLink resolver and cache - the geocat.ch sandbox uses and is developing an XLink resolver and cache mechanism. The implementation in the BlueNetMEST sandbox uses the same cache mechanism (based on Apache JCS) but the resolver has been rewritten to handle (amongst other things) relative links to fragments in the same record and to avoid caching . See
+
+Minor changes were required to change the display of metadata fragments in the !GeoNetwork editor so that they cannot be edited. 
  
 Future work would add:
@@ -44 +46 @@
  * URN resolver to provide a level of indirection that can be used to cope with changing URLs and ensure referential integrity. Metadata fragments are linked into records using XLinks. XLinks can use URLs or URNs in the link attribute (xlink:href). URNs are intended to provide a permanent A service that provides the ability to register a urn and associated URL, and lookup a URL given a URN, would allow the implementation to use URNs in place of URLs, thus providing a measure of control over broken links/missing content which can occur if we were to use URLs.
  * Support for updating a fragment in !GeoNetwork- sometimes it makes sense for a fragment to be edited and saved back into the external database from which it was harvested. WFS-T support would be used to provide this facility.
+ * Change some other GeoNetwork harvesters (eg. OGC WxS capabilities harvester) to harvest fragments rather than complete metadata records using the same approach as the WFS fragment harvester.
  * Support in the editor for fragments: the original intention of subtemplates was that they be accessible from the editor ie. a user could select a fragment (eg. contact info) to use when editing that portion of a metadata record. Some work appears to have already been done in the geocat.ch sandbox on this function.
  * Access to fragments by other editor tools: Other editing tools (eg. the wizard based ANZMETLite tool) can use fragments in their interface to ease the metadata entry and editing process. Fragments harvested into !GeoNetwork should be accessible to these tools.