[GeoNetwork-devel] RNDT profile and UUID generation

GeoNetwork GeoNetwork Developer
1

Hi list,

as already mentioned in a previous thread we're dealing with RNDT, an Italian
profile of ISO19139, and we have created a schema plugin for it here:
   http://github.com/geonetwork/schema-plugins/tree/master/iso19139.rndt

This profile puts some restrictions on the metadata fileIdentifier syntax and
some other internal ids.
Going into details, the fileIdentifier should be built using a fixed code
assigned to the source governative organization that creates the metadata, and
a dynamic part; the profile reccommends to use a timestamp for the dynamic
part, but it's not mandatory.

The solution implemented in the published schema plugin solves the issue of
creating the metadata ids using the update-fixed-info.xsl file, and setting as
true the readwriteUuid property of the schema.
The fixed code is stored as the geonetwork site uuid (that fits nicely in there,
and it's available in the various xsl transformation inside GN) and the UUID
generated by GN is used as the dynamic part.

So far, so good.

First question is: did you find any profile requiring particular constraints
such this in the creation of the UUIDs? How did you solve the problem?

I remember Francois had to do with a profile that needed to deal with the
resource identifier and the catalog URL
(http://sourceforge.net/p/geonetwork/mailman/message/31624545/).

Now we are trying to allow the creation of RNDT metadata for different
organizations inside a single GeoNetwork instance.
Note that the existing implementation, by storing the fixed prefix as the GN
site ID, only allows to create/edit metadata related to a single organization.
Allowing a multi-organization instance requires that a list of such fixed codes
should be stored somewhere else, and possibily externalized in some way.
The schema plugin architecture at the moment does not provide similar
functionalities.

Any work in progress, or plan, about improvements in schema plugin in this
direction?

   Thanks,
   Emanuele

--

Our support, Your Success!
Visit http://opensdi.geo-solutions.it for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

2

Haven't had to do it yet but we have had one organisation that is/was considering have a parseable fileIdentifier here in AU.

So if I understand correctly, the problem sounds like it could be addressed using a related records approach like the following:

1. Having service metadata records for each site/catalogue with fileIdentifier (or an MD_Identifier) set to GeoNetwork site id (harvested between all sites that use this approach).

2. Allow the user to create a sibling or parentIdentifier relationship between their metadata record and a service metadata record of the organisation they want it associated with. (May need a bit of fiddling in the sibling/parentIdentifier related record handling stuff).

3. Update the fileIdentifier with the value of this sibling/parentIdentifier using your readWriteUuid solution when the record is saved (update-fixed-info.xsl) - if the sibling/parentidentifier isn't there then that means use the current catalogue site identifier as the association.

Would work for metadata records created and managed in GN but presumably that is the use case you're dealing with. This way you could use the existing stuff for this. (If I was doing it, I'd use service metadata records as siblings approach - see http://trac.osgeo.org/geonetwork/wiki/MetadataSiblings as that would leave parentIdentifier free for something else).

You could also do a thesaurus approach: keep site identifiers as term identifiers for organisation names in a thesaurus, allow the user to choose a term from your thesaurus when they edit a record for the first time, then copy the site identifier into the fileIdentifier using your readWriteUuid approach.

Maybe this is all too twisty but probably there are other ways to do this using the flexibility of GN :slight_smile:

Cheers,
Simon

________________________________________
From: Emanuele Tajariol [etj@anonymised.com]
Sent: Saturday, 29 March 2014 12:51 AM
To: Geonetwork devel lists
Subject: [GeoNetwork-devel] RNDT profile and UUID generation

Hi list,

as already mentioned in a previous thread we're dealing with RNDT, an Italian
profile of ISO19139, and we have created a schema plugin for it here:
   schema-plugins/iso19139.rndt at develop · geonetwork/schema-plugins · GitHub

This profile puts some restrictions on the metadata fileIdentifier syntax and
some other internal ids.
Going into details, the fileIdentifier should be built using a fixed code
assigned to the source governative organization that creates the metadata, and
a dynamic part; the profile reccommends to use a timestamp for the dynamic
part, but it's not mandatory.

The solution implemented in the published schema plugin solves the issue of
creating the metadata ids using the update-fixed-info.xsl file, and setting as
true the readwriteUuid property of the schema.
The fixed code is stored as the geonetwork site uuid (that fits nicely in there,
and it's available in the various xsl transformation inside GN) and the UUID
generated by GN is used as the dynamic part.

So far, so good.

First question is: did you find any profile requiring particular constraints
such this in the creation of the UUIDs? How did you solve the problem?

I remember Francois had to do with a profile that needed to deal with the
resource identifier and the catalog URL
([GeoNetwork-devel] Metadata uuid creation | GeoNetwork - Geographic Metadata Catalog).

Now we are trying to allow the creation of RNDT metadata for different
organizations inside a single GeoNetwork instance.
Note that the existing implementation, by storing the fixed prefix as the GN
site ID, only allows to create/edit metadata related to a single organization.
Allowing a multi-organization instance requires that a list of such fixed codes
should be stored somewhere else, and possibily externalized in some way.
The schema plugin architecture at the moment does not provide similar
functionalities.

Any work in progress, or plan, about improvements in schema plugin in this
direction?

   Thanks,
   Emanuele

--

Our support, Your Success!
Visit http://opensdi.geo-solutions.it for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://twitter.com/geosolutions_it

-------------------------------------------------------

------------------------------------------------------------------------------
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

3

Hi Simon,

thanks a lot, these are really interesting ideas.

   Ciao,
   Emanuele

Alle 15:41:48 di Friday 28 March 2014, Simon.Pigot@anonymised.com ha scritto:

Haven't had to do it yet but we have had one organisation that is/was
considering have a parseable fileIdentifier here in AU.

So if I understand correctly, the problem sounds like it could be addressed
using a related records approach like the following:

1. Having service metadata records for each site/catalogue with
fileIdentifier (or an MD_Identifier) set to GeoNetwork site id (harvested
between all sites that use this approach).

2. Allow the user to create a sibling or parentIdentifier relationship
between their metadata record and a service metadata record of the
organisation they want it associated with. (May need a bit of fiddling in
the sibling/parentIdentifier related record handling stuff).

3. Update the fileIdentifier with the value of this
sibling/parentIdentifier using your readWriteUuid solution when the record
is saved (update-fixed-info.xsl) - if the sibling/parentidentifier isn't
there then that means use the current catalogue site identifier as the
association.

Would work for metadata records created and managed in GN but presumably
that is the use case you're dealing with. This way you could use the
existing stuff for this. (If I was doing it, I'd use service metadata
records as siblings approach - see
http://trac.osgeo.org/geonetwork/wiki/MetadataSiblings as that would leave
parentIdentifier free for something else).

You could also do a thesaurus approach: keep site identifiers as term
identifiers for organisation names in a thesaurus, allow the user to
choose a term from your thesaurus when they edit a record for the first
time, then copy the site identifier into the fileIdentifier using your
readWriteUuid approach.

Maybe this is all too twisty but probably there are other ways to do this
using the flexibility of GN :slight_smile:

Cheers,
Simon

________________________________________
From: Emanuele Tajariol [etj@anonymised.com]
Sent: Saturday, 29 March 2014 12:51 AM
To: Geonetwork devel lists
Subject: [GeoNetwork-devel] RNDT profile and UUID generation

Hi list,

as already mentioned in a previous thread we're dealing with RNDT, an
Italian profile of ISO19139, and we have created a schema plugin for it
here:
http://github.com/geonetwork/schema-plugins/tree/master/iso19139.rndt

This profile puts some restrictions on the metadata fileIdentifier syntax
and some other internal ids.
Going into details, the fileIdentifier should be built using a fixed code
assigned to the source governative organization that creates the metadata,
and a dynamic part; the profile reccommends to use a timestamp for the
dynamic part, but it's not mandatory.

The solution implemented in the published schema plugin solves the issue of
creating the metadata ids using the update-fixed-info.xsl file, and setting
as true the readwriteUuid property of the schema.
The fixed code is stored as the geonetwork site uuid (that fits nicely in
there, and it's available in the various xsl transformation inside GN) and
the UUID generated by GN is used as the dynamic part.

So far, so good.

First question is: did you find any profile requiring particular
constraints such this in the creation of the UUIDs? How did you solve the
problem?

I remember Francois had to do with a profile that needed to deal with the
resource identifier and the catalog URL
(http://sourceforge.net/p/geonetwork/mailman/message/31624545/).

Now we are trying to allow the creation of RNDT metadata for different
organizations inside a single GeoNetwork instance.
Note that the existing implementation, by storing the fixed prefix as the
GN site ID, only allows to create/edit metadata related to a single
organization. Allowing a multi-organization instance requires that a list
of such fixed codes should be stored somewhere else, and possibily
externalized in some way. The schema plugin architecture at the moment
does not provide similar functionalities.

Any work in progress, or plan, about improvements in schema plugin in this
direction?

   Thanks,
   Emanuele

--

Our support, Your Success!
Visit http://opensdi.geo-solutions.it for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------