The architecture of the PCFA is modular, as can be seen in Fig. 5. Each module consists of both the client and the server side, which gives the developers freedom in what their module can do, making the application extensible. All the modules are based on a module template, which contains the code for user and context management as well as for quad store access, so that the developer can focus on the added functionality. The modules use a shared relational database, which contains user information, user preferences and stored ﬁles, and can be used for caching of results of more complex SPARQL queries for faster response time when, for example, paging through a longer list of results. The public procurement data itself is stored in two instances of a quad store. The public quad store contains published data accessible to everyone (part of the LOD cloud). The private quad store contains unpublished data for each user of the application and for application management.
Fig. 5. PCFA architecture
The current implementation consists of the following modules. The system manager module handles registrations, logging in and out, and user preferences management. The ﬁling module implements the lifecycles of calls for tenders, tenders and invitations to tenders. The matchmaking module implements the functionality behind the search for similar calls for tenders and suitable suppliers for contracting authorities (buyers) and suitable open calls for tenders for suppliers. Finally, the conﬁgurations module allows the users to specify a more detailed conﬁguration for individual types of public procurement (cars, IT, etc.). There are two separate quad stores used in the application. There is a private space for each user, where unpublished calls for tenders, tenders themselves and invitations for suppliers to submit a tender to a call are kept. This quad store is not accessible from the internet and is managed solely by the PCFA, which makes the private data secure. Additionally, there is the public space quad store, as part of the LOD cloud, where all the published information is kept and where also the calls for tenders to be compared by the matchmaker reside. This quad store is accessible to everyone on the internet for querying and downloading.
Matchmaking Functionality Internals
The core operation upon which others are based is the discovery of contracts similar to a given contract. To accomplish that, we ﬁrst ﬁlter all contracts based on the similarity of CPV codes according to the hierarchical tree.
Then we reﬁne these results by applying additional comparers, specialized, e.g., in:
1. Tender deadlines: the shorter the interval between the two tender deadlines, the higher the similarity
2. Publication dates: the shorter the interval between the two public contract publication dates, the higher the similarity
3. Geographical distance: we measure the distance between the places where the public contracts were (or are to be) executed. For this purpose, the addresses are automatically converted to geo-coordinates.
4. Textual similarity: we compare the titles of contracts using the SoftTFIDF  algorithm.
The overall match score is then a weighted sum of the scores returned by all comparers.
When looking for suitable suppliers for a given call for tenders, the above approach is used in order to ﬁlter suppliers that have been previously awarded a contract similar to the current one. Similarly, when looking for suitable calls for tenders from the point of view of a supplier, the information (including CPV codes) from the supplier's proﬁle is assembled into a virtual tender, which is matched against the open calls for tenders.