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 FOP. XSL 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

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

Provided Services

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

• e-Document SAT
• Semantics SAT

ABB Capability Realization

Contributors

History