On Designing a Content Management System for the Documents Related

to Past Civil Engineering Projects or Call-for-Tender Responses

Christian Esposito

1 a

and Oscar Tamburis

2 b

Department of Electrical Engineering and Information Technology (DIETI), University of Naples “Federico II”,

via Claudio 21, 80125 Napoli, Italy

Department of Veterinary Medicine and Animal Production (DMVPA), University of Naples “Federico II”,

Via Federico Delpino 1, 80137 Napoli, Italy

Keywords:

Content Management System, Data Storage & Retrieval, Civil Engineering Industrial Practice, Access

Control.

Abstract:

The progressive dematerialization of paper-based documents in favour of digital ones held within servers, and

processed/exchanged by means of the ICT technologies have massively revolutionized several aspects of our

daily lives and industrial practice. The large volume of data handled by the companies has an undeniable value

for their business and must be exploited so as to strengthen their competitiveness. In certain domains, such as

the healthcare or manufacturing, this is nowadays an accepted practice within the context of Big data Analytics,

but in other domains this is not the reality. As an example, we can see the case of the civil engineering

companies, where a large volume of digital documents on past projects or response to public/private tender

procedures are stored, but not efﬁciently used. The main obstacle for the effective use of such data is related to

their storage approach, which is mainly considered as an archive rather than the company’s knowledge to be

inferred and effectively used in the business. The driving idea of this paper is to devise a content management

system within the context of civil engineering to pave the way for a better use of the data held by such a kind

of companies.

1 INTRODUCTION

The current industrial practice encompasses

computer-based communications and the production,

processing or exchange of digital documents. This

is the foundation of our digital society and the

current fourth industrial revolution, where ICTs and

computers play the main role in our daily activity and

business. Such a revolution reached also the civil en-

gineering, where at the beginning we have witnessed

the proliferation of Computer-Aided Drafting (CAD)

tools (Luzadder, 1992) able to substitute manual

with electronic drafting when designing building,

maintenance system or interior design. The next step

has been represented by the arrival of the Building

Information Modeling, or BIM (Eastman et al.,

2018), which targets the creation and management

of digital representations of artefacts and support the

plan, design, construction, and maintenance of di-

verse physical infrastructures. By its deﬁnition, such

https://orcid.org/0000-0002-0085-0748

https://orcid.org/0000-0002-0130-7915

a standard provides architects and civil engineers

with a shared knowledge resource for information

about any kind of facilities, thus forming a reliable

basis for decisions during its life-cycle. At the

moment, another revolution in Europe is undergo-

ing with the EU Directive 2014/24/EU on public

procurement (EUR-Lex, 2014), and the relative

regulation issued by the State Members, as of the

adoption of digital representations in open formats,

like BIM, for the design of civil infrastructure and the

submission of responses to call-for-tenders by means

of certiﬁed emails. This is considerably boosting the

dematerialization of all civil engineering documents

for public procurement and augmenting the volume

of digital data held by such a kind of companies.

When a call-for-tender is issued by a public au-

thority, the time left for writing a response is ex-

tremely limited. Starting by scratch likely means

starting to be ineffective, when it must instead be

viable to leverage on the past experience so that to

quickly draft the response, and to pay all the avail-

able efforts to reﬁne such a draft. Currently, despite

the past documents are stored by the companies, all

650

Esposito, C. and Tamburis, O.

On Designing a Content Management System for the Documents Related to Past Civil Engineering Projects or Call-for-Tender Responses.

DOI: 10.5220/0007750906500657

In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019), pages 650-657

ISBN: 978-989-758-372-8

the lesson learned from past projects and responses

to call are not inferred from these documents, but

by interacting with the senior employees of the com-

pany. Leaving the company knowledge within the se-

nior employees is not a winning choice, as they may

be unavailable due to possible diseases, or have left

the company for retirement or new job offers. The

best solution should be to take advantage of the digi-

tal documents within the company archives and infers

the lessons learnt from them. However, currently this

is not possible as many storage approaches have not

been designed for retrieval but only for conversation

and historical reasons. Moreover, such documents are

not kept at a main server of the company or within the

cloud, but at the terminal of each employee so that

their existence is not well known by the rest of the

company and their accessibility is not guaranteed.

The driving idea of this work is to design and im-

plement a proper data management solution so that

all the documents produced during the company life-

cycle are centrally stored and accessible by all the em-

ployees of a civil engineering company. To this aim

we have implemented a series of RESTful Web Ser-

vices (Richardson and Ruby, 2007), so that the ex-

plicit use of the HTTP methods can be used to imple-

ment the ”create, read, update, and delete” (CRUD)

operations for the digital documents for past civil

engineering projects or tender responses. We have

found, as described in Section 2 that the best strategy

for the storage of such a kind of data set is a Con-

tent Management System (CMS) as Alfresco, on top

of which we have built our system, whose design and

implementation is detailed in Section 3. Such a work

represents only a starting point of our research, and

it does not have the ambition to resolve all the chal-

lenging imposed by our vision. Section 4 describes

our vision on the future research efforts needed to be

spent in order to cover all the demands of the modern

civil engineering companies. Section 5 concludes our

paper with the sum up on our research conducted so

far.

2 BACKGROUND AND RELATED

WORK

In their practice to respond to call-for-tender issues by

public administrations, employees at civil engineer-

ing companies needs to collect a precise set of doc-

uments describing the call of interest and to produce

another set of documents to respond to the tender it-

self. The ﬁrst set describes the demands of the tender

issuer, and the second one is required to participate in

the selection to win the tender. The time needed to

write the documents in the second set is very limited,

and the related efforts can be considerable as many

details need to be considered so as to set up a suc-

cessful response and design. Such documents can be-

long to one of the following groups. The ﬁrst doc-

uments contain the administrative description of the

company, its technical and managerial characteristics,

and a statement of satisfaction of the requirements in

the call. Mainly, the content of these documents is

always invariable despite of a speciﬁc call, so the ef-

fort to write them are very negligible by having sim-

ilar documents produced for past calls. The second

group contains the technical response to the call with

the design of a building, a maintenance plan or the fa-

cility management solution. The last group of docu-

ments are related to the economic-ﬁnancial offer, and

the scheduling of the needed work to implement the

envisioned design. Such documents are particularly

demanding in terms of knowledge to collect, time for

their ﬁnalization or efforts to check their correctness.

Starting by scratch to approach them is not viable

and it should be possible to re-use past similar doc-

uments, according to a similar approach put in place

for the re-use within the context of software engineer-

ing (Land et al., 2009). Not all the documents share

the same format and structure, but the ones within the

ﬁrst and third groups are mainly produced by using

Microsoft Ofﬁce (Word is used to write DOCX doc-

uments for the administrative part, and Excel used

for datasheets containing the economic offer). Such

ﬁles can be archived as they are or in PDF or PNG

after being printed, signed and scanned. The doc-

uments for the technical part of the tender response

are made of digital representations of a given design

produced by a CAD tool, which can have a binary

encoding (each tool adopts a given format), a struc-

tured format derived from XML and so on. To this

end, a concrete example is provided by the DXF and

DWG formats (C¸ etiner, 2010) of ﬁles saved with AU-

TOCAD or the Initial Graphics Exchange Speciﬁca-

tion (IGES) (Liewald, 1985) for the interoperability

among the available CAD tools. Image formats as

PNG or JPG or a vector graphics format such a HPGL

Plotter File (PLT) (Grabowski, 1999) with the render-

ing of a given design can be used as well. The BIM

standard has also its own format to represent the dig-

ital artefacts of a design, called Industry Foundation

Classes (IFC) (Venugopal et al., 2012).

Traditionally, such an heterogeneous set of ﬁles

and digital documents are stored in folders within the

ﬁle systems of their terminals and/or servers, with a

ﬂat organization where each folder contains all the

documentation for a given project/tender response, or

a deep organization where the folders have a hierar-

On Designing a Content Management System for the Documents Related to Past Civil Engineering Projects or Call-for-Tender Responses

651

chical structure (for example a ﬁrst level divided in

years, a second one in classes of project/tender re-

sponses, and a third one distinguishing among won

and lost applications). This is a naive solution whose

main advantage is to be very simple to deﬁne, even

by operators within a computer science major. The

main drawback, on the other side, is related to the

difﬁculties when a speciﬁc document needs to be re-

trieved, as it demands to traverse the overall structure,

open each ﬁle and check if its content matches the

terms of interest. Moreover, all the data of interest

for a given project or tender response initiative are

not only contained in the produced documents, but

also in a set of contextual information and meta-data

within the employees’ notes and discussions. These

meta-data cannot be stored by using such a solution,

but on the contrary they can be easily kept within a

relational database. Such a solution is associated with

a well-structured and expressing query language that

helps to retrieve the data of interest by using a pre-

cise query expression, which requires operators hav-

ing a solid background in computer science. Within

the tables and tuples, the meta-data can ﬁnd place,

but relational database are not suitable when dealing

with ﬁles, unless each tuple contains a pointer (such

as the ﬁle absolute path within the ﬁle system) to the

ﬁle related to the meta-data contained in such a tu-

ple. This requires the user to be aware to keep such a

pointer consistent in case of ﬁle movements. A Con-

tent Management System, on the contrary, represents

a hybrid solution among the previous ones: as the ﬁrst

approach, ﬁles are contained within hierarchy of fold-

ers managed by the ﬁle system; while as the second

one a relational database with meta-data per each ﬁle

is deﬁned. The CMS products keeps the two sides of

the systems consistent so that by querying the meta-

data it becomes possible to retrieve the ﬁles of inter-

est. In our envisioned system, we have used a CMS

product named Alfresco (Shariff et al., 2009), and on

top of it we have designed and implemented our solu-

tion.

3 PROPOSED SOLUTION

Figure 1 depicts the overall architecture of the envi-

sioned system, where we have the ﬁle system with the

documents of the company, and the database holding

the relative meta-data. The Alfresco solution is pro-

vided as a war ﬁle executed by the web container rep-

resented by Apache Tomcat. Such a product provides

a management and user console represented by the

share.war, so that all the functionalities of the prod-

uct can be directly invoked by authorized administra-

Figure 1: High-level architecture of the proposed system.

tors and users, while we have the DocMan.war imple-

menting all the operations of our system (such as the

CRUD operations for the kind of documents managed

by the system), exposing a RESTful web services im-

plemented within the .NET framework, and providing

a set of web pages as GUI for the web clients. More

details on key aspects of our system are provided in

the following subsections.

3.1 Alfresco Data Modelling

The user is not able to directly manipulate ﬁles and tu-

ples in Alfresco, respectively within the repository in

the ﬁle system or the tables of the relational database,

but these aspects are abstracted by proper modelling

the data of interest in types. More speciﬁcally, the

data managed by Alfresco are represented in terms of

nodes and links among them. A node can be any-

thing, such as an image, a fragment of XML, and so

on. A node can contain a set of other nodes, and in

this case, we represent a folder. Each node exhibits

a unique identiﬁer and a set of properties, each char-

acterized by a name and a value. The containment is

not the only relationship among nodes: the other ones

are the speciﬁcation (i.e., a child node inherits all the

property deﬁnitions of the father node in addition to

its speciﬁc ones) and the association (i.e., a node is se-

mantically related to another one and holds properties

with the identiﬁer or the associated node, similarly to

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

652

Figure 2: Repository structure.

a foreign key among tuples in a relational database).

The property deﬁnition is done by assigning a type

to a node, in a similar way of classes on the Object-

Oriented programming languages. Alfresco provides

a set of predeﬁned node types, but the user is able to

customize them by deﬁned new types as well.

In our system, we have identiﬁed two types of

nodes: the documents describing the call-for-tender

and their annexes, and the documents related to the

tender response and/or project. To this aim we have

structured the repository in ﬁve folders, as depicted in

Figure 2:

• The folder holding the documents describing the

calls;

• The ﬁrst part of the response documents with the

administrative details of the company;

• The second part of the response documents with

the technical design of the project;

• The third part of the response documents with the

economic and ﬁnancial offer;

• All the feedback received for the submitted re-

sponses requested by the company.

Within each folder, a series of documents can be

stored, each exhibiting a different type such as Mi-

crosoft ofﬁce documents, PDF or IFC, all modelled

as a Document with a unique identiﬁer, a path (i.e.,

the pointer of the ﬁle within the ﬁle system), and its

byte content. We have envisioned two types in Al-

fresco: one for the documents of the calls, and one

for the documents of the responses. The ﬁrst one has

the following properties:

• CIG – represents the identiﬁcation code of the call

as a string, and allows to trace the call within the

Italian public administration.

• CUG – represents the identiﬁcation code of the

public procurement as a string.

• Identiﬁer – speciﬁes an internal identiﬁcation

code for the company as a string.

• Contracting Entity – speciﬁes which entity of

the public administration has issued the call-for-

tender.

• Text – contains a brief description of the call.

• Type – is an enumeration of the speciﬁc type of

the call, such as building a new facility, maintain

an existing one and so on.

• Publication Year.

• Expiration Date.

• Place – indicates where (in Italy) the project

should take place.

• Inspection Needed – is a ﬂag whose true value

indicates that an inspection of the work area is

needed before submitting the response.

• State – is the state of the call and is an enumera-

tion with elements such as Open, Close or Forth-

coming.

The second type has the following properties:

• Identiﬁer – represents a local identiﬁer of the doc-

ument within the company.

• Object – is a string summarizing the content of the

document.

• Support – characterizes the type of document as

an enumeration containing DOC, PDF, IFC, Im-

age, Binary, and so on so that all the possible for-

mats of the ﬁles are represented.

• Class – is another enumeration for the speciﬁc

role of the document within the response and

project, such as Administrative, Technical, Finan-

cial, Call Description and Feedback.

These two types are designed based on the Docu-

ment type offered by Alfresco, and share with it the

two properties of Creator, indicating the user that

has created the document in Alfresco, and Creation

Date. Moreover, some documents may be related

to a response that has been evaluated and for which

we know whether the response has been successful

or not. In this case, we have modelled such addi-

tional properties of an assessed document as an as-

pect, which is a type with properties to enhance exist-

ing content types. Our aspect is named Assessed and

features the following properties:

• Assessor - represents the identiﬁer of the person

who made the evaluation or the entity in the public

administration that has made it.

• Assessment - represents the received mark as a

number or a letter.

• Positive Aspects - indicates what has been evalu-

ated as positive within the document.

On Designing a Content Management System for the Documents Related to Past Civil Engineering Projects or Call-for-Tender Responses

653

• Negative Aspects - indicates what has been evalu-

ated as negative within the document.

• Distance from the Winner - represents how far the

received rank is with respect to the one obtained

by the winning response (this is 0 if the speciﬁc

response was the successful one).

• Won - a Boolean value indicating if this document

belongs to a response that has obtained the tender.

3.2 RESTful API of DocMan.war and

its Interconnection with Alfresco

The API we offer contains a series of functionalities

to create, modify and infer ﬁles and their meta-data

according to the previous modelling:

• Loading new ﬁles, within the repository and set-

ting their properties based on the above model.

• Change the values given to the properties for a

document that exists within the repository.

• Removal of one or more documents from the

repository, uniquely identiﬁed by means of an id

or belonging to a speciﬁc call-for-tender.

• Search for one or more documents. The search

methods can be of two types:

– Free search, where a search string is passed to

the engine, so as to give the users the freedom

to express their own search criteria, but requir-

ing them to have an ICT background. There-

fore, this operation will be offered only to ad-

ministrators or IT technicians in service at the

company.

– Pre-coded searches, meaning a series of meth-

ods for which the search strings are already

coded within the engine. The users can easily

recall them by selecting the value of the search

parameters. Examples can be:

∗ Return documents of a speciﬁc type (admin-

istrative, technical or other) for a given set of

calls;

∗ Return the winning responses in a given time

period, that is an adjacent set of years;

∗ Return the winning responses for a certain

type (design of buildings, maintenance or

other);

∗ Return documents for which the object meets

a certain regular expression if applied to its

content;

∗ Return call-for-tenders for one or more spe-

ciﬁc contracting authorities.

Each of these functionalities is offered by means of

an HTTP method, such as the POST method (used to

create a new instance of the Call type or the Document

type), and the GET method (used to obtain a node

with a given identiﬁer), and so on.

The interaction between Alfresco and our soft-

ware can occur by means of Alfresco’s API, but we

have preferred to use the standard interface offered

by the Content Management Interoperability Services

(CMIS) (OASIS, 2015), which is a standard for the

interoperability with CMS, so that if we decide in

the future to substitute Alfresco with another similar

product we do not have to make any changes to

our system. CMIS deﬁnes in fact an abstraction

layer for controlling diverse document management

systems and repositories using web protocols, such

as REST, AtomPub and so on, which any product

like Alfresco implements. CMIS provides a query

language whose syntax is based on SQL-92, with

its clauses such as SELECT, FROM, JOIN and

so on. When the user needs to express a query

string for the free search, they must be compliant

to the CMIS Query Language. For example, to

have all the documents in the folder Part A the

command should be: SELE CT ∗ FROMcmis :

f older W HERE IN FOLDER(

Part A

). Within

our work, we have used a library so as to in-

teract with Alfresco by means of CMIS, called

Apache Chemistry (speciﬁcally its distribution

for .NET named DotCMIS), where the bind-

ing endpoint for the Alfresco repository was

http://localhost:8080/open/service/CMIS.

3.3 Security Aspects

The interactions of the user with the RESTful web

services of our solution needs to be protected. One

level of protection is to implement an authentication

and authorization mechanism so that only legitimate

users can invoke the operations of our system. Within

the context of the web services, the WS-Security stan-

dard (Atkinson, B. et al., 2002) indicates the mecha-

nisms to be used in such a case. Speciﬁcally, we have

preferred to use JSON Web Token (JWT) (Jones et al.,

2015) given its simplicity and stateless nature. The

users provide its credential as username and password

to the server, which checks if they are present in its

identity storage and returns a token in case of success.

The adopted model is, therefore, the Access Control

List (ACL) (Barkley, 1997), where we can ﬁnd which

users are granted access to objects/functionalities of

the system. It is possible to have a more complex

model, even by integrating JWT within the context

of the eXtensible Access Control Markup Language

(XACML) (OASIS, 2017) and its architecture with

the standardized authorization ﬂow. Later on, when

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

654

Figure 3: Client-Server interactions with JWT.

requesting a HTTP method, the token is inserted in

the SOAP header of the request. The server grants

the access to the incoming requests with valid tokens.

Figure 3 shows such interaction. To this aim, we have

extended the architecture in Figure 1 by adding an ad-

ditional war hosting the functionalities of managing

the identities, requesting token by giving a valid cou-

ple of username and password, checking the validity

of a given token, revoke the grant for a given user. It

is evident that all our services strongly interact with

such an additional set of RESTful web services so as

to decide to grant or deny a received request.

3.4 Prototype

We have implemented our solution within the context

of the .NET framework, and run a set of unit tests

to verify the correct behaviour of the invoked oper-

ations by using the GUI offered by the share.war of

the Alfresco product. Figure 4a shows the realized

web pages as GUI of our implemented web services,

and Figure 4b shows the form for the insertion of a

new document ﬁlled with some testing text. Figure 4c

shows that the new document is eventually available

within the repository managed by Alfresco.

4 FUTURE RESEARCH

DIRECTIONS

The proposed system is just the starting point for fur-

ther speculations and research on the addressed topic.

Several open challenges are still open, among which

the most interesting one is how to improve the search

expressiveness. Speciﬁcally, CMIS and Alfresco sup-

port a SQL-like query language, consisting in SQL-92

SELECT statements. This exhibits a twofold draw-

back. On the one hand, operators are required to

have a background on databases and SQL, which is

not always the case as in civil engineering compa-

nies it is more reasonable to have users not skilled

(a) Implemented GUI for the implemented RESTful web

services.

(b) Example of the use of the prototype to insert a new

document.

Figure 4: Prototype testing (local GUI in Italian).

on computer science basic concepts. On the other

hand, the expressiveness of the query is limited as it

is performed on the term-matching. In the WHERE

clause, the user indicates some terms upon which the

search must be done. Such a query term must be

found in the meta-data of the documents in order to

have such documents returned by the query. Slight

changes (such as the query term expressed in its sin-

gular form, while some documents have it as plu-

ral) imply a lower number of documents being re-

trieved. Moreover, semantic-based queries may be

needed as various synonymous can be used within

the documents that we want to be returned as a re-

On Designing a Content Management System for the Documents Related to Past Civil Engineering Projects or Call-for-Tender Responses

655

sult of a query. To this aim more advanced solutions

need to be coupled with Alfresco, without recurring

to ontologies and their supporting framework, as their

effectiveness is questionable and their usability has

a huge learning trend (Dur

an-Mu

noz and Bautista-

Zambrana, 2017; Schulz et al., 2009).

Another aspect worth deepening may be how to

transfer such a system within the cloud, so that it

becomes accessible even in case of companies that

have multiple premises spanning around the world.

However, a change like that implies that the sensi-

tive company data may be stored outside the secu-

rity domain and control of the company, thus vulner-

able to possible leakage and misuses. To this aim,

it is crucial to protect its conﬁdentiality and integrity

by means of proper cryptographic primitives (Singh

et al., 2016), without having to pay the cost of a re-

duced processing and retrieval capacity offered by the

system (Fu et al., 2016). Moreover, our security only

means allowing the management of the authentication

and authorization when interacting with the system,

but other security-related issues, such as protecting

the SOAP messages exchanging, detecting a possible

misbehaviour and managing the trust degree of the in-

teracting users, are not minor concerns and need to be

properly investigated. Last, JWT applies a very sim-

ple access control model, while more advanced and

dynamic models are available in the literature, such

as in (Esposito, 2018) and may be integrated within

the solution by extending what provided by JWT. This

may allow to achieve a more ﬁne-grained control over

the access requests and to implement more resilient

solutions when companies encompasses multiple con-

sultants on speciﬁc projects.

5 CONCLUSIONS

The present work intended to provide some insights

as to the challenging and novel issue of storing and

managing all the documents that a civil engineering

company may produce in its life time when partic-

ipating to a project and/or responding to a call-for-

tender issues by a public administration. Our starting

point was represented by a content management sys-

tem tailored to this application domain built on top of

Alfresco, by implementing a set of RESTful web ser-

vices within the .NET framework. We have indicated

the possible research direction on improving the eas-

iness and expressiveness of the query language and

dealing with the key security demands in the system,

especially in the case of its cloudiﬁcation. We be-

lieve that similar issues arise in other domains, from

the healthcare to the manufacturing industry, where

unstructured documents must be stored and queried.

Apart from the details of the properties described in

Section 3 and the repository structure in Figure 2, all

the design and relative implementation can be easily

adapter for other domains.

ACKNOWLEDGMENT

The described work has been partially supported by

the PROBIM research project, funded by the Italian

Ministry of Economic Development within the con-

text of Horizon 2020 - PON I&C 2014-20.

REFERENCES

Atkinson, B. et al. (2002). Web services security

(ws-security). speciﬁcation. In Available at

https://www.it.iitb.ac.in/∼madhumita/research topics/

authentication/WS%20Security.pdf.

Barkley, J. (1997). Comparing simple role based access

control models and access control lists. In Proceed-

ings of the second ACM workshop on Role-based ac-

cess control.

C¸ etiner, O. (2010). A review of building information model-

ing tools from an architectural design perspective. in:

Handbook of research on building information model-

ing and construction informatics: Concepts and tech-

nologies. In IGI Global.

Dur

an-Mu

noz, I. and Bautista-Zambrana, M. R. (2017).

Applying ontologies to terminology: Advantages and

disadvantages. In HERMES-Journal of Language and

Communication in Business, 26(51):65-77.

Eastman, C., Teicholz, P., Sacks, R., and Liston, K. (2018).

Bim handbook - a guide to building information mod-

eling for owners, managers, designers, engineers and

contractors. In John Wiley & Sons Inc, 3rd edition.

Esposito, C. (2018). Interoperable, dynamic and privacy-

preserving access control for cloud data storage when

integrating heterogeneous organizations. In Journal of

Network and Computer Applications, 108: 124-136.

EUR-Lex (2014). Directive 2014/24/eu of the euro-

pean parliament and of the council of 26 febru-

ary 2014 on public procurement and repealing di-

rective 2004/18/ec text with eea relevance. In D.

Available on line at https://eur-lex.europa.eu/legal-

content/EN/TXT/?uri=celex%3A32014L0024.

Fu, Z., Ren, K., Shu, J., Sun, X., and Huang, F. (2016). En-

abling personalized search over encrypted outsourced

data with efﬁciency improvement. IEEE Transactions

on Parallel and Distributed Systems, 27(9):2546–

2559.

Grabowski, R. (1999). Hpgl overview. In Available at

cstep.luberth.com.

Jones, M., Bradley, J., and Sakimura, N. (2015). Json

web token (jwt). no. rfc 7519. In Available at

https://jwt.io/.

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

656

Land, R., Sundmark, D., L

uders, F., Krasteva, I., and Cau-

sevic, A. (2009). Reuse with software components-a

survey of industrial state of practice. In International

Conference on Software Reuse, 150-159.

Liewald, M. H. (1985). Initial graphics exchange speciﬁca-

tion: successes and evolution. In Computers & graph-

ics 9.1.

Luzadder, W. J. (1992). Introduction to engineering draw-

ing: The foundations of engineering design and com-

puter aided drafting. In Prentice Hall PTR.

OASIS (2015). Content management interoperabil-

ity services (cmis) - version 1.1. In Available

at http://docs.oasis-open.org/cmis/CMIS/v1.1/CMIS-

v1.1.html.

OASIS (2017). extensible access control markup

language (xacml) v3.0 approved as an oasis

standard. In Available at https://www.oasis-

open.org/committees/xacml/.

Richardson, L. and Ruby, S. (2007). Restful web services.

In O’Reilly Media.

Schulz, S., Stenzhorn, H., Boeker, M., and Smith, B.

(2009). Strengths and limitations of formal ontolo-

gies in the biomedical domain. In Revista electronica

de comunicacao, informacao & inovacao em saude:

RECIIS, 3(1):31.

Shariff, M., Bhandari, A., and V. Choudhary, P. M. (2009).

Alfresco 3 enterprise content management implemen-

tation. In Packt Publishing.

Singh, S., Jeong, Y.-S., and Park, J. H. (2016). A survey

on cloud computing security: Issues, threats, and so-

lutions. Journal of Network and Computer Applica-

tions, 75:200 – 222.

Venugopal, M., Eastman, C., Sacks, R., and Teizer, J.

(2012). Semantics of model views for information ex-

changes using the industry foundation class schema.

In Advanced Engineering Informatics, 26(2).

On Designing a Content Management System for the Documents Related to Past Civil Engineering Projects or Call-for-Tender Responses

657