Difference between revisions of "Portal development - backend"
(17 intermediate revisions by 2 users not shown) | |||
Line 161: | Line 161: | ||
Link: | Link: | ||
*[[portal development frontend]] | *[[portal development frontend]] | ||
+ | |||
+ | == 9 Ripensamento su scelta CKAN == | ||
+ | |||
+ | === Requisiti portale === | ||
+ | ==== Harvesting: ==== | ||
+ | Il backend dovrà gestire l'harvesting di metadati da due tipologie di sorgenti: | ||
+ | * Istanze dello Starter Kit che pubblicano | ||
+ | ** Record di metadati RNDT | ||
+ | ** Record di metadati SensorML | ||
+ | * Istanze del software GI-Cat che pubblicano generici metadati ISO | ||
+ | |||
+ | L'harvesting dovrà anche provvedere al popolamento del triple store che conterrà la versione semanticamente arricchita dei metadati (insieme a tutte le strutture dati necessarie all'enactment del portale). Questi dati possono essere generati dall'EDIML secondo le definizioni contenute nel corrispondente template (in alternativa al foglio di stile che al momento implementa questa trasformazione). | ||
+ | |||
+ | Nota 1: i metadati provenienti dagli Starter Kit disporranno di un corrispondente record in formato EDIML (sia che si tratti di layer geografici che di descrizioni di sensori). I record ISO prodotti da GI-Cat avranon un EDIML corrispondente come esito del semantic lift in via di realizzazione. Quindi ha senso gestire le operazioni di harvesting a partire dall'EDIML. | ||
+ | |||
+ | Nota 2: Anche distaccandosi da CKAN, si potrebbe mantenere la struttura DCAT-based del metadato in modo da poter esportare metadati verso i vari open data portals (l'istanza di CKAN attualmente istallata può servire a testare questa funzionalità). | ||
+ | |||
+ | ==== Discovery: ==== | ||
+ | * Protocolli: | ||
+ | ** CSW | ||
+ | ** Uno o più protocolli general-purpose (es. OAI-PMH, OpenSearch, ...) | ||
+ | ** Query SPARQL indirizzata all'endpoint del portale (anche non direttamente accessibile all'utente finale, da utilizzarsi per l'estensione dei risultati da ricerca classica con ulteriori riultati ottenuti dall'informazione semantica) | ||
+ | ** Feed RSS/ATOM/ecc. (inclusi qui anche se non propriamente una discovery essendo una pratica push) | ||
+ | * Modalità: | ||
+ | ** Ricerca specifica in tutti i campi del metadato con fuzzy-matching e gestione del ranking | ||
+ | ** Gestione delle componenti della ricerca di ambito geospaziale (es. bbox, temporal extent, ...) | ||
+ | ** Definizione e gestione di facet per il raffinamento dei risultati | ||
+ | ** Query SPARQL secondo "pattern" per il momento precostituiti in grado di restituire ulteriori risultati | ||
+ | ** Integrazione di risultati ulteriori con i risultati ottenuti da una discovery classica | ||
+ | * Output: | ||
+ | ** accesso ai dati dei nodi periferici secondo gli standard esposti dagli Starter Kit | ||
+ | ** accesso ai metadati secondo differenti formati ()HTML, XML, RDF) attraverso content negotiation | ||
+ | ** harvestin g del portale da strumenti terzi (es. un altro portale) | ||
== Meetings == | == Meetings == | ||
* [[Skype call 07-07-2016|Skype call 07-07-2016]] | * [[Skype call 07-07-2016|Skype call 07-07-2016]] | ||
+ | * [[Skype call 02-08-2016|Skype call 02-08-2016]] | ||
+ | * [[Skype-call_16-09-2016|Skype call del 16-09-2016]] | ||
+ | * [[Skype-call_02-12-2016|Skype call del 02-12-2016]] | ||
+ | |||
+ | [[Category:Sviluppo Portale]] |
Latest revision as of 11:04, 2 December 2016
Contents
- 1 Server CKAN per realizzazione backend:
- 2 Next steps
- 3 1. Personalizzazione record di metadati
- 4 2. Test inserimento record RNDT
- 5 3. Verifica output RDF dei metadati corrispondenti
- 6 4. Harvesting EDIML prodotti dai vari nodi
- 7 5 Discovery attraverso la API
- 8 6. Definizione dei facet disponibili
- 9 7. Creazione di "organizations" corrispondenti a istituti
- 10 8. Note varie
- 11 9 Ripensamento su scelta CKAN
- 12 Meetings
Server CKAN per realizzazione backend:
indirizzo IP: 155.253.20.62
Next steps
- Personalizzazione record di metadati
- Test inserimento record RNDT
- Verifica output RDF dei metadati corrispondenti
- Harvesting EDIML prodotti dai vari nodi (dovrebbero essere già sul server centrale?)
- Discovery attraverso la API
- Definizione dei facet disponibili
- Creazione di "organizations" corrispondenti a istituti
1. Personalizzazione record di metadati
2. Test inserimento record RNDT
3. Verifica output RDF dei metadati corrispondenti
4. Harvesting EDIML prodotti dai vari nodi
@prefix dcat: <http://www.w3.org/ns/dcat#> . @prefix dct: <http://purl.org/dc/terms/> . @prefix vcard: <http://www.w3.org/2006/vcard/ns#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix meta: <http://def.seegrid.csiro.au/isotc211/iso19115/2003/metadata#> . @prefix basic: <http://def.seegrid.csiro.au/isotc211/iso19103/2005/basic#> . @prefix ext: <http://def.seegrid.csiro.au/isotc211/iso19115/2003/extent#> . @prefix temp: <http://def.seegrid.csiro.au/isotc211/iso19108/2002/temporal#> . @prefix qual: <http://def.seegrid.csiro.au/isotc211/iso19115/2003/dataquality#> . @prefix cite: <http://def.seegrid.csiro.au/isotc211/iso19115/2003/citation> . @prefix crs: <http://def.seegrid.csiro.au/isotc211/iso19111/2007/crs#> . <http://sp7.irea.cnr.it/metadata/$mdID> a dcat:CatalogRecord ; dct:identifier "$id_md_1"^^xsd:string ; # RNDT only dct:language <$ling_md_1_uri> ; dct:format <$chset_md_1_uri> ; # RNDT only dct:replaces <$id_file_prec_1_uri> ; dct:type <$liv_ger_1_uri> ; dcat:contactPoint [ a vcard:Individual ; vcard:hasUID <$md_resp_1_uri> ; vcard:hasRole <$md_resp_2_uri> ] ; dct:modified "$data_md"^^xsd:date ; foaf:primaryTopic <http://sp7.irea.cnr.it/data/$id> . # DCAT-specific <http://sp7.irea.cnr.it/data/$id> a dcat:Dataset ; crs:SingleCRS <sist_rif_spa_1_uri> ; # RNDT only dct:title "$tit_1"^^xsd:string ; cite:date [ a cite:Date ; date "$data_1"^^xsd:date ; dateType <$data_2_uri> ] ; dct:identifier "$id_1"^^xsd:string ; dcat:contactPoint [ a vcard:Individual ; # RNDT only vcard:hasUID <$resp_1_uri> ; vcard:hasRole <$resp_5_uri> ] ; dct:type <$pres_form_1_uri> ; # RNDT only dct:isPartOf <$id_liv_sup_1> ; # RNDT only skos:note "$altri_dettagli_1"^^xsd:string ; # RNDT only dct:description "$desc"^^xsd:string ; dcat:contactPoint [ a vcard:Individual ; vcard:hasUID <$pdc_1_uri> ; vcard:hasRole <$pdc_2 _uri> ] ; dct:accrualPeriodicity <$freq_agg_1_uri> ; # INSPIRE Theme dcat:theme <$tem_ins_1_uri> ; # keyword from controlled vocabulary dcat:theme <$keyw_voc_contr_1_uri> ; # observed parameter dcat:theme <$par_oss_1_uri> ; # RITMARE only # free-text keyword dcat:keyword "$keyw"^^xsd:string ; meta:resourceConstraints[ a LegalConstraints; meta:useLimitation "$lim_uso_1"^^xsd:string ; meta:accessConstraints <$vinc_acc_1_uri> ; meta:useConstraints <$vinc_frui_1_uri> ; # RNDT only meta:otherConstraints "$altri_vinc_1"^^xsd:string ] ; meta:resourceConstraints[ a SecurityConstraints; meta:classification <$vinc_sic_1_uri> ] ; meta:spatialRepresentationType <$tip_rap_spa_1_uri> ; # RNDT only meta:equivalentScale "$sca_equ_1"^^xsd:integer ; # RNDT only meta:distance "$dist_1"^^xsd:integer ; # RNDT only dct:language <$ling_1_uri> ; dct:format <$charset_1_uri> ; # RNDT only # topic category dcat:theme <$cat_tem_1_url> ; dct:spatial [a ext:GeographicBoundingBox; ext:eastBoundLongitude "$loc_geo_2"^^xsd:decimal; ext:westBoundLongitude "$loc_geo_1"^^xsd:decimal; ext:southBoundLatitude "$loc_geo_4"^^xsd:decimal; ext:northBoundLatitude "$loc_geo_3"^^xsd:decimal ]; ext:minumumValue "$est_vert_1"^^xsd:decimal ; # RNDT only ext:maximumValue "$est_vert_2"^^xsd:decimal ; # RNDT only ext:verticalCRS <$est_vert_3_uri> ; # RNDT only dct:temporal [ a ext:TemporalExtent; temp:begin "$est_temp_1"^^xsd:date; temp:end "$est_temp_2"^^xsd:date ]; meta:supplementalInformation "$info_suppl_1"^^xsd:string ; # RNDT only dcat:contactPoint [ a vcard:Individual ; # RNDT only vcard:hasUID <$distr_1_uri> ; vcard:hasRole <$distr_2 _uri> ] ; dcat:landingPage <$ris_online_1> ; meta:dataQualityInfo [ a qual:DataQuality ; # qual:scope <$liv_ger_1_uri> ; FIXED qual:report [ a qual:PositionalAccuracy ; basic:uom <http://www.bipm.org/en/si/base_units#m> ; basic:value "acc_pos_5"^^xsd:real ] ]; dct:provenance "$gene_1"^^xsd:string .
5 Discovery attraverso la API
6. Definizione dei facet disponibili
7. Creazione di "organizations" corrispondenti a istituti
- verifica se la loro definizione aggiunge qualcosa all'espressività della ricerca (es. riferendo i record di metadati all'organizzazione corrispondente)
- verifica se la definizione di "groups" posa aggiungere qualcosa
8. Note varie
Portale:
- indirizzo esterno http://155.253.20.62/
- indirizzo interno http://10.0.0.34/
Installazione CKAN API
EMDIML GetIT
- trasformazione con XSLT (già pronto) può produrre RDF INSPIRE (in allegato i due xslt che trasformano l'EDIML)
- l'RDF viene archiviato
- trasformazione con XSLT? (deve essere ancora preparato) per produrre input per CKAN
- plugin per CKAN che riconosca il nostro formato metadati
- esportare da CKAN il metadato in RDF (utilizzando la mappatura utilizzata nel plugin di cui sopra
Test con GeoSK http://geosk.ve.ismar.cnr.it/
Tipologia di risorse in un GeIT:
- versione 1 di EDI
- versione 2 di EDI
- risorse layer, mappe, documenti con metadati ISO non EDIML (da caricare nel backend ma da ignorare per la conversione RDF - per ora-)
Attività addizionali:
- preparare API con lista delle risorse metadatate con EDIML
- la lista deve puntare alla risorsa ediml
- http://geosk.ve.ismar.cnr.it/layers/geonode:writegdal_pheno2/ediml
- a questo indirizzo è disponibile la nuova API: http://geosk.ve.ismar.cnr.it/mdtools/api/listediml
Link:
9 Ripensamento su scelta CKAN
Requisiti portale
Harvesting:
Il backend dovrà gestire l'harvesting di metadati da due tipologie di sorgenti:
- Istanze dello Starter Kit che pubblicano
- Record di metadati RNDT
- Record di metadati SensorML
- Istanze del software GI-Cat che pubblicano generici metadati ISO
L'harvesting dovrà anche provvedere al popolamento del triple store che conterrà la versione semanticamente arricchita dei metadati (insieme a tutte le strutture dati necessarie all'enactment del portale). Questi dati possono essere generati dall'EDIML secondo le definizioni contenute nel corrispondente template (in alternativa al foglio di stile che al momento implementa questa trasformazione).
Nota 1: i metadati provenienti dagli Starter Kit disporranno di un corrispondente record in formato EDIML (sia che si tratti di layer geografici che di descrizioni di sensori). I record ISO prodotti da GI-Cat avranon un EDIML corrispondente come esito del semantic lift in via di realizzazione. Quindi ha senso gestire le operazioni di harvesting a partire dall'EDIML.
Nota 2: Anche distaccandosi da CKAN, si potrebbe mantenere la struttura DCAT-based del metadato in modo da poter esportare metadati verso i vari open data portals (l'istanza di CKAN attualmente istallata può servire a testare questa funzionalità).
Discovery:
- Protocolli:
- CSW
- Uno o più protocolli general-purpose (es. OAI-PMH, OpenSearch, ...)
- Query SPARQL indirizzata all'endpoint del portale (anche non direttamente accessibile all'utente finale, da utilizzarsi per l'estensione dei risultati da ricerca classica con ulteriori riultati ottenuti dall'informazione semantica)
- Feed RSS/ATOM/ecc. (inclusi qui anche se non propriamente una discovery essendo una pratica push)
- Modalità:
- Ricerca specifica in tutti i campi del metadato con fuzzy-matching e gestione del ranking
- Gestione delle componenti della ricerca di ambito geospaziale (es. bbox, temporal extent, ...)
- Definizione e gestione di facet per il raffinamento dei risultati
- Query SPARQL secondo "pattern" per il momento precostituiti in grado di restituire ulteriori risultati
- Integrazione di risultati ulteriori con i risultati ottenuti da una discovery classica
- Output:
- accesso ai dati dei nodi periferici secondo gli standard esposti dagli Starter Kit
- accesso ai metadati secondo differenti formati ()HTML, XML, RDF) attraverso content negotiation
- harvestin g del portale da strumenti terzi (es. un altro portale)