Hi,
We have a requirement to harvest metadata records stored in some targetted GeoNetwork instances into a more general metadata registry via OAI-PMH. The format in which we require records is a custom format of no real relevance or interest to the geospatial community - probably much like Dublin Core 
After playing around with the GeoNetwork source code I have created a patch which enhances the existing OAI-PMH service to support transforms of "native" formats (i.e. those supported by a GeoNetwork instance) into other arbitrary formats (e.g. DC profiles, MODS, or custom XML) which may be required by external (i.e. non-GeoNetwork node) metadata harvesters/aggregators.
This patch modifies the ListIdentifiers, GetRecord and ListRecords classes in order to include in harvest responses records which are able to be transformed to the requested metadataPrefix. For example, if on the harvest request the metadataPrefix specified is iso19139, not only are records which are stored natively in iso19139 but also any other records associated with a schema which can be transformed to iso19139. Whether a schema can be transformed is determined by checking for a <metadataPrefix>.xsl file within a schema's "convert" directory. In the patch for example, every schema now has an oai_dc.xsl in its convert directory which removes the need for any special handling for oai_dc (I have left tthe Lib.toOaiDc and the oai-dc.xsml files intact though to avoid any unintended side effects). It also means configuring new crosswalks is merely a matter of dropping new schemas and/or stylesheets into the existing schema configuration areas.
The attached zip contains a patch file as well as a sample schema which may be used for testing the patch (simply place the rifcs directory into the $GEO/web/geonetwork/xml/schemas directory to allow support of "rifcs" and then place the rifcs.xsl file into the iso19139/convert directory in order to support a metadataPrefix of rifcs and transformation of iso19139 records to rifcs format)
What I was hoping is that this patch could be reviewed by the committer-types and applied to the GeoNetwork code base as I think it may be useful to others and it would certainly be useful to those GeoNetwork nodes we are planning to harvest in Australia. Any feedback, guidance as well as acknowledgment that this patch will be incorporated into the GeoNetwork code base (or not!) and when (or if!) would be greatly appreciated.
Thanks.
Scott.
(attachments)
patch.zip (22 KB)
Hi Scott,
Great to see this type of contribution! It will further enhance GeoNetwork's interoperability.
I'll review the patch for inclusion initially in the BlueNetMEST sandbox (which I'd like to rename as the ANZMEST sandbox soon to better reflect its usage as an Australia/NZ Community version of GeoNetwork) - that way it will get some use in this sandbox in the Australia/NZ context at least which will be important for your harvesting work.
We can then propose to put it into 2.4.x depending upon the feedback we get/changes/enhancements we might need/want to make and any interrelationships with other parts of GN.
If thats ok with you then I'll go ahead and let you know once I've reviewed it and incorporated it into the sandbox.
All of the above doesn't preclude any of the other committers who may be interested in the patch from doing something similar!
Cheers and thanks,
Simon
Scott Yeadon wrote:
Hi,
We have a requirement to harvest metadata records stored in some targetted GeoNetwork instances into a more general metadata registry via OAI-PMH. The format in which we require records is a custom format of no real relevance or interest to the geospatial community - probably much like Dublin Core 
After playing around with the GeoNetwork source code I have created a patch which enhances the existing OAI-PMH service to support transforms of "native" formats (i.e. those supported by a GeoNetwork instance) into other arbitrary formats (e.g. DC profiles, MODS, or custom XML) which may be required by external (i.e. non-GeoNetwork node) metadata harvesters/aggregators.
This patch modifies the ListIdentifiers, GetRecord and ListRecords classes in order to include in harvest responses records which are able to be transformed to the requested metadataPrefix. For example, if on the harvest request the metadataPrefix specified is iso19139, not only are records which are stored natively in iso19139 but also any other records associated with a schema which can be transformed to iso19139. Whether a schema can be transformed is determined by checking for a <metadataPrefix>.xsl file within a schema's "convert" directory. In the patch for example, every schema now has an oai_dc.xsl in its convert directory which removes the need for any special handling for oai_dc (I have left tthe Lib.toOaiDc and the oai-dc.xsml files intact though to avoid any unintended side effects). It also means configuring new crosswalks is merely a matter of dropping new schemas and/or stylesheets into the existing schema configuration areas.
The attached zip contains a patch file as well as a sample schema which may be used for testing the patch (simply place the rifcs directory into the $GEO/web/geonetwork/xml/schemas directory to allow support of "rifcs" and then place the rifcs.xsl file into the iso19139/convert directory in order to support a metadataPrefix of rifcs and transformation of iso19139 records to rifcs format)
What I was hoping is that this patch could be reviewed by the committer-types and applied to the GeoNetwork code base as I think it may be useful to others and it would certainly be useful to those GeoNetwork nodes we are planning to harvest in Australia. Any feedback, guidance as well as acknowledgment that this patch will be incorporated into the GeoNetwork code base (or not!) and when (or if!) would be greatly appreciated.
Thanks.
Scott.
------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at GeoNetwork - Geographic Metadata Catalog download | SourceForge.net
Hi Simon,
That sounds great! Feel free to contact me at any point with regards to the patch.
Thanks.
Scott.
Simon Pigot wrote:
Hi Scott,
Great to see this type of contribution! It will further enhance GeoNetwork's interoperability.
I'll review the patch for inclusion initially in the BlueNetMEST sandbox (which I'd like to rename as the ANZMEST sandbox soon to better reflect its usage as an Australia/NZ Community version of GeoNetwork) - that way it will get some use in this sandbox in the Australia/NZ context at least which will be important for your harvesting work.
We can then propose to put it into 2.4.x depending upon the feedback we get/changes/enhancements we might need/want to make and any interrelationships with other parts of GN.
If thats ok with you then I'll go ahead and let you know once I've reviewed it and incorporated it into the sandbox.
All of the above doesn't preclude any of the other committers who may be interested in the patch from doing something similar!
Cheers and thanks,
Simon
Scott Yeadon wrote:
Hi,
We have a requirement to harvest metadata records stored in some targetted GeoNetwork instances into a more general metadata registry via OAI-PMH. The format in which we require records is a custom format of no real relevance or interest to the geospatial community - probably much like Dublin Core
After playing around with the GeoNetwork source code I have created a patch which enhances the existing OAI-PMH service to support transforms of "native" formats (i.e. those supported by a GeoNetwork instance) into other arbitrary formats (e.g. DC profiles, MODS, or custom XML) which may be required by external (i.e. non-GeoNetwork node) metadata harvesters/aggregators.
This patch modifies the ListIdentifiers, GetRecord and ListRecords classes in order to include in harvest responses records which are able to be transformed to the requested metadataPrefix. For example, if on the harvest request the metadataPrefix specified is iso19139, not only are records which are stored natively in iso19139 but also any other records associated with a schema which can be transformed to iso19139. Whether a schema can be transformed is determined by checking for a <metadataPrefix>.xsl file within a schema's "convert" directory. In the patch for example, every schema now has an oai_dc.xsl in its convert directory which removes the need for any special handling for oai_dc (I have left tthe Lib.toOaiDc and the oai-dc.xsml files intact though to avoid any unintended side effects). It also means configuring new crosswalks is merely a matter of dropping new schemas and/or stylesheets into the existing schema configuration areas.
The attached zip contains a patch file as well as a sample schema which may be used for testing the patch (simply place the rifcs directory into the $GEO/web/geonetwork/xml/schemas directory to allow support of "rifcs" and then place the rifcs.xsl file into the iso19139/convert directory in order to support a metadataPrefix of rifcs and transformation of iso19139 records to rifcs format)
What I was hoping is that this patch could be reviewed by the committer-types and applied to the GeoNetwork code base as I think it may be useful to others and it would certainly be useful to those GeoNetwork nodes we are planning to harvest in Australia. Any feedback, guidance as well as acknowledgment that this patch will be incorporated into the GeoNetwork code base (or not!) and when (or if!) would be greatly appreciated.
Thanks.
Scott.
------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hi Scott,
Quick update: The patch is in the BlueNetMEST sandbox (has been for quite a few days) and I've added rifcs.xsl to the convert dir of all iso profiles which should help your harvesting when people start adopting the latest version of the MEST - still needs testing - hopefully later this week.
Cheers,
Simon
Scott Yeadon wrote:
Hi Simon,
That sounds great! Feel free to contact me at any point with regards to the patch.
Thanks.
Scott.
Simon Pigot wrote:
Hi Scott,
Great to see this type of contribution! It will further enhance GeoNetwork's interoperability.
I'll review the patch for inclusion initially in the BlueNetMEST sandbox (which I'd like to rename as the ANZMEST sandbox soon to better reflect its usage as an Australia/NZ Community version of GeoNetwork) - that way it will get some use in this sandbox in the Australia/NZ context at least which will be important for your harvesting work.
We can then propose to put it into 2.4.x depending upon the feedback we get/changes/enhancements we might need/want to make and any interrelationships with other parts of GN.
If thats ok with you then I'll go ahead and let you know once I've reviewed it and incorporated it into the sandbox.
All of the above doesn't preclude any of the other committers who may be interested in the patch from doing something similar!
Cheers and thanks,
Simon
Scott Yeadon wrote:
Hi,
We have a requirement to harvest metadata records stored in some targetted GeoNetwork instances into a more general metadata registry via OAI-PMH. The format in which we require records is a custom format of no real relevance or interest to the geospatial community - probably much like Dublin Core
After playing around with the GeoNetwork source code I have created a patch which enhances the existing OAI-PMH service to support transforms of "native" formats (i.e. those supported by a GeoNetwork instance) into other arbitrary formats (e.g. DC profiles, MODS, or custom XML) which may be required by external (i.e. non-GeoNetwork node) metadata harvesters/aggregators.
This patch modifies the ListIdentifiers, GetRecord and ListRecords classes in order to include in harvest responses records which are able to be transformed to the requested metadataPrefix. For example, if on the harvest request the metadataPrefix specified is iso19139, not only are records which are stored natively in iso19139 but also any other records associated with a schema which can be transformed to iso19139. Whether a schema can be transformed is determined by checking for a <metadataPrefix>.xsl file within a schema's "convert" directory. In the patch for example, every schema now has an oai_dc.xsl in its convert directory which removes the need for any special handling for oai_dc (I have left tthe Lib.toOaiDc and the oai-dc.xsml files intact though to avoid any unintended side effects). It also means configuring new crosswalks is merely a matter of dropping new schemas and/or stylesheets into the existing schema configuration areas.
The attached zip contains a patch file as well as a sample schema which may be used for testing the patch (simply place the rifcs directory into the $GEO/web/geonetwork/xml/schemas directory to allow support of "rifcs" and then place the rifcs.xsl file into the iso19139/convert directory in order to support a metadataPrefix of rifcs and transformation of iso19139 records to rifcs format)
What I was hoping is that this patch could be reviewed by the committer-types and applied to the GeoNetwork code base as I think it may be useful to others and it would certainly be useful to those GeoNetwork nodes we are planning to harvest in Australia. Any feedback, guidance as well as acknowledgment that this patch will be incorporated into the GeoNetwork code base (or not!) and when (or if!) would be greatly appreciated.
Thanks.
Scott.
------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at GeoNetwork - Geographic Metadata Catalog download | SourceForge.net
------------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at GeoNetwork - Geographic Metadata Catalog download | SourceForge.net
Hi Simon,
Cheers for that. Just one clarification - the rifcs.xsl provided with the patch should *only* go into the iso19139/convert dir as the supplied stylesheet is targetted at transforming iso19139 to RIF-CS. I have attached a stylesheet which converts iso19139 MCP to RIF-CS which I think is what most of the MEST instances hold so may make more sense for the testing. It would go into the iso19139.mcp/convert directory.
Scott.
Simon Pigot wrote:
Hi Scott,
Quick update: The patch is in the BlueNetMEST sandbox (has been for quite a few days) and I've added rifcs.xsl to the convert dir of all iso profiles which should help your harvesting when people start adopting the latest version of the MEST - still needs testing - hopefully later this week.
Cheers,
Simon
Scott Yeadon wrote:
Hi Simon,
That sounds great! Feel free to contact me at any point with regards to the patch.
Thanks.
Scott.
Simon Pigot wrote:
Hi Scott,
Great to see this type of contribution! It will further enhance GeoNetwork's interoperability.
I'll review the patch for inclusion initially in the BlueNetMEST sandbox (which I'd like to rename as the ANZMEST sandbox soon to better reflect its usage as an Australia/NZ Community version of GeoNetwork) - that way it will get some use in this sandbox in the Australia/NZ context at least which will be important for your harvesting work.
We can then propose to put it into 2.4.x depending upon the feedback we get/changes/enhancements we might need/want to make and any interrelationships with other parts of GN.
If thats ok with you then I'll go ahead and let you know once I've reviewed it and incorporated it into the sandbox.
All of the above doesn't preclude any of the other committers who may be interested in the patch from doing something similar!
Cheers and thanks,
Simon
Scott Yeadon wrote:
Hi,
We have a requirement to harvest metadata records stored in some targetted GeoNetwork instances into a more general metadata registry via OAI-PMH. The format in which we require records is a custom format of no real relevance or interest to the geospatial community - probably much like Dublin Core
After playing around with the GeoNetwork source code I have created a patch which enhances the existing OAI-PMH service to support transforms of "native" formats (i.e. those supported by a GeoNetwork instance) into other arbitrary formats (e.g. DC profiles, MODS, or custom XML) which may be required by external (i.e. non-GeoNetwork node) metadata harvesters/aggregators.
This patch modifies the ListIdentifiers, GetRecord and ListRecords classes in order to include in harvest responses records which are able to be transformed to the requested metadataPrefix. For example, if on the harvest request the metadataPrefix specified is iso19139, not only are records which are stored natively in iso19139 but also any other records associated with a schema which can be transformed to iso19139. Whether a schema can be transformed is determined by checking for a <metadataPrefix>.xsl file within a schema's "convert" directory. In the patch for example, every schema now has an oai_dc.xsl in its convert directory which removes the need for any special handling for oai_dc (I have left tthe Lib.toOaiDc and the oai-dc.xsml files intact though to avoid any unintended side effects). It also means configuring new crosswalks is merely a matter of dropping new schemas and/or stylesheets into the existing schema configuration areas.
The attached zip contains a patch file as well as a sample schema which may be used for testing the patch (simply place the rifcs directory into the $GEO/web/geonetwork/xml/schemas directory to allow support of "rifcs" and then place the rifcs.xsl file into the iso19139/convert directory in order to support a metadataPrefix of rifcs and transformation of iso19139 records to rifcs format)
What I was hoping is that this patch could be reviewed by the committer-types and applied to the GeoNetwork code base as I think it may be useful to others and it would certainly be useful to those GeoNetwork nodes we are planning to harvest in Australia. Any feedback, guidance as well as acknowledgment that this patch will be incorporated into the GeoNetwork code base (or not!) and when (or if!) would be greatly appreciated.
Thanks.
Scott.
------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
------------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
(attachments)
rifcs.xsl (20 KB)
Yep - I've already modified it to suit the other iso19139 profiles as required - I'll check it (them) against your attached xslt with the testing this week.
Cheers and thanks,
Simon
Scott Yeadon wrote:
Hi Simon,
Cheers for that. Just one clarification - the rifcs.xsl provided with the patch should *only* go into the iso19139/convert dir as the supplied stylesheet is targetted at transforming iso19139 to RIF-CS. I have attached a stylesheet which converts iso19139 MCP to RIF-CS which I think is what most of the MEST instances hold so may make more sense for the testing. It would go into the iso19139.mcp/convert directory.
Scott.
Simon Pigot wrote:
Hi Scott,
Quick update: The patch is in the BlueNetMEST sandbox (has been for quite a few days) and I've added rifcs.xsl to the convert dir of all iso profiles which should help your harvesting when people start adopting the latest version of the MEST - still needs testing - hopefully later this week.
Cheers,
Simon
Scott Yeadon wrote:
Hi Simon,
That sounds great! Feel free to contact me at any point with regards to the patch.
Thanks.
Scott.
Simon Pigot wrote:
Hi Scott,
Great to see this type of contribution! It will further enhance GeoNetwork's interoperability.
I'll review the patch for inclusion initially in the BlueNetMEST sandbox (which I'd like to rename as the ANZMEST sandbox soon to better reflect its usage as an Australia/NZ Community version of GeoNetwork) - that way it will get some use in this sandbox in the Australia/NZ context at least which will be important for your harvesting work.
We can then propose to put it into 2.4.x depending upon the feedback we get/changes/enhancements we might need/want to make and any interrelationships with other parts of GN.
If thats ok with you then I'll go ahead and let you know once I've reviewed it and incorporated it into the sandbox.
All of the above doesn't preclude any of the other committers who may be interested in the patch from doing something similar!
Cheers and thanks,
Simon
Scott Yeadon wrote:
Hi,
We have a requirement to harvest metadata records stored in some targetted GeoNetwork instances into a more general metadata registry via OAI-PMH. The format in which we require records is a custom format of no real relevance or interest to the geospatial community - probably much like Dublin Core
After playing around with the GeoNetwork source code I have created a patch which enhances the existing OAI-PMH service to support transforms of "native" formats (i.e. those supported by a GeoNetwork instance) into other arbitrary formats (e.g. DC profiles, MODS, or custom XML) which may be required by external (i.e. non-GeoNetwork node) metadata harvesters/aggregators.
This patch modifies the ListIdentifiers, GetRecord and ListRecords classes in order to include in harvest responses records which are able to be transformed to the requested metadataPrefix. For example, if on the harvest request the metadataPrefix specified is iso19139, not only are records which are stored natively in iso19139 but also any other records associated with a schema which can be transformed to iso19139. Whether a schema can be transformed is determined by checking for a <metadataPrefix>.xsl file within a schema's "convert" directory. In the patch for example, every schema now has an oai_dc.xsl in its convert directory which removes the need for any special handling for oai_dc (I have left tthe Lib.toOaiDc and the oai-dc.xsml files intact though to avoid any unintended side effects). It also means configuring new crosswalks is merely a matter of dropping new schemas and/or stylesheets into the existing schema configuration areas.
The attached zip contains a patch file as well as a sample schema which may be used for testing the patch (simply place the rifcs directory into the $GEO/web/geonetwork/xml/schemas directory to allow support of "rifcs" and then place the rifcs.xsl file into the iso19139/convert directory in order to support a metadataPrefix of rifcs and transformation of iso19139 records to rifcs format)
What I was hoping is that this patch could be reviewed by the committer-types and applied to the GeoNetwork code base as I think it may be useful to others and it would certainly be useful to those GeoNetwork nodes we are planning to harvest in Australia. Any feedback, guidance as well as acknowledgment that this patch will be incorporated into the GeoNetwork code base (or not!) and when (or if!) would be greatly appreciated.
Thanks.
Scott.
------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at GeoNetwork - Geographic Metadata Catalog download | SourceForge.net
------------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at GeoNetwork - Geographic Metadata Catalog download | SourceForge.net
------------------------------------------------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. Best Open Source Mac Front-Ends 2024
------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at GeoNetwork - Geographic Metadata Catalog download | SourceForge.net