Changes between Version 16 and Version 17 of ComposedMetadataRecords

Timestamp:

Aug 31, 2009, 9:11:44 PM (15 years ago)

Author:

simonp

Comment:

--

ComposedMetadataRecords

@@ -20 +20 @@
 
 === Links ===
- * '''Subtemplates''': Metadata fragments are equivalent to subtemplates (which were only partially implemented in !GeoNetwork). Subtemplates appear to have been an extension of the template concept in !GeoNetwork. Templates are complete metadata records with some elements filled in. A user can clone such a record for use in the editor as a template. At this stage all connection between the template and the cloned record is broken ie. changes to the template are not visible in the cloned record and vice versa. Subtemplates (as they were partially implemented in !GeoNetwork) took the template concept down to the level of individual elements in the metadata record. So for example, contact information would be implemented  This proposal intends to implement subtemplates as fragments of metadata harvested from an external database. 
+ * '''Subtemplates''': Metadata fragments are equivalent to subtemplates (which were only partially implemented in !GeoNetwork). Subtemplates appear to have been an extension of the template concept in !GeoNetwork. Templates are complete metadata records with some elements filled in. A user can clone such a record for use in the editor as a template. At this stage all connection between the template and the cloned record is broken ie. changes to the template are not visible in the cloned record and vice versa. Subtemplates (as they were partially implemented in !GeoNetwork) took the template concept down to the level of individual elements in the metadata record. So for example, contact information could be saved as a subtemplate and then reused when editing different elements. The implementation of subtemplates didn't make clear whether the link between a subtemplate and the record it had been added to was maintained. This proposal intends to implement subtemplates as fragments of metadata harvested from an external database - the link between a metadata record and a fragment will be maintained ie. changes in the fragment will be visible in the record.  
  * '''Composed, Componentized and Relational Metadata''': The idea of composed or componentized metadata and the term itself, appears to be common to many discussions on the net eg. (albeit obliquely) http://eww.jot.fm/issues/issue_2007_11/column6.pdf. Another term with similar concepts is "relational" metadata (!LISASoft metadata report). Although there has been discussion in and around these topics and even some implementation of fragments in !GeoNetwork as subtemplates, this proposal appears to be the first to suggest the mechanisms for implementing these concepts in !GeoNetwork using fragments harvested from a database with a WFS interface. 
- * '''Email discussions''':
- * '''Other wiki discussions''':
 
 === Voting History ===
@@ -35 +33 @@
 == Proposal == 
 
-WFS fragment harvester - this is a harvester that accepts (along with the usual harvester parameters) the 
+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 
+
+ * XLink resolver and cache
 
 Future work would add:
 
- * Transaction support - sometimes it makes sense for a fragment to be edited and saved back into the external database. WFS-T support would be used to provide this facility. 
+ * 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.
+ * Support in the editor for fragments: 
  * Support for metadata fragments through !GeoServer community schemas, including how to configure the !GeoServer WFS embedded with !GeoNetwork to provide the WFS interface.
  * 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.