Re3gistry 1.1 - Quick customisation guide

The example included in  the Re3gistry software package will create a structure like the INSPIRE registry service. If you want to create your own registry configuration with your own registers, follow the step presented below.

During this guide we are going to create a custom initialization of the system and to create a simple register - called "simple" (like the INSPIRE theme register) and a hierarchical register - called "hierarchical" (like the INSPIRE codelist register).

 

Database initialization guide

Open the file /example/databasedatabase-initialization.sql contained in the Re3gistry package 1.1. The detailed information for each of the section are explained below.

1. Reference: these elements are the references to the information of the registry and of each registry. These elements are localized; this means that the information related to each of this entry will be inserted in the localization file. The only thing to be edited here is the e-mail in the contact point (first line)

--reference

INSERT INTO reference VALUES ('1', 'inspire-registry-dev@jrc.ec.europa.eu', 'contactpoint', '2015-06-30 00:00:00', NULL);

INSERT INTO reference VALUES ('2', NULL, 'legalnotice', '2015-06-30 00:00:00', NULL);

INSERT INTO reference VALUES ('3', NULL, 'controlbody', '2015-06-30 00:00:00', NULL);

INSERT INTO reference VALUES ('4', NULL, 'registrymanager', '2015-06-30 00:00:00', NULL);

INSERT INTO reference VALUES ('5', NULL, 'registermanager', '2015-06-30 00:00:00', NULL);

INSERT INTO reference VALUES ('6', NULL, 'registerowner', '2015-06-30 00:00:00', NULL);

INSERT INTO reference VALUES ('7', NULL, 'registersubmitter', '2015-06-30 00:00:00', NULL);

2. Registry: the information related to the registry system. The elements to be edited are (in order):

  • The unique id of the registry
  • The "code" (uriname) related to the registry; this will be used toghether with the "base URI" to compose the URI of the registry
  • The "base URI" of the registry (concatenathed with the "code" it will create the URI of the regisr)
--registry

INSERT INTO registry VALUES ('1', 'registry', 'http://inspire.ec.europa.eu', '4', '2015-06-30 00:00:00', NULL);

3. Register: the following scripts will create each register. The information related to the registers are localized. THe following script will create only the technical entries needed for each registers. The element to be edited rfor each register are (in order):

  • The unique id of the register
  • The "base URL" of the register (this is repeated for each register because the registers could have different URLs).
  • The "code" (uriname) related to the register; this will be used toghether with the "base URL" to compose the url of the register
  • The reference to the id of the registry previously created (bullet point 2)

The other elements contained in the following scripts, are the link to the reference information, created at the beginning of this guide. They can be left as ther are.

--register

INSERT INTO register VALUES ('1', 'http://inspire.ec.europa.eu', 'simple', '6', '5', '3', '7','1', '2', '1', '2015-06-30 00:00:00', NULL);

INSERT INTO register VALUES ('2', 'http://inspire.ec.europa.eu', 'hierarchical', '6', '5', '3', '7','1', '2', '1', '2015-06-30 00:00:00', NULL);

4. Item Class: the item class defines a group of items contained in the register. The item class can have parent/child relations to identify if the items are part of a collection (in a hierarchical register). For more information about the "item class", please refer to the complete documentation - chapter 2.3. The element to be edited rfor each register are (in order):

  • The unique id of the item class
  • The reference to the related register id (it can be taken from the script created at the bullet point 3 in this guide - "register")
  • The item class "code" (uriname)
  • The order in the hierarchy (lower numbers come first)
  • The order in wich the data procedure is going to process it (lower numbers processed first)
  • The id of the parent item class
--itemcalss

INSERT INTO itemclass VALUES ('1', '1', 'Simple', 0, 1, NULL, '2015-06-30 00:00:00', NULL);

INSERT INTO itemclass VALUES ('2', '2', 'Hierarchical', 0, 2, NULL, '2015-06-30 00:00:00', NULL);

INSERT INTO itemclass VALUES ('3', '2', 'HierarchicalLevel1', 1, 3,  '2','2015-06-30 00:00:00', NULL);

5. Language code: one entry for each of the language supported by the registry. The element to be edited for each register are (in order):

  • The unique id of the language
  • The label of the language
  • The 2 digit code of the language
  • The code of the language following ISO 639 - 2
  • The indicatin if the language is the "master language" for the system, our example: EN is our "master language". The TRUE is indicating this.
--languagecode

INSERT INTO languagecode VALUES ('1', 'english', 'en', 'eng', TRUE);

INSERT INTO languagecode VALUES ('2', 'italiano', 'it', 'ita');

INSERT INTO languagecode VALUES ('3', 'czech', 'cs', 'cze');

INSERT INTO languagecode VALUES ('4', 'bulgarian', 'bg', 'bul');

INSERT INTO languagecode VALUES ('5', 'danish', 'da', 'dan');

INSERT INTO languagecode VALUES ('6', 'german', 'de', 'ger');

INSERT INTO languagecode VALUES ('7', 'greek', 'el', 'gre');

INSERT INTO languagecode VALUES ('8', 'spanish', 'es', 'spa');

INSERT INTO languagecode VALUES ('9', 'estonian', 'et', 'est');

INSERT INTO languagecode VALUES ('10', 'finnish', 'fi', 'fin');

INSERT INTO languagecode VALUES ('11', 'french', 'fr', 'fra');

INSERT INTO languagecode VALUES ('12', 'hungarian', 'hu', 'hun');

INSERT INTO languagecode VALUES ('13', 'lithuanian', 'lt', 'lit');

INSERT INTO languagecode VALUES ('14', 'latvian', 'lv', 'lav');

INSERT INTO languagecode VALUES ('15', 'maltese', 'mt', 'mlt');

INSERT INTO languagecode VALUES ('17', 'polish', 'pl', 'pol');

INSERT INTO languagecode VALUES ('16', 'dutch', 'nl', 'dut');

INSERT INTO languagecode VALUES ('18', 'portuguese', 'pt', 'por');

INSERT INTO languagecode VALUES ('19', 'romanian', 'ro', 'rum');

INSERT INTO languagecode VALUES ('20', 'slovak', 'sk', 'slo');

INSERT INTO languagecode VALUES ('21', 'slovenian', 'sl', 'slv');

INSERT INTO languagecode VALUES ('22', 'swedish', 'sv', 'swe');

INSERT INTO languagecode VALUES ('23', 'croatian', 'hr', 'hrv');

6. Status: the list of available statuses. This information has to be left as they are. The only customization can be the status "base URL".

--status

INSERT INTO status VALUES ('1', 'http://inspire.ec.europa.eu/registry/status', 'valid');

INSERT INTO status VALUES ('2', 'http://inspire.ec.europa.eu/registry/status', 'invalid');

INSERT INTO status VALUES ('3', 'http://inspire.ec.europa.eu/registry/status', 'submitted');

INSERT INTO status VALUES ('4', 'http://inspire.ec.europa.eu/registry/status', 'superseded');

INSERT INTO status VALUES ('5', 'http://inspire.ec.europa.eu/registry/status', 'retired');

7. Procedure status: these information are related to the procedure status. They have to be left as they are.

--procedurestatus

INSERT INTO procedurestatus VALUES ('1', 'Queued');

INSERT INTO procedurestatus VALUES ('2', 'Failed');

INSERT INTO procedurestatus VALUES ('3', 'Completed');

INSERT INTO procedurestatus VALUES ('4', 'Storing data');

INSERT INTO procedurestatus VALUES ('5', 'Writing files');

INSERT INTO procedurestatus VALUES ('6', 'Deployed');

INSERT INTO procedurestatus VALUES ('7', 'Checking data');

INSERT INTO procedurestatus VALUES ('8', 'Loading');

INSERT INTO procedurestatus VALUES ('9', 'Imported');

 

Database localization

After the initialization of the database with the reqquired element, now the localization information can be loaded. For each of the localized element, there shall be an entry in the database. The localization for the master language is mandatory, whereas the localization for any other language is optional. If the system does not find the language, it ill use the master language to represent the item.

The script for the localization has to refer to the specific element, inserted by the initialization scripts, using the element's unique id. Each different element has a different place to put the id in the localization script.

The structure of the script is explained below. Depending on the element that has to be localized, one of the element in the square brackets shall be completed.

INSERT INTO localization VALUES('_localization unique id_','[_item unique id_]',[_item class unique id_],'_language code_','[_register unique id_]','[_customattribute value unique id_]','_lable_','_definition_','_description_','_uri','2015-06-30 00:00:00',_date last update_,[_registry unique id_],[_reference unique id_],'[_status unique id_]');

An example of localization for the english language is provided below:

--reference localization for language en

INSERT INTO localization VALUES('1',NULL,NULL,'1',NULL,NULL,'European Commission, Joint Research Centre',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,'4',NULL);

INSERT INTO localization VALUES('2',NULL,NULL,'1',NULL,NULL,'JRC INSPIRE Registry Team',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,'1',NULL);

INSERT INTO localization VALUES('3',NULL,NULL,'1',NULL,NULL,'Europa Legal Notice',NULL,NULL,'http://ec.europa.eu/geninfo/legal_notices_en.htm','2015-06-30 00:00:00',NULL,NULL,'2',NULL);

INSERT INTO localization VALUES('4',NULL,NULL,'1',NULL,NULL,'INSPIRE Maintenance and Implementation Group (MIG)',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,'3',NULL);

INSERT INTO localization VALUES('5',NULL,NULL,'1',NULL,NULL,'Members of INSPIRE Maintenance and Implementation Group (MIG)',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,'7',NULL);

INSERT INTO localization VALUES('6',NULL,NULL,'1',NULL,NULL,'European Commission, Joint Research Centre',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,'5',NULL);

INSERT INTO localization VALUES('7',NULL,NULL,'1',NULL,NULL,'European Union',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,'6',NULL);

--registry localization for language en

INSERT INTO localization VALUES('8',NULL,NULL,'1',NULL,NULL,'TEST registry','This is a test.',NULL,NULL,'2015-06-30 00:00:00',NULL,'1',NULL,NULL);

--register localization for language en

INSERT INTO localization VALUES('9',NULL,NULL,'1','1',NULL,'INSPIRE simple register','This is a test.',NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,NULL);

INSERT INTO localization VALUES('10',NULL,NULL,'1','2',NULL,'INSPIRE hierarchical register','This is a test.',NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,NULL);

--itemclass localization for language en

INSERT INTO localization VALUES('11',NULL,'2','1',NULL,NULL,'Simple',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,NULL);

INSERT INTO localization VALUES('12',NULL,'3','1',NULL,NULL,'Hierarchical',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,NULL);

INSERT INTO localization VALUES('13',NULL,'4','1',NULL,NULL,'Hierarchical level 1',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,NULL);

--status localization for language en

INSERT INTO localization VALUES('14',NULL,NULL,'1',NULL,NULL,'Valid',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,'1');

INSERT INTO localization VALUES('15',NULL,NULL,'1',NULL,NULL,'Invalid',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,'2');

INSERT INTO localization VALUES('16',NULL,NULL,'1',NULL,NULL,'Submitted',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,'3');

INSERT INTO localization VALUES('17',NULL,NULL,'1',NULL,NULL,'Superseded',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,'4');

INSERT INTO localization VALUES('18',NULL,NULL,'1',NULL,NULL,'Retired',NULL,NULL,NULL,'2015-06-30 00:00:00',NULL,NULL,NULL,'5');

 

Custom import file guide

This part of the guide helps to create a data import file (following the examples of the two registers created above in this guide).

Start by opening the example data file contained in the Re3gistry 1.1 package at this folder: /compiled/Re3gistry-1.1/examples/EmptyDataFile.zip. This file contains one folder for each item class available in the system. In each of the folder, there shall be one file for each action that is needed to perform.

For example, if the only action to be performed is an addition, the only file that shall be available in the folder is the addition.csv file.

For the example presented in this guide, the folder to be created are 3: "Simple", "Hierarchical" and "HierarchicalLevel1". Note: each folder shall have exactly the same name of each item class available in the system (previously created at bullet point 4 in this quide).
Below you can find an example content for each of the item class.

1. "Simple"

The following example will insert an item with the id "it1" in the simple register in english and italian. The file will also add a custom attribute called "ExampleCustomAttribute" which is required, and it is not multivanued, coded or foreign key. For more information on the custom attribute, please refer to the complete guide - chapter 3.5.

/Simple/addition.csv

LocalId|ParentLocalId|CollectionLocalId|Language|Label|Definition|Description|Status|Comment|*ExampleCustomAttribute[t,f,f,f]

it1|||en|item test|test definition|test description|valid|First import|example custom attribute content

it1|||it|elemento test|definizione test|descrizione test|valid|primo import|esempio di contenuto per custom attribute

2. "Hierarchical"

The following example will insert 3 items with the id "h1", "h2" and h3 in the hierarchical register in english with no custom attibute.

/Hierarchical/addition.csv

LocalId|ParentLocalId|CollectionLocalId|Language|Label|Definition|Description|Status|Comment

h1|||en|item test 1|test definition|test description|valid|First import

h2|||en|item test 2|test definition|test description|valid|First import

h3|||en|item test 3|test definition|test description|valid|First import

The following example will invalidate the element with the id h3 and will set the element h2 as successor of the invalidate ditem.

/Hierarchical/invalidation.csv

LocalId|CollectionLocalId|SuccessorLocalId|SuccessorCollectionLocalId|Comment

h3||h2||

3. "Hierarchica Level 1"

The following example will insert an item with the id "hl1" and another with the id "hl2" in the hierarchical register in english with no custom attibute.

Notes:

This file is related to an item class that has a parent (the parent is the "Hierarchical" item class); that's why the field CollectionLocalId is filled with an element from the "Hierarchical" item class (the one presented above at bullet point 2).

The hl2 item has also a parent/child relation. In fact it has the item hl1 as parent. This parent/child relation is different from the collection hierarchy relation. Indeed, the collection hierarchy relation establishes a relation between elements belonging from different item classes (like the "Hierarchical" and "HierarchicalLevel1" item class). The parent/child relation establishes a relation between elements belonging from the same item class.

/HierarchicalLevel1/addition.csv

LocalId|ParentLocalId|CollectionLocalId|Language|Label|Definition|Description|Status|Comment

hl1||h1|en|item test 1|test definition|test description|valid|First import

hl2|hl1|h2|en|item test 2|test definition|test description|valid|First import

 

Trasformation files

For each new register added to the system, the related XSLT trasformation files shall be created in order to get the right export files.

An example XSL files can be found in the Re3gistry 1.1 package, folder: /example/xsl

There is a file for each register and a file for each item class available in the system. Below there is an example realted to the file needed to froduce the HTML format for the example registers created in this guide.

/xsl/html/simple_register.html.xsl

/xsl/html/Simple.html.xsl

/xsl/html/hierarchical_register.html.xsl

/xsl/html/Hierarchical.html.xsl

/xsl/html/HierarchicalLevel1.html.xsl

To have an example of the XSL code, open the files contained in the Re3gistry 10 package. In particular:

  • for the "simple register" look at the /xsl/html/theme_register.html.xsl and /xsl/html/Theme.html.xsl
  • for the "hierarchical register" look at the /xsl/html/codelist_register.html.xsl, CodeList.html.xsl and CodeListValue.html.xsl

 

Deployer configuration

The deployer module is responsible for deploying all the static files produced by the staticization system to the target production server. This is needed if the production server is in a different machine (or the files in the same machine need to be moved to another place in the same system).

The module automatically takes all the static file produced and move them to the configured target place.

The system uses a configurable script to launch the deployment process. This script can be found in the main application properties folder under scripts/Re3gistryDeployer.

The system automatically recognise the operative system (linux or windows) and launch the relative file (linux-deploy.sh or windows-deploy.bat). These shell script can be configured and customized to perform the needed operation in order to move the produced files to another dirctory as well as to another server.

To configure the Deployer module, the properties to be customized are contained in the RegistryDeployer.properties file. The properties are described below.

deploy.script.folder: this property represents the folder where the .sh of .bat file are stored.

deploy.rss.file: this property is the location of the base RSS file. It is the master file that keeps all the RSS news. If the "RSS update" option has been selected, the RSS update system takes this file and updates it with the new information. Then the file is copied to the target path

deploy.rss.targetfolder: the folder in wich the rss file is stored after the update (usually is the same folder that contains all the files produced by the staticizer)

deploy.rss.baseuri: this is the base uri of the RSS file, stored in the rss file as the channel's "link" element (example: for the inspire registry, it is http://inspire.ec.europa.eu/registry/rss/)

 

 

If you need more detailed information, you can read the complete Re3gistry 1.1 documentation.