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 <jose.garcia@anonymised.com>
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 <jocook@anonymised.com>
> 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 <jose.garcia@anonymised.com>
>> 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 <
>>> dev@anonymised.com> 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
>>>> GeoNetwork-users@lists.sourceforge.net
>>>> 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
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork