Responsabilités de l'exploitation et de l'exploitant agricole

Farm décrit l'unité de production. Person, Organization et InformalGroup décrivent les personnes ou les entités qui en sont responsables. L'identité d'une exploitation est distincte de l'identité de son exploitant et de tout enregistrement.

AgriculturalHolderRole signifie responsabilité d'exploitant agricole : les décisions clés sur l'utilisation des ressources et le contrôle de gestion d'une exploitation, seul ou conjointement, y compris sa responsabilité technique et économique. Il ne signifie pas la propriété, l'emploi ou la seule gestion quotidienne. Un exploitant peut aussi être le responsable de la gestion quotidienne, mais le fait d'être gérant n'établit pas la responsabilité d'exploitant. Les variantes typées (PersonAgriculturalHolderRole, OrganizationAgriculturalHolderRole et GroupAgriculturalHolderRole) nomment une Person, une Organization ou un Group via holder_person, holder_organization ou holder_group, et l'exploitation via holder_farm, sans admettre un planificateur logiciel comme sujet responsable. Une Farm ne liste pas ses rôles d'exploitant ; retrouvez-les via holder_farm.

Les enregistrements d'exemple synthétiques décrivent une exploitation, un ancien exploitant coopératif, deux exploitants individuels conjoints actuels et un ancien collectif informel. Aucun des deux individus n'a besoin d'un identifiant national. Le collectif a un nom sans liste complète de ses membres. L'exemple indique la superficie totale de l'exploitation, les types de régime foncier et le bétail détenu, mais aucune parcelle. Le vocabulaire de Farm n'exige ni propriété foncière, ni superficie positive, ni liste de parcelles ; une exploitation sans terre a une farm_area égale à zéro. La succession datée est un exemple explicite de continuité affirmée de l'unité, et non une règle universelle pour les ventes, les fusions ou les scissions.

Ces distinctions suivent le FAO WCA 2020, volume 1, Rome 2017, paragraphes 6.2, 6.7–6.14 et 6.17–6.21. Les noms de classes, les propriétés de date et la persistance sont des choix de conception de PublicSchema. Le projet de référence de janvier 2026 du FAO WCA 2030, paragraphes 4.21–4.24, distingue également les responsables non rémunérés de la gestion quotidienne. Aucune conformité au recensement n'est revendiquée.

Champs synthétiques et enregistrement

farm_area est la superficie totale exploitée par l'exploitation, quel que soit le titre, sous forme de QuantityValue avec son unité (par exemple UCUM har pour les hectares). Ce n'est pas la somme des superficies des parcelles partagées avec d'autres exploitations. land_tenure liste chaque type d'arrangement selon lequel l'exploitation exploite des terres, conformément aux types de régime foncier de l'item 0204 du WCA 2030 ; il décrit la manière dont l'exploitation utilise les terres, et non qui détient des droits sur celles-ci, et il est sensible parce que certaines valeurs révèlent un régime foncier précaire. livestock_type liste les types de bétail détenus sur l'exploitation, que l'exploitation en soit propriétaire ou non, regroupés selon les classes de bétail du WCA 2030. Ces champs synthétiques ne remplacent pas les enregistrements détaillés des parcelles, du régime foncier ou des animaux.

Un FarmerRegistration reconnaît une personne, une organisation ou un groupe comme agriculteur à une fin administrative déterminée. registered_farms nomme facultativement les exploitations qu'il couvre. L'enregistrement n'établit pas la responsabilité d'exploitant, des droits sur les terres ni une éligibilité à un programme.

Vocabulaire et profil d'exemple local

Tous les champs du vocabulaire sont facultatifs, afin que les descriptions partielles restent utiles. Le JSON Schema généré valide les champs disponibles, mais les références sous forme de chaînes ne prouvent pas l'identité de la cible, et une référence à un rôle abstrait ne valide pas en elle-même l'extrémité d'un rôle concret. Le SHACL généré vérifie les relations typées du graphe lorsque la hiérarchie des classes est fournie.

Exécutez le profil de démonstration, nommé de façon indépendante, depuis la racine du dépôt :

uv run --locked python examples/farm-operators/validate_profile.py

Le profil exige que les rôles d'exploitant concrets identifient une Farm via holder_farm et exactement leur propre extrémité d'exploitant typée. Il résout localement les chaînes et les objets imbriqués, rejette les cibles manquantes ou de mauvais type, rejette l'AgriculturalHolderRole abstrait, vérifie l'ordre des dates d'effet et rejette les champs que le vocabulaire ne définit plus sur Farm et WorkRelationship. Les dates inconnues restent absentes et ne prouvent pas si une responsabilité est actuelle. Ce profil ne prend en charge que les types concrets listés ; l'étendre à d'autres sous-types de groupe ou de personne exige une modification explicite.

Le profil est un exemple reproductible, et non un service de registre opérationnel. Il n'établit ni propriété, ni enregistrement, ni droit à prestation, ni autorisations de divulgation. L'éligibilité d'un groupe reste une décision du programme. Les subventions aux coopératives ne peuvent pas être insérées dans des champs de bénéficiaire dont la plage de valeurs est Party sans contrat distinct.

Migration depuis les exploitations fondées sur Group

Farm n'hérite plus des champs d'appartenance d'un groupe de personnes. Préservez les anciennes valeurs sources avant de décider quel sujet elles décrivent. La valeur normative GroupType/farm reste le classificateur des enregistrements de groupe externes représentant des unités de production, y compris dans les modèles agricoles ou de protection sociale à plat. Elle n'a pas été redéfinie comme classificateur de liste de membres. GroupRole/operator décrit toujours sa fonction d'appartenance d'origine, la gestion quotidienne ; ne la faites pas correspondre automatiquement à un rôle d'exploitant. GroupMembership lui-même reste une relation de Person à Group.

L'ADR-021 consigne les alternatives envisagées.

Travail sur une exploitation

Utilisez HoldingWorkAssignment pour relier une Person à une Farm sur laquelle elle travaille ou est censée travailler. Il décrit un travailleur ou un responsable de la gestion quotidienne de l'exploitation. Une affectation directe ne nécessite ni assertion d'employeur, ni contrat de travail, ni seconde relation. Elle peut décrire un responsable non rémunéré de la gestion quotidienne, une contribution familiale ou un travail rémunéré sans faire de cette personne un exploitant.

Utilisez WorkRelationship lorsque la relation économique a sa propre identité : le travail d'une personne pour une unité économique. Cette unité peut être une production du ménage ou une entreprise et n'a pas besoin d'être une organisation dotée de la personnalité morale. work_economic_unit contient l'URI de son sujet. Le profil d'exemple résout localement cet URI vers une Organization, un Household, un InformalGroup ou une Farm ; affirmer cette extrémité signifie que le sujet est l'unité économique concernée, et non que chaque instance de ces types en est automatiquement une. Lorsque la partie liée en tant qu'employeur diffère de l'unité économique, comme une agence agissant comme employeur de droit, legal_employer la nomme ; le profil d'exemple ne résout pas ce lien.

Une affectation sur une exploitation peut être reliée à la relation de travail à l'aide de assignment_work_relationship. Par exemple, un salarié d'agence a une relation avec l'agence de travail temporaire et deux affectations sur des exploitations différentes. Un prestataire indépendant peut de même avoir une relation avec sa propre entreprise et des affectations pour plusieurs clients. Une exploitation cliente ne devient pas pour autant l'employeur ni un emploi distinct. L'affectation et la relation liée doivent identifier la même Person. Aucune des deux n'implique un rôle d'exploitant.

L'exemple de travail synthétique comprend des responsables de la gestion quotidienne rémunérés et non rémunérés, un exploitant qui gère aussi l'exploitation, une production familiale pour usage propre, un travailleur familial collaborant dans une production marchande, un travailleur d'agence et un prestataire. Il conserve des identités distinctes pour la personne, l'exploitation, la relation économique et l'affectation.

Champ facultatif	Ce qu'il décrit
work_functions	Une ou plusieurs fonctions, telles que la gestion quotidienne ou la récolte. Affectations de travail sur l'exploitation uniquement.
work_form	Emploi, production pour usage propre ou autre forme de travail identifiée.
work_status	Situation dans une classification indiquée, telle que la situation dans la profession ou une situation au travail plus large.
work_remuneration	Salaire, honoraires, absence de rémunération régulière ou autre modalité de paiement indiquée.
work_seasonality	Caractère saisonnier, indépendamment de la fonction, de la situation, de la durée du contrat et du temps de travail.

work_form prend une valeur FormOfWork ; les quatre autres utilisent des enregistrements CodedValue qui nomment leur schéma. Les cinq sont facultatifs et décrivent le travail dans la relation ou l'affectation qui les contient, et non le statut global de la personne au regard de l'activité. Les classifications manquantes restent inconnues ; les classifications d'une relation liée ne sont pas automatiquement copiées sur les affectations. Placez de préférence les classifications de la relation économique sur la WorkRelationship lorsque les deux sont présentes ; les fonctions sur une exploitation relèvent de l'affectation. Les désaccords de classification exigent un examen des sources ; cet exemple ne les tranche pas. Les champs d'emploi existants de Person et les codes de vocabulaire restent inchangés.

Les schémas d'exemple sous https://example.org/farm-work/v1/ sont des codes locaux synthétiques. Leurs libellés illustrent des dimensions indépendantes ; ce ne sont pas des codes officiels de l'OIT ni une revendication de conformité à l'ICSE. Une classification fournie nécessite l'URI de son schéma et son code d'origine. Les valeurs inconnues ou locales peuvent être conservées sans deviner d'équivalent standard. Pour un profil lié à un standard, identifiez le schéma et l'édition exacts et validez séparément son applicabilité.

Le Manuel ICSE-18 de l'OIT, août 2023, p. 4–5 et 21 de la version imprimée, fournit la distinction entre personne et unité économique et explique pourquoi les contributions familiales non rémunérées à une production marchande peuvent constituer un emploi, alors que le travail pour usage propre est une forme différente. L'emploi ne signifie pas toujours le statut de salarié. Ces distinctions motivent le modèle ; l'OIT ne prescrit ni la classe d'affectation ni la sérialisation en cinq champs. Le projet de référence de janvier 2026 du FAO WCA 2030, §§ 4.21–4.24 et 7.9.16–7.9.18, éclaire les distinctions entre gérant et exploitant, et entre salarié et prestataire.

L'édition finale, FAO WCA 2030, 2026, a été publiée le 4 mai 2026 selon la page du cycle de la FAO. Les types de régime foncier (item 0204, paragraphes 7.2.38 à 7.2.47) et les classes de bétail (annexe 8) utilisés par le vocabulaire suivent l'édition finale ; les numéros de paragraphe cités plus haut pour le travail et la gestion proviennent du projet de janvier.

Limites du profil de travail et migration

Le profil exécutable valide les deux fichiers d'exemple. Pour WorkRelationship, il exige une Person et une unité économique résolue localement ; pour HoldingWorkAssignment, il exige une Person et une Farm. Un lien de relation facultatif doit se résoudre vers une WorkRelationship de cette même personne. Les champs de classification restent facultatifs. Les dates fournies doivent être valides et ordonnées. Une affectation liée doit s'inscrire dans les bornes connues de la relation ; les dates absentes ne deviennent pas des intervalles infinis.

Pour ces exemples de travail, start_date est le premier jour calendaire effectif et end_date le dernier. Le profil rejette une date de fin antérieure à la date de début lorsque les deux dates sont fournies. L'affectation d'Amina à la gestion se termine le 30 juin 2025 et l'affectation qui la remplace commence le 1er juillet 2025, sans aucun jour effectif en commun. La responsabilité d'exploitant reste inchangée. Cela met en œuvre la convention des dates de relation. La conversion des dates sources suit le guide de conversion des dates de relation, qui exige de confirmer d'abord la frontière et la précision des dates de la source.

Une ancienne appartenance de Person à Farm avec un rôle de responsable de la gestion quotidienne ou de travailleur peut devenir une HoldingWorkAssignment une fois sa signification de travail et l'identité de sa cible confirmées. Conservez le code de rôle et le schéma d'origine dans work_functions lorsque c'est approprié ; ne déduisez pas de ce rôle la rémunération, la forme, la situation, la saisonnalité ni la responsabilité d'exploitant. Un code GroupRole/operator décrit la gestion quotidienne et ne désigne pas automatiquement un exploitant. Une appartenance qui décrit une propriété nécessite une assertion de propriété, et non une affectation de travail. GroupMembership reste une relation de Person à Group et ne peut pas cibler Farm.

L'alternative plus simple la plus solide est un unique FarmWorkerRole. Il convient à une liste de travailleurs, mais confond la relation économique de l'agence ou du prestataire avec chaque lieu de travail. Exiger une WorkRelationship et une affectation pour chaque participant introduit des enregistrements inutiles lorsque seule la participation est connue. Le lien facultatif prend en charge les deux cas. Aucun nombre d'heures, aucun droit relevant du droit du travail ni aucun comptage automatique pour le recensement n'est revendiqué ici.