eKB è un progetto per sviluppare delle APIs di gestione uno endpoint SPARQL. Supporta gli standard:
- SPARQL 1.1 Query Language
- SPARQL 1.1 Update
- SPARQL1.1 Service Description
- SPARQL Query Results XML Format
- SPARQL 1.1 Protocol
- SPARQL 1.1 Graph Store HTTP Protocol
Include inoltre un forward reasoner in grado di supportare le regole di produzione (espresse con SPARQL) e un backword reasoner in grado di trattare i principali assiomi RDFS e (in opzione altri Entailment Regimes).
Il servizio è compatibile con l'architettura KEES ed è utilizzato nel servizio LinkedData.Center.
Interfacce
Ogni cliente riceve le credenziali per accedere alla propria Knowledge Base e viene fornito un completo set di API RESTful per gestire autonomamente la propria base della conoscenza.
Come opzione, è possibile specificare un motore preferenziale per la memorizzazione delle triple RDF (quadstore). Le varie configurazioni del servizio permettono di supportare sino a oltre un miliardo di triple RDF.
Opzioni disponibili
- Possibilità di utilizzare il motore di memorizzazione preferito (Stardog, OpenLink Virtuoso, Apache Marmotta) fornendo la propria licenza.
- Possibilità di installare il servizio in modalità SaaS, come sw appliance (IaaS) o on premises (PaaS) su macchine fisiche o virtuali del cliente (anche interne a firewal)
Protezione da dati inconsistenti
In accordo con l'architettura KEES la base della conoscenza potrebbe trovarsi in uno stato temporaneamente inconsistente durante le fasi di acquisizione di nuovi dati (learning window) o durante le fasi di computo delle inferenze (reasoning window). Durante tali finestre temporanee, il risultato delle query alla base della conoscenza potrebbe non essere corretto.
Per gestire questo problema eKB mette a disposizione due endpoint distinti, liberamente utilizzabili dal cliente.
Un end point è protetto da una guardia che impedisce l'accesso ai dati durante le finestre di learning e di reasoning. In questi casi, ogni accesso all'end-point riceve un messaggio 503 (Service Unavailable). Nell'header http Retry-After è contenuta una stima del tempo (in secondi) che è consigliabile attendere prima di riprovare l'accesso.
L'altro end point non è protetto ed è sempre accessibile. Se ne consiglia l'uso per attività di manutenzione.