Changes between Version 38 and Version 39 of ComposedMetadataRecords


Ignore:
Timestamp:
Apr 27, 2010, 2:49:55 AM (14 years ago)
Author:
simonp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ComposedMetadataRecords

    v38 v39  
    3838 * 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. Current implementation uses deegree WFS where the transformation of the WFS response can be done by the server using xslt. (See http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/sandbox/BlueNetMEST/src/org/fao/geonet/kernel/harvest/harvester/metadatafragments/ - this will be renamed wfsmetadatafragments)
    3939
    40  * XLink resolver and cache - the geocat.ch sandbox has developed an XLink resolver and cache mechanism. The implementation in the BlueNetMEST sandbox uses the same cache mechanism (based on Apache JCS) but parts of the resolver have been rewritten to handle (amongst other things) relative links to fragments in the same record and to avoid caching of such fragments. (See http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/sandbox/BlueNetMEST/jeeves/src/jeeves/xlink)
     40 * XLink resolver and cache - the geocat.ch sandbox has developed an XLink resolver and cache mechanism. The implementation in the BlueNetMEST sandbox uses the same cache mechanism (based on Apache JCS) but parts of the resolver have been rewritten to handle (amongst other things) relative links to fragments in the same record and to avoid caching of such fragments. (See http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/sandbox/BlueNetMEST/jeeves/src/jeeves/xlink). More details:
     41  * Metadata Records in !GeoNetwork would have their !XLinks resolved when read from the database (takes place in XmlSerializer) - only resolved records are seen by users and harvesters
     42  * Reindexing of metadata records that used to be done before servlet startup has been delayed until the servlet is up - this is to allow links between records in the local !GeoNetwork node to be resolved.
     43  * The cache and the lucene index are kept in sync - XLink'd fragments that are held in the cache are eternal (they never time out) unless forced by a new admin operation which clears the cache and then rebuilds the lucene index for all records with XLinks (this operation can be scheduled or run immediately). 
    4144
    42 Minor changes were required to change the display of metadata fragments in the !GeoNetwork editor so that they cannot be edited.
    43  
     45Minor changes were required to the metadata editor so that metadata fragments are recognizable and cannot be edited.
    4446
    4547== Suggestions for Future/Other proposals ==
    … …  
    5860Metadata records as traditionally handled by !GeoNetwork should not be affected by the addition of this feature.
    5961
    60 Effects on harvesting: Composed metadata records can have their XLinks resolved before they are harvested as a harvester usually updates the set of records harvested from a remote site on a regular basis. If there was a requirement for composed metadata records to be harvested with unresolved XLinks then an option could be added to the harvester to prevent XLink resolution before harvesting.
     62Effects on harvesters that harvest from !GeoNetwork: Composed metadata records will have their XLinks resolved before they are harvested as a harvester usually updates the set of records harvested from a remote site on a regular basis. If there was a requirement for composed metadata records to be harvested with unresolved XLinks then an option could be added to the harvester to prevent XLink resolution before harvesting.
    6163
    62 Effects on export (eg. MEF): Composed metadata records exported as MEF files would normally have their XLinks resolved before export. If there was a requirement for composed metadata records to be exported with unresolved XLinks then an option could be added to the MEF export service to prevent XLink resolution before export.
     64Effects on export (eg. MEF): Composed metadata records exported as MEF files would have their XLinks resolved before export. If there was a requirement for composed metadata records to be exported with unresolved XLinks then an option could be added to the MEF export service to prevent XLink resolution before export.
    6365
    6466XLinks and metadata records composed from xlink'd fragments can be made optional through the use of a system configuration option that can turn this feature on or off. This has been implemented in the BlueNetMEST sandbox.
    … …  
    6668== Risks ==
    6769
    68 Some XLink concepts are open to a number of interpretations eg. the notion of a relative URL with fragment identifier such as:
     70 * Some XLink concepts are open to a number of interpretations eg. the notion of a relative URL with fragment identifier such as:
    6971
     72{{{
    7073<gmd:temporalExtent xlink:href="#temporalExtent">
     74}}}
    7175
    72 would (I think) be interpreted as a link to a fragment within the same document. From discussions with the deegree developers (who have an advanced xlink implementation in their WFS), it appears that some organisations are interpreting such a link as being a fragment in any document within the local database. (reference required)
     76 * This should (I think) be interpreted as a link to a fragment within the same document. From discussions with the deegree developers (who have an advanced xlink implementation in their WFS), it appears that some organisations are interpreting such a link as being a fragment in any document within the local database. (reference required).
     77
     78 * Since this proposal and the fragment based harvester included allow xlink attributes on any element in the metadata record, composed metadata records with unresolved xlinks would fail validation. This is not an issue that is confined to composed metadata records though as !GeoNetwork does not provide any config options or other controls for the administrator to handle records that fail validation. 
    7379
    7480== Participants ==