översikt

ROBOT ger ett standardiserat men konfigurerbart sätt att stödja ontologiutvecklingslivscykeln via ett bibliotek med gemensam funktionalitet på hög nivå och ett kommandoradsgränssnitt. ROBOT bygger på OWL API och är kompatibel med alla ontologisyntaxer som OWL API stöder: RDF/XML, OWL/XML, Turtle, OWL Functional Syntax, OWL Manchester Syntax och OBO-format. Källkoden är skriven i Java och är tillgänglig från vårt GitHub-arkiv under en öppen källkod (BSD 3) – licens. Det släpps också som ett Java-bibliotek på Maven Central. ROBOTKOD kan användas från alla programmeringsspråk som körs på Java Virtual Machine (JVM). Kommandoradsverktyget är förpackat som en JAR-fil som kan köras på Unix (inklusive macOS och Linux), Windows och andra plattformar som stöds av JVM. Denna JAR-fil är tillgänglig för nedladdning från ROBOT GitHub-webbplatsen , tillsammans med plattformsspecifika skript för att använda ’robot’ från kommandoraden. Installationsanvisningar och dokumentation finns tillgängliga från http://robot.obolibrary.org.

arkitektur

vi beskrev tidigare verktygets grundläggande arkitektur, som vi sammanfattar här.

robotens källkod består av två delar: ’robot-core’ och ’robot-command’. ”robot-core ”är ett bibliotek som stöder gemensamma ontologiska utvecklingsuppgifter, som vi kallar”operationer”. ”robot-command” tillhandahåller ett kommandoradsgränssnitt uppdelat i” kommandon”, som var och en sveper en ”robot-core” – operation.

de flesta ROBOTOPERATIONER paketerar lågnivåfunktionalitet som tillhandahålls av OWL API till högnivåfunktionalitet som är gemensam för ontologiutvecklingsarbetsflöden i OBO-samhället. För bästa kompatibilitet strävar vi efter att matcha den exakta versionen av OWL API som används av ROBOT med den exakta versionen som används av den senaste Prot Ozong-versionen. Vissa operationer använder Apache Jena . Varje operation fungerar med Java-objekt som representerar OWL ontologier, OWL reasoners,OWL klasser, etc., medan varje kommando fungerar med kommandoradsalternativ strängar och filer. Kommandona utför också olika konverterings-och valideringssteg. Kommandoradsgränssnittet använder Apache Commons CLI-biblioteket för att analysera kommandon.

varje operation har en uppsättning enhetstester byggda med JUnit som körs varje gång slutprodukten (JAR-filen) genereras. Varje kommando i ROBOT dokumenteras på sin egen webbsida (t.ex. http://robot.obolibrary.org/reason). Webbsidorna är författade i Markdown-format och innehåller inbäddade kommandoradsexempel som analyseras och exekveras som en del av våra integrationstester, med resultaten jämfört med en ”guldstandard” uppsättning utgångar. Robots ’diff’ – funktionalitet används när man jämför ontologifiler, annars används standardfiljämförelse. Detta bidrar till att säkerställa korrekthet och konsekvens av dokumentation och kod. Enhetstesterna och integrationstesterna utförs på varje dragförfrågan på kodbasen via Travis continuous integration (Travis CI), så att Bidrag till kodbasen verifieras.

kommandon och operationer

ROBOT tillhandahåller för närvarande 15 operationer (i biblioteket ’robot-core’) och 19 kommandon (för kommandoradsgränssnittet). Vissa kommandon är ganska specialiserade, och de flesta ontologiprojekt kommer inte att använda dem alla. Här ger vi en översikt över de vanligaste och allmänna kommandona. I varje fall stöds kärnfunktionen av operationer i’ robot-core ’ -biblioteket, som kan användas oberoende av kommandoradsgränssnittet från vilket programmeringsspråk som helst som körs på JVM.

konvertera

en mängd olika OWL-ontologiformat stöds, inklusive RDF / XML, Turtle, Manchester, OBO-format och mer. För att möjliggöra ytterligare interoperabilitet, ROBOT innehåller en’ konvertera ’ kommando för att ändra mellan stöds ontologi format. En fullständig lista över format som stöds kan hittas i’ Konvertera ’ dokumentation .

resonemang

resonemang är en av de viktigaste operationerna i ROBOT. Kommandot reason omfattar två användningsområden: logisk validering av en ontologi och automatisk klassificering. I båda fallen kan användarna välja sin föredragna reasoner, som används för att utföra inferens. Stora ontologier som Gen ontologi använder vanligtvis älg, som utför resonemang snabbt med OWL EL-profilen. Mindre ontologier med rikare axiomatisering, såsom Relations ontologi, använder vanligtvis en komplett Uggla DL reasoner som eremit .

när kommandot’ reason ’ åberopas på en input ontology, kommer ROBOT att initiera en reasoner med OWL API Reasoner-gränssnittet. De resulterande slutsatserna kontrolleras för att säkerställa att ontologin är logiskt sammanhängande: ontologin måste vara konsekvent och inte ha några otillfredsställande klasser (dvs., klasser som inte kan instanseras utan att införa en inkonsekvens). Om ontologin är osammanhängande rapporteras detta och utförandet stoppas. ROBOT kan eventuellt utföra ytterligare kontroller, till exempel att se till att inga två klasser anses vara likvärdiga efter resonemang.

om ontologin är konsekvent kommer roboten att utföra automatisk klassificering. Alla direkta härledda ’underklass’ Axiom läggs till ontologin. Generering av andra typer av axiom kan konfigureras.

påståendet av alla härledda axiomer är ofta ett grundläggande steg i frisättningsprocessen för biomedicinska ontologier. Många av dessa ontologiklasser hävdar bara en enda namngiven superklass (’a underklass B’, där B är en annan klass i ontologin) och noll eller flera anonyma superklasser och/eller anonyma ekvivalenta klasser (’a underklass/ekvivalentto (r vissa B)’, där R är en objektegenskap). Dessa anonyma klasser tillåter reasoner att göra slutsatser, som sedan hävdas. Därför kan en klass i versionen av en ontologi ha mer än en namngiven superklass.

kommandot ” reason ”har ytterligare” helper ” – kommandon. Kommandot ’relax’ hävdar innebar underklass av axiom enligt en enkel strukturell regel: ett uttryck ’a ekvivalentto (r vissa B) och …’ innebär ’a underklass av r vissa B’. Detta kan vara användbart eftersom konsumenter av bio-ontologier ofta förväntar sig att navigera i dessa uttryck, t.ex. partonomi I GO och Uberon. Kommandot ’relax’ befriar ontologiutvecklaren från behovet av att hävda dessa utöver ekvivalensaxiomerna, och som sådan ingår det också ofta i släpparbetsflöden. Slutligen tar kommandot ’ minska ’bort redundanta underklasser av axiom och kan användas efter’ koppla av ’ för att ta bort dubbla axiom som hävdades i det steget.

kommandot materialisera använder en Expression Materializing Reasoner (EMR) för att hävda härledda uttryck för formen ’en underklass av r vissa B’ . Där ’reason’ kommandot hävdar härledda namngivna superklasser,’ materialisera ’ hävdar anonyma superklasser. Detta är inte en del av standardfrisättningscykeln men kan vara fördelaktigt för att skapa kompletta ontologiska delmängder.

arbeta med externa ontologier

OBO-gjuteriet syftar till att samordna ontologier på ett modulärt sätt, så att delar av vissa ontologier kan användas som byggstenar för andra ontologier. Till exempel används chebi chemical entities ontology för att konstruera UGGLADEFINITIONER för metaboliska processer och aktiviteter i Gen ontologin . Det finns en mängd olika strategier för att utnyttja externa ontologier och hantera beroenden mellan ontologier, beroende på användningsfallet.

Extract

kommandot ’extract’ skapar en modul baserad på en uppsättning enheter att extrahera (”seed”). Det finns fyra olika extraktionsmetoder (som specificeras av alternativet ’–method’): MIREOT, TOP, BOT och STAR.

Robots mireot-extraktionsmetod baseras på principen med samma namn och kräver att en eller flera ”botten” – enheter anges. Eventuellt kan en eller flera” topp ” enheter också anges. Kommandot extraherar alla enheter på” botten ” nivå och deras förfäder upp till ”topp” nivå från ingångs ontologi. Om inga ”topp”-enheter tillhandahålls ingår förfäder upp till toppnivån (”owl: Thing”).

topp -, BOT-och STJÄRNMETODERNA använder implementeringen av OWL API Syntactic Locality Module Extraction (SLME), vilket garanteras att fånga all information som är logiskt relevant för fröuppsättningen . BOTMETODEN (”botten”) inkluderar alla relationer mellan inmatningsenheterna och deras förfäder. TOPPMETODEN inkluderar alla relationer mellan inmatningsenheterna och deras ättlingar. Slutligen inkluderar STJÄRNMETODEN bara alla relationer mellan inmatningsenheter. STJÄRNMETODEN producerar de minsta utgångarna, medan TOPPMETODEN vanligtvis producerar de största utgångarna.

för att stödja ontologitermens ursprung har kommandot ’extract’ Ett ’–annotate-with-source true ’ – alternativ som kommer att kommentera varje extraherad term med webbadressen till källontologin som den extraheras från.

ta bort och filtrera

kommandona ’ta bort’ och ’filter’ används för finkorniga operationer på OWL Axiom. ’ta bort’ tillåter användare att välja vilka uppsättningar Axiom de vill ta bort från ett mål ontologi. ’filter’ gör det motsatta, så att endast valda Axiom kopieras från ingången till en ny output ontologi.

dessa två kommandon fungerar genom att börja med en fröuppsättning enheter, sedan använda olika väljare för att hitta relaterade enheter och slutligen välja vilka axiomtyper som ska tas bort eller filtreras. Vi förväntar oss bara ett litet antal ”kraftanvändare” att använda den här funktionen direkt, men dessa kommandon kommer så småningom att ge en grund för andra kommandon på högre nivå.

dessa kommandon kan användas för att generera ontologiundergrupper baserade på anteckningar genom att antingen filtrera efter eller ta bort enheter med den angivna anteckningen. OBO Foundry-ontologier kommenterar ofta klasser med egenskapen’ i delmängd ’ för att ange var en klass kan användas. Med annoteringsväljaren kan en användare ange ett fullständigt annoteringsvärde eller ett mönster som matchar med reguljärt uttryck.

sammanfoga

kommandot ’sammanfoga’ kombinerar två eller flera separata ingångs ontologier i en enda ontologi. Det ger också möjlighet att slå samman alla importerade ontologier av en enda inmatad ontologi till en huvud ontologi, som ofta används när man skapar en release.

sammanslagning av importerade ontologier (specificerad av importdeklarationer) till indata ontologin utförs automatiskt, så att användaren inte behöver lista varje importerad ontologi som en inmatning. Vi erbjuder alternativet (’–collapse-import-closure false’) för att stänga av den här funktionen, stödja fall där användare kan slå samman flera indata ontologier som har importdeklarationer men vill hålla importen separat.

frågande och rapportering

Ontologiarbetsflöden inkluderar vanligtvis frågeoperationer över ontologin, som producerar rapporter som kan vara informativa för både redaktörer och användare av ontologin-till exempel en tabell över alla klasser plus deras textdefinitioner. Frågeoperationer kan också användas för valideringskontroller. SPARQL-frågespråket ger ett universellt och deklarativt sätt för ontologiansvariga att skapa ontologirapporter och valideringskontroller . ROBOT ger ett bekvämt sätt att utföra frågor med kommandot ’query’ eller valideringskontroller med ’verifiera’. Dessutom innehåller kommandot’ rapport ’ ett konfigurerbart paket med standardfrågor för OBO-projekt som kan användas i alla ontologiska arbetsflöden, utan att kräva att underhållaren känner till SPARQL.

Query

Robots ’query’ – kommando kör SPARQL-frågor på ontologier eller andra RDF-resurser. Detta kan användas av en ontologiansvarig för att antingen utföra interaktiva frågor eller mer typiskt för att inkludera standardfrågor i ett ontologiarbetsflöde. Kommandot ’query’ sveper en av de få operationer som använder Apache Jena , snarare än OWL API. Jena API tillåter ROBOT att ladda en ontologi som en samling tripplar som ingår i ett RDF-modellobjekt. Det ger en SPARQL-frågemotor för de modellerna, som vi använder för att köra alla frågor.

’SPARQL SELECT’ – frågor ger en kommaseparerad tabell med resultat. Ställ frågor producera en fil med ett booleskt värde. ’SPARQL CONSTRUCT’ – frågor producerar en RDF-fil, som kan bearbetas vidare av ROBOT eller slås samman tillbaka till den laddade ontologin. ”CONSTRUCT’ s ger ett bekvämt sätt att utföra” Makro ” stil expansion . ’SPARQL UPDATE’ – frågor infoga och / eller ta bort data direkt i en ontologi (som en RDF-Modell). ROBOT konverterar den uppdaterade RDF-modellen tillbaka till ett OWL API-ontologiobjekt som ska sparas i någon av de syntaxer som stöds.

kommandot ’query’ stöder ett alternativ för att ladda importerade ontologier som namngivna grafer med alternativet ’–use-graphs’. Om detta är inställt på ’true’ kan importen frågas som namngivna grafer (namnet är den ontologins IRI) och standardgrafen är en union av alla grafer. Att använda standarddiagrammet liknar att göra en sammanslagning av all import före frågan, men skillnaden mellan importen skulle gå förlorad i en sammanslagning.

verifiera

kommandot ’verifiera’ är en variant av körningen ’SPARQL SELECT’. Frågorna används för att säkerställa att en ontologi överensstämmer med en förutbestämd uppsättning villkor; till exempel, se till att ingen klass har flera textdefinitioner. Med en SELECT-fråga lyckas ’verifiera’ (dvs avsluta med statuskod 0) om inga resultat returneras. Det kommer att misslyckas (dvs., avsluta med en icke-noll statuskod) om några resultat returneras från frågan. Så, med tanke på en SPARQL-fråga som väljer för ogiltiga data, verifierar kommandot’ verifiera ’ att ontologin (eller annan resurs) inte innehåller några sådana ogiltiga data.

rapport

kommandot ’rapport ’är en förlängning av’ fråga ’och’ verifiera ’ som ger en serie konfigurerbara kvalitetskontroller (QC) för en ontologi och returnerar ett kalkylblad eller YAML-utgång av överträdelserna. Kalkylbladet matas ut i antingen kommatecken-eller tab-separerade format och lätt för en användare att läsa, medan YAML utgång kan enkelt analyseras av andra program.

QC-kontrollerna inkluderar anteckningskontroller, logiska kontroller och metadatakontroller. Anteckningar är viktiga för att underlätta mänsklig förståelse, så kommandot rapport hittar fall där saknade eller dubbla anteckningar kan orsaka problem. Logiska kontroller tittar på ontologins strukturella koherens och konsistens. Slutligen identifierar’ rapport ’ saknad ontologi metadata, som specificeras av OBO Foundry rekommendationer.

det finns tre nivåer av överträdelser som rapporteras: fel, varning och INFO. Ett fel är det allvarligaste, till exempel en saknad eller dubblett etikett. Som standard misslyckas kommandot ’rapport’ om det finns några felnivåöverträdelser, vilket stoppar alla automatiserade byggprocesser. Dessa typer av överträdelser måste fastställas innan man publicerar en ontologi. Överträdelser på Varningsnivå bör fastställas så snart som möjligt, t.ex. härledda en-till-en-klassekvivalenser, som vanligtvis är oavsiktliga i OBO-projekt. INFO är för rekommenderade korrigeringar som hjälper till att upprätthålla konsistens över OBO Foundry ontologier, till exempel att börja en definition med en stor bokstav och sluta med en period. ’rapport’ kan konfigureras med ett kommandoradsalternativ för att misslyckas på en annan överträdelsenivå eller att aldrig misslyckas, oavsett eventuella överträdelser. Vi dokumenterar varje QC-kontroll med ett förslag på en manuell fix som användaren kan tillämpa.

en standard ”profil” med rapportnivåer för varje QC-kontroll tillhandahålls av ROBOT, men användare kan också skapa egna profiler. I dessa profiler kan de ändra överträdelsenivåerna för enskilda kontroller, välja att utesluta vissa kontroller och lägga till egna kontroller som SPARQL-frågor. Till exempel kan vissa ontologier kategorisera en klass som saknar en textdefinition som ett fel, medan andra kan kategorisera detta som en varning. Ett av våra mål är att konvergera på en standardprofil som är maximalt användbar för uppsättningen av alla ontologier i OBO-biblioteket, vilket uppmuntrar till antagande av gemensamma kvalitetskontroller.

reparera

även om de flesta problem som uppstår av ’validera’ och ’rapport’ måste åtgärdas manuellt, ger ROBOT också ett ’reparation’ – kommando som automatiskt kan åtgärda vissa problem. Den nuvarande implementeringen sammanfogar anteckningar på dubbla Axiom och uppdaterar referenser till föråldrade klasser när de kommenteras med en föreslagen ersättning. Vi har för avsikt att utvidga ’reparation’ till ett bredare spektrum av vanliga problem för vilka rätt fix är tydlig.

Templated ontology development

ROBOT ger en mall-driven ontologi term generation system. Användare har också möjlighet att ansluta sitt eget termgenereringssystem till sitt arbetsflöde, till exempel Dead Simple OWL Design Patterns (DOS-DPs) .

en stor mängd data lagras i kalkylblad och databaser, och tabellformat är väl lämpade för många typer av data. Robots mallkommando tillåter användare att konvertera tabelldata till RDF/OWL-format. En ROBOTMALL är helt enkelt en tab-separated values (TSV) eller comma-separated values (CSV) – fil med några speciella konventioner, som beskrivs i robotens malldokumentation .

dessa mallar kan användas för modulär ontologiutveckling. Mallkalkylbladet kan upprätthållas som en del av ontologins källkodsförvar, och istället för att direkt redigera ontologifilen redigerar Utvecklare rader i kalkylbladet som motsvarar termer i ontologin. Kommandot ’mall’ används sedan för att generera en modul i ontologin, som ingår som ett importuttalande i redaktörernas version av ontologin och slås samman under utgivningsprocessen.

arbetsflöden

ett arbetsflöde består av en uppsättning uppgifter som samordnas av vissa arbetsflödessystem. Ontologiarbetsflöden består av uppgifter som att utföra QC-kontroller, bygga importmoduler, resonera över ontologier och generera olika ontologiprodukter.

roboten själv är inte en arbetsflödeshanterare, även om den tillåter att flera kommandon kedjas ihop till ett långt kommando. Vid kedjning av ROBOTKOMMANDON skickas utdata ontologin från ett kommando direkt som ingång till nästa kommando. Till exempel kan kedja användas för att ersätta två kommandon som sammanfogar ontologier och sedan resonera över den sammanslagna produkten:

`robot merge –input ont-1.owl — ingång ont-2.owl-utgång samman.uggla.

robot anledning-inmatning sammanslagna.owl-utgång motiverad.uggla`.

istället för att skapa den sammanslagna produkten och köra ’reason’ över det, kan det göras i ett kommando:

`robot merge –input ont-1.owl — ingång ont-2.owl anledning-utgång motiverad.uggla`.

den viktigaste fördelen med kedja är att ontologier inte behöver serialiseras och analyseras mellan varje steg; samma OWL API ontology-objekt upprätthålls i minnet och passerar genom kedjan av ROBOTKOMMANDON. För stora ontologier kan kedjning avsevärt förbättra robotens prestanda.

eftersom ROBOTKOMMANDON kan köras på kommandoraden kan ett antal olika arbetsflödessystem användas. Vi lyfter fram användningen av GNU Make, som vanligtvis används för att kompilera programvara. En Makefile består av en uppsättning regler som används för att göra ”mål”. I ontologiutveckling används Makefilen för automatiserade uppgifter, till exempel att förbereda en ontologi för frisläppande. I detta fall är målen vanligtvis ontologifiler. ”Recepten” för reglerna är systemkommandon i Unix-stil, utförda av kommandot ”make”.

ROBOTKOMMANDON kan användas som ”recept” för att göra ”mål”. Ett typiskt arbetsflöde använder inte alla 19 av ROBOTKOMMANDONA. Till exempel kan inte alla ontologiprojekt använda ROBOTMALLAR och därför behöver inte alla release-arbetsflöden inkludera kommandot Mall. Ontologiutvecklare kan bestämma vilka kommandon som behövs för att utföra utgåvan och bygga ett arbetsflöde kring dessa kommandon. Figur 1 visar ett standard sätt på vilket ett urval av ROBOTKOMMANDON kombineras för en release arbetsflöde.

ROBOT release arbetsflöde. En typisk release arbetsflöde med ROBOT. Ontologi Redigera fil ONT-redigera.owl verifieras först som en kvalitetskontrollkontroll med ROBOT ’verifiera’. Sedan används textfiler som innehåller listor över externa ontologiska termer i importkatalogen för att regenerera importmoduler med ’extract’, vilket säkerställer att importen är uppdaterad. ONT-redigera.owl passeras sedan genom en serie ROBOTKOMMANDON (’reason’,’ relax’,’ reduce ’och’ annotate’) för att generera utgåvan, ONT.uggla. Slutligen ONT.owl konverteras till OBO-format

först körs kvalitetskontroller över redaktörens version av ontologin med ”rapport” eller ”verifiera”. Dessa letar efter motsvarande klasser, avslutande blanksteg i Anteckningar, självreferenser, felaktig korsreferenssyntax och saknade etiketter. Resultaten sparas i en specificerad ’rapporter /’ katalog. Om det finns några FELNIVÅÖVERTRÄDELSER misslyckas uppgiften och skriver överträdelserna till ett bord så att de enkelt kan identifieras. Detta steg gör det möjligt för utvecklare att snabbt se om nya förändringar har infört några problem inom ontologin och åtgärda dem innan de släpps.

förutsatt att det första QC-kontrollsteget har slutförts, är nästa steg att skapa importmodulerna. Roboten ’ extract ’körs för varje post i en importlista, som har motsvarande termfiler (för fröuppsättningen) i katalogen’ import/’. Detta skapar alla importmoduler i samma’ import/ ’ katalog. Detta säkerställer att när en ontologi släpps med externa termer är alla externa termer uppdaterade med de släppta versionerna av källontologierna. Släppa out-of-date externa termer kan orsaka förvirring, eftersom termen kommer att visa både gamla och nya detaljer i ontologi söktjänster som Ontobee och ontologi Lookup Service . Ytterligare QC-kontroller kan köras över hela ontologin med import med kommandot ’ verifiera ’eller genom att köra’ rapport ’ igen.

sist skapas de viktigaste släppprodukterna: OWL-filen och OBO-filen. För att skapa OWL-utgåvan skickas redaktörens fil genom en serie kedjade ROBOTKOMMANDON:’ reason’,’ relax’,’ reduce ’och’ annotate’. Denna serie kommandon hjälper till att säkerställa att den släppta ontologin är både lätt att bläddra och förstå, såväl som fri från överflödiga Axiom. Om något av dessa kommandon misslyckas avslutas Make-processen med motsvarande felmeddelande. Till exempel, om en ontologi är osammanhängande kommer ’reason’ – steget att misslyckas. Slutligen lägger kommandot’ kommentera ’ versionen IRI till ontologins metadata. Denna OWL-fil konverteras sedan till OBO-format, vid vilken tidpunkt alla mål kopieras till en daterad släppkatalog.

Ontology Development Kit

att skapa en Makefile för att samordna alla dessa steg kan vara utmanande. Vi underlättar detta för ontologiutvecklare genom att tillhandahålla ett Ontologiutvecklingspaket (ODK) . Detta kan användas för att skapa ett GitHub-arkiv enligt en standardlayout, med en standard Makefile som följer arbetsflödet som beskrivs ovan. Det resulterande GitHub-arkivet konfigureras också automatiskt för att köra valideringsstegen (till exempel ’rapport’) för arbetsflödet via Travis CI . Arbetsflödet kan också utföras med Docker med ODK-behållare som släppts på Dockerhub . Detta möjliggör enkelt utförande av arbetsflöden på antingen den lokala datorn hos en ontologiutvecklare, med Travis CI, eller genom skalbara verktyg som Jenkins .

ODK bygger på ROBOT och demonstrerar Robots användbarhet, men en fullständig diskussion ligger utanför ramen för denna artikel.