┌──────────────────────────┐      ┌──────────────────────────┐
│ Creation                 |      │ Creation                 | 
│--------------------------│      │--------------------------│
│             ┌─────────┐  │      │             ┌─────────┐  │
│ Title       │         │  │      │ Title       │         │  │
│             └─────────┘  |      │             └─────────┘  |
│  ┌───────────────────┐   │ ---> │             ┌─────────┐  │
│  | Validation ../..  │   │      │ Description |         │  │
│  └───────────────────┘   │      │             └─────────┘  │
|                          │      |  ┌────────────────┐      │
| Warning : 2 steps !      |      │  |     Save       │      │
└──────────────────────────┘      │  └────────────────┘      │
                                  └──────────────────────────┘

Before​

Until now, creating a resource in the demonstrator forms (in the BO or MY interface) was a two-stage process. Firstly, the title and an initial validation (which created the resource in the database), then a complementary form, where you would find the rest of the fields that make up the resource.

Problem: Most of the time, the user didn't know what to enter in the 'title' field, as they didn't yet see the overall content of the form.

From now on​

So we simplified it by merging everything into the same form.

Most of the forms in the demonstrator have been revised to simplify their input.

Removal of the title for competences

┌──────────────────────────┐      ┌──────────────────────────┐
│ Competence creation      |      │ Competence creation      | 
│--------------------------│      │--------------------------│
│             ┌─────────┐  │      │             ┌─────────┐  │
│ Title       │         │  │      │ Description │         │  │
│             └─────────┘  |      │             └─────────┘  |
│             ┌─────────┐  │ ---> │  ┌────────────────┐      │
│ Description |         │  │      │  |      Save      │      │
│             └─────────┘  │      │  └────────────────┘      │
|  ┌────────────────┐      │      └──────────────────────────┘
|  |     Save       │      |                                                
│  └────────────────┘      │                                                
└──────────────────────────┘                                                

In the same vein, users didn't know what to enter in the 'title' field for skills.

We have therefore removed it, and generated an automatic title based on the user ID and an incremental number.

For more information on the demonstrator's interfaces, please consult the user manuals:

• My-competences
• Back-office

┌────────────────────────┐      ┌────────────────────────┐
│         PAIR           |      │       HECO v1.0        |
│------------------------│      │------------------------│
│ ┌────────────────────┐ │----->│ ┌────────────────────┐ │
│ │   pair:hasSkill    │ │      │ │ heco:hasCompetence │ │
│ └────────────────────┘ │      │ └────────────────────┘ │
└────────────────────────┘      └────────────────────────┘

What is the PAIR ontology?​

The primary objective of the Virtual Assembly is to map communities. So, in addition to the SemApps toolbox, it created a PAIR ontology to map Pprojects, Actors, Iideas and Rresources. Events and other concepts were added later...

A gradual migration...​

At the beginning, the first versions of the Carto4CH demonstrator mapped people (actors), organisations and skills, so PAIR had everything we needed for a proof of concept.

As the project progressed, we wanted to move away from PAIR, because its raison d'être was not the same as that of HeCo. So we added classes and relationships from HeCo in addition to PAIR.

For the first year, the two ontologies coexisted very well, and that's the strength of the semantic web, being able to use and mix several ontologies! But after a while, and for the maintenance of the application, it's wise to make long-term choices.

Let's liberate ontologies!​

It is important to see the Carto4CH demonstrator as "a technical solution that can interface with the HeCo ontology ". In other words, HeCo must not be specific to any implementation. It must be able to live its life as an ontology without worrying about how developers are going to use it.

At the end of June 2023, the HeCo ontology was upgraded to V1.0, which for us meant that it could enter a 'production' and 'maintenance' cycle, and we were able to start thinking about moving away from the PAIR ontology.

In July-August 2023, work was carried out to align the HeCo ontology with all the classes/relations present in the code and in the demonstrator database, so as to become as little dependent on PAIR as possible.

We can now say that the demonstrator uses the HeCo ontology 95% of the time.

In fact, some of the specific features of SemApps meant that we had to keep references to PAIR in certain places. But if we've done this, it's more for comfort or simplicity, it doesn't mean that there are things missing from the HeCo ontology.

New HeCo ontology version 1.0 !​

We have updated the HeCo ontology to version 1.0. You can consult this new version online or via a schema, an OWL file and a presentation document: HeCo Ontology.

┌────────────────────────┐
│ Demonstrator Carto4CH  |
│------------------------│
│ ┌────────────────────┐ │
│ │      SemApps       │ │
│ │--------------------│ │
│ │ ┌────────────────┐ │ │
│ │ │  React-Admin   │ │ │
│ │ └────────────────┘ │ │
│ └────────────────────┘ │
└────────────────────────┘

What is React-Admin?​

The Carto4CH demonstrator user interface is based on the SemApps toolbox, which itself depends on a technical foundation (framework) called React-Admin. This technical foundation is maintained by the (French) company Marmelabs. It uses the JavaScript library React.

In short, the SemApps components used for the user interface are in fact an assembly of components from the React-Admin framework. These components have been adapted (writing 'overlays') so that they can interface with one (or more) SemApps servers (which are coded in Node JS, another Javascript library).

Why migrate?​

This new feature concerns an important code refactoring, which will enable our demonstrator :

• be up to date with the basic components on which it depends,
• be more stable, benefiting from bug fixes
• access to new current or future functionalities.

So we're going to take advantage of this migration to give you some technical details about how it works, in as simple a way as possible.

Explanation​

Since the start of the Carto4CH project, we've been using version 3 of React-Admin. However, a few months ago, Marmelab released a major version, version 4, and we therefore had to 'migrate' the code for the SemApps components to this version, as well as all the interfaces that use these components. For the Virtual Assembly, this operation was far from neutral, and it took our teams several weeks to update the SemApps components so that they worked with the new version of React-Admin. This was completed at the beginning of July, allowing us to update the Carto4CH demonstrator interface code ourselves.

These adaptations were first made to the back-office, then to My-skills.

Once we had achieved iso-functionality, we realised that this new version 4.0 made it possible to simplify certain interfaces, or to simplify code writing, because in version 3 we had added 'band-aids' because of bugs that were fixed in version 4. So we've gone through the demonstrator code a second time, to make it easier to maintain in the future.

For more information about the inner workings of SemApps, see Technical documentation > SemApps technical doc

The production phase has begun.

We've provided partners with a technical "package" enabling them to install and configure their own production server.

This package uses the same code as the demonstrator, but for a single server.

For more information, see Technical documentation > Deploying a server.

Since the beginning of the project, we've been using organization names to call the two demonstrator servers. For the sake of neutrality, we now call them Server A and Server B.

We have therefore renamed all elements referring to organizations :

• in this portal
• in access URLs to the demonstrator
• in schemas
• in server files

We have added documentations allowing users to add their skills more easily and to understand the different interfaces proposed by the demonstrator.

For the moment, there are 3 interfaces developed in the demonstrator:

• My-competences
• Back-office
• Carto

Publication of a new version of the HeCo ontology.

• Page of the ontology
• Corresponding schema

To make it easier to fill competencies and simplify the user experience, we have added a new application to the demonstrator called My-competence.

In this application, the user logs in, and then only sees her personal data. It can then fill in his CV in a streamlined interface.

It can be adapted to the instance, as for example in the demonstrator, we have called it My-ServerA (for the instance A).

You can find the user documentation of this application in Project doc. > Doc. Demonstrator > My-competences.

Technically, it is a second interface using the [SemApps] toolkit (/docs/technical-documentation/presentation-semapps). It points to the same data as the back-office application.

Abandonment of reified relations​

For technical reasons and time constraints, we have decided to abandon the reified relations mechanism to provide a first functional version containing the management of :

• trainings
• jobs
• contributions
• competences (with 4 fixed qualities)

Indeed, after a few months of complex implementation and difficulty in explaining the interface during the skills workshops, we moved towards a simpler solution, consisting in freezing 4 qualities, each linked to a repository:

• Disciplines
• Sectors
• Studied Objects
• Tools

Advantage: The user will thus be better guided in entering competences

Disadvantage: If we want to add a new quality in the future, we will have to go through the code.

Postponement of automatic repositories​

We have also decided to move towards internal repositories, filled in by each person's entries in each server. We continue to use the ESCO and Wikidata repositories for input help.

Advantage: Time saving and simplicity of architecture. We want to start small, but we want it to work, because it is still a demonstrator. This will allow us to have a beginning of a repository for the day when we need to create an automatic one.

Disadvantage: This means that at the beginning, the choice lists will not be filled up much, but that as we go along, these lists will be filled up with the qualities created by everyone in each instance.

Since SemApps is fully used in this project, it seemed important to give it a full place in this portal.

At the same level as SOLID, we added a reference page, with a link to https://semapps.org, which has recently been updated with a new stable release.

We have added a schema, explaining the notion of "semantic toolbox" which summarizes what SemApps is.