Notice bibliographique
Résumé
In earlier versions of the community discovering problem, the overlap between communities was restricted by a simple count upper-bound. In this paper, we introduce the [Formula: see text]-Packing with [Formula: see text]-Overlap problem to allow for more complex constraints in the overlap region than those previously studied. Let [Formula: see text] be all possible subsets of vertices of [Formula: see text] each of size at most [Formula: see text], and [Formula: see text] be a function. The [Formula: see text]-Packing with [Formula: see text]-Overlap problem seeks at least [Formula: see text] induced subgraphs in a graph [Formula: see text] subject to: (i) each subgraph has at most [Formula: see text] vertices and obeys a property [Formula: see text], and (ii) for any pair [Formula: see text], with [Formula: see text], [Formula: see text] (i.e., the pair [Formula: see text] does not conflict). We also consider a variant that arises in clustering applications: each subgraph of a solution must contain a set of vertices from a given collection of sets [Formula: see text], and no pair of subgraphs may share vertices from the sets of [Formula: see text]. In addition, we propose similar formulations for packing hypergraphs. We give an [Formula: see text] algorithm for our problems where [Formula: see text] is the parameter and [Formula: see text] and [Formula: see text] are constants, provided that: (i) [Formula: see text] is computable in polynomial time in [Formula: see text] and (ii) the function [Formula: see text] satisfies specific conditions. Specifically, [Formula: see text] is hereditary, applicable only to overlapping subgraphs, and computable in polynomial time in [Formula: see text] and [Formula: see text]. Motivated by practical applications we give several examples of [Formula: see text] functions which meet those conditions.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,003 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,003 | 0,001 |
| Études des sciences et des technologies | 0,000 | 0,002 |
| Communication savante | 0,001 | 0,002 |
| Science ouverte | 0,009 | 0,003 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».