Description

Document Provisioning is an architecture building block which is introduced in the application view of e-Document SAT as one of its basic components. It is defined on a conceptual level as a reference architecture model, in alignment with EIRA architecture principles defined by Interoperability Solutions for European Public Administrations (ISA) Programme of European Commission, and is responsible for the provision of any electronic document (e-Document).

In order to set out all the functionalities related to an e-Document, two process models are defined; the Document Production and the Document Consumption. These models may be instantiated and processed by a document producer, or a document consumer respectively, in order to either create or visualize an e-Document. Each activity defined in these models is optional and reflects each functionality related to an e-Document. Hence, a producer, or a consumer, of an e-Document may include only the activities that are specific to their needs.

Document Provisioning recommends specifications and standards that will aid and support the defined process models and their corresponding functionalities. Its main objective is to ensure the technical, the syntactic and the semantic interoperability in the field of e-Documents.

An electronic document (e-Document) is any document in electronic format, containing structured or unstructured data, used in the context of e-SENS, and accompanied by a generic metadata file describing it. In case the e-Document is a structured document, its semantics must derive from the Domain Knowledge.

An e-Document format is a specification that lays down the syntax (structure) and semantics of a particular type of e-Documents.

Version:0.7.0
Status:In use
Sustainability 
Assessment:
N/A

Interoperability Level:

Interoperability Level

 

 

 

 

Core Knowledge, defined in Semantics SAT, is an ensemble of core vocabularies commonly agreed, understood, and reused across all business domains of e-SENS. Every component of the Core Knowledge may be reused, qualified, restricted, extended, and associated with other components of the library. It is intended to be jointly governed by all domains that make use of it. The e-Government Core Vocabularies defined by ISA constitute the main parts of the Core Knowledge.

Domain Knowledge, defined in Semantics SAT, is an RDF-based controlled library which describes concepts and terms existing in a specific business domain of e-SENS. This library must be built upon the Core Knowledge library of e-SENS. It is the responsibility of the respective domain to maintain and evolve their Domain Knowledge.

Based on the two actors that use Document Provisioning, namely the producer and the consumer of an e-Document, two process models are defined and supported.

 

The Document Production model comprises one or more of the following activities related to an e-Document:

  1. convert or transform;
  2. structure;
  3. attach business rules;
  4. validate;
  5. annotate.

Below is presented a possible instantiation of a Document Production model using the BPMN modeling language:

The Document Consumption model comprises one or more of the following activities related to an e-Document:

  1. validate;
  2. extract information;
  3. convert or transform;
  4. present.

Below is presented a possible instantiation of a Document Consumption model:

All the activities of the above models correspond to the functions defined and supported by Document Provisioning. These functions are described in the sections that follow.

Conversion and Transformation

Document Provisioning encompasses a conversion step in both its defined process models. Some e-Documents may need to be converted from one file type to another. This ensures the technical interoperability between the parties involved in a message exchange. In addition to the conversion function, a transformation function is also supported which refers to the construction of a second XML tree from a source XML tree in order to achieve the syntactic interoperability.

The World Wide Web Consortium (W3C) defines the former document conversion function as formatting whereas the latter one as transformation. Both functions accept an input document in XML format and via an XSL stylesheet, produce the presentation of that XML source content. XSL is a standard specification of W3C that supports the formatting process and typically any conversion from a structured document such as XML, or HTML, to a Portable Document Format (PDF) file, a PostScript (PS) file, or even a Portable Network Graphics (PNG) file. An open source implementation of W3C XSL is the Apache FOPXSL Transformations (XSLT) is another standard specification released by W3C which supports the transformation of a structured document from one XML format to another XML, or HTML, format.

Structuring

The structuring functionality of Document Provisioning is fully covered by the e-Document engineering methodology defined in Guidelines for public administrations on e-Document engineering methods by ISA. This methodology, in essence, defines three distinct phases. The conceptual phase, the logical phase and the physical phase. The whole process of creating a customized e-Document exchange format is called Application Profiling.

Application Profiling

Conceptual Level

At the conceptual level, the context of the given use case must be specified in Application Profiling. This is accomplished through the definition of a Business Process and is a functionality that is described and covered in detail in the Process SAT. At this same level of abstraction, apart from the process definition, resides also the Core Knowledge library. According to the CCTS generic principles, which Document Provisioning endorses, the components of Core Knowledge library must form the data building blocks that describe common concepts of the world (common concepts of all domains) in a context-neutral manner. All these vocabularies constitute the common library that will be used by each domain to create a new e-Document format (i.e. XSD) for a specific purpose. Document Provisioning points to the e-Government Core Vocabularies of ISA, namely the Core Person, the Core Location and the Core Business, as a recommended architectural choice for this purpose. Of course, other core vocabularies can be combined as well. Ideally, this conceptual model should be represented in an RDF graph, or in a UML class diagram, so that in the future all data modelers will have a clear picture of the concepts used in e-SENS and the relationships among them. It is also strongly recommended to register all these data building blocks in an appropriate RDF repository where they will be accessible and searchable for reuse.

Logical Level

At the logical level, always according to the proposed e-Document engineering methodology, the first step is to define the specific information exchange requirements of each Transaction that is part of the defined Business Process. These requirements are ideally documented in a special spreadsheet template along with their traces back to the high level requirements, the goals, the scope, and the representative examples of the given use case. The information requirements will actually drive the selection of specific data components that will satisfy them and will eventually be incorporated into the final e-Document format.

In essence, these data elements are the refinement (or the qualification) of the concepts (core components) that where defined at the conceptual level. Most of the times, this refinement is a restriction of a core component. This means that the derived new object class (ABIE) will have fewer basic business information entities (BBIEs) (or simply fewer attributes) than its corresponding core component (ACC).

However, sometimes the requirements point to an extension of a core component. Document Provisioning states that this extension should be performed only by defining the contained core component (the generalization) as an association (ASBIE) of the new object class with the additional properties (or attributes).

Physical Level

The transition from the logical model to the physical one, is an automated process, usually facilitated by a tool, and creates the desirable e-Document formats in a desirable specific syntax (i.e. XSD, RELAX NG etc.). The main facilitator technology that supports such a tool however, is the Naming and Design Rules (NDR) specification. Document Provisioning doesn’t mandate the usage of any particular NDR (i.e. CCTS NDR, UBL NDR) as long as is a reference architecture building block and does not interfere in a choice made at the physical level.

Annotation

Annotation is a textual comment or a note that is about, or refers to, an e-Document or a segment thereof, namely an identifiable data element. It may also refer to another annotation of the same document.

Document Provisioning recommends the Open Annotation (OA) Data Model defined by the W3C Open Annotation Community Group. It is intended to satisfy any annotation requirements that may arise in a business domain without the need to modify their e-Document formats.

All annotations must be persisted as a collection object inside a single annotation document, a special structured JSON document that will conform to a defined JSON-LD Schema. When such annotation document exists, it must be packed together with its associated e-Document(s) in a container format. It is recommended to use the Document Container (e-Container) ABB for this purpose.

An annotation must have a single Body section, which amongst other properties contains the annotation text, and a single Target section, where a certain URI either points to the whole e-Document, to a specific data element or even to another annotation.

Document Provisioning fully supports the annotation of identifiable data elements inside an e-Document by utilizing the FragmentSelector class from the Open Annotations Data Model. Thus, it is possible to uniquely identify any data element of an e-Document using the above class along with the XPointer mechanism of XML.

Business Rules

Document Provisioning recommends the usage of Schematron, a rule-based XML schema language which is an ISO/IEC standard along with XML Path Language (XPath) 2.0 expressions, a W3C Recommendation, in order to serialize and attach to an e-Document many of the business rules defined in that phase. However, Schematron does not support statements with an action or a result. It only detects the presence or absence of patterns in an e-Document and reports the result. For these kinds of statements, which are optional, it is recommended to build a Business Rule Engine (BRE) by making use of W3C Rule Interchange Format (RIF) ensemble of standards.

The validation of an e-Document assures its conformance to its e-Document format. It also assures its validity to all Schematron rules and any other optional business rules defined in a BRE.

Extraction or Presentation

The extraction of structured information which refers to an e-Document and the presentation of these data to the end user, are considered to be the final steps of the process model outlined in Document Provisioning. These steps MUST be performed by a conforming consumer application through the utilization of predefined XSL stylesheets that will convert or transform the structured part of an e-Document to the necessary exchange format. In addition, the consumer application MUST also be able to assign any unstructured part of the e-Document to an external application in order to deal with its presentation.

ABB Profiling

In general, profiling is the tailoring of standards and specifications for particular use cases or environments. In e-SENS, ABB Profiling is the process of constructing a solution building block (SBB) that is derived from an architecture building block (ABB). In the following activity diagram the profiling process of Document Provisioning is depicted. This is the recommended process that solution architects in collaboration with ABB experts should follow. The final outcome of the process should be an instantiation of an SBB which is either an actual solution implemented by the solution architects and developers or a particular software component procured for this purpose (off-the-shelf solution). Overall, the profiling process is performed on each functionality of Document Provisioning.

Generic Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this section of the document are to be interpreted as described in [RFC2119]. When used in this way, these terms will always be shown in ALL CAPS; when these words appear in ordinary typeface they are intended to have their ordinary English meaning.

Below are outlined the requirements that are fulfilled by the Document Provisioning ABB:

Functional Requirement
ID

Requirement Description

Compulsory

Reference to Requirements

R-DocProv-1

A producer, or a consumer, of an e-Document MAY instantiate only the activities of the process models, namely the Document Production and the Document Consumption respectively, that are specific to their needs. Every activity of the two process models is considered OPTIONAL.

 

No

 

R-DocProv-2Any e-Document MUST be accompanied by a structured metadata file. This metadata file MUST reference and describe the e-Document. Its elements MUST derive either from the Core Knowledge or from the Domain Knowledge libraries.Yes 
R-DocProv-3The Core Knowledge MUST contain an ensemble of core vocabularies commonly agreed, understood and reused across all business domains.YesR-eDocument-1, 
R-eDocument-2
R-DocProv-4The Core Knowledge MUST contain the e-Government Core Vocabularies released by ISA.NoR-eDocument-1, 
R-eDocument-2
R-DocProv-5The Core Knowledge MUST be jointly governed by all business domains.Yes 
R-DocProv-6Domain Knowledge libraries SHOULD describe as many as possible concepts and terms existing in the specific business domains.No 
R-DocProv-7A Domain Knowledge library MUST be built upon the Core Knowledge library.Yes 
R-DocProv-8A Domain Knowledge library MUST NOT make use of equivalent core elements other than the core elements defined by the Core Knowledge.Yes 
R-DocProv-9A conforming Document Producer MUST make use of a Domain Knowledge in order to structure an e-Document.Yes 
R-DocProv-10The conversion of an e-Document SHOULD adhere the W3C XSL specification.Νο 
R-DocProv-11The transformation of an e-Document SHOULD adhere the W3C XSLT Transformations specification.No 
R-DocProv-12The structured part of an e-Document MUST be conformant to its associated e-Document Format.Yes

R-eDocument-1,
R-eDocument-2

R-DocProv-13The e-Document format SHOULD be defined in W3C XML Schema.
No

R-eDocument-1,
R-eDocument-2

R-DocProv-14

An e-Document format MUST follow a specific grammar (i.e. UBL Naming and Design Rules).

Yes

R-eDocument-1,
R-eDocument-2

R-DocProv-15An e-Document format MAY include a unique identifier data element for an e-Document.No 
R-DocProv-16The structured part of an e-Document MAY be transformed via an XSL stylesheet to a spread sheet format and vice versa.No

R-eDocument-3,

R-eDocument-5

R-DocProv-17The structured part of an e-Document MAY be transformed via an XSL stylesheet to an RDF based format (RDF/XML) and vice versa.NoR-eDocument-4
R-DocProv-18The producer of an e-Document MAY attach to it all the defined schematron rules.NoR-eDocument-6
R-DocProv-19The consumer of an e-Document MAY validate the attached schematron rules it might have.NoR-eDocument-6
R-DocProv-20The producer of an e-Document MAY make use of the Open Annotations data model in order to annotate the structured data elements of an e-Document.NoR-eDocument-7
R-DocProv-21The producer of an e-Document MAY make use of the Open Annotations data model in order to annotate an e-Document at document level.NoR-eDocument-7
R-DocProv-22

The producer of an e-Document MAY make use of validation tools like W3C XML Schema Validators and Schematron Validators.

NoR-eDocument-8
R-DocProv-23The structured part of an e-Document MAY be transformed via an XSLT stylesheet to an HTML file.NoR-eDocument-12, R-eDocument-18
R-DocProv-24The structured part of an e-Document MAY be converted via an XSL stylesheet to a PDF file.NoR-eDocument-12, R-eDocument-18
R-DocProv-25The consumer of an e-Document MAY make use of validation tools like W3C XML Schema Validators and Schematron Validators.NoR-eDocument-14

Provided Services

Provided ServicesPurposeOutcome
Convert e-DocumentConvert an e-Document from one format to another, mainly for presentation purposes.e-Document is converted
Transform e-DocumentTransform an e-Document from one structured format to another for further processing.e-Document is transformed
Capture business requirementsThe business requirements specify the context of a business process.Business requirements are captured
Model business informationThe information requirement model reflects the structure of the exchanged information in a business process.Business information is modeled
Identify business rulesThe identified business rules reflect the behavior of the exchanged information in a business process.Business Rules are identified
Perform syntax bindingThe information requirement model is mapped to an existing standardized e-Document format.Syntax binding is applied
Create e-Document formatThe information requirement model creates a new e-Document format based to existing standardized core data libraries.e-Document format is created
Attach business rulesThe identified business rules are serialized to a standard syntax and are ready to be attached to the e-Documents exchanged in a business process.Business rules are attached
Annotate e-DocumentAnnotate an e-Document in order to attach a note to it or to a specific element of it, in case it is structured.e-Document is annotated
Validate e-DocumentValidate an e-Document both against its document format and its attached validation artefacts.e-Document is validated
Extract structured information and present e-DocumentExtract the information an e-Document holds in a structures way that is easy to persist and present.e-Document is extracted and presented

Application view

Information view

The diagram below represents an example of how a business document might look like:


The diagram below represents an example of how an annotation document might look like:


Related ABBs

ABB Capability Realization

Contributors

Name

Surname

Organisation

Country

PanagiotisNICOLAOUUPRCGreece

History

Version

Date

Changes made

Modified by

0.2

17.03.2014

Template

Klaus Vilstrup Pedersen

0.3

27.07.2014

Initial Draft for Document Provisioning ABB-Component.

Panagiotis Nicolaou

0.4

04.08.2014

Second Draft for Document Provisioning ABB-Component.

Panagiotis Nicolaou

0.41

19.08.2014

Amendments after first review cycle.

Panagiotis Nicolaou

0.5

24.08.2014

Annotations specification added.

Panagiotis Nicolaou

0.51

29.08.2014

Incorporation of ISA suggestions; Replies to ISA comments.

Panagiotis Nicolaou

0.52

11.10.2014

Better alignment with the template. Conversion and transformation section added.

Panagiotis Nicolaou

0.53

13.10.2014

Final refinements towards 0.6 version.

Panagiotis Nicolaou

0.6017.10.2014Final version, for inclusion in D6.2Panagiotis Nicolaou
0.6111.11.2014Amendments after decisions taken in the Bucharest F2F meeting.Panagiotis Nicolaou
0.7.021.04.2015Alignment to the new e-SENS EIRA templatePanagiotis Nicolaou
  • No labels