Skip to content

Specification

Jump to bottom
sylvainloiseau edited this page Jul 23, 2026 · 25 revisions

Spécification pour la création et l'édition d'entité

Remplace tous les tickets suivants, qui sont marqués maintenant "duplicate" :

Terminologie

  • DefinedOntologies : ontologies pour lesquelles, dans le répertoire de configuration de l'application, il y a le fichier OWL définissant l'ontologie ET il y a une section correspondante dans le fichier JSON de configuration de l'application. Pour simplifier, disons qu'une ontologie pour laquelle il n'y a que l'un ou l'autre mais pas les deux est ignorée (n'est pas comptée dnas la liste des defined ontologies)
  • ProjectOntologies : ontologies présentes (rencontrées) dans un projet, soit à travers un type, soit à travers une propriété.
  • UsedOnlyOntologies : ontologie rencontrée dans le projet mais qui n'est pas dans les DefinedOntology
  • CreateDialogue
  • TypeSelectorDialog : boite de dialogue pour ajouter des types à une entité. Cette boîte de dialogue affiche les types présent dans les DefinedOntology, pas les types qui sont dans les UsedOnlyOntology : cette boîte de dialogue offre les types dont on connait les ontologies. Si un utilisateur veut pouvoir ajouter des types appartenant à une autre ontologie, il doit d'abord éditer le fichier JSON et ajouter la définition OWL dans un répertoire.
  • PropertySelectorDialog
  • OntologiesParameters Paramètres d'une ontologie définie pour l'application LinguisticFieldArchive. Les OntologiesParameters sont lues par l'application LinguisticFieldArchive et permettent de déclarer (1) les ontologies avec lesquelles on peut éditer les données dans l'application et (2) de paramètres comment ces ontologies s'affichent (cf. mainType et mainProperty).
  • mainType : énumère les types les plus importants d'une ontologie, pour les rendre plus accessible à l'utilisateur. Défini dans les OntologiesParameters.
  • mainProperties : pour certains types d'une ontologie, définit des propriétés principale. Permet de définir une sorte de formulaire pour chaque type. Défini dans les OntologiesParameters.
  • NavigateurDeType : hiérarchie affichée à gauche dans la page d'édition des entités regroupant les entités par types. Cet arbre vise à permettre la navigation dans les entités existantes dans le projet : affiche les types effectivement trouvés dans le projet, pas les types définis dans des ontologies mais pas utilisés.

Convention

<chips>
[bouton]
[togle|togle]
_[tab|tab]_____ 
|             |        
|             |        
|             |        
|--------------                     
[_____] text field
[_____]\/ drop-down

Paramètres de l'application

Beaucoup de propositions ci-dessous présupposent que soit déjà réalisé la lecture et le parsing du fichier json de paramètre de l'application. Voir ticket #69 : Application configuration https://github.com/sylvainloiseau/FieldArchive/issues/69

-> Il faut sans doute commencer par cela.

L'application lors du démarrage découvre les ontologies qui sont présentes dans ce répertoire et qui ont une entrée dans le fichier JSON, dites DefinedOntologies. Ces ontologies sont aussi paramétrées dans le fichier json et cela conditionne l'affichage (cf. #69).

Une ontologie est dite présente dans le fichier de configuration JSON s'il y a au moins une entrée pour cette ontologie :

'ontologies' : {
   bio:{
   },
   // autres ontologies
}

Le fait que une ontologie soit une DefinedOntologie n'a d'effet que sur l'affichage des ontologies dans l'application. Cela n'empêche pas qu'un projet puisse contenir des entités et des properties dans d'autres ontologies, non connues par l'application, et qu'il faille toujours les afficher.

Ce qui affiché dans l'arbre de gauche dans la page gestion des ressources (NavigateurDeType): est uniquement ce qui est découvert dans le projet: les ProjectOntologies. Si dans le projet on trouve :

<entity> a http://dico-ontology#Entry

dans le panneau de gauche (le NavigateurDeType) il y a :

  http://dico-ontology
   - Entry

Même si une ontologie est DefinedOntology, du moment qu'il n'y a aucune entité qui a un type appartenant à cette ontologie dans le projet, inutile de le mettre dans NavigateurDeType : celui-ci présente ce qui existe réelement.

Si une entitée est créée et que on lui attribue un type de cette ontologie, cette fois l'arbre gauche doit avoir une entrée pour cette ontologie (au rafraichissement de la page)

Dans les ontologies, il faut extraire au démarrage:

  • liste des types

  • liste des propriétés, avec pour chaque propriété:

    • type du domaine
    • nom de la property
    • type du range si objectproperty
    • type si dataproperty :
      • Literal (s'il n'y a pas plus d'information)
      • type xsd:
        • Chaîne | xsd:string
        • Booléen | xsd:boolean
        • Entiers | xsd:integer, xsd:int, xsd:long, xsd:short, xsd:byte, xsd:positiveInteger, xsd:nonNegativeInteger, xsd:negativeInteger, xsd:nonPositiveInteger, xsd:unsignedInt, etc.
        • Décimaux | xsd:decimal
        • Flottants | xsd:float, xsd:double
        • Date/heure | xsd:date, xsd:time, xsd:dateTime, xsd:dateTimeStamp, xsd:gYear, xsd:gMonth, xsd:gDay, xsd:gYearMonth, xsd:gMonthDay, xsd:duration, xsd:yearMonthDuration, xsd:dayTimeDuration
        • Binaire | xsd:hexBinary, xsd:base64Binary
        • URI | xsd:anyURI
      • chaîne + langue
    • cardinalité

  • cardinalité est le nombre d'occurrence autorisé de la propriété sur une entité. Prendre en compte les cas suivants:

    • owl:minCardinality
    • owl:maxCardinality
    • owl:cardinality
    • FunctionalProperty, qui est égale à maxCardinality=1

Exemple de FunctionalProperty dans FOAF:

  <rdf:Property rdf:about="http://xmlns.com/foaf/0.1/primaryTopic"
 vs:term_status="stable" rdfs:label="primary topic" rdfs:comment="The primary topic of some page or document.">
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>

Eventuellement écrit dans un fichier csv la première fois qu'une ontologie est rencontrée (quand le fichier csv n'est pas trouvé) ; au prochain démarrage seul le fichier csv est lu:

types.csv
Person

properties.csv
domain;nom;range;type;maxCardinality;minCardinality;
           Activity;objectproperty
           xsd:dateType;dataproperty;

Pour chaque ontologie il faut aussi essayer de convenir d'un prefix, qui peut être :

  • une propriété “http://purl.org/vocab/vann/preferredNamespacePrefix” dans l'ontologie et dans ce cas prendre le litteral
  • prendre le nom du sous-répertoire de l’ontologie dans les paramètres du projet...
  • prendre le nom du dictionnaire dans le fichier JSON OntologiesParameters

Création d'une entité

La création d'une entité ouvre une fenêtre modale contenant une ou deux information à donner selon le contexte:

a/ si on sélectionne le bouton “New rico:XXX”, par exemple “new rico:Activity”, ça contient uniquement un champ texte pour saisir la dataproperty rico:name, plus la possibilité d'ajouter d'autres types.

Type : <chips: rico:Agent>       [add type(s)]

name: [______]

[create] [cancel]

b/ si on sélectionne le bouton “New entity” (au dessus du premier), ça propose en plus, d’abord, de sélectionner le type de l’entité -> un ou plusieurs types :

Type : [select type(s)]

name: [______]

[create] [cancel]

Quand on clique sur [Ajouter un type] ou [Select type] ça ouvre la fenêtre sélecteur de type (voir ci-dessous).

Le bouton [Create] est grisé tant que le champ name est vide + tant qu'il n'y a aucun type.

Quand on clique sur le bouton [Create], pour rappel, deux triples sont créés :

   <iri_resource> rdf:type rico:Activity
   <iri_resource> rico:name "xxx"

Une fois le bouton [Create] sélectionné, on ferme la fenêtre modale et on bascule dans le panneau d’édition de l’entité créée.

Lors de la création, une dataproperty http://purl.org/dc/terms/created est ajoutée sur l'object avec une estampille temporelle.

Avantages :

  • un seul contexte d’édition d’entité à maintenir (et non le formulaire de création + le formulaire d’édition)
  • limiter les contextes où l’utilisateur travaille en contexte de fenêtre modale (avec les risques de fenêtres qui s’empilent...)
  • Il est clair que l’entité est créée, sinon les boutons sont confus : on confirme la création d’une relation, mais en fait elle n’est pas créée tant que l’entité elle-même n’est créée.

Fenêtre sélecteur de type

  • Dans chaque ontologie on peut choisir un seul type.
  • Par contre on peut choisir plusieurs types issus de différentes ontologies

Fenêtre :

Au dessus : chips par type sélectionné : <rico:Agent> <foaf:Person> (petit bouton "supprimer" pour les retirer)
Button toggle : *ontology* : [rico|bio|foaf] <- ce sont les *DefinedOntologies*
                              "you can choose one type by ontology"
                                                il ne faut pas inclure les ontologies rencontrées dans le projet mais sur lesquelles on ne sait rien (ni leur classe...)
                                                c'est à dire les *UsedOnlyOntologies*
                                                rico est toujours en premier
Deuxième niveau : un drop-down: avec des sections : https://v7.material.angular.dev/components/select/overview#creating-groups-of-options
                                et si possible filtrable au clavier.
                    Si l'ontologie a une section "mainType" dans sa définition JSON:
                      Première section : "Main type"  (optionnelle, si les main types sont dans le fichier JSON)
                      Deuxième section : "All types"  par ordre alphabétique, sans les main types s'il y a des main types
                    Sinon : un dropdown sans groupes avec tous les types

                  Bouton [Enter]  [cancel]

Exemple:

*Selected*: <rico:Agent> (-) <foaf:Person> (-)
-----------------------------------------------
*ontology*: [*rico*|bio|foaf] 
            "you can choose one type by ontology"

Type in rico: 

            [Agent   ]\/

[Enter]  [cancel]

Remarque :

  • quand on crée une entité, cela fait donc deux boîtes de dialogue superposées : boîte de dialogue CreateDialog + au dessus le TypeSelectorDialog. Il me semble que ce n'est pas trop grave, car il ne peut pas y avoir davantage de boîte de dialogue au dessus. On peut chercher une autre solution du côté d'un pattern "progressive disclosure", ou bien utiliser un stepper https://v7.material.angular.dev/components/stepper/overview
  • Il n'est pas imposé à l'utilisateur de sélectionner un type de l'ontologie rico. L'utilisateur peut très bien sélectionner le type uniquement le faof:Person par exemple, si l'ontologie FOAF est une DefinedOntologies. Dans ce cas, une propriété rico:name sera quand même ajoutée à l'entité, pour le bon fonctionnement de l'application.

Une fois l'entité créée, on ouvre le panneau d'édition de l'entité

Layout

Je me demande si le panneau latéral pour éditer une entité n'est pas trop petit. Ne serait-il pas possible d'utiliser le même dispositif que dans la page de gestion des datasources, pour éditer une datasource listée dans la table des datasource : sur une ligne de la table, quand on clique sur l'icône édition, cela ouvre un espace au-dessus de la table, pour éditer. Quand on clique sur la ligne, cela ouvre un résumé read-only de l'entité (désactiver cela pour simplifier).

Dans le formulaire d’édition d'une entité, je propose qu’il n’y ait pas de bouton [validate] ou [save]... en bas : toute modification est immédiatement validée, sauf dans les champs textes où il faut cliquer sur l’icône d’un crayon pour éditer puis sur l’icône d’une tick box pour valider (comme déjà discuté: #50).

Cela est davantage compatible en plus avec le fait que le panneau soit un peu comme une page html : quand on clique sur une entité référencée comme objet d'une relation, on va sur la page d'édition de cette entité.

Lors de toute modification, la valeur de http://purl.org/dc/terms/modified est mise à jour.

Le formulaire contient des tab pour les différentes ontologies auxquelles appartiennent cette entité (pour lesquelles un type a été associé à cette entité). Serait-il possible d'utiliser des tab les un à côté des autres (https://v7.material.angular.dev/components/tabs/overview), et non pas les un en dessous des autres comme actuellement. Ou alors, des accordéons.

Layout general du panneau Entity edition 

<TypeA> (-)  <TypeB> (-)       [Add Type]
<TypeC> (-) 
_[tab1 | tab2 | tab3]____________________
|                                       |              
| # Main properties                     |                     
|                                       |                 
| *name* [balbalba_______] (-).         |
|                                       |                 
| *has or had participant*              |  
|        <a>Jeremaia</a> (-)            |    
|        [select an Agent]\/            |    
|        [create an Agent]              |  
|                                       |  
| # Properties                          |  
|                                       |  
| `[Create property]`                   |  
------------------------------------------

Champs

Principe des champs du formulaire :

Cardinalité

  • Si l'ontologie ne fournit aucune information de maxCardinality, alors on considère que c'est une cardinalité ouverte (0 ou plusieurs).

pour une dataproperty:

  name : [valeur_______] (-)
         [_____________]

pour une objectproperty:

  name : <a>valeur</a> (-)
         [_____________]\/
  • Si l'ontologie fournit une information sur la maxCardinalité et que celle ci est de 1, alors il n'y a qu'un champ offert.

dataproperty

petite icône à droite du champ pour le rendre éditable puis, si on est en mode édition, une icone pour enregistrer les validations (comme déjà discuté: #50). Chaque enregistrement déclenche une mise à jour de dcterms:modified.

Vous pouvez avoir dans le graphe:

<entity> rico:name "foo".
<entity> rico:name "bar".

Dans le formulaire il y a du coup forcément ça :

  name : [foo__________] (-)(stylo)
         [bar__________] (-)(stylo)
         [_____________]

Si l'utilisateur edit, change, et valide la première ("foo") qu'il remplace par "faa" : il faut chercher le triple <entity> rico:name "foo", le supprimer, et le remplacer par <entity> rico:name "faa". Mais il ne faut pas supprimer <entity> rico:name "bar".

Concernant les datatype:

1/ Si l'ontologie ne fournit pas d'information (autre que Literal, qui est la racine de la hiérarchie des types des dataproperties), alors on accepte n'importe quel texte; avec une lang (https://github.com/sylvainloiseau/FieldArchive/issues/16):

  name : [valeur_______][lang]

Si le datatype est Literal, lang peut être vide.

Si le datatype est un type xsd, alors on peut mettre un filtre pour valider la valeur en fonction du type. Si c'est une date, proposer un date chooser.

Si c'est explicitement un datatype rdfs:langString (text+lang) la lang doit être présente, et ne peut être vide.

name : [_____________][lang]

(lang grisé : prompt)

Quand la maxCardinalité est > 1 (explicitement ou implicitement), il n'y a aucune contrainte sur l'unicité des étiquettes de langue.

Si maxCardinalité > 1 (explicitement ou implicitement) et que le type est explicitement langString, alors il faut que le champ + la langue soit non vide pour qu'un nouveau champ vide soit offert en dessous pour accueillir une valeur supplémentaire :

  name : [valeur saisie (-)(edit) ][fr  ] 
         [                        ][lang]
  • il peut y avoir deux valeurs avec la même valeur lang. Il n'y a aucune contrainte là-dessus. Il peut également y avoir plusieurs valeurs sans langue associée.
  • lang : c'est une valeur dans un référentiel BCP 47 :

Les codes de langues

BCP 47 is based primarily on: (https://en.wikipedia.org/wiki/IETF_language_tag)

  • ISO 639 language codes (e.g., en, fr, de)
  • ISO 3166 country codes (e.g., US, CA, GB)

BCP 47 permet en fait un grand nombre de valeurs possibles : en-gb, mais aussi sl-rozaj-biske... Most triplestores only check that the tag is syntactically well-formed (rejettent par exemple en_gb) mais ne vérifient pas que ce soit réellement des noms de langues ou de pays : xx-yy est accepté...

"To verify that every subtag is officially registered would require keeping an up-to-date copy of the IANA Language Subtag Registry, which changes over time. Consequently, most RDF libraries and triplestores do not perform semantic validation against the registry."

Vérification syntaxique : Each language tag is composed of one or more "subtags" separated by hyphens (-). Each subtag is composed only of either basic Latin letters or digits. (https://en.wikipedia.org/wiki/IETF_language_tag)

Je vous propose de vérifier uniquement cela : le code match la regexp ([a-ZA-Z0-9]+)(-[a-ZA-Z0-9]+)*.

Object property

  • drop-down qui affiche les valeurs de la propriété "name" des entités du type correspondant (s'il y a plusieurs names on prend le premier).
  • une fois sélectionnée, le triple est directement créé dans le triplestore (pas de bouton [valider] en bas du formulaire). Eventuellement un bouton "add" juste à droite du drop-down.

Soit dès qu'on sélectionne une valeur dans le drop-down, le triple est créé:

  has or had participant : 
         [         ]\/

L'utilisateur à cliqué sur une valeur du drop-down, ça crée le triple :

  has or had participant : 
         <a>namedel'entite</a> (-)
         [         ]\/

Soit l'utilisateur sélectionne une valeur dans le drop-down (ça fait rien pour l'instant) et clique sur un bouton "add" pour créer le triple:

  has or had participant : 
         [         ]\/ [add]

L'utilisateur à cliqué sur [add], ça crée le triple :

  has or had participant : 
         <a>namedel'entite</a> (-)
         [         ]\/
  • une fois sélectionné/validé, le name de l'entité référencée ne s'affiche plus dans un drop-down, mais dans un cartouche, comme un lien, pour que l'on voit bien que c'est différent d'une dataproperty que l'on pourrait directement éditer.
  • Le name est une URL : quand on clique dessus, cela ouvre l'éditeur de l'entité référencée. Ajouter une petite icône "supprimer" à droite du champ pour supprimer cette objectproperty.
  • On ne peut pas éditer une iri : on peut juste la supprimer, puis en ajouter une autre (cf. section ci-dessous l'exemple de "has or had participant"). Cf ci-dessous : il faut cliquer sur (-) :
  has or had participant : 
         <a>namedel'entite</a> (-)
         [         ]\/
  • Si la cardinalité ne l'intérdit pas (s'il n'y a pas une maxCardinality de 1), il y a toujours un drop-box en dessous pour sélectionner une nouvelle IRI.

état initial :

  has or had participant : 
         [         ]\/   drop-down filtrable
         [create a new agent : à la volée]

quand une valeur a été saisie :

  has or had participant : 
         _valeur1______   (-)                    <- devenu lien hypertext
         [          ]\/   drop-down filtrable
         [create a new agent : à la volée]

-> ça crée autant de triplet qu'il y a de valeur saisie

Par exemple :

  has or had participant : 
         _valeur1______   (-)        <- lien hypertext
         _valeur2______   (-)        <- lien hypertext
         [          ]\/   drop-down filtrable
         [create a new agent]        <-  création d'entité à la volée

Dans le cas où créée un nouvelle entité à la volée au moyen du bouton [Create a new XX], il faut que le type (e.g. Agent) soit déjà proposé et il ne faut pas que l'utilisateur puisse le supprimé puisqu'il est requis pour que cette entité soit dans le range de la propriété où il est. Un autre solution est que dans la fenêtre Create, il n'y a ait pas le bouton "Add type", uniquement name.

ça crée les triplets :

<entityx> rico:hasOrHadParticipant <iri1>
<entityx> rico:hasOrHadParticipant <iri2>

le bouton [create a new agent : à la volée] ouvre une modale pour saisir le nom ; avec le type précablé, et on ne peut rien faire d'autre que définir ce nom. Une fois créé, le nom apparaît selectionné dans le drop-down.

Pourrait-on pour les drop-down utiliser un widget où on peut entrer au clavier le début d'une valeur et avoir un filtrage des valeurs :

https://angular.dev/guide/aria/autocomplete

Section "Main properties"

Pour chaque tab-ontologie, si une section mainProperty est définie pour cette ontologie dans le fichier json de paramètres, une première section Main properties est affichée ; sinon cette section est sautée.

Pour chacune des propriétés listées dans la section Main properties du fichier json des paramètres de l'application.

Le comportement pour les dataproperty et les objectproperty suit ce qui est décrit plus haut. Par exemple, pour une rico:Activité il y a la propriété has or had participant qui est dans la section mainProperties du json. Le formulaire affiche donc :

# Main properties                <- titre de section

  *name* [ valeur         ][lang]

  *has or had participant*:
     [select an Agent]\/
     [create a new agent]

[select an Agent]\/ est un drop-down qui donne la propriété name pour tous les Agents existant. [new agent] est un bouton pour créer un nouvel agent à la volée.

  • Quand un élément est sélectionné dans le drop-down, comme déjà décrit ci-dessus, il devient un text clickable et un nouveau drop-down vide apparaît en bas pour sélectionner une autre entité Agent et donc créer une autre relation :
# Main properties               <- titre de section

  *has or had participant*:
     ___jeremaia________ (-)
     [select an Agent]\/
     [create a new agent]
  • Le bouton [New agent] ouvre la fenêtre “Create an entity” c’est à dire où on peut juste mettre un name (cf. ci-dessus). Quand on clique sur Create de cette fenêtre modale (possible seulement si un name est donné, comme décrit ci-dessus), ça crée l’entité, ferme la fenêtre, et l’entité juste créée est automatiquement pré-selectionnée dans le drop-down

Ensuite il y a la section titrée Other property. Plus ci-dessous.

Les différentes ontologies

Dans le panneau d’édition, il y a des onglets pour les différentes ontologies auxquelles appartient les propriétés de l'entité éditée. Il faut un onglet pour les ontologies appartenant à l'union de ces deux contextes :

  • toute les ontologies dont l'entité appartient à l'un des types
  • toutes les ontologies auxquelles appartiennent les properties des tuples dont l'entité est le sujet.

Si une entité a :

<entity> rdf:type http://faof/v1/Person
<entity> rico:name "foo"
<entity> bio:parent <entity2>

-> il faut trois tab : Foaf, Rico, et Bio.

Ainsi :

  • pour chaque ontologie dont l'entité possède un type (par exemple, si une entité est le sujet d'un triplet tel que "<entité> rdf:type foaf:Person", alors il faut qu'il y ait un onglet pour l'ontologie FOAF pour cette entité.
  • pour chacune des ontologies auxquelles appartiennent les properties dont une entité est le sujet. Par exemple s'il y a un triplet "<entité> bio:parent 'John Doe'", alors il faut un onglet pour l'ontologie "bio" pour cette entité.

Attention, dans les deux cas (type ou propriété), l'ontologie peut-être DefinedOntology ou non. En effet l'attribution d'un type (<entit> rdf:type dico:Article) peut avoir été fait par l'utilisateur dans l'application (avec une DefinedOntology) ou venir d'un ExternalDataSource par exemple, et donc on a aucun contrôle sur le vocabulaire présent dans le projet. De même, une propriété peut venir d'un ExternalDataSource. Il peut également y avoir une propriété d'un ontologie DefinedOntology sans que l'entité ait une déclaration de type vers cette ontologie (par exemple une propriété dcterm:dateModified peut avoir été attribué à une entité, mais celle-ci ne déclare pas appartenir à un type Dcterm.

Quand l'ontology n'est pas DefinedOntology, pour créer une nouvelle propriété, il faut utiliser le formulaire permettant de :

  • rentrer à la main le nom de la propriété
  • sélectionner si on veut mettre un literal ou un objet
  • rentrer le literal ou l'IRI

Comme on ne connait pas de préfix pour cette ontologie, on est obligé de mettre l'IRI complète de l'ontologie dans le titre du tab.

Pour extraire l'IRI de l'ontologie à partir de l'IRI d'une propriété ou d'un type, on utilisera l'heuristique suivante :

  • if there is a #, split after the last #;
  • otherwise, split after the last /.

Section "Properties"

Dans la section Others properties, il y a les properties de cette entité qui n'appartiennent pas aux mainProperties. A la suite de ces propriétés, il y a le bouton [New property], qui ouvre la fenêtre PropertySelectorDialog sur laquelle vous avez travaillé la semaine dernière. Bien sûr, quand l'entité vient d'être créée, cette section est vide et contient uniquement le bouton [New property]

Quand on sollicite ce bouton, on est donc toujours dans l'un des tab, et donc dans l'une des ontologies. Dans la fenêtre PropertySelectorDialog, il n’est donc plus nécessaire de proposer à l'utilisateur de commencer par choisir l’ontologie : on est toujours dans une ontologie donnée, en fonction du tab dans lequel on est. La fenêtre ne fonctionne que pour une ontologie donnée

Fenêtre PropertySelectorDialog

je propose que dans cette fenêtre on sélectionne seulement la propriété et que, une fois la propriété choisie, on revienne dans la fenêtre principale pour sélectionner l’entité ou pour entrer la chaîne de caractère du literal. On ne sélectionne donc pas l'entité dans cette fenêtre modale. Cette fenêtre modale est une sorte de "navigateur de propriété". Ca limite le temps dans les fenêtre modale.

Il faut donc retirer la sélection des entités.

Avantages :

  • Ça permet que, un fois qu’on a sélectionné une objectproperty (par exemple 'has or had participants'), on puisse sélectionner plusieurs entités objects (et donc créer plusieurs instances de cette objects properties (comme décrit ci-dessus avec l'exemple de "has or had participant")), sans ouvrir à nouveau la fenêtre modale de sélection de la propriété.
  • peut être sera-t-il utile d'avoir un EntitySelectorDialog plus tard ; ainsi il ne se superposera pas au PropertySelectorDialog.

Dans cette fenêtre : mettre des liens hypertextes plutôt que des boutons radio : il y a uniquement à cliquer sur la propriété pour la sélectionner, fermer la fenêtre, et revenir dans la fenêtre principale d’édition. Comme ça pas besoin de scroller en bas, et un seul click est nécessaire au lieu de sélectionner + bouton "Ok".

  • Dans la liste des propriétés proposées dans la fenêtre du navigateur de propriétés, il ne doit pas y avoir les propriétés déjà proposées dans "Main properties" -> ou plutôt, si possible, mettre ces propriétés mais sans lien et avec la mention "property already added to the form".
  • Dans la liste des propriétés proposées dans la fenêtre du navigateur de propriétés, il ne doit pas y avoir les propriétés qui ont déjà été sélectionnées et pour lesquelles un triplet a été créé dans la section "Properties". -> ou plutôt, si possible, mettre ces propriétés mais sans lien et avec la mention "property already added to the form". En effet : supposons que l'on sélectionne dans le sélecteur de propriété une propriété xyz dont le range est un Agent. On retourne dans la fenêtre principae et on sélectionne un agent. Un nouveau dropdown vide est proposé ensuite en dessous. Si on veut ajouter un nouveau triplet avec cette propriété pointant sur un autre agent, on doit donc sélectioner ici un agent, en utilisant le drop-down, et non pas ré-ouvrir le sélecteur de propriété.

Table

Comme indiqué ci-dessous, le formulaire d'édition pourrait s'ouvrir au dessus de la table, tout comme le formulaire d'édition d'une DataSource s'ouvre au dessus de la table des DataSource. La table doit donc contenir une icône "édition" tout à droite (ou bien il suffit de cliquer sur la ligne). La table doit contenir également une icône "supprimer", qui déclenche une question "voulez vous supprimer l'entité". Si on supprime l'entité, ça veut dire que tous les triplets, dans le graphes internes, qui ont cette entité comme sujet ou comme objet sont supprimées.

the column "Source" and "Accès" should be removed: it is not a resource, but a triplet that belongs to a DataSource (instead, a list of the DataSources where the resource is present, as objet or subject, could be give)

colonnes avec les valeurs pour : http://purl.org/dc/terms/modified et http://purl.org/dc/terms/created

InternalDataSource vs ExternalDataSource

Dans un formulaire, il y a toujours des triplets issus de ExternalDataSource qui ne doivent donc pas être éditables : pas de bouton [delete] (pour une objectproperty) pas de bouton [edit] (pour une dataproperty), et une couleur distincte.

Pour chaque ExternalDataSource, les triplets qui y sont trouvés peuvent être présenté dans le formulaire, dans une couleur distincte, sans outil de suppression / edition des properties, avec un badge au dessus du champ pour indiquer l'origine.

Imaginons que l'on trouve une dataproperty rico:name dans l'ExternalDataSource "mygramps" avec la valeur "foo":

| # Main properties                     |                     
|                                       |                 
| *name* [balbalba_______] (-, edit)    |          
|        [foo____________] {mygramps}   |        
|        [_______________].             |

les accolades ici dénotent un badge.

Imaginons que l'on trouve une object property rico:hasOrHadParticipant:

|                                       |                 
| *has or had participant*              |  
|        <a>Jeremaia</a> (-)            |    
|        <a>Andrew </a> {mygramps}      |    
|        [select an Agent]\/            |    
|        [create an Agent]              |  
|                                       |

Autrement dit les propriétés des différentes DataSource sont groupées et présentés ensemble, mais celles issues d'ExternalDataSource sont présentées en gris, non supprimables/modifiables, et avec un badge.

Clone this wiki locally