Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pianificazione Funzioni Repository Annotazioni #278

Open
mnamici opened this issue Apr 22, 2024 · 2 comments
Open

Pianificazione Funzioni Repository Annotazioni #278

mnamici opened this issue Apr 22, 2024 · 2 comments
Assignees

Comments

@mnamici
Copy link
Collaborator

mnamici commented Apr 22, 2024

Di seguito elenco alcune considerazioni sulle funzionalità da implementare per il repository delle annotazioni.

Al momento stiamo immaginando i seguenti step di utilizzo:

  1. Tramite un nuovo tab nell'ontology manager, configurare la connessione al repository (REST).
    Salvare l'indirizzo del repository tra le preferenze utente (potrebbe essere utile configurare una lista dei repository consultabili?)
  2. Realizzare un'interfaccia in stile ontology explorer dove poter consultare le informazioni memorizzate nel repository (lista entità, ricerca, consultazione annotazioni delle entità).
  3. Una volta selezionata l'entità da utilizzare, supportare il d&d dal pannello di consultazione del repository al diagramma con inserimento del nodo appropriato.
  4. Tenere traccia dei nodi creati in questo modo indicando in una annotazione il repository di provenienza ed eventuali altri metadati (es. versione del repository).
  5. Supportare la visualizzazione delle annotazioni importate dal repository in modo che non debbano essere salvate nel graphol, questo potrebbe essere implementato attraverso una funzionalità del metodo getAnnotationAssertions dei nodi entità in modo tale che ritorni anche le annotazioni provenienti dal repository. Forse per separare le annotazioni definite nel progetto graphol da quelle provenienti da repository esterni è sufficiente aggiungere una annotazione speciale ai tipi graphol e, quando si consultano le annotazioni di una occorrenza, fare la richiesta REST e mostrare le annotazioni importate in una tabella separata.
  6. Aggiungere verifica nell'esportatore graphol per la presenza di annotazioni che indicano la provenienza da repository esterni, ed in tal caso evitare di salvare tali annotazioni nel file graphol.
  7. L'esportatore OWL ed il resto ottengono in automatico il comportamento desiderato (includere annotazioni esterne).

Rimangono alcuni punti non molto chiari al momento:

  • Quale deve essere il comportamento dell'esportazione delle annotazioni? Se si esportano in excel, e poi si reimportano modificate nel progetto graphol vanno a finire le annotazioni provenienti dal repository esterno.
  • Quale annotazione usare per annotare che un nodo proviene da un repository esterno? Come ogni annotazione va gestita la possibilità di avere più di una occorrenza, in tal caso l'unione è probabilmente la soluzione più corretta.
@mnamici
Copy link
Collaborator Author

mnamici commented Jun 7, 2024

La prima iterazione della funzionalità del repository è stata integrata.
Lo stato attuale è consultabile dal branch metastat.

@mnamici
Copy link
Collaborator Author

mnamici commented Jun 10, 2024

Aggiungo alcuni punti sui quali possiamo ragionare durante la prossima riunione:

Relativamente all'interfaccia REST, ci sono le seguenti funzionalità su cui prendere una decisione:

  1. Quali sono i requisiti di autenticazione previsti per il servizio?
    Qui è possibile adottare diverse modalità, ad esempio:
  • Utilizzare un'autenticazione a token, con utenze gestite separatamente per questo servizio;
  • Utilizzare un'autenticazione di tipo SSO, passando per un servizio esterno per ottenimento e verifica del token. Questo può essere utile se si prevede che le utenze siano gestite separatamente.
  1. Qual'è il volume atteso di entità del DB?
    Questo potrebbe determinare il tipo di interfacciamento migliore. Al momento le rotte permettonono di ottenere tutte le entità definite, e il filtraggio viene fatto client-side, ma se il si prevede una quantità molto elevata di entità, sarebbe più appropriato passare per un servizio di ricerca server-side.

Poi ci sono alcuni punti dettati dal passaggio DB->OWL:

  1. Le IRI saranno parte del DB o devono essere generate dinamicamente attraverso, ad esempio, template?
  2. Si prevede che il DB gestisca i prefissi del formato RDF?
    Al momento il servizio non ha la nozione di prefisso (che è una nozione legata al formato di serializzazione), e la presentazione nell'interfaccia segue i prefissi del progetto. Se per qualche ragione si vuole che tutti i progetti condividano le stesse IRI prefissate, va deciso come gestire la cosa.

Infine una considerazione di natura generale:

  1. E' auspicabile avere una forma di raggruppamento delle entità nell'interfaccia grafica, ad esempio per categorie associate alle entità?
    Ovviamente si intende una forma molto semplice, ad 1 o al massimo 2 livelli, estratti esplicitamenete dal DB, non una classificazione semantica con un albero dei concetti, perché questo contraddice un pò il fatto di non partire subito da un catalogo di ontologie.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants