Muriel Foulonneau et al.
rules defined in the model. Validation descriptions must be defined in the model( OWL) and implemented in Java code. The OCD validator module( java library) is capable of validating OCD contents using the validator core module and pre‐defined validation rules. The module parses the OCD container and builds an in‐memory representation of the OCD content. OCD payload documents are also parsed with document parser modules. Finally, the Validator core module runs validations and returns validation results.
Validation rules are represented using OWL. An OWL model defines names and descriptions for the specific administrative procedure and its requirements. Administrative procedure requirements are treated as validation rules by the semantic validator. Each requirement is validated by the validator to check whether a particular application is valid according to the defined set of requirements. Each validation rule defined in the OWL model must be implemented in Java code. The Validation core module contains general rules( for example, the rule requiresDocumentType can be used to define requirements to provide specific documents for an application procedure). Additional rules may be defined for each administrative procedure.
Validation rules are defined by declaring OWL individuals which must be declared as instances of OWL classes from the SPOCS ontology.
The ontology underlying the validation process includes entities such as an Administrative procedure( the specific administrative procedure, which defines requirements for an application process), a Document type( the types of the documents provided by an applicant during the administrative process), and a Requirement( as defined in the administrative procedure).
In case a Lithuanian Travel Agent applies for a travel agent certificate in Portugal, the Portuguese receiver validates documents provided by the Lithuanian Travel Agent. The Portuguese Travel Agent application procedure is defined as an instance of the class Procedure named ForeignTravelAgentApplicationProcedure. It is assigned a set of Document Types as objects of a statement, with the requiresDocumentType property as predicate.
6. The automatic validation of a document and application based on data
The data source on document equivalences can then be used for verifying the requirements of a procedure and the validity of a particular application. The validation of the application against the procedure requirements is based on a data collection process.
The Polish government has issued very sophisticated rules, which have to be fulfilled in order deliver a service in Poland. There are requirements beyond the mere provision of the document type requested, which have to be fulfilled in order to ensure that a specific procedure form can be used. Regarding the documents themselves, their content has to be taken into consideration. Conditions apply to determine the validity of a bank guarantee for a particular scope of activities. The equivalence is defined based on either the document type or the document content( i. e., the information it contains). A user who applies to deliver a service has to fulfil a condition on a minimum level of financial guarantee. In the scope of administrative procedures, the documents to be provided are not all issued by administrative authorities, but rather by private institutions, such as banks or insurance companies. The insurance guarantee document includes three, i. e., the area of activity, the level of financial guarantee, and the scope of business activity.
The system creates data based on an empty instance of a resource. The required information is represented as questions included in a dedicated online form. When all data are collected, the guarantee for travel agent services is deemed either valid or invalid in the scope of the administrative application procedure. The Polish regulation is encoded as Bank guarantee rules using Jena rules. A Bank guarantee ontology was defined. Each document allows creating an instance of bank guarantee. The instance of bank guarantee is empty at the beginning of the process. It grows as answers are provided to questions created by the system. Rules are applied with the Jena rule engine. A rule is defined with a list of conditions( premises) and a list of outcomes( conclusions) separated by an arrow. Each rule is presented in brackets. It uses a RDF triple structure. After the rule engine interprets the rule, it computes new RDF triples. It identifies new missing information for every stage. The system creates questions whose answers fill the document instance. The instance is updated with each answer to a new question. The last stage of the interaction computes a final analysis which is displayed.
183