Changing Geonetwork schema

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Changing Geonetwork schema

Jo Cook
Hi List,

I'm wondering what method people use to change the schema that
metadata is stored in. The scenario- I want to convert records in
Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
(iso19139.gemini23). I can change the actual metadata using an xsl
transformation, but as far as Geonetwork's database is concerned, the
records are still stored with a schemaid of iso19139.gemini22. I can
manually update the records in the database to change from one to the
other, but that's not ideal for end-users of the catalog who may want
to use a phased approach for converting and not do them all at once.

What other methods have people used to fully convert records in place?
I really don't want to harvest into a new catalog, or export and
re-import them if at all possible.

Thanks

Jo

--
Jo Cook
t:+44 7930 524 155/twitter:@archaeogeek
Please note that currently I do not work on Friday afternoons. For
urgent responses at that time, please visit
support.astuntechnology.com or phone our office on 01372 744009

--
-- 
*Sign up to our mailing list
<https://astuntechnology.com/company/#email-updates> for updates on news,
products, conferences, events and training*
*
*

Astun Technology Ltd,
Epsom Square Centre, 6-7 The Derby Square, Epsom, Surrey, KT19 8AG, UK 

t:+44 1372 744 009 w: astuntechnology.com <http://astuntechnology.com/
twitter:@astuntech <https://twitter.com/astuntech>



iShare - enterprise
geographic intelligence platform <https://astuntechnology.com/ishare/>

GeoServer, PostGIS and QGIS training
<https://astuntechnology.com/training-courses/>
Helpdesk and customer
portal
<https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>





Company registration no. 5410695. Registered in England and Wales.
Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
864201149.


_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jeff Campbell
Hi Jo,

We are facing a similar issue with a small number of metadata records in the database from iso19115-3 going to iso19115-3.2018. We do not have a conclusion yet. Below I describe some of the approaches we are considering. I hope this is helpful, or at least starts discussion, raises other questions, and potentially results in a "best practice" that I will volunteer to write for the documentation.

We considered adding the -3 to -3.2018 xsl transform to the list of transforms on the "Import new records" page. Then we could export the 2014 version files, and then import (and transform) with the overwrite metadata with same uuid option. We have not yet tested that to see if the metadata database record is fully and correctly updated with the schemid.  I do not  have a deep knowledge of the code and am not sure if this was ever defined as a requirement or test case. I too am hesitant to do things in unanticipated ways and have established a rule that our external programs will access the geonetwork database in read-only mode.

We also considered exporting the metadata records, using GeoNetwork to delete the older schema records, and then import keeping the uuid in the import file. My thought is this would force the deletion of the database metadata record, so when imported, it would have to create an entire new record.  BUT this has the side effect of the metadata.id value changing. I am not sure if that is good, neutral, or causes problems.

Regardless of the way to update the records, I would guess that it would be good to force reindexing.

We have the added complexity of using many "directories"/"snippets"/"re-usable element content"/some other name.  We also have nested snippets - responsibleParty snippet contains a link to a contact snippet that contains an onlineResource snippet.  How to export the metadata.data field without resolving the xlinks to snippets is not entirely clear. We have written some postgres queries to write the content of metadata.data to a file. I noticed that the code for the download file list of formats seems to have parameters that could allow specifying that the xlinks should not be resolved. We have not figured out how to do that.

Bigger Picture

We have several hundred published records at this time all stored as 19139.  Many were transformed from legacy metadata formats. Since we expect potentially many thousands of records starting from legacy formats, or perhaps minimal formal metadata, we are thinking about training for 19115-3.2018 instead of the double learning curve for 19139 and then 19115-3.x. If we decide that 19115-3.2018 is our primary internal format, it seems to make sense to convert the snippets to that format instead of on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the conversion becomes much more difficult and risky if the snippet uuid has to be changed.  

Any comments and questions are welcome. We're also happy to contribute code, but our customization is minimal, so far.

Jeff


On 3/17/2020 2:05 PM, Jo Cook wrote:
Hi List,

I'm wondering what method people use to change the schema that
metadata is stored in. The scenario- I want to convert records in
Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
(iso19139.gemini23). I can change the actual metadata using an xsl
transformation, but as far as Geonetwork's database is concerned, the
records are still stored with a schemaid of iso19139.gemini22. I can
manually update the records in the database to change from one to the
other, but that's not ideal for end-users of the catalog who may want
to use a phased approach for converting and not do them all at once.

What other methods have people used to fully convert records in place?
I really don't want to harvest into a new catalog, or export and
re-import them if at all possible.

Thanks

Jo




_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jose Garcia
Hi

You can add in the schema that you want to upgrade in the process folder a
file ending with the suffix -schemaupgrade.xsl that makes the upgrade,
changing the elements in the xml to match the new schema and updating the
schemaid in the database, the process can be invoked using
 XlsProcessingApi and MetadataProcessApi, but both seem oriented to single
metadata updates.

See
https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7

Regards,
Jose García

On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
[hidden email]> wrote:

> Hi Jo,
>
> We are facing a similar issue with a small number of metadata records in
> the database from iso19115-3 going to iso19115-3.2018. We do not have a
> conclusion yet. Below I describe some of the approaches we are considering.
> I hope this is helpful, or at least starts discussion, raises other
> questions, and potentially results in a "best practice" that I will
> volunteer to write for the documentation.
>
> We considered adding the -3 to -3.2018 xsl transform to the list of
> transforms on the "Import new records" page. Then we could export the 2014
> version files, and then import (and transform) with the overwrite metadata
> with same uuid option. We have not yet tested that to see if the metadata
> database record is fully and correctly updated with the schemid.  I do not
> have a deep knowledge of the code and am not sure if this was ever defined
> as a requirement or test case. I too am hesitant to do things in
> unanticipated ways and have established a rule that our external programs
> will access the geonetwork database in read-only mode.
>
> We also considered exporting the metadata records, using GeoNetwork to
> delete the older schema records, and then import keeping the uuid in the
> import file. My thought is this would force the deletion of the database
> metadata record, so when imported, it would have to create an entire new
> record.  BUT this has the side effect of the metadata.id value changing.
> I am not sure if that is good, neutral, or causes problems.
>
> Regardless of the way to update the records, I would guess that it would
> be good to force reindexing.
>
> We have the added complexity of using many
> "directories"/"snippets"/"re-usable element content"/some other name.  We
> also have nested snippets - responsibleParty snippet contains a link to a
> contact snippet that contains an onlineResource snippet.  How to export the
> metadata.data field without resolving the xlinks to snippets is not
> entirely clear. We have written some postgres queries to write the content
> of metadata.data to a file. I noticed that the code for the download file
> list of formats seems to have parameters that could allow specifying that
> the xlinks should not be resolved. We have not figured out how to do that.
>
> Bigger Picture
>
> We have several hundred published records at this time all stored as
> 19139.  Many were transformed from legacy metadata formats. Since we expect
> potentially many thousands of records starting from legacy formats, or
> perhaps minimal formal metadata, we are thinking about training for
> 19115-3.2018 instead of the double learning curve for 19139 and then
> 19115-3.x. If we decide that 19115-3.2018 is our primary internal format,
> it seems to make sense to convert the snippets to that format instead of
> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
> conversion becomes much more difficult and risky if the snippet uuid has to
> be changed.
>
> Any comments and questions are welcome. We're also happy to contribute
> code, but our customization is minimal, so far.
>
> Jeff
>
>
> On 3/17/2020 2:05 PM, Jo Cook wrote:
>
> Hi List,
>
> I'm wondering what method people use to change the schema that
> metadata is stored in. The scenario- I want to convert records in
> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
> (iso19139.gemini23). I can change the actual metadata using an xsl
> transformation, but as far as Geonetwork's database is concerned, the
> records are still stored with a schemaid of iso19139.gemini22. I can
> manually update the records in the database to change from one to the
> other, but that's not ideal for end-users of the catalog who may want
> to use a phased approach for converting and not do them all at once.
>
> What other methods have people used to fully convert records in place?
> I really don't want to harvest into a new catalog, or export and
> re-import them if at all possible.
>
> Thanks
>
> Jo
>
>
>
> _______________________________________________
> GeoNetwork-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
> GeoNetwork OpenSource is maintained at
> http://sourceforge.net/projects/geonetwork
>


--











*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
(0)318 416664 <+31318416664>Please consider the environment before printing
this email.*

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jo Cook
Hi Jose,

That's great news- I will try it out. Is it something that would easily
backport to 3.4? (Happy to give it a go if it's simple enough).

Thanks

Jo

On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia <[hidden email]> wrote:

> Hi
>
> You can add in the schema that you want to upgrade in the process folder a
> file ending with the suffix -schemaupgrade.xsl that makes the upgrade,
> changing the elements in the xml to match the new schema and updating the
> schemaid in the database, the process can be invoked using
>  XlsProcessingApi and MetadataProcessApi, but both seem oriented to single
> metadata updates.
>
> See
> https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
>
> Regards,
> Jose García
>
> On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
> [hidden email]> wrote:
>
>> Hi Jo,
>>
>> We are facing a similar issue with a small number of metadata records in
>> the database from iso19115-3 going to iso19115-3.2018. We do not have a
>> conclusion yet. Below I describe some of the approaches we are considering.
>> I hope this is helpful, or at least starts discussion, raises other
>> questions, and potentially results in a "best practice" that I will
>> volunteer to write for the documentation.
>>
>> We considered adding the -3 to -3.2018 xsl transform to the list of
>> transforms on the "Import new records" page. Then we could export the 2014
>> version files, and then import (and transform) with the overwrite metadata
>> with same uuid option. We have not yet tested that to see if the metadata
>> database record is fully and correctly updated with the schemid.  I do not
>> have a deep knowledge of the code and am not sure if this was ever defined
>> as a requirement or test case. I too am hesitant to do things in
>> unanticipated ways and have established a rule that our external programs
>> will access the geonetwork database in read-only mode.
>>
>> We also considered exporting the metadata records, using GeoNetwork to
>> delete the older schema records, and then import keeping the uuid in the
>> import file. My thought is this would force the deletion of the database
>> metadata record, so when imported, it would have to create an entire new
>> record.  BUT this has the side effect of the metadata.id value changing.
>> I am not sure if that is good, neutral, or causes problems.
>>
>> Regardless of the way to update the records, I would guess that it would
>> be good to force reindexing.
>>
>> We have the added complexity of using many
>> "directories"/"snippets"/"re-usable element content"/some other name.  We
>> also have nested snippets - responsibleParty snippet contains a link to a
>> contact snippet that contains an onlineResource snippet.  How to export the
>> metadata.data field without resolving the xlinks to snippets is not
>> entirely clear. We have written some postgres queries to write the content
>> of metadata.data to a file. I noticed that the code for the download file
>> list of formats seems to have parameters that could allow specifying that
>> the xlinks should not be resolved. We have not figured out how to do that.
>>
>> Bigger Picture
>>
>> We have several hundred published records at this time all stored as
>> 19139.  Many were transformed from legacy metadata formats. Since we expect
>> potentially many thousands of records starting from legacy formats, or
>> perhaps minimal formal metadata, we are thinking about training for
>> 19115-3.2018 instead of the double learning curve for 19139 and then
>> 19115-3.x. If we decide that 19115-3.2018 is our primary internal format,
>> it seems to make sense to convert the snippets to that format instead of
>> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
>> conversion becomes much more difficult and risky if the snippet uuid has to
>> be changed.
>>
>> Any comments and questions are welcome. We're also happy to contribute
>> code, but our customization is minimal, so far.
>>
>> Jeff
>>
>>
>> On 3/17/2020 2:05 PM, Jo Cook wrote:
>>
>> Hi List,
>>
>> I'm wondering what method people use to change the schema that
>> metadata is stored in. The scenario- I want to convert records in
>> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
>> (iso19139.gemini23). I can change the actual metadata using an xsl
>> transformation, but as far as Geonetwork's database is concerned, the
>> records are still stored with a schemaid of iso19139.gemini22. I can
>> manually update the records in the database to change from one to the
>> other, but that's not ideal for end-users of the catalog who may want
>> to use a phased approach for converting and not do them all at once.
>>
>> What other methods have people used to fully convert records in place?
>> I really don't want to harvest into a new catalog, or export and
>> re-import them if at all possible.
>>
>> Thanks
>>
>> Jo
>>
>>
>>
>> _______________________________________________
>> GeoNetwork-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>> GeoNetwork OpenSource is maintained at
>> http://sourceforge.net/projects/geonetwork
>>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
> *Vriendelijke groeten / Kind regards,Jose García
> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
> (0)318 416664 <+31318416664>Please consider the environment before printing
> this email.*
>


--
*Jo Cook*
t:+44 7930 524 155/twitter:@archaeogeek
Please note that currently I do not work on Friday afternoons. For urgent
responses at that time, please visit support.astuntechnology.com or phone
our office on 01372 744009

--
-- 
*Sign up to our mailing list
<https://astuntechnology.com/company/#email-updates> for updates on news,
products, conferences, events and training*
*
*

Astun Technology Ltd,
Epsom Square Centre, 6-7 The Derby Square, Epsom, Surrey, KT19 8AG, UK 

t:+44 1372 744 009 w: astuntechnology.com <http://astuntechnology.com/
twitter:@astuntech <https://twitter.com/astuntech>



iShare - enterprise
geographic intelligence platform <https://astuntechnology.com/ishare/>

GeoServer, PostGIS and QGIS training
<https://astuntechnology.com/training-courses/>
Helpdesk and customer
portal
<https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>





Company registration no. 5410695. Registered in England and Wales.
Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
864201149.

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jose Garcia
Hi Jo

The changed files should be quite similar in 3.4.x. I'll check if can
manage tomorrow to make a PR.

Regards,
Jose García


On Thu, Mar 19, 2020 at 5:31 PM Jo Cook <[hidden email]> wrote:

> Hi Jose,
>
> That's great news- I will try it out. Is it something that would easily
> backport to 3.4? (Happy to give it a go if it's simple enough).
>
> Thanks
>
> Jo
>
> On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia <[hidden email]>
> wrote:
>
>> Hi
>>
>> You can add in the schema that you want to upgrade in the process folder
>> a file ending with the suffix -schemaupgrade.xsl that makes the upgrade,
>> changing the elements in the xml to match the new schema and updating the
>> schemaid in the database, the process can be invoked using
>>  XlsProcessingApi and MetadataProcessApi, but both seem oriented to single
>> metadata updates.
>>
>> See
>> https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
>>
>> Regards,
>> Jose García
>>
>> On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
>> [hidden email]> wrote:
>>
>>> Hi Jo,
>>>
>>> We are facing a similar issue with a small number of metadata records in
>>> the database from iso19115-3 going to iso19115-3.2018. We do not have a
>>> conclusion yet. Below I describe some of the approaches we are considering.
>>> I hope this is helpful, or at least starts discussion, raises other
>>> questions, and potentially results in a "best practice" that I will
>>> volunteer to write for the documentation.
>>>
>>> We considered adding the -3 to -3.2018 xsl transform to the list of
>>> transforms on the "Import new records" page. Then we could export the 2014
>>> version files, and then import (and transform) with the overwrite metadata
>>> with same uuid option. We have not yet tested that to see if the metadata
>>> database record is fully and correctly updated with the schemid.  I do not
>>> have a deep knowledge of the code and am not sure if this was ever defined
>>> as a requirement or test case. I too am hesitant to do things in
>>> unanticipated ways and have established a rule that our external programs
>>> will access the geonetwork database in read-only mode.
>>>
>>> We also considered exporting the metadata records, using GeoNetwork to
>>> delete the older schema records, and then import keeping the uuid in the
>>> import file. My thought is this would force the deletion of the database
>>> metadata record, so when imported, it would have to create an entire new
>>> record.  BUT this has the side effect of the metadata.id value
>>> changing. I am not sure if that is good, neutral, or causes problems.
>>>
>>> Regardless of the way to update the records, I would guess that it would
>>> be good to force reindexing.
>>>
>>> We have the added complexity of using many
>>> "directories"/"snippets"/"re-usable element content"/some other name.  We
>>> also have nested snippets - responsibleParty snippet contains a link to a
>>> contact snippet that contains an onlineResource snippet.  How to export the
>>> metadata.data field without resolving the xlinks to snippets is not
>>> entirely clear. We have written some postgres queries to write the content
>>> of metadata.data to a file. I noticed that the code for the download file
>>> list of formats seems to have parameters that could allow specifying that
>>> the xlinks should not be resolved. We have not figured out how to do that.
>>>
>>> Bigger Picture
>>>
>>> We have several hundred published records at this time all stored as
>>> 19139.  Many were transformed from legacy metadata formats. Since we expect
>>> potentially many thousands of records starting from legacy formats, or
>>> perhaps minimal formal metadata, we are thinking about training for
>>> 19115-3.2018 instead of the double learning curve for 19139 and then
>>> 19115-3.x. If we decide that 19115-3.2018 is our primary internal format,
>>> it seems to make sense to convert the snippets to that format instead of
>>> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
>>> conversion becomes much more difficult and risky if the snippet uuid has to
>>> be changed.
>>>
>>> Any comments and questions are welcome. We're also happy to contribute
>>> code, but our customization is minimal, so far.
>>>
>>> Jeff
>>>
>>>
>>> On 3/17/2020 2:05 PM, Jo Cook wrote:
>>>
>>> Hi List,
>>>
>>> I'm wondering what method people use to change the schema that
>>> metadata is stored in. The scenario- I want to convert records in
>>> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
>>> (iso19139.gemini23). I can change the actual metadata using an xsl
>>> transformation, but as far as Geonetwork's database is concerned, the
>>> records are still stored with a schemaid of iso19139.gemini22. I can
>>> manually update the records in the database to change from one to the
>>> other, but that's not ideal for end-users of the catalog who may want
>>> to use a phased approach for converting and not do them all at once.
>>>
>>> What other methods have people used to fully convert records in place?
>>> I really don't want to harvest into a new catalog, or export and
>>> re-import them if at all possible.
>>>
>>> Thanks
>>>
>>> Jo
>>>
>>>
>>>
>>> _______________________________________________
>>> GeoNetwork-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>>> GeoNetwork OpenSource is maintained at
>>> http://sourceforge.net/projects/geonetwork
>>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Vriendelijke groeten / Kind regards,Jose García
>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>> (0)318 416664 <+31318416664>Please consider the environment before printing
>> this email.*
>>
>
>
> --
> *Jo Cook*
> t:+44 7930 524 155/twitter:@archaeogeek
> Please note that currently I do not work on Friday afternoons. For urgent
> responses at that time, please visit support.astuntechnology.com or phone
> our office on 01372 744009
>
>
> --
> *Sign up to our mailing list
> <https://astuntechnology.com/company/#email-updates> for updates on news,
> products, conferences, events and training*
>
> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
> Surrey, KT19 8AG, UK
> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
> <https://twitter.com/astuntech>
>
> iShare - enterprise geographic intelligence platform
> <https://astuntechnology.com/ishare/>
> GeoServer, PostGIS and QGIS training
> <https://astuntechnology.com/training-courses/>
> Helpdesk and customer portal
> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>
> Company registration no. 5410695. Registered in England and Wales.
> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
> 864201149.
>


--











*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
(0)318 416664 <+31318416664>Please consider the environment before printing
this email.*

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jo Cook
Hi Jose (and list)

I can get this process working via the api just fine, but I'm struggling
with getting it working as a suggestion. With the files from
https://github.com/AstunTechnology/iso19139.gemini22_GN3/commit/25417e5be1ddd692cf676ea23c335d106bc9618f
the suggestion appears in the list but when it's run I get the following
error:

(URL:
http://localhost:8080/geonetwork/srv/api/records/918/processes/iso19139.gemini23-schemaupgrade?process=iso19139.gemini23-schemaupgrade&id=918
)
<apiError>
<code>runtime_exception</code>
<description>
Not found:0, Not owner:0, No process found:1. is not a valid value for:
Processing failed
</description>
<message>BadParameterEx</message>
</apiError>

and I'm really not sure what I am doing wrong. Any ideas?

Thanks

Jo






On Thu, Mar 19, 2020 at 4:33 PM Jose Garcia <[hidden email]> wrote:

> Hi Jo
>
> The changed files should be quite similar in 3.4.x. I'll check if can
> manage tomorrow to make a PR.
>
> Regards,
> Jose García
>
>
> On Thu, Mar 19, 2020 at 5:31 PM Jo Cook <[hidden email]>
> wrote:
>
>> Hi Jose,
>>
>> That's great news- I will try it out. Is it something that would easily
>> backport to 3.4? (Happy to give it a go if it's simple enough).
>>
>> Thanks
>>
>> Jo
>>
>> On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia <[hidden email]>
>> wrote:
>>
>>> Hi
>>>
>>> You can add in the schema that you want to upgrade in the process folder
>>> a file ending with the suffix -schemaupgrade.xsl that makes the upgrade,
>>> changing the elements in the xml to match the new schema and updating the
>>> schemaid in the database, the process can be invoked using
>>>  XlsProcessingApi and MetadataProcessApi, but both seem oriented to single
>>> metadata updates.
>>>
>>> See
>>> https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
>>>
>>> Regards,
>>> Jose García
>>>
>>> On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
>>> [hidden email]> wrote:
>>>
>>>> Hi Jo,
>>>>
>>>> We are facing a similar issue with a small number of metadata records
>>>> in the database from iso19115-3 going to iso19115-3.2018. We do not have a
>>>> conclusion yet. Below I describe some of the approaches we are considering.
>>>> I hope this is helpful, or at least starts discussion, raises other
>>>> questions, and potentially results in a "best practice" that I will
>>>> volunteer to write for the documentation.
>>>>
>>>> We considered adding the -3 to -3.2018 xsl transform to the list of
>>>> transforms on the "Import new records" page. Then we could export the 2014
>>>> version files, and then import (and transform) with the overwrite metadata
>>>> with same uuid option. We have not yet tested that to see if the metadata
>>>> database record is fully and correctly updated with the schemid.  I do not
>>>> have a deep knowledge of the code and am not sure if this was ever defined
>>>> as a requirement or test case. I too am hesitant to do things in
>>>> unanticipated ways and have established a rule that our external programs
>>>> will access the geonetwork database in read-only mode.
>>>>
>>>> We also considered exporting the metadata records, using GeoNetwork to
>>>> delete the older schema records, and then import keeping the uuid in the
>>>> import file. My thought is this would force the deletion of the database
>>>> metadata record, so when imported, it would have to create an entire new
>>>> record.  BUT this has the side effect of the metadata.id value
>>>> changing. I am not sure if that is good, neutral, or causes problems.
>>>>
>>>> Regardless of the way to update the records, I would guess that it
>>>> would be good to force reindexing.
>>>>
>>>> We have the added complexity of using many
>>>> "directories"/"snippets"/"re-usable element content"/some other name.  We
>>>> also have nested snippets - responsibleParty snippet contains a link to a
>>>> contact snippet that contains an onlineResource snippet.  How to export the
>>>> metadata.data field without resolving the xlinks to snippets is not
>>>> entirely clear. We have written some postgres queries to write the content
>>>> of metadata.data to a file. I noticed that the code for the download file
>>>> list of formats seems to have parameters that could allow specifying that
>>>> the xlinks should not be resolved. We have not figured out how to do that.
>>>>
>>>> Bigger Picture
>>>>
>>>> We have several hundred published records at this time all stored as
>>>> 19139.  Many were transformed from legacy metadata formats. Since we expect
>>>> potentially many thousands of records starting from legacy formats, or
>>>> perhaps minimal formal metadata, we are thinking about training for
>>>> 19115-3.2018 instead of the double learning curve for 19139 and then
>>>> 19115-3.x. If we decide that 19115-3.2018 is our primary internal format,
>>>> it seems to make sense to convert the snippets to that format instead of
>>>> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
>>>> conversion becomes much more difficult and risky if the snippet uuid has to
>>>> be changed.
>>>>
>>>> Any comments and questions are welcome. We're also happy to contribute
>>>> code, but our customization is minimal, so far.
>>>>
>>>> Jeff
>>>>
>>>>
>>>> On 3/17/2020 2:05 PM, Jo Cook wrote:
>>>>
>>>> Hi List,
>>>>
>>>> I'm wondering what method people use to change the schema that
>>>> metadata is stored in. The scenario- I want to convert records in
>>>> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
>>>> (iso19139.gemini23). I can change the actual metadata using an xsl
>>>> transformation, but as far as Geonetwork's database is concerned, the
>>>> records are still stored with a schemaid of iso19139.gemini22. I can
>>>> manually update the records in the database to change from one to the
>>>> other, but that's not ideal for end-users of the catalog who may want
>>>> to use a phased approach for converting and not do them all at once.
>>>>
>>>> What other methods have people used to fully convert records in place?
>>>> I really don't want to harvest into a new catalog, or export and
>>>> re-import them if at all possible.
>>>>
>>>> Thanks
>>>>
>>>> Jo
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> GeoNetwork-users mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>>>> GeoNetwork OpenSource is maintained at
>>>> http://sourceforge.net/projects/geonetwork
>>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Vriendelijke groeten / Kind regards,Jose García
>>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>>> (0)318 416664 <+31318416664>Please consider the environment before printing
>>> this email.*
>>>
>>
>>
>> --
>> *Jo Cook*
>> t:+44 7930 524 155/twitter:@archaeogeek
>> Please note that currently I do not work on Friday afternoons. For urgent
>> responses at that time, please visit support.astuntechnology.com or
>> phone our office on 01372 744009
>>
>>
>> --
>> *Sign up to our mailing list
>> <https://astuntechnology.com/company/#email-updates> for updates on news,
>> products, conferences, events and training*
>>
>> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
>> Surrey, KT19 8AG, UK
>> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
>> <https://twitter.com/astuntech>
>>
>> iShare - enterprise geographic intelligence platform
>> <https://astuntechnology.com/ishare/>
>> GeoServer, PostGIS and QGIS training
>> <https://astuntechnology.com/training-courses/>
>> Helpdesk and customer portal
>> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>>
>> Company registration no. 5410695. Registered in England and Wales.
>> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>> 864201149.
>>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
> *Vriendelijke groeten / Kind regards,Jose García
> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
> (0)318 416664 <+31318416664>Please consider the environment before printing
> this email.*
>


--
*Jo Cook*
t:+44 7930 524 155/twitter:@archaeogeek
Please note that currently I do not work on Friday afternoons. For urgent
responses at that time, please visit support.astuntechnology.com or phone
our office on 01372 744009

--
-- 
*Sign up to our mailing list
<https://astuntechnology.com/company/#email-updates> for updates on news,
products, conferences, events and training*
*
*

Astun Technology Ltd,
Epsom Square Centre, 6-7 The Derby Square, Epsom, Surrey, KT19 8AG, UK 

t:+44 1372 744 009 w: astuntechnology.com <http://astuntechnology.com/
twitter:@astuntech <https://twitter.com/astuntech>



iShare - enterprise
geographic intelligence platform <https://astuntechnology.com/ishare/>

GeoServer, PostGIS and QGIS training
<https://astuntechnology.com/training-courses/>
Helpdesk and customer
portal
<https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>





Company registration no. 5410695. Registered in England and Wales.
Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
864201149.

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jose Garcia
Hi Jo

It seems from the error that can't find the xsl in the schema related to
the metadata with id 918

I understand the xslt *iso19139.gemini23-schemaupgrade* is in the GEMINI
2.2 schema and the metadata with the id 918 is a GEMINI 2.2 record correct?

Regards,
Jose García

On Fri, Mar 20, 2020 at 2:03 PM Jo Cook <[hidden email]> wrote:

> Hi Jose (and list)
>
> I can get this process working via the api just fine, but I'm struggling
> with getting it working as a suggestion. With the files from
> https://github.com/AstunTechnology/iso19139.gemini22_GN3/commit/25417e5be1ddd692cf676ea23c335d106bc9618f
> the suggestion appears in the list but when it's run I get the following
> error:
>
> (URL:
> http://localhost:8080/geonetwork/srv/api/records/918/processes/iso19139.gemini23-schemaupgrade?process=iso19139.gemini23-schemaupgrade&id=918
> )
> <apiError>
> <code>runtime_exception</code>
> <description>
> Not found:0, Not owner:0, No process found:1. is not a valid value for:
> Processing failed
> </description>
> <message>BadParameterEx</message>
> </apiError>
>
> and I'm really not sure what I am doing wrong. Any ideas?
>
> Thanks
>
> Jo
>
>
>
>
>
>
> On Thu, Mar 19, 2020 at 4:33 PM Jose Garcia <[hidden email]>
> wrote:
>
>> Hi Jo
>>
>> The changed files should be quite similar in 3.4.x. I'll check if can
>> manage tomorrow to make a PR.
>>
>> Regards,
>> Jose García
>>
>>
>> On Thu, Mar 19, 2020 at 5:31 PM Jo Cook <[hidden email]>
>> wrote:
>>
>>> Hi Jose,
>>>
>>> That's great news- I will try it out. Is it something that would easily
>>> backport to 3.4? (Happy to give it a go if it's simple enough).
>>>
>>> Thanks
>>>
>>> Jo
>>>
>>> On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia <[hidden email]>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> You can add in the schema that you want to upgrade in the process
>>>> folder a file ending with the suffix -schemaupgrade.xsl that makes the
>>>> upgrade, changing the elements in the xml to match the new schema and
>>>> updating the schemaid in the database, the process can be invoked using
>>>>  XlsProcessingApi and MetadataProcessApi, but both seem oriented to single
>>>> metadata updates.
>>>>
>>>> See
>>>> https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
>>>>
>>>> Regards,
>>>> Jose García
>>>>
>>>> On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
>>>> [hidden email]> wrote:
>>>>
>>>>> Hi Jo,
>>>>>
>>>>> We are facing a similar issue with a small number of metadata records
>>>>> in the database from iso19115-3 going to iso19115-3.2018. We do not have a
>>>>> conclusion yet. Below I describe some of the approaches we are considering.
>>>>> I hope this is helpful, or at least starts discussion, raises other
>>>>> questions, and potentially results in a "best practice" that I will
>>>>> volunteer to write for the documentation.
>>>>>
>>>>> We considered adding the -3 to -3.2018 xsl transform to the list of
>>>>> transforms on the "Import new records" page. Then we could export the 2014
>>>>> version files, and then import (and transform) with the overwrite metadata
>>>>> with same uuid option. We have not yet tested that to see if the metadata
>>>>> database record is fully and correctly updated with the schemid.  I do not
>>>>> have a deep knowledge of the code and am not sure if this was ever defined
>>>>> as a requirement or test case. I too am hesitant to do things in
>>>>> unanticipated ways and have established a rule that our external programs
>>>>> will access the geonetwork database in read-only mode.
>>>>>
>>>>> We also considered exporting the metadata records, using GeoNetwork to
>>>>> delete the older schema records, and then import keeping the uuid in the
>>>>> import file. My thought is this would force the deletion of the database
>>>>> metadata record, so when imported, it would have to create an entire new
>>>>> record.  BUT this has the side effect of the metadata.id value
>>>>> changing. I am not sure if that is good, neutral, or causes problems.
>>>>>
>>>>> Regardless of the way to update the records, I would guess that it
>>>>> would be good to force reindexing.
>>>>>
>>>>> We have the added complexity of using many
>>>>> "directories"/"snippets"/"re-usable element content"/some other name.  We
>>>>> also have nested snippets - responsibleParty snippet contains a link to a
>>>>> contact snippet that contains an onlineResource snippet.  How to export the
>>>>> metadata.data field without resolving the xlinks to snippets is not
>>>>> entirely clear. We have written some postgres queries to write the content
>>>>> of metadata.data to a file. I noticed that the code for the download file
>>>>> list of formats seems to have parameters that could allow specifying that
>>>>> the xlinks should not be resolved. We have not figured out how to do that.
>>>>>
>>>>> Bigger Picture
>>>>>
>>>>> We have several hundred published records at this time all stored as
>>>>> 19139.  Many were transformed from legacy metadata formats. Since we expect
>>>>> potentially many thousands of records starting from legacy formats, or
>>>>> perhaps minimal formal metadata, we are thinking about training for
>>>>> 19115-3.2018 instead of the double learning curve for 19139 and then
>>>>> 19115-3.x. If we decide that 19115-3.2018 is our primary internal format,
>>>>> it seems to make sense to convert the snippets to that format instead of
>>>>> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
>>>>> conversion becomes much more difficult and risky if the snippet uuid has to
>>>>> be changed.
>>>>>
>>>>> Any comments and questions are welcome. We're also happy to contribute
>>>>> code, but our customization is minimal, so far.
>>>>>
>>>>> Jeff
>>>>>
>>>>>
>>>>> On 3/17/2020 2:05 PM, Jo Cook wrote:
>>>>>
>>>>> Hi List,
>>>>>
>>>>> I'm wondering what method people use to change the schema that
>>>>> metadata is stored in. The scenario- I want to convert records in
>>>>> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
>>>>> (iso19139.gemini23). I can change the actual metadata using an xsl
>>>>> transformation, but as far as Geonetwork's database is concerned, the
>>>>> records are still stored with a schemaid of iso19139.gemini22. I can
>>>>> manually update the records in the database to change from one to the
>>>>> other, but that's not ideal for end-users of the catalog who may want
>>>>> to use a phased approach for converting and not do them all at once.
>>>>>
>>>>> What other methods have people used to fully convert records in place?
>>>>> I really don't want to harvest into a new catalog, or export and
>>>>> re-import them if at all possible.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jo
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> GeoNetwork-users mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>>>>> GeoNetwork OpenSource is maintained at
>>>>> http://sourceforge.net/projects/geonetwork
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Vriendelijke groeten / Kind regards,Jose García
>>>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>>>> (0)318 416664 <+31318416664>Please consider the environment before printing
>>>> this email.*
>>>>
>>>
>>>
>>> --
>>> *Jo Cook*
>>> t:+44 7930 524 155/twitter:@archaeogeek
>>> Please note that currently I do not work on Friday afternoons. For
>>> urgent responses at that time, please visit support.astuntechnology.com or
>>> phone our office on 01372 744009
>>>
>>>
>>> --
>>> *Sign up to our mailing list
>>> <https://astuntechnology.com/company/#email-updates> for updates on news,
>>> products, conferences, events and training*
>>>
>>> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
>>> Surrey, KT19 8AG, UK
>>> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
>>> <https://twitter.com/astuntech>
>>>
>>> iShare - enterprise geographic intelligence platform
>>> <https://astuntechnology.com/ishare/>
>>> GeoServer, PostGIS and QGIS training
>>> <https://astuntechnology.com/training-courses/>
>>> Helpdesk and customer portal
>>> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>>>
>>> Company registration no. 5410695. Registered in England and Wales.
>>> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>>> 864201149.
>>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Vriendelijke groeten / Kind regards,Jose García
>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>> (0)318 416664 <+31318416664>Please consider the environment before printing
>> this email.*
>>
>
>
> --
> *Jo Cook*
> t:+44 7930 524 155/twitter:@archaeogeek
> Please note that currently I do not work on Friday afternoons. For urgent
> responses at that time, please visit support.astuntechnology.com or phone
> our office on 01372 744009
>
>
> --
> *Sign up to our mailing list
> <https://astuntechnology.com/company/#email-updates> for updates on news,
> products, conferences, events and training*
>
> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
> Surrey, KT19 8AG, UK
> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
> <https://twitter.com/astuntech>
>
> iShare - enterprise geographic intelligence platform
> <https://astuntechnology.com/ishare/>
> GeoServer, PostGIS and QGIS training
> <https://astuntechnology.com/training-courses/>
> Helpdesk and customer portal
> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>
> Company registration no. 5410695. Registered in England and Wales.
> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
> 864201149.
>


--











*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
(0)318 416664 <+31318416664>Please consider the environment before printing
this email.*

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Xiawucha ZZ
In reply to this post by Jo Cook
Hi Jo,
I think the url you're using might be wrong, can you try
http://localhost:8080/geonetwork/srv/api/0.1/records/918/processes/iso19139.gemini23-schemaupgrade
<http://geo-dev.nal.usda.gov:8080/geonetwork/srv/api/0.1/records/m_3807708_se_18_1_20170725/processes/iso19115-3.2018-schemaupgrade>
?
In the swagger api document, it's
/api/0.1/records/{metadataUuid}/processes/{process}
<https://geodata-stage.nal.usda.gov/geonetwork/doc/api/#/operations/records/processRecordPreview>
<https://geodata-stage.nal.usda.gov/geonetwork/doc/api/#/operations/records/processRecordPreview>
I tried to upgrade our iso19115-3 to iso19115-3.2018 using that api, it
works. But I'm using version 3.10.1.
Thanks,
Zhuoyue

On Fri, Mar 20, 2020 at 9:03 AM Jo Cook <[hidden email]> wrote:

> Hi Jose (and list)
>
> I can get this process working via the api just fine, but I'm struggling
> with getting it working as a suggestion. With the files from
>
> https://github.com/AstunTechnology/iso19139.gemini22_GN3/commit/25417e5be1ddd692cf676ea23c335d106bc9618f
> the suggestion appears in the list but when it's run I get the following
> error:
>
> (URL:
>
> http://localhost:8080/geonetwork/srv/api/records/918/processes/iso19139.gemini23-schemaupgrade?process=iso19139.gemini23-schemaupgrade&id=918
> )
> <apiError>
> <code>runtime_exception</code>
> <description>
> Not found:0, Not owner:0, No process found:1. is not a valid value for:
> Processing failed
> </description>
> <message>BadParameterEx</message>
> </apiError>
>
> and I'm really not sure what I am doing wrong. Any ideas?
>
> Thanks
>
> Jo
>
>
>
>
>
>
> On Thu, Mar 19, 2020 at 4:33 PM Jose Garcia <[hidden email]>
> wrote:
>
> > Hi Jo
> >
> > The changed files should be quite similar in 3.4.x. I'll check if can
> > manage tomorrow to make a PR.
> >
> > Regards,
> > Jose García
> >
> >
> > On Thu, Mar 19, 2020 at 5:31 PM Jo Cook <[hidden email]>
> > wrote:
> >
> >> Hi Jose,
> >>
> >> That's great news- I will try it out. Is it something that would easily
> >> backport to 3.4? (Happy to give it a go if it's simple enough).
> >>
> >> Thanks
> >>
> >> Jo
> >>
> >> On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia <[hidden email]>
> >> wrote:
> >>
> >>> Hi
> >>>
> >>> You can add in the schema that you want to upgrade in the process
> folder
> >>> a file ending with the suffix -schemaupgrade.xsl that makes the
> upgrade,
> >>> changing the elements in the xml to match the new schema and updating
> the
> >>> schemaid in the database, the process can be invoked using
> >>>  XlsProcessingApi and MetadataProcessApi, but both seem oriented to
> single
> >>> metadata updates.
> >>>
> >>> See
> >>>
> https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
> >>>
> >>> Regards,
> >>> Jose García
> >>>
> >>> On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
> >>> [hidden email]> wrote:
> >>>
> >>>> Hi Jo,
> >>>>
> >>>> We are facing a similar issue with a small number of metadata records
> >>>> in the database from iso19115-3 going to iso19115-3.2018. We do not
> have a
> >>>> conclusion yet. Below I describe some of the approaches we are
> considering.
> >>>> I hope this is helpful, or at least starts discussion, raises other
> >>>> questions, and potentially results in a "best practice" that I will
> >>>> volunteer to write for the documentation.
> >>>>
> >>>> We considered adding the -3 to -3.2018 xsl transform to the list of
> >>>> transforms on the "Import new records" page. Then we could export the
> 2014
> >>>> version files, and then import (and transform) with the overwrite
> metadata
> >>>> with same uuid option. We have not yet tested that to see if the
> metadata
> >>>> database record is fully and correctly updated with the schemid.  I
> do not
> >>>> have a deep knowledge of the code and am not sure if this was ever
> defined
> >>>> as a requirement or test case. I too am hesitant to do things in
> >>>> unanticipated ways and have established a rule that our external
> programs
> >>>> will access the geonetwork database in read-only mode.
> >>>>
> >>>> We also considered exporting the metadata records, using GeoNetwork to
> >>>> delete the older schema records, and then import keeping the uuid in
> the
> >>>> import file. My thought is this would force the deletion of the
> database
> >>>> metadata record, so when imported, it would have to create an entire
> new
> >>>> record.  BUT this has the side effect of the metadata.id value
> >>>> changing. I am not sure if that is good, neutral, or causes problems.
> >>>>
> >>>> Regardless of the way to update the records, I would guess that it
> >>>> would be good to force reindexing.
> >>>>
> >>>> We have the added complexity of using many
> >>>> "directories"/"snippets"/"re-usable element content"/some other
> name.  We
> >>>> also have nested snippets - responsibleParty snippet contains a link
> to a
> >>>> contact snippet that contains an onlineResource snippet.  How to
> export the
> >>>> metadata.data field without resolving the xlinks to snippets is not
> >>>> entirely clear. We have written some postgres queries to write the
> content
> >>>> of metadata.data to a file. I noticed that the code for the download
> file
> >>>> list of formats seems to have parameters that could allow specifying
> that
> >>>> the xlinks should not be resolved. We have not figured out how to do
> that.
> >>>>
> >>>> Bigger Picture
> >>>>
> >>>> We have several hundred published records at this time all stored as
> >>>> 19139.  Many were transformed from legacy metadata formats. Since we
> expect
> >>>> potentially many thousands of records starting from legacy formats, or
> >>>> perhaps minimal formal metadata, we are thinking about training for
> >>>> 19115-3.2018 instead of the double learning curve for 19139 and then
> >>>> 19115-3.x. If we decide that 19115-3.2018 is our primary internal
> format,
> >>>> it seems to make sense to convert the snippets to that format instead
> of
> >>>> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
> >>>> conversion becomes much more difficult and risky if the snippet uuid
> has to
> >>>> be changed.
> >>>>
> >>>> Any comments and questions are welcome. We're also happy to contribute
> >>>> code, but our customization is minimal, so far.
> >>>>
> >>>> Jeff
> >>>>
> >>>>
> >>>> On 3/17/2020 2:05 PM, Jo Cook wrote:
> >>>>
> >>>> Hi List,
> >>>>
> >>>> I'm wondering what method people use to change the schema that
> >>>> metadata is stored in. The scenario- I want to convert records in
> >>>> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
> >>>> (iso19139.gemini23). I can change the actual metadata using an xsl
> >>>> transformation, but as far as Geonetwork's database is concerned, the
> >>>> records are still stored with a schemaid of iso19139.gemini22. I can
> >>>> manually update the records in the database to change from one to the
> >>>> other, but that's not ideal for end-users of the catalog who may want
> >>>> to use a phased approach for converting and not do them all at once.
> >>>>
> >>>> What other methods have people used to fully convert records in place?
> >>>> I really don't want to harvest into a new catalog, or export and
> >>>> re-import them if at all possible.
> >>>>
> >>>> Thanks
> >>>>
> >>>> Jo
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> GeoNetwork-users mailing list
> >>>> [hidden email]
> >>>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
> >>>> GeoNetwork OpenSource is maintained at
> >>>> http://sourceforge.net/projects/geonetwork
> >>>>
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> *Vriendelijke groeten / Kind regards,Jose García
> >>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe
> NetherlandsT: +31
> >>> (0)318 416664 <+31318416664>Please consider the environment before
> printing
> >>> this email.*
> >>>
> >>
> >>
> >> --
> >> *Jo Cook*
> >> t:+44 7930 524 155/twitter:@archaeogeek
> >> Please note that currently I do not work on Friday afternoons. For
> urgent
> >> responses at that time, please visit support.astuntechnology.com or
> >> phone our office on 01372 744009
> >>
> >>
> >> --
> >> *Sign up to our mailing list
> >> <https://astuntechnology.com/company/#email-updates> for updates on
> news,
> >> products, conferences, events and training*
> >>
> >> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
> >> Surrey, KT19 8AG, UK
> >> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
> >> <https://twitter.com/astuntech>
> >>
> >> iShare - enterprise geographic intelligence platform
> >> <https://astuntechnology.com/ishare/>
> >> GeoServer, PostGIS and QGIS training
> >> <https://astuntechnology.com/training-courses/>
> >> Helpdesk and customer portal
> >> <
> https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal
> >
> >>
> >> Company registration no. 5410695. Registered in England and Wales.
> >> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
> >> 864201149.
> >>
> >
> >
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *Vriendelijke groeten / Kind regards,Jose García
> > <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT:
> +31
> > (0)318 416664 <+31318416664>Please consider the environment before
> printing
> > this email.*
> >
>
>
> --
> *Jo Cook*
> t:+44 7930 524 155/twitter:@archaeogeek
> Please note that currently I do not work on Friday afternoons. For urgent
> responses at that time, please visit support.astuntechnology.com or phone
> our office on 01372 744009
>
> --
> --
> *Sign up to our mailing list
> <https://astuntechnology.com/company/#email-updates> for updates on news,
> products, conferences, events and training*
> *
> *
>
> Astun Technology Ltd,
> Epsom Square Centre, 6-7 The Derby Square, Epsom, Surrey, KT19 8AG, UK
>
> t:+44 1372 744 009 w: astuntechnology.com <http://astuntechnology.com/>
> twitter:@astuntech <https://twitter.com/astuntech>
>
>
>
> iShare - enterprise
> geographic intelligence platform <https://astuntechnology.com/ishare/>
>
> GeoServer, PostGIS and QGIS training
> <https://astuntechnology.com/training-courses/>
> Helpdesk and customer
> portal
> <
> https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal
> >
>
>
>
>
>
> Company registration no. 5410695. Registered in England and Wales.
> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
> 864201149.
>
> _______________________________________________
> GeoNetwork-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
> GeoNetwork OpenSource is maintained at
> http://sourceforge.net/projects/geonetwork
>

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jeff Campbell
Just to clarify, the URLs that are not localhost are in our development environment with no public access.
Zhuoyue and I are working on the same project.

Jeff

On 3/20/2020 9:57 AM, Xiawucha ZZ wrote:
Hi Jo,
I think the url you're using might be wrong, can you try
http://localhost:8080/geonetwork/srv/api/0.1/records/918/processes/iso19139.gemini23-schemaupgrade
<http://geo-dev.nal.usda.gov:8080/geonetwork/srv/api/0.1/records/m_3807708_se_18_1_20170725/processes/iso19115-3.2018-schemaupgrade>
?
In the swagger api document, it's
/api/0.1/records/{metadataUuid}/processes/{process}
<https://geodata-stage.nal.usda.gov/geonetwork/doc/api/#/operations/records/processRecordPreview>
<https://geodata-stage.nal.usda.gov/geonetwork/doc/api/#/operations/records/processRecordPreview>
I tried to upgrade our iso19115-3 to iso19115-3.2018 using that api, it
works. But I'm using version 3.10.1.
Thanks,
Zhuoyue

On Fri, Mar 20, 2020 at 9:03 AM Jo Cook [hidden email] wrote:

Hi Jose (and list)

I can get this process working via the api just fine, but I'm struggling
with getting it working as a suggestion. With the files from

https://github.com/AstunTechnology/iso19139.gemini22_GN3/commit/25417e5be1ddd692cf676ea23c335d106bc9618f
the suggestion appears in the list but when it's run I get the following
error:

(URL:

http://localhost:8080/geonetwork/srv/api/records/918/processes/iso19139.gemini23-schemaupgrade?process=iso19139.gemini23-schemaupgrade&id=918
)
<apiError>
<code>runtime_exception</code>
<description>
Not found:0, Not owner:0, No process found:1. is not a valid value for:
Processing failed
</description>
<message>BadParameterEx</message>
</apiError>

and I'm really not sure what I am doing wrong. Any ideas?

Thanks

Jo






On Thu, Mar 19, 2020 at 4:33 PM Jose Garcia [hidden email]
wrote:

Hi Jo

The changed files should be quite similar in 3.4.x. I'll check if can
manage tomorrow to make a PR.

Regards,
Jose García


On Thu, Mar 19, 2020 at 5:31 PM Jo Cook [hidden email]
wrote:

Hi Jose,

That's great news- I will try it out. Is it something that would easily
backport to 3.4? (Happy to give it a go if it's simple enough).

Thanks

Jo

On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia [hidden email]
wrote:

Hi

You can add in the schema that you want to upgrade in the process
folder
a file ending with the suffix -schemaupgrade.xsl that makes the
upgrade,
changing the elements in the xml to match the new schema and updating
the
schemaid in the database, the process can be invoked using
 XlsProcessingApi and MetadataProcessApi, but both seem oriented to
single
metadata updates.

See

https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
Regards,
Jose García

On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
[hidden email]> wrote:

Hi Jo,

We are facing a similar issue with a small number of metadata records
in the database from iso19115-3 going to iso19115-3.2018. We do not
have a
conclusion yet. Below I describe some of the approaches we are
considering.
I hope this is helpful, or at least starts discussion, raises other
questions, and potentially results in a "best practice" that I will
volunteer to write for the documentation.

We considered adding the -3 to -3.2018 xsl transform to the list of
transforms on the "Import new records" page. Then we could export the
2014
version files, and then import (and transform) with the overwrite
metadata
with same uuid option. We have not yet tested that to see if the
metadata
database record is fully and correctly updated with the schemid.  I
do not
have a deep knowledge of the code and am not sure if this was ever
defined
as a requirement or test case. I too am hesitant to do things in
unanticipated ways and have established a rule that our external
programs
will access the geonetwork database in read-only mode.

We also considered exporting the metadata records, using GeoNetwork to
delete the older schema records, and then import keeping the uuid in
the
import file. My thought is this would force the deletion of the
database
metadata record, so when imported, it would have to create an entire
new
record.  BUT this has the side effect of the metadata.id value
changing. I am not sure if that is good, neutral, or causes problems.

Regardless of the way to update the records, I would guess that it
would be good to force reindexing.

We have the added complexity of using many
"directories"/"snippets"/"re-usable element content"/some other
name.  We
also have nested snippets - responsibleParty snippet contains a link
to a
contact snippet that contains an onlineResource snippet.  How to
export the
metadata.data field without resolving the xlinks to snippets is not
entirely clear. We have written some postgres queries to write the
content
of metadata.data to a file. I noticed that the code for the download
file
list of formats seems to have parameters that could allow specifying
that
the xlinks should not be resolved. We have not figured out how to do
that.
Bigger Picture

We have several hundred published records at this time all stored as
19139.  Many were transformed from legacy metadata formats. Since we
expect
potentially many thousands of records starting from legacy formats, or
perhaps minimal formal metadata, we are thinking about training for
19115-3.2018 instead of the double learning curve for 19139 and then
19115-3.x. If we decide that 19115-3.2018 is our primary internal
format,
it seems to make sense to convert the snippets to that format instead
of
on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
conversion becomes much more difficult and risky if the snippet uuid
has to
be changed.

Any comments and questions are welcome. We're also happy to contribute
code, but our customization is minimal, so far.

Jeff


On 3/17/2020 2:05 PM, Jo Cook wrote:

Hi List,

I'm wondering what method people use to change the schema that
metadata is stored in. The scenario- I want to convert records in
Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
(iso19139.gemini23). I can change the actual metadata using an xsl
transformation, but as far as Geonetwork's database is concerned, the
records are still stored with a schemaid of iso19139.gemini22. I can
manually update the records in the database to change from one to the
other, but that's not ideal for end-users of the catalog who may want
to use a phased approach for converting and not do them all at once.

What other methods have people used to fully convert records in place?
I really don't want to harvest into a new catalog, or export and
re-import them if at all possible.

Thanks

Jo



_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork


--











*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe
NetherlandsT: +31
(0)318 416664 <+31318416664>Please consider the environment before
printing
this email.*


--
*Jo Cook*
t:+44 7930 524 155/twitter:@archaeogeek
Please note that currently I do not work on Friday afternoons. For
urgent
responses at that time, please visit support.astuntechnology.com or
phone our office on 01372 744009


--
*Sign up to our mailing list
<https://astuntechnology.com/company/#email-updates> for updates on
news,
products, conferences, events and training*

Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
Surrey, KT19 8AG, UK
t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
<https://twitter.com/astuntech>

iShare - enterprise geographic intelligence platform
<https://astuntechnology.com/ishare/>
GeoServer, PostGIS and QGIS training
<https://astuntechnology.com/training-courses/>
Helpdesk and customer portal
<
https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal

          
Company registration no. 5410695. Registered in England and Wales.
Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
864201149.


--











*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT:
+31
(0)318 416664 <+31318416664>Please consider the environment before
printing
this email.*


--
*Jo Cook*
t:+44 7930 524 155/twitter:@archaeogeek
Please note that currently I do not work on Friday afternoons. For urgent
responses at that time, please visit support.astuntechnology.com or phone
our office on 01372 744009

--
--
*Sign up to our mailing list
<https://astuntechnology.com/company/#email-updates> for updates on news,
products, conferences, events and training*
*
*

Astun Technology Ltd,
Epsom Square Centre, 6-7 The Derby Square, Epsom, Surrey, KT19 8AG, UK

t:+44 1372 744 009 w: astuntechnology.com <http://astuntechnology.com/>
twitter:@astuntech <https://twitter.com/astuntech>



iShare - enterprise
geographic intelligence platform <https://astuntechnology.com/ishare/>

GeoServer, PostGIS and QGIS training
<https://astuntechnology.com/training-courses/>
Helpdesk and customer
portal
<
https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal

        




Company registration no. 5410695. Registered in England and Wales.
Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
864201149.

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork




_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jo Cook
In reply to this post by Jose Garcia
Hi Jose,

Yes, that record is a gemini 2.2 record. The xslt
iso19139.gemini23-schemaupgrade is in the Gemini 2.2 schema folder, but it
references an xsl in the Gemini 2.3 folder. I will check it can find that
one.

Jo

On Fri, Mar 20, 2020 at 1:56 PM Jose Garcia <[hidden email]> wrote:

> Hi Jo
>
> It seems from the error that can't find the xsl in the schema related to
> the metadata with id 918
>
> I understand the xslt *iso19139.gemini23-schemaupgrade* is in the GEMINI
> 2.2 schema and the metadata with the id 918 is a GEMINI 2.2 record correct?
>
> Regards,
> Jose García
>
> On Fri, Mar 20, 2020 at 2:03 PM Jo Cook <[hidden email]>
> wrote:
>
>> Hi Jose (and list)
>>
>> I can get this process working via the api just fine, but I'm struggling
>> with getting it working as a suggestion. With the files from
>> https://github.com/AstunTechnology/iso19139.gemini22_GN3/commit/25417e5be1ddd692cf676ea23c335d106bc9618f
>> the suggestion appears in the list but when it's run I get the following
>> error:
>>
>> (URL:
>> http://localhost:8080/geonetwork/srv/api/records/918/processes/iso19139.gemini23-schemaupgrade?process=iso19139.gemini23-schemaupgrade&id=918
>> )
>> <apiError>
>> <code>runtime_exception</code>
>> <description>
>> Not found:0, Not owner:0, No process found:1. is not a valid value for:
>> Processing failed
>> </description>
>> <message>BadParameterEx</message>
>> </apiError>
>>
>> and I'm really not sure what I am doing wrong. Any ideas?
>>
>> Thanks
>>
>> Jo
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 19, 2020 at 4:33 PM Jose Garcia <[hidden email]>
>> wrote:
>>
>>> Hi Jo
>>>
>>> The changed files should be quite similar in 3.4.x. I'll check if can
>>> manage tomorrow to make a PR.
>>>
>>> Regards,
>>> Jose García
>>>
>>>
>>> On Thu, Mar 19, 2020 at 5:31 PM Jo Cook <[hidden email]>
>>> wrote:
>>>
>>>> Hi Jose,
>>>>
>>>> That's great news- I will try it out. Is it something that would easily
>>>> backport to 3.4? (Happy to give it a go if it's simple enough).
>>>>
>>>> Thanks
>>>>
>>>> Jo
>>>>
>>>> On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> You can add in the schema that you want to upgrade in the process
>>>>> folder a file ending with the suffix -schemaupgrade.xsl that makes the
>>>>> upgrade, changing the elements in the xml to match the new schema and
>>>>> updating the schemaid in the database, the process can be invoked using
>>>>>  XlsProcessingApi and MetadataProcessApi, but both seem oriented to single
>>>>> metadata updates.
>>>>>
>>>>> See
>>>>> https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
>>>>>
>>>>> Regards,
>>>>> Jose García
>>>>>
>>>>> On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> Hi Jo,
>>>>>>
>>>>>> We are facing a similar issue with a small number of metadata records
>>>>>> in the database from iso19115-3 going to iso19115-3.2018. We do not have a
>>>>>> conclusion yet. Below I describe some of the approaches we are considering.
>>>>>> I hope this is helpful, or at least starts discussion, raises other
>>>>>> questions, and potentially results in a "best practice" that I will
>>>>>> volunteer to write for the documentation.
>>>>>>
>>>>>> We considered adding the -3 to -3.2018 xsl transform to the list of
>>>>>> transforms on the "Import new records" page. Then we could export the 2014
>>>>>> version files, and then import (and transform) with the overwrite metadata
>>>>>> with same uuid option. We have not yet tested that to see if the metadata
>>>>>> database record is fully and correctly updated with the schemid.  I do not
>>>>>> have a deep knowledge of the code and am not sure if this was ever defined
>>>>>> as a requirement or test case. I too am hesitant to do things in
>>>>>> unanticipated ways and have established a rule that our external programs
>>>>>> will access the geonetwork database in read-only mode.
>>>>>>
>>>>>> We also considered exporting the metadata records, using GeoNetwork
>>>>>> to delete the older schema records, and then import keeping the uuid in the
>>>>>> import file. My thought is this would force the deletion of the database
>>>>>> metadata record, so when imported, it would have to create an entire new
>>>>>> record.  BUT this has the side effect of the metadata.id value
>>>>>> changing. I am not sure if that is good, neutral, or causes problems.
>>>>>>
>>>>>> Regardless of the way to update the records, I would guess that it
>>>>>> would be good to force reindexing.
>>>>>>
>>>>>> We have the added complexity of using many
>>>>>> "directories"/"snippets"/"re-usable element content"/some other name.  We
>>>>>> also have nested snippets - responsibleParty snippet contains a link to a
>>>>>> contact snippet that contains an onlineResource snippet.  How to export the
>>>>>> metadata.data field without resolving the xlinks to snippets is not
>>>>>> entirely clear. We have written some postgres queries to write the content
>>>>>> of metadata.data to a file. I noticed that the code for the download file
>>>>>> list of formats seems to have parameters that could allow specifying that
>>>>>> the xlinks should not be resolved. We have not figured out how to do that.
>>>>>>
>>>>>> Bigger Picture
>>>>>>
>>>>>> We have several hundred published records at this time all stored as
>>>>>> 19139.  Many were transformed from legacy metadata formats. Since we expect
>>>>>> potentially many thousands of records starting from legacy formats, or
>>>>>> perhaps minimal formal metadata, we are thinking about training for
>>>>>> 19115-3.2018 instead of the double learning curve for 19139 and then
>>>>>> 19115-3.x. If we decide that 19115-3.2018 is our primary internal format,
>>>>>> it seems to make sense to convert the snippets to that format instead of
>>>>>> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
>>>>>> conversion becomes much more difficult and risky if the snippet uuid has to
>>>>>> be changed.
>>>>>>
>>>>>> Any comments and questions are welcome. We're also happy to
>>>>>> contribute code, but our customization is minimal, so far.
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>>
>>>>>> On 3/17/2020 2:05 PM, Jo Cook wrote:
>>>>>>
>>>>>> Hi List,
>>>>>>
>>>>>> I'm wondering what method people use to change the schema that
>>>>>> metadata is stored in. The scenario- I want to convert records in
>>>>>> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
>>>>>> (iso19139.gemini23). I can change the actual metadata using an xsl
>>>>>> transformation, but as far as Geonetwork's database is concerned, the
>>>>>> records are still stored with a schemaid of iso19139.gemini22. I can
>>>>>> manually update the records in the database to change from one to the
>>>>>> other, but that's not ideal for end-users of the catalog who may want
>>>>>> to use a phased approach for converting and not do them all at once.
>>>>>>
>>>>>> What other methods have people used to fully convert records in place?
>>>>>> I really don't want to harvest into a new catalog, or export and
>>>>>> re-import them if at all possible.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jo
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> GeoNetwork-users mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>>>>>> GeoNetwork OpenSource is maintained at
>>>>>> http://sourceforge.net/projects/geonetwork
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Vriendelijke groeten / Kind regards,Jose García
>>>>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>>>>> (0)318 416664 <+31318416664>Please consider the environment before printing
>>>>> this email.*
>>>>>
>>>>
>>>>
>>>> --
>>>> *Jo Cook*
>>>> t:+44 7930 524 155/twitter:@archaeogeek
>>>> Please note that currently I do not work on Friday afternoons. For
>>>> urgent responses at that time, please visit support.astuntechnology.com or
>>>> phone our office on 01372 744009
>>>>
>>>>
>>>> --
>>>> *Sign up to our mailing list
>>>> <https://astuntechnology.com/company/#email-updates> for updates on news,
>>>> products, conferences, events and training*
>>>>
>>>> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
>>>> Surrey, KT19 8AG, UK
>>>> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
>>>> <https://twitter.com/astuntech>
>>>>
>>>> iShare - enterprise geographic intelligence platform
>>>> <https://astuntechnology.com/ishare/>
>>>> GeoServer, PostGIS and QGIS training
>>>> <https://astuntechnology.com/training-courses/>
>>>> Helpdesk and customer portal
>>>> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>>>>
>>>> Company registration no. 5410695. Registered in England and Wales.
>>>> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>>>> 864201149.
>>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Vriendelijke groeten / Kind regards,Jose García
>>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>>> (0)318 416664 <+31318416664>Please consider the environment before printing
>>> this email.*
>>>
>>
>>
>> --
>> *Jo Cook*
>> t:+44 7930 524 155/twitter:@archaeogeek
>> Please note that currently I do not work on Friday afternoons. For urgent
>> responses at that time, please visit support.astuntechnology.com or
>> phone our office on 01372 744009
>>
>>
>> --
>> *Sign up to our mailing list
>> <https://astuntechnology.com/company/#email-updates> for updates on news,
>> products, conferences, events and training*
>>
>> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
>> Surrey, KT19 8AG, UK
>> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
>> <https://twitter.com/astuntech>
>>
>> iShare - enterprise geographic intelligence platform
>> <https://astuntechnology.com/ishare/>
>> GeoServer, PostGIS and QGIS training
>> <https://astuntechnology.com/training-courses/>
>> Helpdesk and customer portal
>> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>>
>> Company registration no. 5410695. Registered in England and Wales.
>> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>> 864201149.
>>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
> *Vriendelijke groeten / Kind regards,Jose García
> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
> (0)318 416664 <+31318416664>Please consider the environment before printing
> this email.*
>


--
*Jo Cook*
t:+44 7930 524 155/twitter:@archaeogeek
Please note that currently I do not work on Friday afternoons. For urgent
responses at that time, please visit support.astuntechnology.com or phone
our office on 01372 744009

--
-- 
*Sign up to our mailing list
<https://astuntechnology.com/company/#email-updates> for updates on news,
products, conferences, events and training*
*
*

Astun Technology Ltd,
Epsom Square Centre, 6-7 The Derby Square, Epsom, Surrey, KT19 8AG, UK 

t:+44 1372 744 009 w: astuntechnology.com <http://astuntechnology.com/
twitter:@astuntech <https://twitter.com/astuntech>



iShare - enterprise
geographic intelligence platform <https://astuntechnology.com/ishare/>

GeoServer, PostGIS and QGIS training
<https://astuntechnology.com/training-courses/>
Helpdesk and customer
portal
<https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>





Company registration no. 5410695. Registered in England and Wales.
Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
864201149.

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jo Cook
In reply to this post by Xiawucha ZZ
Hi,

That URL is automatically generated by the suggest process, it's not
something I have any control over, as far as I can tell? My xsl works
when using the API.

Thanks

Jo

On Fri, Mar 20, 2020 at 1:57 PM Xiawucha ZZ <[hidden email]> wrote:

>
> Hi Jo,
> I think the url you're using might be wrong, can you try http://localhost:8080/geonetwork/srv/api/0.1/records/918/processes/iso19139.gemini23-schemaupgrade ? In the swagger api document, it's /api/0.1/records/{metadataUuid}/processes/{process}
> I tried to upgrade our iso19115-3 to iso19115-3.2018 using that api, it works. But I'm using version 3.10.1.
> Thanks,
> Zhuoyue
>
> On Fri, Mar 20, 2020 at 9:03 AM Jo Cook <[hidden email]> wrote:
>>
>> Hi Jose (and list)
>>
>> I can get this process working via the api just fine, but I'm struggling
>> with getting it working as a suggestion. With the files from
>> https://github.com/AstunTechnology/iso19139.gemini22_GN3/commit/25417e5be1ddd692cf676ea23c335d106bc9618f
>> the suggestion appears in the list but when it's run I get the following
>> error:
>>
>> (URL:
>> http://localhost:8080/geonetwork/srv/api/records/918/processes/iso19139.gemini23-schemaupgrade?process=iso19139.gemini23-schemaupgrade&id=918
>> )
>> <apiError>
>> <code>runtime_exception</code>
>> <description>
>> Not found:0, Not owner:0, No process found:1. is not a valid value for:
>> Processing failed
>> </description>
>> <message>BadParameterEx</message>
>> </apiError>
>>
>> and I'm really not sure what I am doing wrong. Any ideas?
>>
>> Thanks
>>
>> Jo
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 19, 2020 at 4:33 PM Jose Garcia <[hidden email]> wrote:
>>
>> > Hi Jo
>> >
>> > The changed files should be quite similar in 3.4.x. I'll check if can
>> > manage tomorrow to make a PR.
>> >
>> > Regards,
>> > Jose García
>> >
>> >
>> > On Thu, Mar 19, 2020 at 5:31 PM Jo Cook <[hidden email]>
>> > wrote:
>> >
>> >> Hi Jose,
>> >>
>> >> That's great news- I will try it out. Is it something that would easily
>> >> backport to 3.4? (Happy to give it a go if it's simple enough).
>> >>
>> >> Thanks
>> >>
>> >> Jo
>> >>
>> >> On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia <[hidden email]>
>> >> wrote:
>> >>
>> >>> Hi
>> >>>
>> >>> You can add in the schema that you want to upgrade in the process folder
>> >>> a file ending with the suffix -schemaupgrade.xsl that makes the upgrade,
>> >>> changing the elements in the xml to match the new schema and updating the
>> >>> schemaid in the database, the process can be invoked using
>> >>>  XlsProcessingApi and MetadataProcessApi, but both seem oriented to single
>> >>> metadata updates.
>> >>>
>> >>> See
>> >>> https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
>> >>>
>> >>> Regards,
>> >>> Jose García
>> >>>
>> >>> On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
>> >>> [hidden email]> wrote:
>> >>>
>> >>>> Hi Jo,
>> >>>>
>> >>>> We are facing a similar issue with a small number of metadata records
>> >>>> in the database from iso19115-3 going to iso19115-3.2018. We do not have a
>> >>>> conclusion yet. Below I describe some of the approaches we are considering.
>> >>>> I hope this is helpful, or at least starts discussion, raises other
>> >>>> questions, and potentially results in a "best practice" that I will
>> >>>> volunteer to write for the documentation.
>> >>>>
>> >>>> We considered adding the -3 to -3.2018 xsl transform to the list of
>> >>>> transforms on the "Import new records" page. Then we could export the 2014
>> >>>> version files, and then import (and transform) with the overwrite metadata
>> >>>> with same uuid option. We have not yet tested that to see if the metadata
>> >>>> database record is fully and correctly updated with the schemid.  I do not
>> >>>> have a deep knowledge of the code and am not sure if this was ever defined
>> >>>> as a requirement or test case. I too am hesitant to do things in
>> >>>> unanticipated ways and have established a rule that our external programs
>> >>>> will access the geonetwork database in read-only mode.
>> >>>>
>> >>>> We also considered exporting the metadata records, using GeoNetwork to
>> >>>> delete the older schema records, and then import keeping the uuid in the
>> >>>> import file. My thought is this would force the deletion of the database
>> >>>> metadata record, so when imported, it would have to create an entire new
>> >>>> record.  BUT this has the side effect of the metadata.id value
>> >>>> changing. I am not sure if that is good, neutral, or causes problems.
>> >>>>
>> >>>> Regardless of the way to update the records, I would guess that it
>> >>>> would be good to force reindexing.
>> >>>>
>> >>>> We have the added complexity of using many
>> >>>> "directories"/"snippets"/"re-usable element content"/some other name.  We
>> >>>> also have nested snippets - responsibleParty snippet contains a link to a
>> >>>> contact snippet that contains an onlineResource snippet.  How to export the
>> >>>> metadata.data field without resolving the xlinks to snippets is not
>> >>>> entirely clear. We have written some postgres queries to write the content
>> >>>> of metadata.data to a file. I noticed that the code for the download file
>> >>>> list of formats seems to have parameters that could allow specifying that
>> >>>> the xlinks should not be resolved. We have not figured out how to do that.
>> >>>>
>> >>>> Bigger Picture
>> >>>>
>> >>>> We have several hundred published records at this time all stored as
>> >>>> 19139.  Many were transformed from legacy metadata formats. Since we expect
>> >>>> potentially many thousands of records starting from legacy formats, or
>> >>>> perhaps minimal formal metadata, we are thinking about training for
>> >>>> 19115-3.2018 instead of the double learning curve for 19139 and then
>> >>>> 19115-3.x. If we decide that 19115-3.2018 is our primary internal format,
>> >>>> it seems to make sense to convert the snippets to that format instead of
>> >>>> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
>> >>>> conversion becomes much more difficult and risky if the snippet uuid has to
>> >>>> be changed.
>> >>>>
>> >>>> Any comments and questions are welcome. We're also happy to contribute
>> >>>> code, but our customization is minimal, so far.
>> >>>>
>> >>>> Jeff
>> >>>>
>> >>>>
>> >>>> On 3/17/2020 2:05 PM, Jo Cook wrote:
>> >>>>
>> >>>> Hi List,
>> >>>>
>> >>>> I'm wondering what method people use to change the schema that
>> >>>> metadata is stored in. The scenario- I want to convert records in
>> >>>> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
>> >>>> (iso19139.gemini23). I can change the actual metadata using an xsl
>> >>>> transformation, but as far as Geonetwork's database is concerned, the
>> >>>> records are still stored with a schemaid of iso19139.gemini22. I can
>> >>>> manually update the records in the database to change from one to the
>> >>>> other, but that's not ideal for end-users of the catalog who may want
>> >>>> to use a phased approach for converting and not do them all at once.
>> >>>>
>> >>>> What other methods have people used to fully convert records in place?
>> >>>> I really don't want to harvest into a new catalog, or export and
>> >>>> re-import them if at all possible.
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>> Jo
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> GeoNetwork-users mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>> >>>> GeoNetwork OpenSource is maintained at
>> >>>> http://sourceforge.net/projects/geonetwork
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> *Vriendelijke groeten / Kind regards,Jose García
>> >>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>> >>> (0)318 416664 <+31318416664>Please consider the environment before printing
>> >>> this email.*
>> >>>
>> >>
>> >>
>> >> --
>> >> *Jo Cook*
>> >> t:+44 7930 524 155/twitter:@archaeogeek
>> >> Please note that currently I do not work on Friday afternoons. For urgent
>> >> responses at that time, please visit support.astuntechnology.com or
>> >> phone our office on 01372 744009
>> >>
>> >>
>> >> --
>> >> *Sign up to our mailing list
>> >> <https://astuntechnology.com/company/#email-updates> for updates on news,
>> >> products, conferences, events and training*
>> >>
>> >> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
>> >> Surrey, KT19 8AG, UK
>> >> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
>> >> <https://twitter.com/astuntech>
>> >>
>> >> iShare - enterprise geographic intelligence platform
>> >> <https://astuntechnology.com/ishare/>
>> >> GeoServer, PostGIS and QGIS training
>> >> <https://astuntechnology.com/training-courses/>
>> >> Helpdesk and customer portal
>> >> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>> >>
>> >> Company registration no. 5410695. Registered in England and Wales.
>> >> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>> >> 864201149.
>> >>
>> >
>> >
>> > --
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > *Vriendelijke groeten / Kind regards,Jose García
>> > <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>> > (0)318 416664 <+31318416664>Please consider the environment before printing
>> > this email.*
>> >
>>
>>
>> --
>> *Jo Cook*
>> t:+44 7930 524 155/twitter:@archaeogeek
>> Please note that currently I do not work on Friday afternoons. For urgent
>> responses at that time, please visit support.astuntechnology.com or phone
>> our office on 01372 744009
>>
>> --
>> --
>> *Sign up to our mailing list
>> <https://astuntechnology.com/company/#email-updates> for updates on news,
>> products, conferences, events and training*
>> *
>> *
>>
>> Astun Technology Ltd,
>> Epsom Square Centre, 6-7 The Derby Square, Epsom, Surrey, KT19 8AG, UK
>>
>> t:+44 1372 744 009 w: astuntechnology.com <http://astuntechnology.com/>
>> twitter:@astuntech <https://twitter.com/astuntech>
>>
>>
>>
>> iShare - enterprise
>> geographic intelligence platform <https://astuntechnology.com/ishare/>
>>
>> GeoServer, PostGIS and QGIS training
>> <https://astuntechnology.com/training-courses/>
>> Helpdesk and customer
>> portal
>> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>>
>>
>>
>>
>>
>> Company registration no. 5410695. Registered in England and Wales.
>> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>> 864201149.
>>
>> _______________________________________________
>> GeoNetwork-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>> GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork



--
Jo Cook
t:+44 7930 524 155/twitter:@archaeogeek
Please note that currently I do not work on Friday afternoons. For
urgent responses at that time, please visit
support.astuntechnology.com or phone our office on 01372 744009

--
-- 
*Sign up to our mailing list
<https://astuntechnology.com/company/#email-updates> for updates on news,
products, conferences, events and training*
*
*

Astun Technology Ltd,
Epsom Square Centre, 6-7 The Derby Square, Epsom, Surrey, KT19 8AG, UK 

t:+44 1372 744 009 w: astuntechnology.com <http://astuntechnology.com/
twitter:@astuntech <https://twitter.com/astuntech>



iShare - enterprise
geographic intelligence platform <https://astuntechnology.com/ishare/>

GeoServer, PostGIS and QGIS training
<https://astuntechnology.com/training-courses/>
Helpdesk and customer
portal
<https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>





Company registration no. 5410695. Registered in England and Wales.
Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
864201149.


_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jo Cook
In reply to this post by Jo Cook
Hi Jose,

I think the problem seems to be that the suggest process is using the ID to
generate the URL but the API process in Swagger uses the UUID. If I switch
to using the ID in Swagger then I get the same failure message. Is that
likely?

Jo

On Mon, Mar 23, 2020 at 8:38 AM Jo Cook <[hidden email]> wrote:

> Hi Jose,
>
> Yes, that record is a gemini 2.2 record. The xslt
> iso19139.gemini23-schemaupgrade is in the Gemini 2.2 schema folder, but it
> references an xsl in the Gemini 2.3 folder. I will check it can find that
> one.
>
> Jo
>
> On Fri, Mar 20, 2020 at 1:56 PM Jose Garcia <[hidden email]>
> wrote:
>
>> Hi Jo
>>
>> It seems from the error that can't find the xsl in the schema related to
>> the metadata with id 918
>>
>> I understand the xslt *iso19139.gemini23-schemaupgrade* is in the GEMINI
>> 2.2 schema and the metadata with the id 918 is a GEMINI 2.2 record correct?
>>
>> Regards,
>> Jose García
>>
>> On Fri, Mar 20, 2020 at 2:03 PM Jo Cook <[hidden email]>
>> wrote:
>>
>>> Hi Jose (and list)
>>>
>>> I can get this process working via the api just fine, but I'm struggling
>>> with getting it working as a suggestion. With the files from
>>> https://github.com/AstunTechnology/iso19139.gemini22_GN3/commit/25417e5be1ddd692cf676ea23c335d106bc9618f
>>> the suggestion appears in the list but when it's run I get the following
>>> error:
>>>
>>> (URL:
>>> http://localhost:8080/geonetwork/srv/api/records/918/processes/iso19139.gemini23-schemaupgrade?process=iso19139.gemini23-schemaupgrade&id=918
>>> )
>>> <apiError>
>>> <code>runtime_exception</code>
>>> <description>
>>> Not found:0, Not owner:0, No process found:1. is not a valid value for:
>>> Processing failed
>>> </description>
>>> <message>BadParameterEx</message>
>>> </apiError>
>>>
>>> and I'm really not sure what I am doing wrong. Any ideas?
>>>
>>> Thanks
>>>
>>> Jo
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 19, 2020 at 4:33 PM Jose Garcia <[hidden email]>
>>> wrote:
>>>
>>>> Hi Jo
>>>>
>>>> The changed files should be quite similar in 3.4.x. I'll check if can
>>>> manage tomorrow to make a PR.
>>>>
>>>> Regards,
>>>> Jose García
>>>>
>>>>
>>>> On Thu, Mar 19, 2020 at 5:31 PM Jo Cook <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Jose,
>>>>>
>>>>> That's great news- I will try it out. Is it something that would
>>>>> easily backport to 3.4? (Happy to give it a go if it's simple enough).
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jo
>>>>>
>>>>> On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> You can add in the schema that you want to upgrade in the process
>>>>>> folder a file ending with the suffix -schemaupgrade.xsl that makes the
>>>>>> upgrade, changing the elements in the xml to match the new schema and
>>>>>> updating the schemaid in the database, the process can be invoked using
>>>>>>  XlsProcessingApi and MetadataProcessApi, but both seem oriented to single
>>>>>> metadata updates.
>>>>>>
>>>>>> See
>>>>>> https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
>>>>>>
>>>>>> Regards,
>>>>>> Jose García
>>>>>>
>>>>>> On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> Hi Jo,
>>>>>>>
>>>>>>> We are facing a similar issue with a small number of metadata
>>>>>>> records in the database from iso19115-3 going to iso19115-3.2018. We do not
>>>>>>> have a conclusion yet. Below I describe some of the approaches we are
>>>>>>> considering. I hope this is helpful, or at least starts discussion, raises
>>>>>>> other questions, and potentially results in a "best practice" that I will
>>>>>>> volunteer to write for the documentation.
>>>>>>>
>>>>>>> We considered adding the -3 to -3.2018 xsl transform to the list of
>>>>>>> transforms on the "Import new records" page. Then we could export the 2014
>>>>>>> version files, and then import (and transform) with the overwrite metadata
>>>>>>> with same uuid option. We have not yet tested that to see if the metadata
>>>>>>> database record is fully and correctly updated with the schemid.  I do not
>>>>>>> have a deep knowledge of the code and am not sure if this was ever defined
>>>>>>> as a requirement or test case. I too am hesitant to do things in
>>>>>>> unanticipated ways and have established a rule that our external programs
>>>>>>> will access the geonetwork database in read-only mode.
>>>>>>>
>>>>>>> We also considered exporting the metadata records, using GeoNetwork
>>>>>>> to delete the older schema records, and then import keeping the uuid in the
>>>>>>> import file. My thought is this would force the deletion of the database
>>>>>>> metadata record, so when imported, it would have to create an entire new
>>>>>>> record.  BUT this has the side effect of the metadata.id value
>>>>>>> changing. I am not sure if that is good, neutral, or causes problems.
>>>>>>>
>>>>>>> Regardless of the way to update the records, I would guess that it
>>>>>>> would be good to force reindexing.
>>>>>>>
>>>>>>> We have the added complexity of using many
>>>>>>> "directories"/"snippets"/"re-usable element content"/some other name.  We
>>>>>>> also have nested snippets - responsibleParty snippet contains a link to a
>>>>>>> contact snippet that contains an onlineResource snippet.  How to export the
>>>>>>> metadata.data field without resolving the xlinks to snippets is not
>>>>>>> entirely clear. We have written some postgres queries to write the content
>>>>>>> of metadata.data to a file. I noticed that the code for the download file
>>>>>>> list of formats seems to have parameters that could allow specifying that
>>>>>>> the xlinks should not be resolved. We have not figured out how to do that.
>>>>>>>
>>>>>>> Bigger Picture
>>>>>>>
>>>>>>> We have several hundred published records at this time all stored as
>>>>>>> 19139.  Many were transformed from legacy metadata formats. Since we expect
>>>>>>> potentially many thousands of records starting from legacy formats, or
>>>>>>> perhaps minimal formal metadata, we are thinking about training for
>>>>>>> 19115-3.2018 instead of the double learning curve for 19139 and then
>>>>>>> 19115-3.x. If we decide that 19115-3.2018 is our primary internal format,
>>>>>>> it seems to make sense to convert the snippets to that format instead of
>>>>>>> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
>>>>>>> conversion becomes much more difficult and risky if the snippet uuid has to
>>>>>>> be changed.
>>>>>>>
>>>>>>> Any comments and questions are welcome. We're also happy to
>>>>>>> contribute code, but our customization is minimal, so far.
>>>>>>>
>>>>>>> Jeff
>>>>>>>
>>>>>>>
>>>>>>> On 3/17/2020 2:05 PM, Jo Cook wrote:
>>>>>>>
>>>>>>> Hi List,
>>>>>>>
>>>>>>> I'm wondering what method people use to change the schema that
>>>>>>> metadata is stored in. The scenario- I want to convert records in
>>>>>>> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
>>>>>>> (iso19139.gemini23). I can change the actual metadata using an xsl
>>>>>>> transformation, but as far as Geonetwork's database is concerned, the
>>>>>>> records are still stored with a schemaid of iso19139.gemini22. I can
>>>>>>> manually update the records in the database to change from one to the
>>>>>>> other, but that's not ideal for end-users of the catalog who may want
>>>>>>> to use a phased approach for converting and not do them all at once.
>>>>>>>
>>>>>>> What other methods have people used to fully convert records in place?
>>>>>>> I really don't want to harvest into a new catalog, or export and
>>>>>>> re-import them if at all possible.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> GeoNetwork-users mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>>>>>>> GeoNetwork OpenSource is maintained at
>>>>>>> http://sourceforge.net/projects/geonetwork
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Vriendelijke groeten / Kind regards,Jose García
>>>>>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>>>>>> (0)318 416664 <+31318416664>Please consider the environment before printing
>>>>>> this email.*
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Jo Cook*
>>>>> t:+44 7930 524 155/twitter:@archaeogeek
>>>>> Please note that currently I do not work on Friday afternoons. For
>>>>> urgent responses at that time, please visit
>>>>> support.astuntechnology.com or phone our office on 01372 744009
>>>>>
>>>>>
>>>>> --
>>>>> *Sign up to our mailing list
>>>>> <https://astuntechnology.com/company/#email-updates> for updates on news,
>>>>> products, conferences, events and training*
>>>>>
>>>>> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square,
>>>>> Epsom, Surrey, KT19 8AG, UK
>>>>> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
>>>>> <https://twitter.com/astuntech>
>>>>>
>>>>> iShare - enterprise geographic intelligence platform
>>>>> <https://astuntechnology.com/ishare/>
>>>>> GeoServer, PostGIS and QGIS training
>>>>> <https://astuntechnology.com/training-courses/>
>>>>> Helpdesk and customer portal
>>>>> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>>>>>
>>>>> Company registration no. 5410695. Registered in England and Wales.
>>>>> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>>>>> 864201149.
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Vriendelijke groeten / Kind regards,Jose García
>>>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>>>> (0)318 416664 <+31318416664>Please consider the environment before printing
>>>> this email.*
>>>>
>>>
>>>
>>> --
>>> *Jo Cook*
>>> t:+44 7930 524 155/twitter:@archaeogeek
>>> Please note that currently I do not work on Friday afternoons. For
>>> urgent responses at that time, please visit support.astuntechnology.com or
>>> phone our office on 01372 744009
>>>
>>>
>>> --
>>> *Sign up to our mailing list
>>> <https://astuntechnology.com/company/#email-updates> for updates on news,
>>> products, conferences, events and training*
>>>
>>> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
>>> Surrey, KT19 8AG, UK
>>> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
>>> <https://twitter.com/astuntech>
>>>
>>> iShare - enterprise geographic intelligence platform
>>> <https://astuntechnology.com/ishare/>
>>> GeoServer, PostGIS and QGIS training
>>> <https://astuntechnology.com/training-courses/>
>>> Helpdesk and customer portal
>>> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>>>
>>> Company registration no. 5410695. Registered in England and Wales.
>>> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>>> 864201149.
>>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Vriendelijke groeten / Kind regards,Jose García
>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>> (0)318 416664 <+31318416664>Please consider the environment before printing
>> this email.*
>>
>
>
> --
> *Jo Cook*
> t:+44 7930 524 155/twitter:@archaeogeek
> Please note that currently I do not work on Friday afternoons. For urgent
> responses at that time, please visit support.astuntechnology.com or phone
> our office on 01372 744009
>
>

--
*Jo Cook*
t:+44 7930 524 155/twitter:@archaeogeek
Please note that currently I do not work on Friday afternoons. For urgent
responses at that time, please visit support.astuntechnology.com or phone
our office on 01372 744009

--
-- 
*Sign up to our mailing list
<https://astuntechnology.com/company/#email-updates> for updates on news,
products, conferences, events and training*
*
*

Astun Technology Ltd,
Epsom Square Centre, 6-7 The Derby Square, Epsom, Surrey, KT19 8AG, UK 

t:+44 1372 744 009 w: astuntechnology.com <http://astuntechnology.com/
twitter:@astuntech <https://twitter.com/astuntech>



iShare - enterprise
geographic intelligence platform <https://astuntechnology.com/ishare/>

GeoServer, PostGIS and QGIS training
<https://astuntechnology.com/training-courses/>
Helpdesk and customer
portal
<https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>





Company registration no. 5410695. Registered in England and Wales.
Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
864201149.

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Changing Geonetwork schema

Jose Garcia
Hi Jo

Ideally should be indifferent using id or uuid as should match the same
record, but will check the issue loading the GEMINI 2.2 schema.

Regards,
Jose García

On Mon, Mar 23, 2020 at 10:15 AM Jo Cook <[hidden email]> wrote:

> Hi Jose,
>
> I think the problem seems to be that the suggest process is using the ID
> to generate the URL but the API process in Swagger uses the UUID. If I
> switch to using the ID in Swagger then I get the same failure message. Is
> that likely?
>
> Jo
>
> On Mon, Mar 23, 2020 at 8:38 AM Jo Cook <[hidden email]>
> wrote:
>
>> Hi Jose,
>>
>> Yes, that record is a gemini 2.2 record. The xslt
>> iso19139.gemini23-schemaupgrade is in the Gemini 2.2 schema folder, but it
>> references an xsl in the Gemini 2.3 folder. I will check it can find that
>> one.
>>
>> Jo
>>
>> On Fri, Mar 20, 2020 at 1:56 PM Jose Garcia <[hidden email]>
>> wrote:
>>
>>> Hi Jo
>>>
>>> It seems from the error that can't find the xsl in the schema related to
>>> the metadata with id 918
>>>
>>> I understand the xslt *iso19139.gemini23-schemaupgrade* is in the
>>> GEMINI 2.2 schema and the metadata with the id 918 is a GEMINI 2.2 record
>>> correct?
>>>
>>> Regards,
>>> Jose García
>>>
>>> On Fri, Mar 20, 2020 at 2:03 PM Jo Cook <[hidden email]>
>>> wrote:
>>>
>>>> Hi Jose (and list)
>>>>
>>>> I can get this process working via the api just fine, but I'm
>>>> struggling with getting it working as a suggestion. With the files from
>>>> https://github.com/AstunTechnology/iso19139.gemini22_GN3/commit/25417e5be1ddd692cf676ea23c335d106bc9618f
>>>> the suggestion appears in the list but when it's run I get the following
>>>> error:
>>>>
>>>> (URL:
>>>> http://localhost:8080/geonetwork/srv/api/records/918/processes/iso19139.gemini23-schemaupgrade?process=iso19139.gemini23-schemaupgrade&id=918
>>>> )
>>>> <apiError>
>>>> <code>runtime_exception</code>
>>>> <description>
>>>> Not found:0, Not owner:0, No process found:1. is not a valid value for:
>>>> Processing failed
>>>> </description>
>>>> <message>BadParameterEx</message>
>>>> </apiError>
>>>>
>>>> and I'm really not sure what I am doing wrong. Any ideas?
>>>>
>>>> Thanks
>>>>
>>>> Jo
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 19, 2020 at 4:33 PM Jose Garcia <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Jo
>>>>>
>>>>> The changed files should be quite similar in 3.4.x. I'll check if can
>>>>> manage tomorrow to make a PR.
>>>>>
>>>>> Regards,
>>>>> Jose García
>>>>>
>>>>>
>>>>> On Thu, Mar 19, 2020 at 5:31 PM Jo Cook <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi Jose,
>>>>>>
>>>>>> That's great news- I will try it out. Is it something that would
>>>>>> easily backport to 3.4? (Happy to give it a go if it's simple enough).
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jo
>>>>>>
>>>>>> On Wed, Mar 18, 2020 at 9:30 AM Jose Garcia <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> You can add in the schema that you want to upgrade in the process
>>>>>>> folder a file ending with the suffix -schemaupgrade.xsl that makes the
>>>>>>> upgrade, changing the elements in the xml to match the new schema and
>>>>>>> updating the schemaid in the database, the process can be invoked using
>>>>>>>  XlsProcessingApi and MetadataProcessApi, but both seem oriented to single
>>>>>>> metadata updates.
>>>>>>>
>>>>>>> See
>>>>>>> https://github.com/geonetwork/core-geonetwork/commit/7f22142621c834abc431ac859b06de087962d7f7
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jose García
>>>>>>>
>>>>>>> On Tue, Mar 17, 2020 at 9:24 PM Jeff Campbell <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>>> Hi Jo,
>>>>>>>>
>>>>>>>> We are facing a similar issue with a small number of metadata
>>>>>>>> records in the database from iso19115-3 going to iso19115-3.2018. We do not
>>>>>>>> have a conclusion yet. Below I describe some of the approaches we are
>>>>>>>> considering. I hope this is helpful, or at least starts discussion, raises
>>>>>>>> other questions, and potentially results in a "best practice" that I will
>>>>>>>> volunteer to write for the documentation.
>>>>>>>>
>>>>>>>> We considered adding the -3 to -3.2018 xsl transform to the list of
>>>>>>>> transforms on the "Import new records" page. Then we could export the 2014
>>>>>>>> version files, and then import (and transform) with the overwrite metadata
>>>>>>>> with same uuid option. We have not yet tested that to see if the metadata
>>>>>>>> database record is fully and correctly updated with the schemid.  I do not
>>>>>>>> have a deep knowledge of the code and am not sure if this was ever defined
>>>>>>>> as a requirement or test case. I too am hesitant to do things in
>>>>>>>> unanticipated ways and have established a rule that our external programs
>>>>>>>> will access the geonetwork database in read-only mode.
>>>>>>>>
>>>>>>>> We also considered exporting the metadata records, using GeoNetwork
>>>>>>>> to delete the older schema records, and then import keeping the uuid in the
>>>>>>>> import file. My thought is this would force the deletion of the database
>>>>>>>> metadata record, so when imported, it would have to create an entire new
>>>>>>>> record.  BUT this has the side effect of the metadata.id value
>>>>>>>> changing. I am not sure if that is good, neutral, or causes problems.
>>>>>>>>
>>>>>>>> Regardless of the way to update the records, I would guess that it
>>>>>>>> would be good to force reindexing.
>>>>>>>>
>>>>>>>> We have the added complexity of using many
>>>>>>>> "directories"/"snippets"/"re-usable element content"/some other name.  We
>>>>>>>> also have nested snippets - responsibleParty snippet contains a link to a
>>>>>>>> contact snippet that contains an onlineResource snippet.  How to export the
>>>>>>>> metadata.data field without resolving the xlinks to snippets is not
>>>>>>>> entirely clear. We have written some postgres queries to write the content
>>>>>>>> of metadata.data to a file. I noticed that the code for the download file
>>>>>>>> list of formats seems to have parameters that could allow specifying that
>>>>>>>> the xlinks should not be resolved. We have not figured out how to do that.
>>>>>>>>
>>>>>>>> Bigger Picture
>>>>>>>>
>>>>>>>> We have several hundred published records at this time all stored
>>>>>>>> as 19139.  Many were transformed from legacy metadata formats. Since we
>>>>>>>> expect potentially many thousands of records starting from legacy formats,
>>>>>>>> or perhaps minimal formal metadata, we are thinking about training for
>>>>>>>> 19115-3.2018 instead of the double learning curve for 19139 and then
>>>>>>>> 19115-3.x. If we decide that 19115-3.2018 is our primary internal format,
>>>>>>>> it seems to make sense to convert the snippets to that format instead of
>>>>>>>> on-the-fly transforms of 19139 to 19115-3.2018.  In that case, the
>>>>>>>> conversion becomes much more difficult and risky if the snippet uuid has to
>>>>>>>> be changed.
>>>>>>>>
>>>>>>>> Any comments and questions are welcome. We're also happy to
>>>>>>>> contribute code, but our customization is minimal, so far.
>>>>>>>>
>>>>>>>> Jeff
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/17/2020 2:05 PM, Jo Cook wrote:
>>>>>>>>
>>>>>>>> Hi List,
>>>>>>>>
>>>>>>>> I'm wondering what method people use to change the schema that
>>>>>>>> metadata is stored in. The scenario- I want to convert records in
>>>>>>>> Gemini 2.2 (iso19139.gemini22)  format to Gemini 2.3
>>>>>>>> (iso19139.gemini23). I can change the actual metadata using an xsl
>>>>>>>> transformation, but as far as Geonetwork's database is concerned, the
>>>>>>>> records are still stored with a schemaid of iso19139.gemini22. I can
>>>>>>>> manually update the records in the database to change from one to the
>>>>>>>> other, but that's not ideal for end-users of the catalog who may want
>>>>>>>> to use a phased approach for converting and not do them all at once.
>>>>>>>>
>>>>>>>> What other methods have people used to fully convert records in place?
>>>>>>>> I really don't want to harvest into a new catalog, or export and
>>>>>>>> re-import them if at all possible.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Jo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> GeoNetwork-users mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>>>>>>>> GeoNetwork OpenSource is maintained at
>>>>>>>> http://sourceforge.net/projects/geonetwork
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Vriendelijke groeten / Kind regards,Jose García
>>>>>>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>>>>>>> (0)318 416664 <+31318416664>Please consider the environment before printing
>>>>>>> this email.*
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Jo Cook*
>>>>>> t:+44 7930 524 155/twitter:@archaeogeek
>>>>>> Please note that currently I do not work on Friday afternoons. For
>>>>>> urgent responses at that time, please visit
>>>>>> support.astuntechnology.com or phone our office on 01372 744009
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Sign up to our mailing list
>>>>>> <https://astuntechnology.com/company/#email-updates> for updates on news,
>>>>>> products, conferences, events and training*
>>>>>>
>>>>>> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square,
>>>>>> Epsom, Surrey, KT19 8AG, UK
>>>>>> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
>>>>>> <https://twitter.com/astuntech>
>>>>>>
>>>>>> iShare - enterprise geographic intelligence platform
>>>>>> <https://astuntechnology.com/ishare/>
>>>>>> GeoServer, PostGIS and QGIS training
>>>>>> <https://astuntechnology.com/training-courses/>
>>>>>> Helpdesk and customer portal
>>>>>> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>>>>>>
>>>>>> Company registration no. 5410695. Registered in England and Wales.
>>>>>> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>>>>>> 864201149.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Vriendelijke groeten / Kind regards,Jose García
>>>>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>>>>> (0)318 416664 <+31318416664>Please consider the environment before printing
>>>>> this email.*
>>>>>
>>>>
>>>>
>>>> --
>>>> *Jo Cook*
>>>> t:+44 7930 524 155/twitter:@archaeogeek
>>>> Please note that currently I do not work on Friday afternoons. For
>>>> urgent responses at that time, please visit support.astuntechnology.com or
>>>> phone our office on 01372 744009
>>>>
>>>>
>>>> --
>>>> *Sign up to our mailing list
>>>> <https://astuntechnology.com/company/#email-updates> for updates on news,
>>>> products, conferences, events and training*
>>>>
>>>> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
>>>> Surrey, KT19 8AG, UK
>>>> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
>>>> <https://twitter.com/astuntech>
>>>>
>>>> iShare - enterprise geographic intelligence platform
>>>> <https://astuntechnology.com/ishare/>
>>>> GeoServer, PostGIS and QGIS training
>>>> <https://astuntechnology.com/training-courses/>
>>>> Helpdesk and customer portal
>>>> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>>>>
>>>> Company registration no. 5410695. Registered in England and Wales.
>>>> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
>>>> 864201149.
>>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Vriendelijke groeten / Kind regards,Jose García
>>> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
>>> (0)318 416664 <+31318416664>Please consider the environment before printing
>>> this email.*
>>>
>>
>>
>> --
>> *Jo Cook*
>> t:+44 7930 524 155/twitter:@archaeogeek
>> Please note that currently I do not work on Friday afternoons. For urgent
>> responses at that time, please visit support.astuntechnology.com or
>> phone our office on 01372 744009
>>
>>
>
> --
> *Jo Cook*
> t:+44 7930 524 155/twitter:@archaeogeek
> Please note that currently I do not work on Friday afternoons. For urgent
> responses at that time, please visit support.astuntechnology.com or phone
> our office on 01372 744009
>
>
> --
> *Sign up to our mailing list
> <https://astuntechnology.com/company/#email-updates> for updates on news,
> products, conferences, events and training*
>
> Astun Technology Ltd, Epsom Square Centre, 6-7 The Derby Square, Epsom,
> Surrey, KT19 8AG, UK
> t:+44 1372 744 009 w: astuntechnology.com twitter:@astuntech
> <https://twitter.com/astuntech>
>
> iShare - enterprise geographic intelligence platform
> <https://astuntechnology.com/ishare/>
> GeoServer, PostGIS and QGIS training
> <https://astuntechnology.com/training-courses/>
> Helpdesk and customer portal
> <https://astuntech.atlassian.net/wiki/spaces/ISHAREHELP/pages/364970043/Astun+Technology+Support+Portal>
>
> Company registration no. 5410695. Registered in England and Wales.
> Registered office: 120 Manor Green Road, Epsom, Surrey, KT19 8LN VAT no.
> 864201149.
>


--











*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
(0)318 416664 <+31318416664>Please consider the environment before printing
this email.*

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork