Difference between revisions of "Skype call 07-07-2016"
Line 21: | Line 21: | ||
** l'alternativa e' un backend from scratch | ** l'alternativa e' un backend from scratch | ||
*** introdurrebbe l'onere di organizzare l'harvesting ma offre l'opportunità di decidere lo schema e il repository per i metadati | *** introdurrebbe l'onere di organizzare l'harvesting ma offre l'opportunità di decidere lo schema e il repository per i metadati | ||
− | * backend per gestione profili utente, descrizione dei widget, file di log | + | * backend per gestione profili utente, descrizione dei widget, file di log, ecc. |
Revision as of 14:45, 7 July 2016
Finalità
Procedere nella definizione dei requisiti del backend in modo da selezionare in tempi brevi la piattaforma o insieme di librerie che lo realizzino.
Requisiti
- consentire l'harvesting dei nodi Ritmare, che siano essi nodi Get-it, istanze Thredds, o altri contributi
- essendo necessariamente parziale la descrizione (metadati) delle risorse da harvestare, non partirei dal presupposto di descrivere in modo esaustivo le risorse eterogenee dell'infrastruttura Ritmare
- un punto di partenza può essere l'abilitazione per queste risorse di una discovery text-based che segua il paradigma WWWW (who, what, where, when) discusso in passato
- l'harvesting secondo il protocollo CSW potrebbe essere il fattore comune da abilitarsi, eventualmente tramite brokering dei nodi attraverso GI-Cat
- meccanismi di discovery più raffinati (es. espansione semantica, ricerca di sensori/osservazioni tramite i protocolli specifici di SOS) potrebbero poi venire realizzati attraverso componenti aggiuntive (es. un triple store che contenga i metadati RDF) e widget dedicati
- questo dovrebbe consentire all'utente di discriminare tra una discovery CSW tradizionale e una più fine discovery semantica, piuttosto che la discovery di osservazioni tramite Thredds rispetto al corrispettivo SOS
- è ipotizzabile un meccanismo di semantic lift per i metadati non prodotti tramite Get-it (avrei già una ipotesi in merito) ma per il momento partirei dal presupposto che solo le risorse provenienti da nodi Get-it abbiano questa caratteristica
- supportare le funzionalità richieste dal frontend
- autenticazione
- gestione profilo utenti
- rappresentazione e articolazione dei widget
- supporto a widget specifici
Piattaforme/librerie
- backend per metadati/discovery ecc.
- 10gg per Stefano e Diego in modo da testare approfonditamente CKAN
- l'alternativa e' un backend from scratch
- introdurrebbe l'onere di organizzare l'harvesting ma offre l'opportunità di decidere lo schema e il repository per i metadati
- backend per gestione profili utente, descrizione dei widget, file di log, ecc.