Mise en place du modèle de données

[alexisjanvier]

Comment allons nous structurer les données ? Lors de cette mise en place, nous avons convenu de créer le modèle sous forme d'objets json afin de les implémenter rapidement au sein du service "api-mocked".

[alexisjanvier]

Personnellement, voila ce que j'aimerais voir sur une offre d'emploi:

• le salaire
• la localisation de la boite
• la taille de la boite
• les clients ou la cible des utilisateurs du produit à développer
• du code produit par l'équipe existante

Bon après, il faut certainement des données factuelles comme la fiche de poste, la stack technique ...

Je me dis qu'on pourrait partir sur un modèle simple du genre :

job : {
    id: uuid,
    title: string,
    description: string,
    type: enum (CDI, CDD, ...)
    salary_offer: ?
    created_at: date (date de création de l'annonce)
    valid_until: date (date de fin de validité de l'annonce)
    company: id ? foreign-key ? Référence à la boite
    created_by: id ? string ? foreign-key ? 
    stack: [string] tableau de tags des technos liées à l'annonce   
}

company : {
    id: uuid ?
    title: string
    description: string, html, markdown, ... ?
    industry: enum (secteur d'activité de la boite)
    type: enum(serviceProvider or publisher) (prestation de service ou éditeur de produit)
    customers_or_target_users: text
    size: enum ? type spécifique ? Taille de la boite en nombre de salariés
    stack: [string] tableau de tags des technos utilisées
    adress: https://schema.org/address ?
    links: tableau de lien web (site, github, twitter, linkedin, ...)   
}

[Chroq]

À voir si on attache pas un contact à la fiche de poste. Je pense pas que ça complexifie des masses le modèle et ça permet de gérer plus finement les différents contacts d'une entreprise (ex : pôle dév, datascience, graphisme, etc...).

Pour l'implémentation, on peut partir sur le modèle suivant :

contact : {
    id: uuid ?
    first_name: string
    last_name: string
    email: string
        phone: string
        job: string ?
}

Si vous avez des idées, n'hésitez pas à améliorer le modèle. L'idée étant de gérer différents contacts au sein des entreprises et de savoir à qui on d'adresse pour les démarches et pas de faire un réseau social avec des tonnes d'infos sur la personne.

[gaelreyrol]

@Chroq À voir si c'est pas problématique de maintenir les infos à jour des contacts ?

@alexisjanvier Est-ce qu'on essaierai pas de matcher avec les types de schema.org ? Par exemple pour une société de coller au type Organization ? On a directement le type pour une annonce aussi avec JobPosting.

Ça a l'avantage d'être déjà documenté, exploitable par les moteurs de recherche et ça sera facile pour faire du json-ld ou pousser encore plus loin avec du hal !

[alexisjanvier]

@gaelreyrol Carrement ! A mon avis tout ce qu l'on pourra faire allant dans le sens d'une donnée ouverte et standardisée ira dans le bon sens ! Donc oui, de mon côté je suis a fond pour coller à la structuration d'objets définis dans schema.org

@Chroq je suis aussi d'accord sur le fait d'avoir un moment donné une notion de contact. Après, je ne sais pas trop ou aller la dessus. Parce que se pose aussi la question du "profil" de la personne publiant l'annonce. Et même un se projetant un peu plus loin dans le projet, à quel moment faire rejoindre un profil CaenCamp, un compte CaenCamp. Et comment le lier par exemple aux profils d'intervenants déjà existant ? Et puis je me dis que ce serait effectivement chouette de savoir qui bosse dans quelle boite ?! Comment pourrait-on recceuillir des "avis" sur les boites ? Comment valider ces avis ? Si on ajoute une boite en base de donnée, comment pourra-t-on différencier de l'information factuelle d'une personne ne travaillant pas dans cette boite d'une information plus ... qualitative ? ajoutée par quelqu'un travaillant au sein de cette boite ? Bref, le sujet est je trouve hyper interessant, mais pas si simple ...

Concernant cette carte, je me dis qu'il s'agit moins de définir un modèle définitif, que de poser une modèle minimum afin de pouvoir construire dessus en se posant toutes ces question, mais en ayant un socle permettant d'avancer aussi bien sur le front que le back.

Du coup, qui se lance pour faire une première PR de proposition sur l'api mockée ?

[gaelreyrol]

Est-ce qu'on attendrai pas les premiers retours pour avancer sur la notion de contact et d'avis ? En tout agilité :smile: !

Pour ce qui est de la PR, je peux essayer de commencer dans les jours qui viennent. Est-ce qu'on part sur un format JSON-LD (en s'appuyant sur https://json-ld.org/) pour coller aux objets définis par schema.org ?

[alexisjanvier]

:+1: pour l'utilisation du JSON-LD. Par contre, je ne sais pas si cela sera facile à mettre en place avec le json-server de l'API mockée ?

[gaelreyrol]

Oui non effectivement ça va pas être simple à priori, j'ai commencé un bout. Pas sur que ça soit pertinent tant qu'on travaillera pas sur l'api finale.

[Chroq]

Merci pour les retours les gars ! Ok, on verra comment gérer en fonction des besoins.

Je guette le repo pour voir si je peux apporter quelque chose dès que vous aurez commencé.

[gaelreyrol]

J'ai commencé un petit bout sur la branche mocked-data-scheme !