Objective

In e-SENS, the Semantic SAT is mostly focused on the semantic interoperability from a legal and official document (evidence, attestation) perspective. Semantic technologies provides many concepts and tools to make machine-understandable descriptions of data, programs, and infrastructure enabling computers to reflect on these artefacts.

These concept and tools allow computer to overcome some of the problem that remain open when using messaging and XML as the basis for interoperability, namely the meaning of the XML labels and the real business meaning of the values contained in an XML document.

In the e-SENS project, Semantics goes beyond the code lists, vocabularies. Ontologies are used as a tool that can be leveraged to tailorize the Generic Building Block with the addition of Domain Knowledge and to infer new knowledge or to integrate knowledge coming from different sources.

Here the term "ontologies" is intended as a "shared conceptualization of the Domain of Interest", not necessarily inplying that they are formalized in OWL or in another language of the semantic web, like RDF or RDFs.

RDF, Resource Description Framework is a language and a data model to describe resources in the web.

The OWL 2 Web Ontology Language is an ontology language with formally defined meaning. OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents.

OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents.

Also Documents, guidelines, BPMN-like descriptions of processes and cross-reference tables are semantic assets and they can be intended as domain ontologies.

The ontologies are encapsuled in software components to offer a service interface (see Semantic Mapping and Terminology services).

Core Knowledge is context neutral knowledge, captured at a conceptual level, to be reused across different business domains.

 Core knowledge is contained in core vocabularies, a kind of  ontologies made up of context-neutral and extensible data models. Core vocabularies are commonly agreed, understood, and reused across different business domains of e-SENS.

The Core Vocabularies do not recommend any particular technical representation (syntax binding) of the conceptual model

ISA Core Vocabularies, but also Master Data suit this definition.

Every component of the Core Knowledge may be reused, qualified, restricted, extended, and associated with other components of the library. 

Core Vocabularies are the starting point for defining mappings between existing vocabularies to guarantee cross-domain and cross-border interoperability that can be attained by interoperability agreements between Public Administrations  and Service providers.

Domain Knowledge responds to competency questions and it is contained in  ontologies, which are shared descriptions of concepts and terms existing in a specific business domain of e-SENS.

Domain knowledge can also respond to competency questions about process.

The ontologies pertaining to different  domains are built upon the Core Knowledge library of e-SENS, that provides descriptions of concepts that are reusable across different domains. It is the responsibility of the respective domain to maintain and evolve their Domain Knowledge.

Domain domain-specific ontologies can be described in RDF - OWL when they cover concepts or in BPMN when they cover processes.

Scope

The scope of the e-SENS Semantics Architecture ABB embraces both these points of view and aims at:

  • Creating an e-SENS specific layer of semantic resources, concepts and codes (Core Concepts, with ISA, reusable across the various domains) to dereference syntactic items (terms);
  • Creating the services to enable semantic mappings between terms and resources or between terms. Translations and searches can later be included in this second task.

The scope of semantics SAT BB is an answer on consolidated domain requirements and actually covers different mapping services, terminology servers with management and policies of creating and updating ontologies. Creation of Multilanguage websites is out of scope.

The separation of data from application and databases or other physical structure opens possibilities to reuse the same information in different programming contexts. It prevents the same data management component being re-implemented across many applications. Semantic technology provides many concepts and tools to make machine-understandable descriptions of data, programs, and infrastructure enabling computers to reflect on these artefacts. The key to machine process-able data is to make data smarter. In addition to raw information they are loaded with understandable meaning and instructions for further processing.

 


Generic Requirements

 

Business Life Cycle - Business Registration

Requirement source

Requirement description

Area

Proposed BB

R5.4-UC1-11

The user should be able to retrieve personalised information about the process according to the country of origin, the type of business/activity and the location he/she will offer services in.

Information exchange

Process

R5.4-UC1-12

Mapping of similar concepts between the different MS applications should be done in order to ensure the compatibility of the information exchanged between different services.

Information exchange

Semantics

R5.4-UC1-14

The concepts defined should be compliant to the principles of the ISA core vocabularies.

Information exchange

Semantics

R5.4-UC1-15

Backward compatibility with the infrastructure that already exists in several MSs (e.g. SPOCS) should be taken into account.

Infrastructure

Semantics

R5.4-UC1-25

Mapping between the required documents in one MS and  the documents provided in the user’s MS should exist in order to verify the compatibility of the documents provided

Information Exchange

Semantics

R5.4-UC1-32

A smart data semantic asset that will allow at a later stage the automatic mapping of documents and information in the business domain across Member States may be created, similar to what is done in eCERTIS[1].

Information Exchange

eDocuments



[1] DG Internal Market and Services. e-Certificate [online]. 30 July 2014, [viewed 03 March 2015]. Available from Internet: http://ec.europa.eu/markt/ecertis/login.do

 

Business Life Cycle - Activity Registration

 

Requirement sourceRequirement descriptionAreaProposed BB

R5.4-UC2-11

The user should be able to retrieve personalised information about the process according to the country of origin, the type of business/activity and the location he/she will offer services in.

Information exchange

Process

R5.4-UC2-12

Mapping of similar concepts between the different MS applications should be done in order to ensure the compatibility of the information exchanged between different services.

Information exchange

Semantics

R5.4-UC2-14

The concepts defined should be compliant to the principles of the ISA core vocabularies.

Information exchange

Semantics

R5.4-UC2-15

Backward compatibility with the infrastructure that already exists in several MSs (e.g. SPOCS) should be taken into account.

Infrastructure

Semantics

R5.4-UC2-25

Mapping between the required documents in one MS and  the documents provided in the user’s MS should exist in order to verify the compatibility of the documents provided

Information Exchange

Semantics

R5.4-UC2-32

A smart data semantic asset that will allow at a later stage the automatic mapping of documents and information in the business domain across Member States may be created, similar to what is done in eCERTIS[1].

Information Exchange

eDocuments



[1] DG Internal Market and Services. e-Certificate [online]. 30 July 2014, [viewed 03 March 2015]. Available from Internet: http://ec.europa.eu/markt/ecertis/login.do

Use Cases and Scenarios

This SAT covers three generic use cases. 

 
Figure 1 Overview of use cases, roles and actors

The use cases are:

  1. A service provider is offering a public service to a user in a different member state
  2. A service provider is managing a collection of business rules specific to a public service or domain
  3. A reference data owner is managing a set of reference data in the form terminologies and codelists.

Supporting public service


Figure 2 Supporting cross- border public services (Generic use case, business process viewpoint)

A citizen or business uses a public service offered by a public administration in another Member State. The service is realised in a business process that involves a number of business functions. Some of these functions are supported by application services that provides querying of business rules and reference data.

Use Case

Public service supported by querying of knowledge systems.

Description

A cross-border public service that is offered by a public administration to citizens and businesses in other member states. The service is realised in a business process that is supported by the automatic querying of managed knowledge in form of multi-language terminologies, [code lists?] and mappings between European and Member State legislation.

Roles and Actors

Roles:
User – a consumer of a public service. [EIRA, but definition pending]
Service provider – a provider of a public service. [EIRA, but definition pending]
Actors:
Citizen – [EIRA, but definition pending]
Business – [EIRA, but definition pending]
Public administration – [EIRA, but definition pending]

Citizens and businesses can be users.
Public administrations can be service providers [and users?].

Goals

To increase efficiency in cross-border public services.

Assumptions

Existence of general, domain or service specific knowledge system that are authorised by service providers.

Artefacts

Reference data (controlled vocabularies/terminologies, code lists)
Business Rules (semantic mapping of legislations in specific context)
Business process descriptions (Events, Tasks, Messages, Data object)

Managing Reference Data



Figure 3 Managing reference data (Generic use case, business process viewpoint)

A reference data owner is managing a collection of reference data. A part of the management process is to receive suggestions from service providers. The management process consists of a number of functions to support collaboration including the distribution of reference data to service providers.

Use Case

Managing reference data that are used in cross-border public services.

Description

The owner of the reference data is providing a managing service that includes: handling suggestions from service providers, authoring, translating to other languages, mapping to other reference data, formal validation and distribution.

Roles and Actors

Roles:
Service provider – a provider of a public service. [EIRA, but definition pending]
Reference Data Owner – The organization that has legal right to a collection of reference data. [not in EIRA, working definition for this document]
Actors:
Public administration – [EIRA, but definition pending]
Private organization – [definition pending]
Public administrations can be service providers.
Public administrations and private organizations can be reference data owners.

Goals

To increase harmonization of use of reference data between cross-border public services.

Assumptions

Existence of general, domain or service specific knowledge system that are authorised by service providers.

Artefacts

Reference data (controlled vocabularies/terminologies, code lists)

Managing Business Rules (Semantic Mappings?)


Figure 4 Managing business rules (Generic use case, business process viewpoint)

A public administration is managing a set of business rules in the context of one of more public services. The process involves authoring of European rules and the localization of rules to Member State context. Business rules are validate against formal requirements. Business rules are distributed to service providers (and users?).

Use Case

Managing business rules and their localization as they are used in cross-border public services.

Description

Public administrations are managing a set of business rules regarding a specific public services or domain in collaboration. The managing process involved initial authoring on a European Level, localisation of rules to Member State level, formal validation of rules and distribution to service providers (and users?)

Roles and Actors

Roles:
Service provider – a provider of a public service. [EIRA, but definition pending]
Public administration – [EIRA, but definition pending]
Public administrations can be service providers.

Goals

To support automated localization of criteria and evidences used in cross-border public services.

Assumptions

Existence of European level regulations that can be localized.

Artefacts

Business Rules (semantic mapping of legislations in specific context)
Business process descriptions (Events, Tasks, Messages, Data object)

Application view


Figure 5 Use of application services in public service (front-office, application usage viewpoint)

In the context of a cross-border public service, the service provider is performing the business function of localising requirements to the jurisdiction of the user. The service provider queries the business process management component. The result is a mapping of generic requirements into local requirements that are to be fulfilled by the user. The user is asked to provide information to be used by service provider. Some of the information has to be structured or annotated with the use of controlled vocabularies. The user queries the Metadata Management Component for a set of terms and their definitions to use. 


Figure 6 Use of application services in public service (back-office, application usage viewpoint)


Figure 7 Use of application services in managing business rules (application usage viewpoint)

 

 

Solution Patterns and Variability

Pattern

Variation

ABB Configuration

 

  

 

 

Orchestration and Topology of ABBs



Figure 5 Use of application services in public service (front-office, application usage viewpoint)

In the context of a cross-border public service, the service provider is performing the business function of localising requirements to the jurisdiction of the user. The service provider queries the business process management component. The result is a mapping of generic requirements into local requirements that are to be fulfilled by the user. The user is asked to provide information to be used by service provider. Some of the information has to be structured or annotated with the use of controlled vocabularies. The user queries the Metadata Management Component for a set of terms and their definitions to use. 


Figure 6 Use of application services in public service (back-office, application usage viewpoint)


Figure 7 Use of application services in managing business rules (application usage viewpoint)


List of ABBs (all visible as elements in drawings above)

  1. Reference data query interface
  2. Business rules query interface
  3. Requirements for controlled vocabularies
  4. Requirement for semantic mappings/business rules
  5. Business rule editing interface

Semantic mapping services ABB

Functionality:

  • Provision of a requirement template,
  • Provision of a Requirement-to-Document mapping
  • Provision of a validation service (evidence to criteria mapping).
  • API interfaces to the knowledge management system

Terminology server ABB

Terminology server basically provides a meaning of the resource and its mapping between to different terminologies and code-lists used across member states countries.
Functionality:

  • Governance of updating terms and mappings
  • Provide mappings between national code-lists and terminologies and terminologies and code-lists on European level.
  • Provide a mechanism of synchronizing mapping information of national and European level.
  • Authorisation policy for translations
  • Generic processes for suggestions for changes to terminologies (new terms)
  • Querying API for online access of terminologies

Domain Knowledge Management system

also intended as an ontology management system, it is a system which lets users to maintain Domain Knowledge formalized in ontologies, provideing the APIS and the facilities to update and integrate this knowledge.

They also offer the APIs to query ontologies, like those leveraged by Semantic Mapping and Terminology services.

Functionalities:

  • Ontology design, creation,  integration, and update;
  • Versioning of ontologies,
  • Assigning rights for users and services which are using an ontology;
  • Provide validation tools after updating an ontology;
  • API to query ontologies and to access them;

Validation tool

Validation service is used for verifying ontology after update or create, the service will mostly be re-use by ontology management system .
Functionality:

  • RDF, RDF-S, OWL – syntax validation
  • Ontology testing: if it is „well-formed" - if there exists at least one set of requirements and one set of evidences that are in correspondence through the ontology. If not we can be sure that the Ontology will restitute False for any instance that we submit.

Optional Services Used From Other ABBs

Application ServiceCorresponding ABBCorresponding SAT
   

 

Information level

 

Term, concept


Codelists


Ontologies


References

 

Contributors

Name

Surname

Organisation

Country

 

   

History

Version

Date

Changes made

Modified by

17.03.2014

Template

Klaus Vilstrup Pedersen

 

0.3

10.05.2014

Basic Semantic Conceptions based on Peppol and Epsos

Giampaolo Sellitto

0.4

30.05.2014

Add Use Cases and e-Codex and Spocs conceptions

Giampaolo Sellitto

0.41

05.06.2014

Group requirements

Giampaolo Sellitto

0.42

22.06.2014

Aligning to new template

Tomasz Dębicki

0.44

12.08.2014

Provide archimate views

Mads Hjoerth

0.45

05.09.2014

Proposition of new ABBa

Giampaolo Sellitto

0.50

26.09.2014

Aligning to new template Architectural ABB, summarize work.

Tomasz Dębicki

0.51

09.10.2014

Requirements section rebuild

Tomasz Dębicki

0.53

17.10.2014

Requirements and use cases generalization

Tomasz Debicki

0.60

03.11.2014

SAT rebuild according to meeting agreements

Tomasz Dębicki, Artur Kośmider.

0.7…

05.11.2014

Aligning to EIRA and general simplification of drawings, use cases and narratives. Separation of terminology and business rules. Added a few definitions to glossay

Mads Hjorth

 

0.830.03.2015First alignment with ABB document provisioningGiampaolo Sellitto
  • No labels