OVERSIKT

ROBOT gir en standardisert, men likevel konfigurerbar måte å støtte ontologiutviklingslivssyklusen via et bibliotek med felles funksjonalitet på høyt nivå og et kommandolinjegrensesnitt. ROBOT bygger PÅ OWL API og er kompatibel med alle ontology syntaxes SOM OWL API støtter: RDF/XML, OWL/XML, Turtle, OWL Funksjonell Syntaks, OWL Manchester Syntaks, OG OBO format. Kildekoden er skrevet I Java og er tilgjengelig fra Vårt GitHub-depot under en åpen kildekode (BSD 3) lisens. Det er også utgitt Som Et Java-bibliotek På Maven Central. ROBOT kode kan brukes fra alle programmeringsspråk som kjører På Java Virtual Machine (JVM). Kommandolinjeverktøyet er pakket som EN JAR-fil som kan kjøres På Unix (inkludert macOS og Linux), Windows og andre plattformer som støttes AV JVM. DENNE JAR-filen er tilgjengelig for nedlasting fra ROBOT GitHub-siden, sammen med plattformspesifikke skript for bruk av ‘robot’ fra kommandolinjen. Installasjonsinstruksjoner og dokumentasjon er tilgjengelig fra http://robot.obolibrary.org.

Arkitektur

vi har tidligere beskrevet verktøyets grunnleggende arkitektur, som vi oppsummerer her.

robotkilden består av to deler: ‘robot-kjerne’ og ‘robot-kommando’. «robot-core» er et bibliotek som støtter vanlige ontologiske utviklingsoppgaver, som vi kaller «operasjoner». «robot-command» gir et kommandolinjegrensesnitt delt inn i «kommandoer», som hver bryter en «robot-core» – operasjon.De FLESTE ROBOTOPERASJONER pakker funksjonalitet på lavt nivå levert av OWL API til funksjonalitet på høyt nivå som er felles for ontologiutviklingsarbeidsflyter I OBO-fellesskapet. For best kompatibilitet, har vi som mål å matche den eksakte versjonen AV OWL API som BRUKES av ROBOT med den eksakte versjonen som brukes av Den nyeste Versjonen Av Proté. Noen operasjoner bruker Apache Jena . Hver operasjon fungerer Med Java-objekter som representerer UGLE ontologier, UGLE reasoners, UGLE klasser, etc., mens hver kommando fungerer med kommandolinjealternativstrenger og filer. Kommandoene utfører også ulike konverterings-og valideringstrinn. Kommandolinjegrensesnittet bruker Apache Commons cli-biblioteket til å analysere kommandoer.

Hver operasjon har et sett med enhetstester bygget Med JUnit som utføres hver gang sluttproduktet (JAR-filen) genereres. Hver kommando I ROBOT er dokumentert på sin egen nettside (f. eks. http://robot.obolibrary.org / reason). Nettsidene er skrevet I Markdown-format og inneholder innebygde kommandolinjeeksempler som analyseres og utføres som en del av våre integrasjonstester, med resultatene sammenlignet med et «gullstandard» sett med utganger. ROBOTS ‘diff’ – funksjonalitet brukes når man sammenligner ontologifiler, ellers brukes standard filsammenligning. Dette bidrar til å sikre korrekthet og konsistens av dokumentasjon og kode. Enhetstestene og integrasjonstestene utføres på en hvilken som helst pull-forespørsel på kodebasen via Travis continuous integration (Travis CI), slik at bidrag til kodebasen blir verifisert.

Kommandoer og operasjoner

ROBOT gir for tiden 15 operasjoner (i ‘robot-core’-biblioteket) og 19 kommandoer (for kommandolinjegrensesnittet). Noen kommandoer er ganske spesialiserte, og de fleste ontologiprosjekter vil ikke benytte seg av dem alle. Her gir vi en oversikt over de vanligste og generelle kommandoene. I hvert tilfelle støttes kjernefunksjonaliteten av operasjoner i ‘robot-core’ – biblioteket, som kan brukes uavhengig av kommandolinjegrensesnittet fra hvilket som helst programmeringsspråk som kjører PÅ JVM.

Convert

EN rekke OWL ontology formater støttes, inkludert RDF / XML, Turtle, Manchester, OBO format, og mer. FOR å muliggjøre ytterligere interoperabilitet, INKLUDERER ROBOT en ‘konverter’ – kommando for å bytte mellom støttede ontologiformater. En komplett liste over støttede formater finner du i ‘konverter’ dokumentasjon .

Resonnement

Resonnement er en av DE viktigste operasjonene I ROBOT. Kommandoen ‘reason’ dekker to bruksområder: logisk validering av en ontologi og automatisk klassifisering. I begge tilfeller kan brukerne velge sin foretrukne reasoner, som brukes til å utføre slutning. Store ontologier som Genet Ontologi vanligvis bruker ELG, som utfører resonnement raskt ved HJELP AV OWL EL profil. Mindre ontologier med rikere aksiomatisering, slik Som Relations Ontology, vanligvis bruker en komplett UGLE DL reasoner som Eremitt .

NÅR kommandoen ‘reason’ påberopes på en input ontology, VIL ROBOT starte en reasoner ved hjelp AV OWL API Reasoner-grensesnittet. De resulterende slutningene kontrolleres for å sikre at ontologien er logisk sammenhengende: ontologien må være konsistent og ikke ha utilfredsstillbare klasser (dvs., klasser som ikke kan startes uten å innføre en inkonsekvens). Hvis ontologien er usammenhengende, rapporteres dette og utførelsen stopper. ROBOT kan eventuelt utføre flere kontroller, slik som å sikre at ingen to klasser er utledes å være tilsvarende post-resonnement.

HVIS ontologien er konsistent, VIL ROBOTEN utføre automatisk klassifisering. Alle direkte utledede ‘subClassOf’ aksiomer legges til ontologien. Generering av andre typer aksiomer kan konfigureres.

påstanden om alle utledede aksiomer er ofte et grunnleggende skritt i frigjøringsprosessen for biomedisinske ontologier. Mange av disse ontologiklassene hevder bare en enkelt navngitt superklasse (‘en underklasse Av B’, Hvor B er en annen klasse i ontologien), og null eller flere anonyme superklasser og/eller anonyme ekvivalente klasser (‘en underklasse Av/ekvivalentto (r Noen B)’, hvor R er en objektegenskap). Disse anonyme klassene tillater begrunnelsen å gjøre avledninger, som deretter hevdes. Derfor, i utgivelsesversjonen av en ontologi, kan en klasse ha mer enn en navngitt superklasse.

kommandoen «årsak» har flere» hjelper » – kommandoer. ‘Relax’ – kommandoen hevder innebar underklasse av aksiomer i henhold til en enkel strukturell regel: et uttrykk ‘a equivalentTo (r Noen B) og …’ innebærer ‘en underklasse Av r Noen B’. Dette kan være nyttig da forbrukere av bio-ontologier ofte forventer å navigere i disse uttrykkene, for eksempel partonomi I GO og Uberon. ‘Relax’ – kommandoen lindrer ontologiutvikleren fra behovet for å hevde disse i tillegg til ekvivalensaksiomene, og som sådan er det også ofte inkludert i utgivelsesarbeidsflyter. Til slutt fjerner kommandoen’ reduser ‘ overflødige underklasser av aksiomer, og kan brukes etter ‘slapp av’ for å fjerne dupliserte aksiomer som ble hevdet i det trinnet.

kommandoen ‘materialisere’ bruker Et Uttrykk Som Materialiserer Reasoner (EMR) for å hevde utledede uttrykk for skjemaet ‘en underklasse Av r noen B’. Hvor’ grunn ‘kommandoen hevder utledes heter super, ‘materialisere’ hevder anonyme superklasser. Dette er ikke en del av standardutgivelsessyklusen, men kan være gunstig for å skape komplette ontologi-undergrupper.

Arbeide med eksterne ontologier

OBO-Støperiet har som mål å koordinere ontologier på en modulær måte, slik at deler av noen ontologier kan brukes som byggesteiner for andre ontologier. For Eksempel brukes chebi chemical entities ontology til å konstruere UGLE definisjoner for metabolske prosesser og aktiviteter I Genet Ontologi . Det finnes en rekke forskjellige strategier for å utnytte eksterne ontologier og håndtere avhengigheter mellom ontologier, avhengig av brukssaken.

Extract

kommandoen ‘extract’ oppretter en modul basert på et sett med enheter som skal trekkes ut («seed»). Det er fire forskjellige utvinningsmetoder( som angitt av alternativet ‘– method’): MIREOT, TOP, BOT og STAR.

ROBOTENS MIREOT ekstraksjonsmetode er basert på prinsippet med samme navn og krever at en eller flere «bunn» enheter er spesifisert. Eventuelt kan en eller flere «topp» enheter også spesifiseres. Kommandoen trekker ut alle» bunn «nivå enheter og deres forfedre opp til «topp» nivå fra input ontology. Hvis ingen» topp » enheter er gitt, er forfedre opp til toppnivåenheten (‘owl: Thing’) inkludert.TOP -, BOT-og STAR-metodene bruker OWL API Syntactic Locality Module Extraction (SLME) – implementeringen, som garantert fanger opp all informasjon som er logisk relevant for frøsettet . BOT-metoden («bunn») inkluderer alle relasjoner mellom inngangsenhetene og deres forfedre. DEN ØVERSTE metoden inkluderer alle relasjoner mellom inngangsenhetene og deres etterkommere. ENDELIG INKLUDERER STAR-metoden bare alle relasjoner mellom inngangsenheter. STAR-metoden produserer de minste utgangene, MENS TOP-metoden vanligvis produserer de største utgangene.

for å støtte ontologi term proveniens, har kommandoen ‘utdrag’ et’ –annotate-with-source true ‘ – alternativ som vil annotere hver ekstrahert term med URL-ADRESSEN til kilden ontologi som den er hentet fra.

Fjern og filtrer

kommandoene ‘fjern’ og ‘filter’ brukes til finkornede operasjoner PÅ UGLEAKSIOMER. ‘fjern’ lar brukerne velge hvilke sett med aksiomer de ønsker å fjerne fra et mål ontologi. ‘filter’ gjør det motsatte, slik at bare valgte aksiomer kopieres fra inngangen til en ny utgang ontologi.

disse to kommandoene fungerer ved å starte med et frøsett av enheter, deretter bruke ulike velgere for å finne relaterte enheter, og til slutt velge hvilke aksiomtyper som skal fjernes eller filtreres. Vi forventer at bare et lite antall «avanserte brukere» vil bruke denne funksjonen direkte, men disse kommandoene vil til slutt gi grunnlag for andre kommandoer på høyere nivå.

disse kommandoene kan brukes til å generere ontologi-delsett basert på merknader ved enten å filtrere for eller fjerne enheter med den angitte merknaden. Obo Foundry ontologies annoterer ofte klasser med egenskapen ‘in delsett’ for å angi hvor en klasse kan brukes. Annotasjonsvelgeren tillater en bruker å gi en fullstendig annotasjonsverdi eller et mønster som samsvarer med vanlig uttrykk.

Merge

kommandoen ‘merge’ kombinerer to eller flere separate input ontologier i en enkelt ontologi. Det gir også muligheten til å slå sammen alle importerte ontologier av en enkelt inngang ontologi i en hoved ontologi, som ofte brukes når du oppretter en utgivelse.

Sammenslåing av importerte ontologier (spesifisert av importsetninger) i inndataontologien utføres automatisk, slik at brukeren ikke trenger å oppgi hver importerte ontologi som inndata. Vi tilbyr muligheten (‘–collapse-import-closure false’) for å slå av denne funksjonen, som støtter tilfeller der brukere kan slå sammen flere input ontologier som har import uttalelser, men ønsker å holde sine import separat.

Spørring og rapportering

Ontologiarbeidsflyter inkluderer vanligvis spørringsoperasjoner over ontologien, og produserer rapporter som kan være informative for både redaktører og brukere av ontologien-for eksempel en tabell over alle klasser pluss deres tekstdefinisjoner. Spørringsoperasjoner kan også brukes til valideringskontroller. SPARQL-spørrespråket gir en universell og deklarativ måte for ontologiholdere å lage ontologirapporter og valideringskontroller på . ROBOT gir en praktisk måte å utføre spørringer med kommandoen’ spørring’, eller valideringskontroller ved hjelp av ‘bekreft’. I tillegg inneholder kommandoen’ rapport ‘ en konfigurerbar pakke med standardspørringer FOR OBO-prosjekter som kan brukes i alle ontology-arbeidsflyter, uten at vedlikeholderen må være kjent MED SPARQL.

Query

ROBOTS ‘query’ – kommando kjører SPARQL-spørringer på ontologier eller ANDRE rdf-ressurser. Dette kan brukes av en ontologi-vedlikeholder til enten å utføre interaktive spørringer, eller mer typisk for å inkludere standardspørringer i en ontologi-arbeidsflyt. Kommandoen ‘spørring’ bryter en Av de få operasjonene Som bruker Apache Jena, i stedet FOR OWL API. Jena API tillater ROBOT å laste en ontologi som en samling av tripler inneholdt AV ET Rdf-Modellobjekt. DET gir EN SPARQL spørring motor for disse modellene, som vi bruker til å kjøre alle spørringer.

‘SPARQL SELECT’ – spørringer produserer en komma-eller tabulatordelt tabell med resultater. SPØR spørringer produsere en fil med En Boolsk verdi. ‘SPARQL CONSTRUCT’ spørringer produserer EN RDF-fil, som kan behandles videre AV ROBOT eller fusjoneres tilbake til den lastede ontologien. ‘CONSTRUCT’ s gir en praktisk måte å utføre» makro » stil utvidelse . ‘SPARQL UPDATE’ spørringer sett inn og / eller fjern data direkte i en ontologi (SOM EN RDF-Modell). ROBOT konverterer den oppdaterte Rdf-Modellen tilbake til ET OWL API ontology-objekt som skal lagres i noen av de støttede syntaksene.kommandoen ‘spørring’ støtter et alternativ for å laste inn importerte ontologier som navngitte grafer med alternativet’ –use-grafer’. Hvis dette er satt til ‘true’, kan importen spørres som navngitte grafer (navnet er ontologys IRI) og standardgrafen er en forening av alle grafer. Bruk av standardgrafen ligner på å gjennomføre en fusjon av all import før spørring, men skillet mellom import vil gå tapt i en fusjon.

Bekreft

kommandoen ‘bekreft’ er en variant av ‘SPARQL SELECT’ – utførelsen. Spørringene brukes til å sikre at en ontologi er i samsvar med et forhåndsbestemt sett av forhold; for eksempel, å sikre at ingen klasse har flere tekstdefinisjoner. Gitt EN UTVALGSSPØRRING, vil’ verify ‘ lykkes (dvs. avslutt med statuskode 0) hvis ingen resultater returneres. Det vil mislykkes (dvs., avslutt med en ikke-null statuskode) hvis noen resultater kommer tilbake fra spørringen. Så, gitt EN SPARQL-spørring Som Velger for ugyldige data, vil’ verify ‘ – kommandoen bekrefte at ontologien (eller annen ressurs) ikke inneholder slike ugyldige data.

Report

kommandoen ‘report’ er en utvidelse av ‘query’ og ‘verify’ som gir en serie konfigurerbare kvalitetskontroller (QC) sjekker for en ontologi og returnerer et regneark eller YAML-utdata av bruddene. Regnearket er utgang i enten komma – eller tabulatordelt format og lett for en bruker å lese, mens YAML utgang lett kan analyseres av andre programmer.

QC-kontrollene inkluderer annotasjonskontroller, logiske kontroller og metadatakontroller. Merknader er viktige for å lette menneskelig forståelse, så kommandoen rapport finner tilfeller der manglende eller dupliserte merknader kan forårsake problemer. Logiske sjekker ser på strukturell sammenheng og konsistens av ontologien. Endelig identifiserer’ report ‘ manglende ontologi metadata, som spesifisert AV OBO Foundry anbefalinger.

det er tre nivåer av brudd som rapporteres: FEIL, ADVARSEL og INFO. En FEIL er den mest alvorlige, for eksempel en manglende eller duplikat etikett. Som standard mislykkes kommandoen ‘rapport’ hvis det er brudd på feilnivå, og stopper eventuelle automatiserte byggeprosesser. Disse typer brudd må løses før publisering av en ontologi. ADVARSEL-nivå brudd bør løses så snart som mulig, f.eks utledet en-til-en klasse ekvivalenser, som vanligvis er utilsiktet I OBO prosjekter. INFO er for anbefalte reparasjoner som bidrar til å opprettholde konsistens PÅ TVERS AV OBO Støperi ontologier, for eksempel begynner en definisjon med en stor bokstav og slutter med en periode. ‘rapport’ kan konfigureres med et kommandolinjealternativ for å mislykkes på et annet bruddnivå eller å aldri mislykkes, uavhengig av eventuelle brudd. Vi dokumenterer hver QC-sjekk med et forslag til en manuell løsning som brukeren kan søke.

EN standard «profil» med rapportnivåer for HVER QC-sjekk leveres av ROBOT, men brukerne kan også lage egne profiler. I disse profilene kan de endre bruddnivåene for individuelle kontroller, velge å ekskludere bestemte kontroller og legge til egne sjekker som SPARQL-spørringer. For eksempel kan noen ontologier kategorisere en klasse som mangler en tekstdefinisjon som en feil, mens andre kan kategorisere dette som en advarsel. Et av våre mål er å konvergere på en standardprofil som er maksimalt nyttig for settet av ALLE ontologier I OBO-biblioteket, og oppfordrer til bruk av felles kvalitetskontroller.

Repair

selv om de fleste problemer som oppstår av ‘valider’ og ‘report’ må løses manuelt, GIR ROBOT også en ‘repair’ – kommando som automatisk kan fikse visse problemer. Den nåværende implementeringen vil slå sammen merknader på dupliserte aksiomer og oppdatere referanser til utdaterte klasser når de er merket med en foreslått erstatning. Vi har til hensikt å utvide ‘reparasjon’ til et bredere spekter av vanlige problemer som den riktige løsningen er klar for.

Templert ontologi utvikling

ROBOT gir en mal-drevet ontologi sikt generasjon system. Brukere har også muligheten til å plugge inn sitt eget termgenereringssystem i arbeidsflyten, for eksempel Dead Simple OWL Design Patterns (DOS-DPS) .

en stor mengde data lagres i regneark og databaser, og tabellformater passer godt til mange typer data. ROBOTS ‘ mal ‘ – kommando lar brukerne konvertere tabelldata til RDF / OWL-format. EN ROBOTMAL er ganske enkelt EN TABULATORDELT verdi (TSV) eller kommadelt verdi (CSV) fil med noen spesielle konvensjoner, som er skissert i robotens maldokumentasjon .

disse malene kan brukes for modulær ontologi utvikling. Malarkene kan vedlikeholdes som en del av ontologys kildekodelager, og i stedet for å redigere ontologifilen direkte, redigerer utviklere rader i regnearket som samsvarer med vilkårene i ontologien. Kommandoen ‘ mal ‘ brukes deretter til å generere en modul av ontologien, som er inkludert som en importerklæring i redaktørens versjon av ontologien og slått sammen under utgivelsesprosessen.

Arbeidsflyter

en arbeidsflyt består av et sett med oppgaver som koordineres av et arbeidsflytsystem. Ontologi arbeidsflyter består av oppgaver som å utføre QC sjekker, bygge import moduler, resonnement over ontologier, og generere ulike ontologi utgivelsen produkter.

ROBOT i seg selv er ikke en arbeidsflytbehandling, selv om det tillater flere kommandoer å bli koblet sammen til en lang kommando. Ved kjeding AV ROBOTKOMMANDOER sendes output ontology fra en kommando direkte som inngang til neste kommando. Kjeding kan for eksempel brukes til å erstatte to kommandoer som slår sammen ontologier og deretter resonerer over det sammenslåtte produktet:

`robot merge –input ont-1.ugle –inngang ont-2.owl — utgang fusjonert.ugle.

robot grunn –input fusjonert.owl-utgang begrunnet.ugle`.I Stedet for å opprette det sammenslåtte produktet og kjøre ‘reason’ over det, kan det gjøres i en kommando: ‘robot merge –input ont-1.ugle –inngang ont-2.owl reason-utgang begrunnet.ugle`.

hovedfordelen ved kjetting er at ontologier ikke må serialiseres og analyseres mellom hvert trinn; DET samme OWL API ontology-objektet opprettholdes i minnet og sendes gjennom KJEDEN AV ROBOTKOMMANDOER. For store ontologier kan kjeding vesentlig forbedre ROBOTENS ytelse.

FORDI ROBOTKOMMANDOER kan utføres på kommandolinjen, kan en rekke forskjellige arbeidsflytsystemer brukes. VI fremhever BRUKEN AV GNU Make , som vanligvis brukes til å kompilere programvare. En Makefile består av et sett med regler som brukes til å lage «mål». I ontologi utvikling, Makefile brukes for automatiserte oppgaver, for eksempel å forberede en ontologi for utgivelse. I dette tilfellet er målene vanligvis ontologiske filer. «Oppskrifter» for reglene er Unix-stil systemkommandoer, utført av kommandoen «make».

ROBOT kommandoer kan brukes som «oppskrifter» for å gjøre «mål». En typisk arbeidsflyt vil ikke bruke alle 19 AV ROBOTKOMMANDOENE. For eksempel kan ikke alle ontology-prosjekter bruke ROBOTMALER, og derfor må ikke alle utgivelsesarbeidsflyter inkludere kommandoen ‘mal’. Ontology utviklere kan bestemme hvilke kommandoer som trengs for å utføre utgivelsen og bygge en arbeidsflyt rundt disse kommandoene. Figur 1 viser en standard mate der et utvalg AV ROBOTKOMMANDOER er kombinert for a gi ut arbeidsflyt.

arbeidsflyten for robotutgivelse. En typisk utgivelse arbeidsflyt ved HJELP AV ROBOT. Den ontologi rediger fil ONT-rediger.owl er først verifisert som en kvalitetskontroll sjekk MED ROBOT ‘verifisere’. Deretter brukes tekstfiler som inneholder lister over eksterne ontologiske termer i importkatalogen til å regenerere importmoduler ved hjelp av ‘utdrag’, slik at importen er oppdatert. ONT-rediger.owl sendes deretter gjennom EN rekke ROBOTKOMMANDOER (‘reason’,’ relax’,’ reduser ‘og’ annotate’) for å generere utgivelsen, ONT.ugle. Til SLUTT, ONT.owl konverteres til OBO-format

for det første kjøres kvalitetskontroller over redaktørens versjon av ontologien med «rapport» eller «verifiser». Disse ser etter tilsvarende klasser, etterfølgende mellomrom i merknader, selvreferanser, feil kryssreferansesyntaks og manglende etiketter. Resultatene lagres i en spesifisert ‘rapporter/’ katalog. Hvis det er brudd på feilnivå, vil oppgaven mislykkes og skrive bruddene til et bord slik at de enkelt kan identifiseres. Dette trinnet lar utviklere raskt se om nye endringer har introdusert noen problemer innen ontologien og fikse dem før de slippes.

Forutsatt at DET første qc-kontrolltrinnet er fullført, er neste trinn å opprette importmodulene. ROBOTEN ‘extract’ kjøres for hver oppføring i en liste over import, som har tilsvarende termfiler (for frøsettet) i’ import/ ‘ – katalogen. Dette skaper alle importmodulene i samme’ import/ ‘ katalog. Dette sikrer at når en ontologi utgis med eksterne vilkår, er alle eksterne vilkår oppdaterte med de utgitte versjonene av kildens ontologier. Utgivelse av utdaterte eksterne vilkår kan føre til forvirring, da begrepet vil vise både gamle og nye detaljer i ontologi-søketjenester som Ontobee og Ontology Lookup-Tjenesten . Ekstra QC sjekker kan kjøres over hele ontology med import ved hjelp av’ verify ‘ kommando eller ved å kjøre ‘report’ igjen.

Sist, de viktigste utgivelsesproduktene er opprettet: OWL-filen OG OBO-filen. FOR å opprette OWL-utgivelsen, sendes redaktørens fil gjennom en rekke kjedede ROBOTKOMMANDOER: ‘reason’, ‘relax’,’ reduser ‘og’annotate’. Denne serien av kommandoer bidrar til å sikre at den utgitte ontologien er både lett å bla gjennom og forstå, samt fri for overflødige aksiomer. Hvis noen av disse kommandoene mislykkes, Avsluttes Make-prosessen med den tilsvarende feilmeldingen. For eksempel, hvis en ontologi er usammenhengende, vil ‘grunnen’ – trinnet mislykkes. Til slutt legger kommandoen ‘annotate’ VERSJONEN IRI til ontologimetadataene. DENNE OWL-filen konverteres deretter TIL OBO-format, hvor alle mål kopieres til en datert utgivelseskatalog.

Ontology Development Kit

Å lage En Makefile for å koordinere alle disse trinnene kan være utfordrende. Vi gjør dette enklere for ontology utviklere ved å tilby En Ontology Development Kit (ODK). Dette kan brukes til å lage Et GitHub-depot etter en standard layout, med en standard Makefile som følger arbeidsflyten beskrevet ovenfor. Det Resulterende GitHub-depotet vil også automatisk konfigureres til å kjøre valideringstrinnene (for eksempel ‘rapport’) av arbeidsflyten via Travis CI . Arbeidsflyten kan også utføres ved Hjelp Av Docker MED ODK containere utgitt På Dockerhub . Dette gir enkel utførelse av arbeidsflyter på enten den lokale datamaskinen til en ontology-utvikler, Med Travis CI, eller gjennom skalerbare byggverktøy som Jenkins .ODK bygger PÅ ROBOT og demonstrerer ROBOTS verktøy, men en full diskusjon er utenfor rammen av denne artikkelen.