lmazuel / onagui Goto Github PK

On ne sait pas toujours si un traitement est terminé, si le résultat met du temps à s’afficher...
En cas d’échec de l’alignement, il pourrait y avoir un message du type “aucun alignement
trouvé”.

"PrefLabels" --> "Libellés préférentiels"
"AltLabels" --> "Synonymes"
"FragURI" --> ?? juste "URI" ? je ne sais pas trop ce qui vient se mettre dans cette zone. Pourrait-on l'afficher plutôt en bas de la partie "Lexique", sous les synonymes ?

Dans la partie centrale, ajouter un onglet “Notes” en plus de “Lexique” et “Commentaires”, qui
affichera les propriétés suivantes (dans cet ordre, de la plus utilisée à la moins utilisée) :
● skos:scopeNote
● skos:definition
● skos:historyNote

L’affichage doit se faire en fonction de la langue d’affichage choisie. Comme pour l’onglet
“Lexique”, on peut afficher côte à côte les notes des 2 concepts choisis.
S’il y a suffisamment de place en hauteur, on peut aussi afficher d’autres notes SKOS :
● skos:changeNote
● skos:example
● skos:editorialNote

Now labels beginning by "é" are at the end of tree

Because they are not. See

We can use a ServiceProvider mechanism : https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html
Just like in RDF4J : http://docs.rdf4j.org/custom-sparql-functions/#_creating_an_spi_configuration

See also #15

This is the super-property of all SKOS mapping propery.
We need to be able to handle this to import a "generic" alignement where the alignment property is currently undefined and needs to be set manually.
We need to add a new Mapping type in the code.

See http://www.ddialliance.org/Specification/XKOS/1.0/OWL/xkos.html#correspondences.
XKOS defines something similar to EDOAL, but there is no score property.

(voir si cette dépendance est vraiment utile ? pourrait-on tout baser sur RDF4J ?)

Aujourd'hui, dans FixedColorManager, on a 3 seuils pour les couleurs d'affichage des scores :

public static final Color COLOR_1 = new Color(51,255,51); // Green
public static final Color COLOR_2 = new Color(255,255,0); // Yellow
public static final Color COLOR_3 = new Color(255,153,0); // Orange
public static final Color COLOR_4 = new Color(255, 0, 0); // Red

private double threshold_1 = 0.75;
private double threshold_2 = 0.5;
private double threshold_3 = 0.25;

On pourrait avoir une implémentation qui génère la couleur de blanc à vert directement en fonction du score.

Quand il y a une correspondance sur un concept, son rond devient vert dans l'arbre.
Quand il n'y a pas de correspondance, son rond reste gris.
Quand il y a une correspondance et que je la supprime, le rond devient rouge; c'est bizarre, je m'attendrais à ce que le rond redeviennent gris. A quoi correspond cet état "rouge" du concept ? faut-il le garder ? est-ce que le rond ne devrait pas redevenir gris ?

Format actuel : "20170331T123736+0200"
Il faudrait formatter un peu mieux pour l'affichage, éventuellement en fonction de la Locale

On ne connaît pas forcément les subtilités des algos d’alignement. Est-il possible d’indiquer -
même sommairement dans une bulle par exemple - les spécificités de chacune des 3
méthodes proposées ?

Depuis avril 2016 Sesame a été repris par la fondation Apache et s'appelle RDF4J. Ce serait bien de migrer vers cette dépendance. RDF4J 1.X est compatible Java7, RDF4J 2.X nécessite Java 8.
Cette migration demande :

• un renommage de tous les imports org.openrdf.sesame en org.eclipse.rdf4j
• parfois, si on utilise RDF4J 2.X, de légère modifications dans le code du fait de l'utilisation des Optional en java 8

Dépendance Maven :

<dependency>
    <groupId>org.eclipse.rdf4j</groupId>
    <artifactId>rdf4j-runtime</artifactId>
    <version>2.1.5</version>
</dependency>

This method https://github.com/lmazuel/onagui/blob/master/src/main/java/fr/onagui/control/MyTreeModel.java#L153 scans all the children of a node to find the corresct index at which to insert a new child. This is called for every new child to be inserted.

The consequence is a N(square) complexity to construct expand a node.

It is much more efficient to insert all children unordered, then sort the children with a sorting algorithm.

les libellés des coches « Concept non alignable » et « pas alignable » ne sont pas
clairs. Il faudrait : « Non alignable dans le voc 1 » et « Non alignable dans le voc 2 »

Si tu mavenises OnaGUI :
Si le "moteur" ou la logique d'alignement d'OnaGUI pouvait être mis dans un module séparé de la partie IHM, ce serait top car ça permettrait de le réutiliser (je pense à une intégration avec SKOS Play par exemple).
Ce n'est pas critique.

En s’appuyant sur les métadonnées dcterms:created / dcterms: modified, cela ne devrait pas
être trop difficile. Il faut un dialogue supplémentaire pour demander l’input à l’utilisateur
“Aligner seulement les concepts créés ou modifiés après le ...”

The last directory from which a vocabulary is loaded is maintained so that, when we load the second vocabulary, we don't have to renavigate the full directory structure.
This does not work however for loading a alignement. It would be nice if this last directory used was also maintained when loading an alignment.

OnaGUI se base visiblement sur la présence de liens skos:hasTopConcept / skos:topConceptOf pour charger le premier niveau des concepts dans un ConceptScheme.
C'est bien, sauf que pas mal de fichiers SKOS ne contiennent pas ces indications de têtes de hiérarchie. Il faudrait ajouter un comportement par défaut : "si aucun concept portant un skos:topConceptOf ou référencé par un skos:hasTopConcept n'a été trouvé, alors on considère comme concepts racines tous les skos:Concept qui ne portent aucun skos:broader ou qui ne sont référencés par aucun skos:narrower".

J'attache un fichier de test.
test-concept-scheme-sans-topConcepts.rdf.zip

Quand on a lancé un alignement, les correspondances trouvées sont toutes en status
« OK ». Je m’attendrais à ce qu’elles soient en status «_ » (pas de status), et qu’on
puisse les mettre en status « OK » pour les valider.

les correspondances créées manuellement devraient être en statut OK

(et dans d'autres langues également, avec les fichiers de ressources qui vont bien)

Remplacer les libellés des types d’alignement dans la dropdown “Type” par les notions SKOS
:
● EQUIV : exactMatch
● OVERLAP : closeMatch
● SUBSUMEDBY : broadMatch
● SUBSUMES : narrowMatch
● supprimer DISJOINT ?
● ajouter skos:relatedMatch

Le fait que la combo-box d'annotations change quand on sélectionne un autre concept qui ne porte pas l'annotation qui était sélectionnée avant est un peu perturbant. Est-ce que ce ne serait pas plus cohérent si la combo-box était initialisée une fois pour toute lors du chargement des vocabulaires avec l'ensemble des propriétés d'annotations (hors prefLabel, altLabel, hiddenLabel) trouvées sur tous les concepts ?

Mais cela peut prendre du temps à scanner l'ensemble du vocabulaire. Peut-etre que c'est mieux de le faire en incrémental, ajouter a les box les nouvelles annotations au fur et a mesure qu'on en trouve des nouvelles?

Faire en sorte que OnaGui ne sélectionne pas la langue d’affichage “au hasard” quand
on charge des thésaurus multilingues. Il faut que l’affichage d’un thesaurus multilingue
soit cohérent. Par exemple, sélectionner par défaut la première langue dans la liste
des langues par ordre alphabétique (exemple : si on a “en” et “fr”, OnaGui peut
sélectionner “en” par défaut);

De plus en plus de thesaurus sont gérés et publiés en utilisant SKOS-XL. Il faudrait
qu’OnaGUI puisse lire ces libellés en plus des libellés SKOS normaux. Une solution simple
est de ramener les libellés SKOS-XL en libellés SKOS standard au moment du chargement
du fichier, avec ces règles d’update :
https://bitbucket.org/tfrancart/sparna/src/64384d2572c9d3bae79f564042ac8e6facd6b602/fr.sp
arna/rdf/skos/skos-toolkit/src/main/resources/fr/sparna/rdf/skos/toolkit/skosxl2skos/?at=master

Currently only skos:hasTopConcept and skos:topConceptof are read.

Some SKOS files don't declare any ConceptScheme and OnAGUI cannot read those. We could simply display the first-level concepts in this case, when no ConceptSchemes are declared.

This is necessary to be able to load RAMEAU from BNF

Meme si évidemment un alignement en SKOS ne permet pas de capturer le score d'une correspondance, sa date, la méthode, etc. on pourrait mettre des valeurs par défaut pour tout cela et charger quand même l'alignement en SKOS :

• score : 1.0
• méthode : manual
• date : la date au moment du chargement

It would make sense to re-order them in this order, with exactMatch first (the most common property) :

• exactMatch
• closeMatch
• relatedMatch
• broadMatch
• narrowMatch
• mappingProperty
• disjoint (not in SKOS)

Actuellement les fichiers avec extension .ttl sont masqués, il faudrait qu'ils soient affichés.
Il faudrait mettre toutes les extensions de fichiers RDF possible.
Ca ce joue ici :

This is due to Mapping.compareTo that uses the type as comparison criteria.
compareTo could be modified to use only criterias that cannot be modified in the GUI.

Typically happens when a concept has a lot of synonyms.
I am not sure what the best solution is : a vertical scrollbar, but on which panel : the entire center panel ? or only the details panel under the alignment table ?

Comme Jean m'a dit qu'OnaGUI était prévu pour être extensible... : est-ce que la procédure pour ajouter un algo d'alignement pourrait être documentée ? quelle classe/interface Java étendre ? comment ajouter le jar à OnaGUI ? faut-il ajouter des nouveaux menus dans l'interface, etc...

On a souvent le cas où on veut faire passer une correspondance de "EXACT" à "OVERLAP", mais on ne peut pas faire cela directement, il faut supprimer la correspondance et la recréer. Ce serait bien de pouvoir éditer le type de la correspondance directement.

Ce n'est pas critique.

!! Attention compliqué !!

Je sais que c’est compliqué, et ce n’est pas forcément prioritaire. Cependant ce serait bien
pratique que OnaGUI sache afficher dans son arbre (sans forcément aligner) des
skos:Collections. On peut reprendre l’algorithme de génération d’arbre à partir du SKOS qui
est utilisé dans SKOS Play :
https://bitbucket.org/tfrancart/sparna/src/9c4946565617bc9dcd53eb8216909ffc94f88398/fr.sp
arna/rdf/skos/skos-toolkit/src/main/java/fr/sparna/rdf/skos/toolkit/SKOSTreeBuilder.java?at=co
nvert&fileviewer=file-view-default
par exemple il faut capable de détecter :
● les collections skos qui sont des microthesaurus et qu’il faut afficher au premier niveau
du thesaurus;
● les collections skos qui correspondent à des tableaux de concepts et qu’il faut afficher
à l’intérieur de la hiérarchie;

Avoir quelque chose de plus explicite comme "All Concept Schemes"

Le fait de voir “Ontologie” dans l’interface est franchement perturbant quand on aligne des
thesaurus. Je propose de remplacer tous les libellés “Ontologie” par “Vocabulaire” :
● “Ontologie 1:” → “Vocabulaire 1:”
● “Filtrage de la table sur onto 1” → “Filtrer sur vocabulaire 1”
● “Fichier > Charger l’ontologie 1” → “Fichier > Charger le vocabulaire 1”
● etc.

(note : je saisis les premières issues GitHub en français car j'ai déjà leur description, tu me diras si tu préfères les avoir en anglais)

This does not happen when we update the validity

Image is worth a thousand words

Currently SKOS container attempt to parse as RDF/XML and Turtle if it fails.