Digital Archive IT system for the Republic administration for geodetic and property affairs of
Republic of Srpska (RSGA), Case no. 16/07231
Appendix 1
Development of Digital Archive IT System
Technical Requirements
Content
1
Introduction .................................................................................................................................. 3
1.1
Purpose .........................................................................................................................................3
1.2
RSGA Digital Archive overall content and functionality ...............................................................3
1.3
Scope of this document ................................................................................................................3
1.4
Business Needs .............................................................................................................................4
1.5
Key Stakeholders ..........................................................................................................................5
1.5.1
Responsibility ............................................................................................................................5
1.5.2
Business Needs .........................................................................................................................5
2
General Architecture Principles .................................................................................................... 6
3
Architecture Decisions and Rationale ........................................................................................... 8
4
Views and Models ......................................................................................................................... 9
4.1
4.1.1
Concerns ...................................................................................................................................9
4.1.2
Stakeholders .............................................................................................................................9
4.2
Context model ..............................................................................................................................9
4.3
Functional view...........................................................................................................................10
4.4
Functional model ........................................................................................................................11
4.5
Information view ........................................................................................................................11
4.6
Static information structure models ..........................................................................................12
4.6.1
Austrian Land Register and Land Cadaster .............................................................................13
4.6.2
Land Cadaster, Topographic Maps, Geodetic Points and Ortophoto .....................................14
4.6.3
Census Cadaster......................................................................................................................15
4.6.4
Revision...................................................................................................................................16
4.6.5
Property Affairs.......................................................................................................................16
4.6.6
Communal Devices Cadaster ..................................................................................................16
4.6.7
Book of Deposited Contracts – buying ...................................................................................17
4.6.8
Book of Deposited Contracts – selling ....................................................................................17
4.6.9
Office Management ................................................................................................................17
4.6.10
Books ..................................................................................................................................17
4.6.11
Land Registry ......................................................................................................................18
4.6.12
Other Documents ...............................................................................................................18
4.7
5
6
Context view .................................................................................................................................9
Deployment view ........................................................................................................................18
Requirements .............................................................................................................................. 20
5.1
General Technical Requirements ...............................................................................................20
5.2
Functional Requirements ...........................................................................................................22
5.3
Non-Functional Requirements ...................................................................................................29
Appendices .................................................................................................................................. 37
1
6.1
References ..................................................................................................................................37
6.2
Definitions...................................................................................................................................38
6.3
List of Acronyms .........................................................................................................................40
2
1 INTRODUCTION
This document is related to the project “Maps for National Development and European Integration”
where Statens kartverk1 (The Norwegian Mapping Authority) is supporting both Administration for
Geodetic and Real Property Affairs in Bosnia and Herzegovina: Republic Administration for Geodetic and
Real Property Affairs (RSGA)2 and Federal Administration for Geodetic and Real Property Affairs (RSGA)3
with developing digital archives.
The complementary project "Capacity Building for Improvement of Land Administration and Procedures
in Bosnia and Herzegovina" (CILAP)4, financed by Lantmäteriet5, focuses on strengthening and
development of the land administration institutions and business processes, human resources, education
and training in using of modern survey technology, development of a legislation framework, property and
land valuation system, an work processes utilizing new, modern digital archives.
1.1 Purpose
The purpose of this document is to provide the necessary background information, business needs,
system scope, and high-level technical specifications for the outsourcing of the detailed design,
development and the implementation of a Digital Archive IT system, to be installed at RSGA.
1.2 RSGA Digital Archive overall content and functionality
RSGA digital archive (DA) is consisting of an DA IT system, and an organization of people that has accepted
the responsibility to preserve relevant RSGA data and make it available for an identified group of potential
consumers who should be able to understand a particular set of preserved data.
The DA IT system is a multitier web-based system that will be used at central level, as well as at cadaster
offices.
The DA will hold documents in various formats. The documents shall be searched by their metadata only,
except for documents having text in readable form, where free text search should be enabled. Search for
documents using spatial criteria is limited to location data contained in the related metadata.
The DA is a responsive multitier web-based application that enables the following key functionalities:
-
Archive and store data in an organized way with versioning to be reflected in the metadata,
Enables metadata management (metadata editor),
Enables creating data templates and data groups,
Enables a secure and controlled data access and modification,
Enables data search and filters based on metadata and simple spatial criteria as far as such data
are contained in the metadata,
Enables controlled and monitored import and export of data,
Enables interaction with other systems using SOA and
Enables backup and safe storage procedures.
1.3 Scope of this document
The scope of the document is to:

Give an overall picture of the background and environment of the system,
1
http://www.statkart.no
2
http://www.rgurs.org
3
http://www.fgu.com.ba
4
http://www.cilap-project.org
5
http://www.lantmateriet.se
3



Describe the system architecture,
Specify the overall system requirements,
Specify the non-functional requirements.
The contractor has the obligation to implement the metadata for each of the classes of archive
documents listed and described in chapter 4.6. The contractor, will consider technical requirements
information contained in this document and all other information that the RSGA will provide during
implementation. If the contractor needs other information for the modifications of metadata, the RSGA
will provide clarifications upon request. In case there is a need for metadata modifications during the
project implementation the contractor can propose changes to the metadata specifications, which need
to be accepted by the RSGA.
1.4 Business Needs
The overall business needs to be covered by the DA (Digital Archive IT System) include:
1. Capture
The system needs to support capturing scanned as well as scanned and georeferenced documents
through a set of predefines business processes. The process of capturing metadata should be automatic
wherever possible (including reading a georeferenced raster location if available). A function to transfer
access rights and metadata from other documents or document sets should be implemented.
2. Dynamic content templates and user access groups
The system needs to enable creation of new content templates or change existing ones. This includes but
is not limited to creating templates with corresponding metadata and spatial references. The same apply
to templates for group of documents. The administrator needs to be able to create users and groups of
users and assign corresponding rights for the users for access to groups of documents or single
documents.
3. Store
The system needs to store all data/documents in an enterprise content repository with versioning
enabled. The system should also support storing original (lossless compression) and compressed (lossy
compression) files for easier distribution.
4. Manage
The system needs to provide content/document6 management and users management.
5. Preserve
The system needs to provide long-term, safe storage and backup of static, archive documents, as well
documents incoming from RSGA internal systems7. The backup procedures should be differential, should
run at times defined by RSGA (hourly, daily, weekly) and do not have to be a part of the software itself
but configured externally. Backup reporting should be implemented.
6. Dissemination
The system needs to provide application services, which can be used by internal systems to search for
and show archive data/documents.
6
7
Archive documents, files, maps and documents from FGA internal systems.
RSGA internal systems are listed in 4.1.1.2.
4
7. Data/Document Search & Access
The system needs to provide advanced search capabilities based on the document itself (if the document
can be read), document metadata and spatial query (if the related metadata has a spatial component8),
all according to the UML metadata models. The access to documents should be controlled through
dynamic user rights that can be applied to a single document or a set of documents and are controlled by
the administrator. Document access should be provided as read only (access only through the
application), watermarked document download, compressed document downloads and original
document download. The system needs to track user activity in regards to system usage and provide the
administrator with reporting capabilities.
1.5 Key Stakeholders
The table below shows the main stakeholders related to the DA, and summarizes their responsibilities
and business needs.
Stakeholder
1.5.1 Responsibility
RSGA
Internal
services)
ISs
(via
External systems - via
services (see 4.1.1.2)




Archiving
DA user management
IT infrastructure
Data replication




Data capture
File management
Provide DA content
Consume DA content
 Consume DA content
1.5.2 Business Needs
 Tool for centralized archiving
and content distribution
 System administration
 System maintenance
 Access control
 Capturing data
 Managing data
 Preserving data
 QC tool
 Managing Replication
 Convert data from paper into
an electronic format
 Search DA
 Retrieve DA data/documents
 Provide data/documents to
DA
 Search DA
 Retrieve DA data/documents
Table 1.1: Stakeholders, their responsibilities and business needs
8
Term spatial component in this documents implies MBR (minimum bounding rectangle) of the space
covered by document’s content.
5
2 GENERAL ARCHITECTURE PRINCIPLES
Architecture of a software-intensive system is the structure or structures of the system, which comprise
software elements, the externally visible properties of those elements, and the relationships among
them. The system architecture defines four different aspects of system:
1. Static structures
Specify the design-time form of a system, i.e. its internal design-time elements (modules, services,
classes, computers, routers) and their arrangement.
2. Dynamic structures
Specify how the system actually works and what the system does in response to external (or internal)
stimulus. Dynamic structures define run-time elements of system and their interactions.
3. Externally visible behavior
Specifies what a system does from the viewpoint of an external observer, i.e. defines the functional
interactions between the system and its environment.
4. Quality properties
An externally visible, nonfunctional properties of a system such as performance, security, or scalability.
System architecture is an abstraction - an architecture description captures architecture. The architecture
description is inherently multi-view. No single view is sufficient to capture architecture because
architecture is multi-disciplinary, with multiple stakeholders and multiple architecture-related concerns
that the architect must deal with. The viewpoints (perspectives on the architecture) are separated from
views (what is captured in the description of a specific architecture from the perspective of a viewpoint
for a system of interest). This distinction is motivated by the body of existing practice that defines
viewpoints for a number of architecture-related concerns. There should be a viewpoint for each view the viewpoint explains the conventions being used in that view.
According to [1] an architecture description contains the following:





Identification of the stakeholders for the architecture and the system of interest,
Identification of the architecture-related concerns of those stakeholders,
A set of architecture viewpoints defined so that all of the stakeholder concerns are covered by
that set of viewpoints,
A set of architecture views, such that there is one view for each viewpoint,
A set of architecture models from which the views are composed.
Figure 2.1 depicts concepts pertaining to the practice of architecture description when applying
ISO/IEC/IEEE 42010 Standard [1] to produce architecture description expressing architecture for the
system-of-interest.
A system is built to address the needs, concerns, goals and objectives of its stakeholders. Stakeholders of
a system have concerns with respect to the system-of-interest considered in relation to its environment.
A concern could be held by one or more stakeholders. Concerns arise throughout the life cycle from
system needs and requirements, from design choices and from implementation and operating
considerations. A concern could be manifest in many forms, such as in relation to one or more stakeholder
needs, goals, expectations, responsibilities, requirements, design constraints, assumptions,
dependencies, quality attributes, architecture decisions, risks or other issues pertaining to the system.
The system architecture is comprised of a number of architecture elements and their relationships, and
can be documented by an architecture description.
An architecture description documents architecture for its stakeholders and demonstrates to them that
it has met their needs. It includes one or more architecture views.
6
A viewpoint defines the aims, intended audience, and content of a class of views and defines the concerns
that views of this class will address.
Fig. 2.1. Conceptual model of an architecture description
A view conforms to ta viewpoint and so communicates the resolution of a number of concerns. An
architecture description comprises a number of views. It addresses one or more of the concerns held by
the system’s stakeholders. The architecture view is composed of one or more architecture models.
An architecture model uses modelling conventions appropriate to the concerns to be addressed. These
conventions are specified by the model kind governing that model. Within an architecture description,
an architecture model can be a part of more than one architecture view.
7
3 ARCHITECTURE DECISIONS AND RATIONALE
The decision on global system architecture is influenced by a number of relevant factors and architectural
principles - all of them have been considered and excessively discussed with RSGA and a centralized
multitier system should be implemented. The two factors that have primarily influenced the global
system architecture are: organization of geodetic administration and telecommunication infrastructure.
RSGA is centralized institution, so the DA of RSGA will be implemented as a centralized system (Fig. 3.1).
Fig. 3.1 RSGA DA as centralized system
Hardware is not part of this procurement. It is obligation of RSGA to provide all hardware necessary for
the implementation of this project.
8
4 VIEWS AND MODELS
4.1 Context view
The Context view describes relationships, dependencies and interactions between DA system and its
environment - the people, systems and external entities with which it interacts. It defines what the system
does and does not do; where the boundaries are between it and the outside world; and how the DA
system interacts with other systems and organizations across these boundaries.
4.1.1 Concerns
4.1.1.1
System scope and responsibilities
This concern does not extend to a complete definition of the system’s requirements. System scope
encompasses:





4.1.1.2
Capturing, storing, managing and distribution of archival data,
Preserving all archive information in a central repository and make them available for an
identified group of users and potential customers,
Data, metadata and spatial search capabilities for all data stored,
Supporting regular and ad hoc extracts to the publishing repository,
Support for integration and communication with other systems via SOA.
Identity of external entities and services
There are several existing and future systems that should be able to integrate with DA. This is why the
main business functionalities of the DA should be exposed to other systems. The bidder has no
responsibility for developing the service interfaces in the existing RSGA internal systems – the
corresponding system providers will develop them.
4.1.1.3
Identity and responsibilities of external interfaces
RSGA internal systems mentioned in may have one or more of the following responsibilities:



Data provider − the system that supplies data directly to DA.
Data consumer − the system that receives data directly from DA.
Service consumer − the system that request some action of DA.
4.1.2 Stakeholders
Stakeholder concerns for the Context viewpoint are listed in Table 4.1:
Stakeholder Class
Concerns
System scope and responsibilities
External systems and services
Acquires
✔
✔
Developers
✔
✔
System administrator
✔
✔
Users
✔
✔
Table 4.1. Stakeholders concerns for the Context viewpoint
4.2 Context model
This model presents an overall picture of DA in its environment in RSGA headquarters and relations to
other systems with which it might interact in the future. Application integration, i.e., interaction with
other systems at RSGA headquarter will be based on service oriented architecture (SOA).
9
Fig. 4.1. RSGA DA Context diagram
4.3 Functional view
The Functional view defines the architecture elements that deliver the DA’s functionality. It describes the
system’s runtime functional components and their responsibilities, interfaces and primary interactions.
This view frames the following concerns of all stakeholders:



Functional capabilities – define what the system is required to do, and implicitly, what is not
required to do.
External interfaces – data and control flows between the system and external systems.
Internal structure – defined by internal elements (components), i.e. what they do and how they
interact with each other.
Stakeholder concerns for the Functional viewpoint are listed in Table 4.2:
Stakeholder Class
Concerns
Functional capabilities
External interfaces
Acquires
✔
✔
Developers
✔
✔
✔
✔
System administrator
Users
Internal structure
✔
✔
Table 4.2: Stakeholders concerns for the Functional viewpoint
10
4.4 Functional model
UML component diagram (Fig 4.2) describes OAIS-compliant functional model9.
Fig 4.2. Digital Archive - UML Component diagram
The Ingest component should provide the services and functions to accept Submission Information
Packages (SIPs) from Producers (or from internal elements under Administration control) and prepare the
contents for storage and management within DA. Ingest functions should include receiving SIPs,
performing quality assurance on SIPs, generating an Archival Information Package (AIP) which complies
with the DA’s data formatting and documentation standards, extracting Descriptive Information from the
AIPs for inclusion in the DA database, and coordinating updates to Archival Storage and Data
Management.
The Archival Storage component should provide the services and functions for the storage, maintenance
and retrieval of AIPs. Archival Storage functions should include receiving AIPs from Ingest and adding
them to permanent storage, managing the storage hierarchy, refreshing the media on which DA holdings
are stored, and providing AIPs to Access to fulfill orders.
The Data Management component should provide the services and functions for populating, maintaining,
and accessing both Descriptive Information, which identifies and documents DA holdings and
administrative data used to manage DA. Data Management functions should include administering the
DA database functions, performing database updates (loading new descriptive information or DA
administrative data), performing queries on the data management data to generate query responses, and
producing reports from these query responses.
The Administration component should provide the services and functions for the overall operation of the
DA.
The Access component should provide the services and functions that support Consumers in determining
the existence, description location and availability of information stored in DA, and allowing Consumers
to request and receive information products. Access functions should include communicating with
Consumers to receive requests, applying controls to limit access to specially protected information,
coordinating the execution of requests to successful completion, generating responses (Dissemination
Information Packages, query responses, reports) and delivering the responses to Consumers.
4.5 Information view
This view describes the way that DA system stores information. The Information view frames the
following concerns of stakeholders:
Potenital bidders are allowed to propose alternative UML model which provide equivalent functional
capabilities.
9
11


Information structure and content – the structure and content of the information that DA stores,
manages and distributes.
Information flow – the way that information moves around system and is accessed, modified and
distributed by its components.
Stakeholder concerns for the Information viewpoint are listed in Table 4.3:
Stakeholder Class
Concerns
Information structure and content
Information flow
Acquires
✔
✔
Developers
✔
✔
System administrator
✔
Users
✔
✔
Table 4.3: Stakeholders concerns for the Information viewpoint
4.6 Static information structure models
DA shall store the following classes of archive10 documents and data from:





















Austrian Land Register and Land Cadaster
Land Cadaster, Topographic Maps, Geodetic Points and Ortophoto
Census Cadaster
Revision
Property Affairs
Communal Devices Cadaster
Book of Deposited Contracts – buying
Book of Deposited Contracts – selling
Office Management
Books
Land Registry
Other Documents
Real Estate Cadaster 1984
Real Estate Cadaster 1996
Real Estate Cadaster 2006
Real Estate Cadaster 2012
Topographic maps
Geodetic points
Ortophoto
Content of Archive of B&H
Vectorized geodetic maps
The list above represents the minimum set of document/content types to be implemented by the DA
System. However, the DA must support creation of new document/content types along with its metadata
through an administrative interface.
Archive documents do not include documents from the exisitng internal systems listed in 4.1.1.2.
However, DA component shall be able to manage documents from these systems.
10
12
Static information structures models (i.e. metadata specification) for these document classes are
presented in sections 4.6.1 – 4.6.12. These are the foundation for specifying the structure of the
metadata. The final set of metadata will be defined during the implementation of the project.
4.6.1 Austrian Land Register and Land Cadaster
The most important metadata (describing all document types) are as follows:






level – political municipalities – mandatory, one of many predefined values,
cadastral municipality – mandatory, one of many predefined values,
document type – mandatory, one of many predefined values,
document name – mandatory,
number of files – number of images or pages in a document – mandatory,
note – not mandatory.
Depending on the document type, the following metadata can appear:
1. Plans and sketches (Planovi i skice)
 contents – mandatory, one of many predefined values,
 nomenclature – not mandatory.
2. Census lists (Popisni listovi)
 census list number – mandatory, one of many predefined values.
3. Possession lists and collection lists (Posjedovni listovi i Sabirni listovi)
 possession/collection list number – mandatory.
4.







Collection of documents (Zbirka isprava)
year – mandatory, one of many predefined values,
number of documents – mandatory,
list of changes – mandatory, one or many,
parcel number – mandatory, one or many,
possession list – mandatory, one or many,
party – mandatory, one or many,
subject type – mandatory, one or many.
5. List of changes nad Other documents (Lista promjena, Drugi dokumenti)
 year.
Fig 4.3. Austrian Land Register and Land Cadaster – UML class diagram
13
4.6.2 Land Cadaster, Topographic Maps, Geodetic Points and Ortophoto
The most important metadata (describing all document types) for Land Cadaster are as follows:
















level – political municipalities – mandatory, one of many predefined values,
cadastral municipality – mandatory, one of many predefined values,
document type – mandatory, one of many predefined values,
content – mandatory, one of many predefined values,
document name – not mandatory for all document types,
number of files – number of images or pages in a document – mandatory,
note – not mandatory,
year – not mandatory for all document types, one of many predefined values,
land possession list – mandatory only for land possession list document type, one or many,
census list – mandatory only for census list document type,
document number – mandatory,
list of changes – not mandatory, one or many,
parcel number – not mandatory, one or many,
party – mandatory, one or many,
subject type – mandatory, one or many,
PL number, one or many.
Fig 4.4. Land Cadaster, Topographic Maps and Ortophoto – UML class diagram
The most important metadata for Topographic Maps are as follows:
14







document type – mandatory, one of many predefined values,
content – mandatory, one of many predefined values,
document name – mandatory,
number of files – number of images or pages in a document – mandatory,
note – not mandatory,
year –mandatory, one of many predefined values,
nomenclature – mandatory.
4.6.3 Census Cadaster
The most important metadata are as follows:
















level – political municipalities – mandatory, one of many predefined values,
cadastral municipality – mandatory, one of many predefined values,
document type – mandatory, one of many predefined values,
content – mandatory, one of many predefined values,
document name – mandatory,
year – mandatory only for Collection of documents, one of many predefined values,
number of files – number of images or pages in a document – mandatory,
note – not mandatory,
census list – mandatory,
list of changes – not mandatory, one or many,
document number – mandatory,
land census list – mandatory only for land census list document type, one or many,
parcel number – not mandatory, one or many,
party – not mandatory, one or many,
subject type – mandatory, one or many,
PL number – not mandatory, one or many.
Fig 4.5. Census cadaster – UML class diagram
15
4.6.4 Revision
The most important metadata (describing all document types) for Revision are as follows:






level – political municipalities – mandatory, one of many predefined values,
cadastral municipality – mandatory, one of many predefined values,
document type – mandatory, one of many predefined values,
document name – not mandatory for all document types,
number of files – number of images or pages in a document – mandatory,
note – not mandatory.
4.6.5 Property Affairs
The most important metadata (describing all document types) for Property Affairs are as follows:
















level – political municipalities – mandatory, one of many predefined values,
cadastral municipality – mandatory, one or many of many predefined values,
document type – mandatory, one of many predefined values,
classification – mandatory, one of many predefined values,
subject type – mandatory, one of many predefined values,
document name – not mandatory for all document types,
year – mandatory, one of many predefined values,
document number – mandatory,
party – mandatory, one or many,
cadastral parcel – mandatory, one or many,
land-registry slip/sheet/parcel – mandatory, one or many,
possession list – mandatory 1/311, one or many,
cadastral-registry slip/sheet – mandatory 1/312, one or many,
immobilities list – mandatory 1/313, one or many,
number of files – number of images or pages in a document – mandatory,
note – not mandatory.
4.6.6 Communal Devices Cadaster
The most important metadata (describing all document types) for Communal Devices Cadaster are as
follows:








level – political municipalities – mandatory, one of many predefined values,
cadastral municipality – mandatory, one or many of many predefined values,
document type – mandatory, one of many predefined values,
maintenance / establishment – mandatory, one of many predefined values,
year – mandatory, one of many predefined values,
document number – mandatory 1/214,
registration number – mandatory 1/215,
type of line – mandatory, one or many of many predefined values,
11
one of the following is mandatory: possession list, cadastral-registry slip/sheet, immobilities list
12
one of the following is mandatory: possession list, cadastral-registry slip/sheet, immobilities list
13
one of the following is mandatory: possession list, cadastral-registry slip/sheet, immobilities list
14
one of the following is mandatory: document number, registration number
15
one of the following is mandatory: document number, registration number
16
 nomenclature – mandatory,
 number of files – number of images or pages in a document – mandatory,
 note – not mandatory.
4.6.7 Book of Deposited Contracts – buying
The most important metadata (describing all document types) for Book of Deposited Contracts – buying
are as follows:












level – political municipalities – mandatory, one of many predefined values,
cadastral municipality – mandatory, one of many predefined values,
document type – mandatory, one or many of many predefined values,
document name – not mandatory for all document types,
year – mandatory, one of many predefined values,
document number – mandatory,
subject type – mandatory, one or many of many predefined values,
entry number – not mandatory, one or many,
parcel number – not mandatory, one or many,
object number – not mandatory, one or many,
number of files – number of images or pages in a document – mandatory,
note – not mandatory.
4.6.8 Book of Deposited Contracts – selling
The most important metadata (describing all document types) for Book of Deposited Contracts – selling
are as follows:












level – political municipalities – mandatory, one of many predefined values,
cadastral municipality – mandatory, one of many predefined values,
document type – mandatory, one of many predefined values,
document name – not mandatory for all document types,
year – mandatory, one of many predefined values,
document number – mandatory, one or many,
subject type – mandatory, one or many,
entry number – not mandatory, one or many,
parcel number – not mandatory, one or many,
object number – not mandatory, one or many,
number of files – number of images or pages in a document – mandatory,
note – not mandatory.
4.6.9 Office Management
The most important metadata (describing all document types) for Office Management are as follows:






level – political municipalities – mandatory, one of many predefined values,
document type – mandatory, one of many predefined values,
document name – not mandatory for all document types,
year – mandatory, one or many of many predefined values,
number of files – number of images or pages in a document – mandatory,
note – not mandatory.
4.6.10 Books
The most important metadata (describing all document types) for Books are as follows:
17







level – political municipalities – mandatory, one of many predefined values,
document type – mandatory, one of many predefined values,
field – mandatory, one of many predefined values,
document name – not mandatory for all document types,
year – mandatory,
number of files – number of images or pages in a document – mandatory,
note – not mandatory.
4.6.11 Land Registry
The most important metadata (describing all document types) for Land Registry are as follows:













level – political municipalities – mandatory, one of many predefined values,
cadastral municipality – mandatory, one or many of many predefined values,
document type – mandatory, one of many predefined values,
document name –mandatory,
year – not mandatory for all document types, one of many predefined values,
document number – mandatory for all documents created after 2007, one or many,
DN number – mandatory, one or many,
parcel – not mandatory, one or many,
land-registry slip/sheet – mandatory for land-registry document type, one or many,
party – mandatory, one or many,
subject type – mandatory, one or many,
number of files – number of images or pages in a document – mandatory,
note – not mandatory.
4.6.12 Other Documents
The most important metadata (describing all document types) for Other Documents are as follows:






level – political municipalities – mandatory, one of many predefined values,
document name – not mandatory for all document types, one of many predefined values,
content – mandatory, one of many predefined values,
subject type – mandatory, one of many predefined values,
number of files – number of images or pages in a document – mandatory,
note – not mandatory.
4.7 Deployment view
This view describes the environment into which the system will be deployed; including the dependencies
the system has on its runtime environment.
Stakeholder Class
Concerns
Runtime platform models
Specification of hosting
Developers
✔
✔
System administrators
✔
✔
Testers
✔
✔
18
Fig 4.10. Deployment at RSGA
19
5 REQUIREMENTS
5.1 General Technical Requirements
Req. ID
Requirement
Description
GTR-1
Core functions
Capturing, storing, managing, Mandatory
preservation and distribution of
DA content.
GTR-2
SOA
Integration and interoperability Mandatory
with other systems shall be
based on SOA.
GTR-3
Data/Content
The DA shall capture, store, Mandatory
manage, preserve and distribute
the following data/content:





















Type
Austrian Land Register
and Land Cadaster
Land
Cadaster,
Topographic
Maps,
Geodetic Points and
Ortophoto
Census Cadaster
Revision
Property Affairs
Communal
Devices
Cadaster
Book of Deposited
Contracts – buying
Book of Deposited
Contracts – selling
Office Management
Books
Land Registry
Other Documents
Real Estate Cadaster
1984
Real Estate Cadaster
1996
Real Estate Cadaster
2006
Real Estate Cadaster
2012
Topographic maps
Geodetic points
Ortophoto
Content of Archive of
B&H
Vectorized
geodetic
maps
20

The DA must support
creation of new content
types
through
an
administrative interface.
GTR-4
OAIS
The system shall be conforming Optional
to OAIS framework.
GTR-5
OSS-based solution
The
system
shall
be Optional
implemented by OSS and related
components (see NFR-SDL-2).
GTR-6
METS for SIP/DIP
Integration and interoperability Optional
services shall use METS for SIP
and DIP.
GTR-7
Multi-tier architecture
The system shall be based on Mandatory
multi-tier architecture, in which
presentation,
application
processing,
and
data
management functions are
physically separated (Fig. 5.1 or
equivalent).
GTR-8
Web interface
User interface shall be Web- Mandatory
based and
a) Operate
efficiently
within the following
Web browsers – all
versions released in the
last 365 days:
 Internet Explorer
 Edge
 Mozilla Firefox
 Safari
 Chrome
b) Can handle the file
format that the system
generates
GTR-9
Open
Source
Compliance
Software The system shall be developed Preferable
using Open Source software and
components, including



Operating systems
Web Servers
DBMS
Table 5.1: General requirements
21
Database
server
Application
server
Web server
Client
DA storage /
database
DA Web
services
DA Web
application
Web browser
External
system
Client of DA
Web services
Fig 5.1. Multi-tier architecture
5.2 Functional Requirements
DA core functional requirements are depicted in the following UML Use Case Diagram:
Fig 5.2. Core DA functional requirements – UML Use Case diagram
Before performing any actions on the DA, users should be authenticated.
Additional functional requirements are given in Table 5.2.
Req. ID
Requirement
Description
Type
FR-1
General functionality
The functionality of DA system Mandatory
shall cover all use cases
22
described in 4.3 (Functional
view) and Fig. 5.2.
FR-2
Security
The system shall support both




Mandatory
Authentication
Authorization
What operations an
authenticated user is
allowed to perform
Secure access via TLS
FR-3
Granular user permissions
The system shall allow granular Mandatory
user permissions to construct
content-specific roles with
privileges. The system must also
support the creation of new
roles with custom privileges.
FR-4
Capture/Scanning/Validation
The system shall support Optional
converting information from
paper documents into an
electronic (at least: PDF/A-2,
TIFF, GIF, JPEG and PNG) format
through scanning.
The bidders shall specify
technical requirements for
scanners.
FR-5
Multiple formats
The system shall support storing Mandatory
of content in multiple formats,
including (but not limited to) the
following:







PDF
TIFF
GIF
JPEG
PNG
MS Word
OpenOffice
FR-6
Image cleanup
The system shall support Mandatory
rotation, straightening, color
adjustment,
transposition,
zoom, aligning, page separation,
annotations and despeckling.
FR-7
Content repository
Content
repository
shall Mandatory
implement
the
following
services:


Definition of content
structure (modeling)
Creation, modification,
and deletion of content,
23







FR-8
Content transformation
associated metadata,
and relationships
Query of content
Access
control
on
content (permissions)
Versioning of content
Content renditions
Locking
Events
Rules/Actions
The system shall be able to Mandatory
perform the following content
transformations:

Image to image (lossy
and
lossless
compression)
FR-9
Delivery
The system shall support Mandatory
delivery of simple document or
collection
of
documents,
including
on-the-fly
compression.
FR-10
Metadata
The system shall support




Mandatory
Metadata entry
Storing metadata for
each document
Linking
with
corresponding
document(s)
Batch metadata update
and insert
Documents that do not have all
mandatory metadata shall be
marked as non-validated. These
documents should be available
for search and retrieval only by
users
with
appropriate
privileges.
FR-11
Metadata extraction
The system should support Mandatory
automatic extracts of metadata
information from inbound
and/or
updated
content,
including MBR.
FR-12
Indexing
The system shall provide Mandatory
classification
and
indexing
through
the
documents'
metadata
24
FR-13
Searching and retrieval
The system shall support Mandatory
searching and retrieval based
on:






FR-14
Define spatial region of interest
General criteria
Targeted criteria
Metadata
QR Code
Bar Code
Enable spatial queries
involving region of
interest and documents’
MBR
The system shall enable users to Mandatory
define simple spatial region of
interest by:




Importing CSV file
Importing GML file
Defining MBR by user
input
Defining circle
FR-15
Backup and restore
The system shall support backing Mandatory
up and restoring DA content
repository
FR-16
Printing, mailing and exporting
The system shall support Mandatory
printing, mailing and exporting:





Part of a document
Part of a image
Single document
Aggregate documents
Document sets
FR-17
Monitoring
The system shall have a module Mandatory
for overall system monitoring
FR-18
Auditing
The system should provide the Mandatory
ability to audit activity, i.e. to
generate, store, and retrieve
auditing information.
FR-19
Georeferencing
The system shall manage geo- Optional
referencing of maps/imagery.
FR-20
Viewing – Map display
The system shall enable the Mandatory
viewing (map display) of georeferenced maps/imagery.
FR-21
Collaboration
The system should allow Mandatory
documents to be retrieved and
worked on by an authorized
user:
25

Access
should
be
blocked to other users
while work is being
performed
on
the
document.
Multiple users should be able to
view and modify (or markup) a
document at the same time in a
collaboration session.
FR-22
Versioning
The system should support Mandatory
versioning and support tracking
content history. Old versions of
documents should not be
deleted.
FR-23
OCR
The system shall support optical Preferable
character recognition
FR-24
QRCode and Barcode
The system shall support Mandatory
document information capture
and retrieval using QRCode and
barcode.
FR-25
Aggregate
documents, The system shall be able to Mandatory
composite documents and manage aggregate documents,
document sets
composite documents and
document sets.
FR-26
Templates
The system should allow for the Mandatory
creating and storing of content
templates, that users can then
use to quickly create content
based on a pre-determined
style.
FR-27
Multiple formats
The system shall be able to store Optional
documents in multiple formats,
if possible. For example, the
system shall be able to combine
multiple images into PDF.
FR-28
Data compression
The system shall enable both Mandatory
lossless
and
lossy
data
compression.
FR-29
Bulk importing
The system shall provide a Mandatory
mechanism for bulk importing of
already scanned documents and
corresponding metadata given
in Excel files, CSV files and XML
files.
During bulk import the system
shall compare number of
26
documents for importing with
control number of documents
contained in metadata.
The system shall be able to
update madatada through bulk
import.
Examples of data prepared for
bulk import can be obtained on
request.
FR-30
Backup and restore
The system shall be able to Mandatory
backup and restore



FR-31
Reporting and analytics
Relevant binaries
Configuration files
Repository
o Content
o Indexes
o Database
The system shall provide Mandatory
reporting
and
analytics
capabilities on:








Users
Content
Errors
Content usage per user
Retreived documents
Non-validated
documents (see FR-32)
report
about
charactersitics of a
documents
(for
example, for images:
format,
resolution,
number of colors, etc.)
etc.
FR-32
Double
validation
and The system shall enable double Mandatory
confirmation of documents and validation of documents (and
metadata
corresponding metadata) that
are imported through Bulk
importing. All metadata shall be
entered twice by distinct users.
Only confirmed documents shall
be available for searching and
retrieving by regular users. Users
with appropriate privileges
should be able to search and
retrieve
non-confirmed
documents as well.
FR-33
Metadata alphabet
Metadata can be entered in Mandatory
Cyrillic or Latin alphabet, but
before insertion into database
27
they should be converted into
Latin alphabet.
FR-34
Splitting documents
The system shall be able to split Mandatory
the documents that are already
in the DA. This is an
administrative function.
FR-35
Access to documents
There are users that are allowed Mandatory
to search the DA, but are not
allowed to see the document,
before their request for
accessing the document is not
approved. All requests to
documents should be logged. All
approvals/disapprovals should
also be logged.
FR-36
Exporting of metadata
The system shall provide a Mandatory
mechanism
for
exporting
metadata in Excel files, CSV files
and XML files – in the same
formats used for bulk import.
FR-37
Deactivation of a document
Document can be deactivated in Mandatory
a
case
of
exemption.
Deactivated documents should
not be available for search and
retrieval by standard users. Only
administrators should be able to
search and retrieve deactivated
documents.
FR-38
Quality Assurance
It should not be possible to Mandatory
insert/import documents into
DA
if
required
quality
charactersitics are not satisfied:
-
for images: format,
resolution, number of
colors, etc.
Table 5.2. DA functional requirements
It is the obligation of the contractor to perform the bulk import (FR-29) of at least one set of documents
for each of the document types listed in GTR-3.
DA should expose at least the following three services listed in Table 5.3.
Service
Functionality
Parameters
authenticate
Web service client Web
service
authentication
credentials
Result
client TRUE and access
token or FALSE
28
searchContent
Search
content/document
Part of Metadata/METS, Metadata/METS
access token
getContent
Returns
the Metadata/METS, access Content/Document
content/document token
or NULL
postContent
Posts, i.e. stores the Metadata/METS, access TRUE
content/document token
(content/document
is stored) or FALSE
recordUpdate
Record
update
content User, metadata/METS, Store metadata, user
access token
and time
Table 5.3. DA services
All inserts and updates shall be approved by administrator of the system (or by user with appropriate
role/privilege).
5.3 Non-Functional Requirements
Concurrent users and availability
NFR-CU-1
Concurrent users
The system shall provide the Mandatory
following
throughput,
i.e.
minimal number of active
concurrent users is 200.
NFR-AV-2
Availability
The system shall have 99.99% Mandatory
availability measured over any
30 day period.
NFR-RT-3
Search response time16
The system shall be able to Mandatory
response to interactive user
search requests as follows:


NFR-RT-4
Update response time
The system shall be able to Mandatory
response to interactive user
update (create, update, delete)
requests as follows:


NFR-RT-5
Log for response time
90% within 2 seconds
100% within 5 seconds
90% within 4 seconds
100% within 8 seconds
(large files excluded)
DA shall provide a log with Mandatory
response times.
Delay between a keystroke action by the user and the completion of the system operation measured
at RSGA HQ, on a standard client desktop workstation equivalent to Intel i3 processor.
16
29
NFR-SC-6
Scalability
The system shall be scalable to Mandatory
handle up to twice the currently
planned number of users.
NFR-GL-7
GUI language
The GUI shall be available in the Mandatory
official languages of B&H and
English.
NFR-CS-8
GUI character sets
The GUI shall support Latin Mandatory
alphabet.
NFR-RE-9
Responsive design
The system must be able to Mandatory
function on all devices and
display resolutions following
responsive design patterns.
NFR-RE-10
Case insensitive search
The system must be able to Mandatory
perform case insensitive search
NFR-EH-1
Errors and warnings
The error and warning messages Mandatory
shall be informative and identify
the errors completely as
possible.
NFR-EH-2
Log files
All detailed error and warning Mandatory
messages
(including
stack
traces) shall be written to the
application log files.
Errors handling
Documentation and source code
NFR-DSC-1
Software description guide
The software description guide Mandatory
shall contain the following:




Development
environment details
Tools
Third-party libraries
Details
about
environment and tools
setup for development
NFR-DSC-2
User manual
The User manual shall describe Mandatory
and illustrate all system
functionalities.
NFR-DSC-3
Help
The help resource files used for Mandatory
the Online Help functions and
tutorials shall be available for
management
and
parallel
update in the official B&H
languages.
30
NFR-DSC-4
Source code
Developed source code and all Mandatory
related customization for DA
shall be delivered to RSGA. All
software rights to the developed
source code will be transferred
to RSGA.
NFR-DSC-5
Data model – Indexing metadata The final and implemented data Mandatory
model (metadata for indexing)
should be delivered as:



UML class diagram
XML schema(s)
Object catalogue
Project implementation
NFR-PI-1
Staged implementation
The supplier shall propose a Mandatory
project plan with the following
stages:








Inception
Detailed system design
Development of pilot
system
Pilot installation and
test
Development of the
final version
Test of final version
Training
Roll-out
NFR-PI-2
Delivery plan
The supplier shall provide a Mandatory
detailed specifications and time
schedule of deliverables, which
shall be approved by RSGA after
the Inception stage.
NFR-PI-3
Project organization
The supplier shall provide a Mandatory
description of the project
organization with roles and
required competences of each
position.
NFR-PI-4
Personnel
The supplier shall provide CVs Mandatory
for experts nominated for
positions for the project.
NFR-PI-5
Reporting
The supplier shall provide for Mandatory
each implementation stage a
report with the findings and
recommendations for further
implementation.
The RSGA shall accept the
reports individually before the
31
project proceeds to the next
stage.
Systems deliverance and licenses
NFR-SDL-1
Pilot and final versions
The DA system shall be delivered Mandatory
in two versions
• Pilot version
• Final version
The specification of the Pilot
version shall be specified in
detail during the Inception stage
of the project, and accepted by
RSGA. Both versions shall be
tested and accepted (FAT and
UAT) prior to installation on the
production environment.
NFR-SDL-2
Software
subscription/maintenance
OSS Fees for all software Mandatory
subscriptions shall be included in
the bid offer of the supplier, and
shall cover a period of one year
(see GTR-5). These subscriptions
shall be paid to the software
vendor by the supplier in a onceonly payment to be made at the
time of the first implementation
of the system, and shall cover
the provision of all specified
system functionality.
RSGA shall reserve the right to
obtain software under a
separate
procedure.
Software subscriptions
and customized solution should
not impose any constraints,
including number of users.
Installation and testing
NFR-IT-1
Installation
The software shall be installed Mandatory
by the supplier at the premises
of the RSGA, under the
supervision of the RSGA staff.
NFR-IT-2
Testing
There should be three stages of Mandatory
the software testing and
acceptance:



FAT
UT
UAT
32
NFR-IT-3
Test plan
The supplier shall deliver a test Mandatory
plan of all tests to be included in
the FAT. This plan shall follow
IEEE 829-2008 guidelines. The
test plan shall contain


NFR-IT-4
Test scenario
Test scenarios
Detailed test cases
The supplier shall prepare a list Mandatory
of test scenarios, which shall
contain a short description of
real use cases or workflows to be
tested.
The list of scenarios shall be
approved by RSGA.
NFR-IT-5
Test and training environment
The supplier shall develop Mandatory
testing,
training
and
development
environments,
separated from the production
system.
NFR-IT-6
FAT
The supplier shall perform FAT Mandatory
on all test cases.
The FAT shall be documented
and accepted by the RSGA prior
to the installation at RSGA.
NFR-IT-7
User test
After installation, an UT shall be Mandatory
performed at RSGA and at least
one office or Internet user
outside
RSGA.
UT
and
acceptance shall be done after
the training is completed for the
relevant RSGA staff.
NFR-IT-8
Error corrections
Based on the user testing the Mandatory
supplier shall correct the
software and install a new
version of the software. The user
tests shall continue until all
errors are removed.
NFR-IT-9
UAT
When all errors are removed, Mandatory
the supplier shall participate in
the UAT. The UAT shall take
place no more than one week
after UT has been completed.
The UAT shall be executed at the
premises of RSGA.
Training
33
NFR-TR-1
Training materials
The training shall include the Mandatory
preparation of all training
materials (including printed
materials) and handouts. All
training materials shall be
available in the official B&H
languages. Part of the system
documentation can be prepared
in English only.
NFR-TR-2
Involve RSGA staff
The supplier shall involve RSGA Mandatory
staff
when
developing
administration
and
user
manuals.
NFR-TR-3
Language and content
The training shall be delivered in Mandatory
any of B&H languages and
involve



NFR-TR-4
Knowledge transfer package
Presentations
Practical exercise using
the system
Discussions
The supplier is obliged to deliver Mandatory
a knowledge transfer package
that includes training for
software
development for
necessary customization.
Warranty and support
NFR-WS-1
Warranty and Maintenance
The supplier shall provide a Mandatory
comprehensive warranty and
maintenance for one year. The
warranty and maintenance shall
cover
all
software
and
customized applications that are
delivered as part of the software
solution.
The warranty and maintenance
period shall begin once UAT as
well as Training is completed and
approved by RSGA.
NFR-WS-2
Error handling
During
the
installation, Mandatory
acceptance and warranty period
the supplier shall provide
corrective services.
The supplier shall present a
proposal for error reporting and
corrective services, including
response times. The maximum
response times are as follows:
34
NFR-WS-3
Support
The support during the warranty Mandatory
shall be implemented via a
three-level support:



NFR-WS-4
1st level support: 1h
2nd level support: 1 day
3rd level support: 7 days
Maintenance
1st level support by a
super-user who can give
rapid help to the users
experiencing a problem
with the system.
2nd level support by an
analyst who can analyze
problems that cannot be
solved
by
the
experienced user, or
analyze the need for
improved functionality
in depth, and prepare
related specifications
for subsequent changes
to the source code.
3rd level support by a
developer who can
make changes to the
source code related to
removing
errors,
including
new
functionality.
The supplier is obliged - if Mandatory
requested by RSGA – to enter
into a maintenance contract
after the warranty period has
expired.
Economic requirements
NFR-ER-1
Price offer
The price offer shall be Mandatory
submitted in the BoQ and signed
by an authorized representative
of the bidder.
NFR-ER-2
Support and maintenance
Yearly cost for software Mandatory
subscriptions, support and
maintenance shall be specified
by the supplier in the BoQ.
Table 5.4. Non-functional requirements
35
36
6 APPENDICES
6.1 References
[1]
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description
[2]
Rozansky, N. and Woods E., Software Systems Architecture: Working With Stakeholders
Using Viewpoints and Perspectives, Addison-Wesley, 2011
[3]
Object Management Group, UML, http://www.uml.org
[4]
2014
Oskar Henriksen AS, Federal Administration for Geodetic and Real Property Affairs - ICT Strategy,
[5]
Oskar Henriksen AS, Republic Administration for Geodetic and Real Property Affairs of Republic
Srpska - ICT Strategy, 2014
[6]
Republic Authority for Geodetic and Real Property Affairs: Digital Archive Strategy, 2014
[7]
The Consultative Committee for Space Data Systems, Reference Model for an Archival
Information System (OAIS), 2012
[8]
The Open Group Architecture Framework (TOGAF), http://www.opengroup.org/togaf/
[9]
The Open Group, TOGAF Version 9.1, Van Haren Publishing, 2013
[10]
Weske, M. Business Process Management: Concepts, Langauges and Architectures,
Springer, 2012
37
6.2 Definitions
Abstraction
The technique of providing summarized or generalized descriptions of detailed and complex content.
Abstraction, as in "level of abstraction", can also mean providing a focus for analysis that is concerned
with a consistent and common level of detail or abstraction. Abstraction in this sense is typically used in
architecture to allow a consistent level of definition and understanding to be achieved in each area of the
architecture in order to support effective communication and decision-making. It is especially useful
when dealing with large and complex architectures as it allows relevant issues to be identified before
further detail is attempted.
Actor
A person, organization, or system that has a role that initiates or interacts with activities. Actors may be
internal or external to an organization.
Application
A deployed and operational IT system that supports business functions and services; for example, a
payroll. Applications use data and are supported by multiple technology components but are distinct
from the technology components that support the application.
Architecture
A formal description of a system, or a detailed plan of the system at component level, to guide its
implementation. Architecture is created solely to meet stakeholders needs.
Architecture element
Fundamental piece from which a system will be constructed.
Concerns
The key interests that are crucially important to the stakeholders in a system, and determine the
acceptability of the system. Concerns may pertain to any aspect of the system's functioning,
development, or operation, including considerations such as performance, reliability, security,
distribution, and evolvability.
Dynamic structure
Defines run-time elements of software system and their interactions.
Stakeholder
An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the
outcome of the architecture. Different stakeholders with different roles will have different concerns.
Static structure
Defines internal design-time elements of software system and their arrangement.
System
A collection of components organized to accomplish a specific function or set of functions.
System stakeholder
An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.
UML Class Diagram
Static structure diagram that describes the structure of a system – system’s classes, their metadata,
operations and the relationships among objects.
UML Use Case Diagram
Representation of a user's interaction with the system.
38
User
Any person, organization, or functional unit that uses the services of an information processing system.
View
The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture
view may be represented by a model to demonstrate to stakeholders their areas of interest in the
architecture.
Viewpoint
A definition of the perspective from which a view is taken. It is a specification of the conventions for
constructing and using a view (often by means of an appropriate schema or template).
Workflow
Automation of business process, in whole or part, during which documents, information, or tasks are
passed from one participant to another for action, according to a set of procedural rules.
System workflow
A system workflow consists of activities that are implemented by software systems without any user
involvement.
Human interaction workflow
A human interaction workflow is a workflow in which humans are actively involved and interacts with
information systems.
Workflow management system
A software system that defines, creates, and manages the execution of workflows through the use of
software, running on one or more workflow engines, which is able to interpret the process definition,
interact with workflow participants, and, where required, invoke the use of IT tools and applications.
39
6.3 List of Acronyms
AIP
Archival Information Package
API
Application Programming Interface
ATA
Advanced Technology Attachment
BoQ
Bill of Quantity
BPMN Business Process Model Notation
COTS
Commercial Off-The-Shelf
CPU
Central Processing Unit
CSV
Comma Separated Values
DA
Digital Archive
DBMS Database Management System
DIP
Dissemination Information Package
DMZ
Demilitarized Zone
EA
Enterprise Architecture
ECM
Enterprise Content Management
ESB
Enterprise Service Bus
FAT
Factory Acceptance Test
RS
Republic of Srpska
RSGA
Republic of Srpska Republic Administration for Geodetic and Property Affairs
FTP
File Transfer Protocol
GA
Geodetic Administration
GB
Gigabyte
GML
Geography Markup Language
GUI
Graphical User Interface
HDD
Hard Disk Drive
HQ
Headquarter
HW
Hardware
JICA
Japan International Coopertion Agency
JCR
Content Repository API for Java
ICT
Information and Communication Technology
IT
Information Technology
IS
Information System
LARIS
Land Registry Information System
LDAP
Lightweight Directory Access Protocol
LGPL
(GNU) Lesser General Public License
MBR
Minimum Bouding Rectangle
METS Metadata Encoding and Transmision Standard
40
MS
Microsoft Corporation
OCR
Optical Character Recognition
OIAS
Open Archival Information System
OSS
Open Source Software
PDF
Portable Document Format
QA
Quality Assurance
QC
Quality Control
RAM
Random Access Memory
RPM
Revolution Per Minute
RINEX Receiver Independent Exchange Format
SATA
Serial ATA
SIP
Submission Information Package
SOA
Service Oriented Architecture
SSD
Solid-State Drive
SSO
Single Sign-On
TB
Terabyte
TIFF
Tagged Image File Format
UAT
User Acceptance Test
UML
Unified Modeling Language
URS
User Requirements Specifications
Wf
Workflow
XML
Extensible Markup Language
41