RNDT profile and UUID generation

[Emanuele Tajariol-2]

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: [phone]
fax:    [phone]
mob:   [phone]

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

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

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

[SimonPigot]

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 :-)
 
Cheers,
Simon

________________________________________
From: Emanuele Tajariol [[hidden email]]
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: [phone]
fax:    [phone]
mob:   [phone]

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

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

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

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

[Emanuele Tajariol-2]

Hi Simon,

thanks a lot, these are really interesting ideas.

   Ciao,
   Emanuele


Alle 15:41:48 di Friday 28 March 2014, [hidden email] 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 :-)
>
> Cheers,
> Simon
>
> ________________________________________
> From: Emanuele Tajariol [[hidden email]]
> 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: [phone]
fax:    [phone]
mob:   [phone]

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

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

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