diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/404.html b/404.html new file mode 100644 index 0000000..8a6632e --- /dev/null +++ b/404.html @@ -0,0 +1,478 @@ + + + + + + + + + + + + + + + + + + BIDS Apps execution specification + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+
+ +
+ + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ +

404 - Not found

+ +
+
+ + +
+ + + +
+ + + +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/CHANGELOG.html b/CHANGELOG.html new file mode 100644 index 0000000..1a32486 --- /dev/null +++ b/CHANGELOG.html @@ -0,0 +1,697 @@ + + + + + + + + + + + + + + + + + + + + + + Release notes - BIDS Apps execution specification + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + + + + + + + +

Changelog

+

All notable changes to this project will be documented in this file.

+

The format is based on Keep a Changelog, +and this project adheres to Semantic Versioning.

+ + +

[0.1.0.dev]

+

Added

+
    +
  • Adopted Boutiques validatable and runnable descriptive standard
  • +
  • Increased flexibility for runtime arguments and command-line formatting
  • +
  • Defined exit codes to indicate various application outcomes
  • +
  • Link between application descriptions and data specification versions
  • +
  • Extensible definition which will scale with the BIDS standards as new entities are added
  • +
+

Changed

+

Deprecated

+
    +
  • Position arguments are no longer supported.
  • +
+

Removed

+

Fixed

+

Security

+ + + + + + +
+
+ + +
+ + + +
+ + + +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/CONTRIBUTING.html b/CONTRIBUTING.html new file mode 100644 index 0000000..494e0eb --- /dev/null +++ b/CONTRIBUTING.html @@ -0,0 +1,597 @@ + + + + + + + + + + + + + + + + + + + + + + + + Contributors - BIDS Apps execution specification + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + + + + + + + +

Contributing

+

Lead Contributors

+ +

Contributors

+ + + + + + + +
+
+ + +
+ + + +
+ + + +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/assets/images/favicon.png b/assets/images/favicon.png new file mode 100644 index 0000000..1cf13b9 Binary files /dev/null and b/assets/images/favicon.png differ diff --git a/assets/javascripts/bundle.51d95adb.min.js b/assets/javascripts/bundle.51d95adb.min.js new file mode 100644 index 0000000..b20ec68 --- /dev/null +++ b/assets/javascripts/bundle.51d95adb.min.js @@ -0,0 +1,29 @@ +"use strict";(()=>{var Hi=Object.create;var xr=Object.defineProperty;var Pi=Object.getOwnPropertyDescriptor;var $i=Object.getOwnPropertyNames,kt=Object.getOwnPropertySymbols,Ii=Object.getPrototypeOf,Er=Object.prototype.hasOwnProperty,an=Object.prototype.propertyIsEnumerable;var on=(e,t,r)=>t in e?xr(e,t,{enumerable:!0,configurable:!0,writable:!0,value:r}):e[t]=r,P=(e,t)=>{for(var r in t||(t={}))Er.call(t,r)&&on(e,r,t[r]);if(kt)for(var r of kt(t))an.call(t,r)&&on(e,r,t[r]);return e};var sn=(e,t)=>{var r={};for(var n in e)Er.call(e,n)&&t.indexOf(n)<0&&(r[n]=e[n]);if(e!=null&&kt)for(var n of kt(e))t.indexOf(n)<0&&an.call(e,n)&&(r[n]=e[n]);return r};var Ht=(e,t)=>()=>(t||e((t={exports:{}}).exports,t),t.exports);var Fi=(e,t,r,n)=>{if(t&&typeof t=="object"||typeof t=="function")for(let o of $i(t))!Er.call(e,o)&&o!==r&&xr(e,o,{get:()=>t[o],enumerable:!(n=Pi(t,o))||n.enumerable});return e};var yt=(e,t,r)=>(r=e!=null?Hi(Ii(e)):{},Fi(t||!e||!e.__esModule?xr(r,"default",{value:e,enumerable:!0}):r,e));var fn=Ht((wr,cn)=>{(function(e,t){typeof wr=="object"&&typeof cn!="undefined"?t():typeof define=="function"&&define.amd?define(t):t()})(wr,function(){"use strict";function e(r){var n=!0,o=!1,i=null,a={text:!0,search:!0,url:!0,tel:!0,email:!0,password:!0,number:!0,date:!0,month:!0,week:!0,time:!0,datetime:!0,"datetime-local":!0};function s(T){return!!(T&&T!==document&&T.nodeName!=="HTML"&&T.nodeName!=="BODY"&&"classList"in T&&"contains"in T.classList)}function f(T){var Ke=T.type,We=T.tagName;return!!(We==="INPUT"&&a[Ke]&&!T.readOnly||We==="TEXTAREA"&&!T.readOnly||T.isContentEditable)}function c(T){T.classList.contains("focus-visible")||(T.classList.add("focus-visible"),T.setAttribute("data-focus-visible-added",""))}function u(T){T.hasAttribute("data-focus-visible-added")&&(T.classList.remove("focus-visible"),T.removeAttribute("data-focus-visible-added"))}function p(T){T.metaKey||T.altKey||T.ctrlKey||(s(r.activeElement)&&c(r.activeElement),n=!0)}function m(T){n=!1}function d(T){s(T.target)&&(n||f(T.target))&&c(T.target)}function h(T){s(T.target)&&(T.target.classList.contains("focus-visible")||T.target.hasAttribute("data-focus-visible-added"))&&(o=!0,window.clearTimeout(i),i=window.setTimeout(function(){o=!1},100),u(T.target))}function v(T){document.visibilityState==="hidden"&&(o&&(n=!0),B())}function B(){document.addEventListener("mousemove",z),document.addEventListener("mousedown",z),document.addEventListener("mouseup",z),document.addEventListener("pointermove",z),document.addEventListener("pointerdown",z),document.addEventListener("pointerup",z),document.addEventListener("touchmove",z),document.addEventListener("touchstart",z),document.addEventListener("touchend",z)}function re(){document.removeEventListener("mousemove",z),document.removeEventListener("mousedown",z),document.removeEventListener("mouseup",z),document.removeEventListener("pointermove",z),document.removeEventListener("pointerdown",z),document.removeEventListener("pointerup",z),document.removeEventListener("touchmove",z),document.removeEventListener("touchstart",z),document.removeEventListener("touchend",z)}function z(T){T.target.nodeName&&T.target.nodeName.toLowerCase()==="html"||(n=!1,re())}document.addEventListener("keydown",p,!0),document.addEventListener("mousedown",m,!0),document.addEventListener("pointerdown",m,!0),document.addEventListener("touchstart",m,!0),document.addEventListener("visibilitychange",v,!0),B(),r.addEventListener("focus",d,!0),r.addEventListener("blur",h,!0),r.nodeType===Node.DOCUMENT_FRAGMENT_NODE&&r.host?r.host.setAttribute("data-js-focus-visible",""):r.nodeType===Node.DOCUMENT_NODE&&(document.documentElement.classList.add("js-focus-visible"),document.documentElement.setAttribute("data-js-focus-visible",""))}if(typeof window!="undefined"&&typeof document!="undefined"){window.applyFocusVisiblePolyfill=e;var t;try{t=new CustomEvent("focus-visible-polyfill-ready")}catch(r){t=document.createEvent("CustomEvent"),t.initCustomEvent("focus-visible-polyfill-ready",!1,!1,{})}window.dispatchEvent(t)}typeof document!="undefined"&&e(document)})});var un=Ht(Sr=>{(function(e){var t=function(){try{return!!Symbol.iterator}catch(c){return!1}},r=t(),n=function(c){var u={next:function(){var p=c.shift();return{done:p===void 0,value:p}}};return r&&(u[Symbol.iterator]=function(){return u}),u},o=function(c){return encodeURIComponent(c).replace(/%20/g,"+")},i=function(c){return decodeURIComponent(String(c).replace(/\+/g," "))},a=function(){var c=function(p){Object.defineProperty(this,"_entries",{writable:!0,value:{}});var m=typeof p;if(m!=="undefined")if(m==="string")p!==""&&this._fromString(p);else if(p instanceof c){var d=this;p.forEach(function(re,z){d.append(z,re)})}else if(p!==null&&m==="object")if(Object.prototype.toString.call(p)==="[object Array]")for(var h=0;hd[0]?1:0}),c._entries&&(c._entries={});for(var p=0;p1?i(d[1]):"")}})})(typeof global!="undefined"?global:typeof window!="undefined"?window:typeof self!="undefined"?self:Sr);(function(e){var t=function(){try{var o=new e.URL("b","http://a");return o.pathname="c d",o.href==="http://a/c%20d"&&o.searchParams}catch(i){return!1}},r=function(){var o=e.URL,i=function(f,c){typeof f!="string"&&(f=String(f)),c&&typeof c!="string"&&(c=String(c));var u=document,p;if(c&&(e.location===void 0||c!==e.location.href)){c=c.toLowerCase(),u=document.implementation.createHTMLDocument(""),p=u.createElement("base"),p.href=c,u.head.appendChild(p);try{if(p.href.indexOf(c)!==0)throw new Error(p.href)}catch(T){throw new Error("URL unable to set base "+c+" due to "+T)}}var m=u.createElement("a");m.href=f,p&&(u.body.appendChild(m),m.href=m.href);var d=u.createElement("input");if(d.type="url",d.value=f,m.protocol===":"||!/:/.test(m.href)||!d.checkValidity()&&!c)throw new TypeError("Invalid URL");Object.defineProperty(this,"_anchorElement",{value:m});var h=new e.URLSearchParams(this.search),v=!0,B=!0,re=this;["append","delete","set"].forEach(function(T){var Ke=h[T];h[T]=function(){Ke.apply(h,arguments),v&&(B=!1,re.search=h.toString(),B=!0)}}),Object.defineProperty(this,"searchParams",{value:h,enumerable:!0});var z=void 0;Object.defineProperty(this,"_updateSearchParams",{enumerable:!1,configurable:!1,writable:!1,value:function(){this.search!==z&&(z=this.search,B&&(v=!1,this.searchParams._fromString(this.search),v=!0))}})},a=i.prototype,s=function(f){Object.defineProperty(a,f,{get:function(){return this._anchorElement[f]},set:function(c){this._anchorElement[f]=c},enumerable:!0})};["hash","host","hostname","port","protocol"].forEach(function(f){s(f)}),Object.defineProperty(a,"search",{get:function(){return this._anchorElement.search},set:function(f){this._anchorElement.search=f,this._updateSearchParams()},enumerable:!0}),Object.defineProperties(a,{toString:{get:function(){var f=this;return function(){return f.href}}},href:{get:function(){return this._anchorElement.href.replace(/\?$/,"")},set:function(f){this._anchorElement.href=f,this._updateSearchParams()},enumerable:!0},pathname:{get:function(){return this._anchorElement.pathname.replace(/(^\/?)/,"/")},set:function(f){this._anchorElement.pathname=f},enumerable:!0},origin:{get:function(){var f={"http:":80,"https:":443,"ftp:":21}[this._anchorElement.protocol],c=this._anchorElement.port!=f&&this._anchorElement.port!=="";return this._anchorElement.protocol+"//"+this._anchorElement.hostname+(c?":"+this._anchorElement.port:"")},enumerable:!0},password:{get:function(){return""},set:function(f){},enumerable:!0},username:{get:function(){return""},set:function(f){},enumerable:!0}}),i.createObjectURL=function(f){return o.createObjectURL.apply(o,arguments)},i.revokeObjectURL=function(f){return o.revokeObjectURL.apply(o,arguments)},e.URL=i};if(t()||r(),e.location!==void 0&&!("origin"in e.location)){var n=function(){return e.location.protocol+"//"+e.location.hostname+(e.location.port?":"+e.location.port:"")};try{Object.defineProperty(e.location,"origin",{get:n,enumerable:!0})}catch(o){setInterval(function(){e.location.origin=n()},100)}}})(typeof global!="undefined"?global:typeof window!="undefined"?window:typeof self!="undefined"?self:Sr)});var Qr=Ht((Lt,Kr)=>{/*! + * clipboard.js v2.0.11 + * https://clipboardjs.com/ + * + * Licensed MIT © Zeno Rocha + */(function(t,r){typeof Lt=="object"&&typeof Kr=="object"?Kr.exports=r():typeof define=="function"&&define.amd?define([],r):typeof Lt=="object"?Lt.ClipboardJS=r():t.ClipboardJS=r()})(Lt,function(){return function(){var e={686:function(n,o,i){"use strict";i.d(o,{default:function(){return ki}});var a=i(279),s=i.n(a),f=i(370),c=i.n(f),u=i(817),p=i.n(u);function m(j){try{return document.execCommand(j)}catch(O){return!1}}var d=function(O){var w=p()(O);return m("cut"),w},h=d;function v(j){var O=document.documentElement.getAttribute("dir")==="rtl",w=document.createElement("textarea");w.style.fontSize="12pt",w.style.border="0",w.style.padding="0",w.style.margin="0",w.style.position="absolute",w.style[O?"right":"left"]="-9999px";var k=window.pageYOffset||document.documentElement.scrollTop;return w.style.top="".concat(k,"px"),w.setAttribute("readonly",""),w.value=j,w}var B=function(O,w){var k=v(O);w.container.appendChild(k);var F=p()(k);return m("copy"),k.remove(),F},re=function(O){var w=arguments.length>1&&arguments[1]!==void 0?arguments[1]:{container:document.body},k="";return typeof O=="string"?k=B(O,w):O instanceof HTMLInputElement&&!["text","search","url","tel","password"].includes(O==null?void 0:O.type)?k=B(O.value,w):(k=p()(O),m("copy")),k},z=re;function T(j){return typeof Symbol=="function"&&typeof Symbol.iterator=="symbol"?T=function(w){return typeof w}:T=function(w){return w&&typeof Symbol=="function"&&w.constructor===Symbol&&w!==Symbol.prototype?"symbol":typeof w},T(j)}var Ke=function(){var O=arguments.length>0&&arguments[0]!==void 0?arguments[0]:{},w=O.action,k=w===void 0?"copy":w,F=O.container,q=O.target,Le=O.text;if(k!=="copy"&&k!=="cut")throw new Error('Invalid "action" value, use either "copy" or "cut"');if(q!==void 0)if(q&&T(q)==="object"&&q.nodeType===1){if(k==="copy"&&q.hasAttribute("disabled"))throw new Error('Invalid "target" attribute. Please use "readonly" instead of "disabled" attribute');if(k==="cut"&&(q.hasAttribute("readonly")||q.hasAttribute("disabled")))throw new Error(`Invalid "target" attribute. You can't cut text from elements with "readonly" or "disabled" attributes`)}else throw new Error('Invalid "target" value, use a valid Element');if(Le)return z(Le,{container:F});if(q)return k==="cut"?h(q):z(q,{container:F})},We=Ke;function Ie(j){return typeof Symbol=="function"&&typeof Symbol.iterator=="symbol"?Ie=function(w){return typeof w}:Ie=function(w){return w&&typeof Symbol=="function"&&w.constructor===Symbol&&w!==Symbol.prototype?"symbol":typeof w},Ie(j)}function Ti(j,O){if(!(j instanceof O))throw new TypeError("Cannot call a class as a function")}function nn(j,O){for(var w=0;w0&&arguments[0]!==void 0?arguments[0]:{};this.action=typeof F.action=="function"?F.action:this.defaultAction,this.target=typeof F.target=="function"?F.target:this.defaultTarget,this.text=typeof F.text=="function"?F.text:this.defaultText,this.container=Ie(F.container)==="object"?F.container:document.body}},{key:"listenClick",value:function(F){var q=this;this.listener=c()(F,"click",function(Le){return q.onClick(Le)})}},{key:"onClick",value:function(F){var q=F.delegateTarget||F.currentTarget,Le=this.action(q)||"copy",Rt=We({action:Le,container:this.container,target:this.target(q),text:this.text(q)});this.emit(Rt?"success":"error",{action:Le,text:Rt,trigger:q,clearSelection:function(){q&&q.focus(),window.getSelection().removeAllRanges()}})}},{key:"defaultAction",value:function(F){return yr("action",F)}},{key:"defaultTarget",value:function(F){var q=yr("target",F);if(q)return document.querySelector(q)}},{key:"defaultText",value:function(F){return yr("text",F)}},{key:"destroy",value:function(){this.listener.destroy()}}],[{key:"copy",value:function(F){var q=arguments.length>1&&arguments[1]!==void 0?arguments[1]:{container:document.body};return z(F,q)}},{key:"cut",value:function(F){return h(F)}},{key:"isSupported",value:function(){var F=arguments.length>0&&arguments[0]!==void 0?arguments[0]:["copy","cut"],q=typeof F=="string"?[F]:F,Le=!!document.queryCommandSupported;return q.forEach(function(Rt){Le=Le&&!!document.queryCommandSupported(Rt)}),Le}}]),w}(s()),ki=Ri},828:function(n){var o=9;if(typeof Element!="undefined"&&!Element.prototype.matches){var i=Element.prototype;i.matches=i.matchesSelector||i.mozMatchesSelector||i.msMatchesSelector||i.oMatchesSelector||i.webkitMatchesSelector}function a(s,f){for(;s&&s.nodeType!==o;){if(typeof s.matches=="function"&&s.matches(f))return s;s=s.parentNode}}n.exports=a},438:function(n,o,i){var a=i(828);function s(u,p,m,d,h){var v=c.apply(this,arguments);return u.addEventListener(m,v,h),{destroy:function(){u.removeEventListener(m,v,h)}}}function f(u,p,m,d,h){return typeof u.addEventListener=="function"?s.apply(null,arguments):typeof m=="function"?s.bind(null,document).apply(null,arguments):(typeof u=="string"&&(u=document.querySelectorAll(u)),Array.prototype.map.call(u,function(v){return s(v,p,m,d,h)}))}function c(u,p,m,d){return function(h){h.delegateTarget=a(h.target,p),h.delegateTarget&&d.call(u,h)}}n.exports=f},879:function(n,o){o.node=function(i){return i!==void 0&&i instanceof HTMLElement&&i.nodeType===1},o.nodeList=function(i){var a=Object.prototype.toString.call(i);return i!==void 0&&(a==="[object NodeList]"||a==="[object HTMLCollection]")&&"length"in i&&(i.length===0||o.node(i[0]))},o.string=function(i){return typeof i=="string"||i instanceof String},o.fn=function(i){var a=Object.prototype.toString.call(i);return a==="[object Function]"}},370:function(n,o,i){var a=i(879),s=i(438);function f(m,d,h){if(!m&&!d&&!h)throw new Error("Missing required arguments");if(!a.string(d))throw new TypeError("Second argument must be a String");if(!a.fn(h))throw new TypeError("Third argument must be a Function");if(a.node(m))return c(m,d,h);if(a.nodeList(m))return u(m,d,h);if(a.string(m))return p(m,d,h);throw new TypeError("First argument must be a String, HTMLElement, HTMLCollection, or NodeList")}function c(m,d,h){return m.addEventListener(d,h),{destroy:function(){m.removeEventListener(d,h)}}}function u(m,d,h){return Array.prototype.forEach.call(m,function(v){v.addEventListener(d,h)}),{destroy:function(){Array.prototype.forEach.call(m,function(v){v.removeEventListener(d,h)})}}}function p(m,d,h){return s(document.body,m,d,h)}n.exports=f},817:function(n){function o(i){var a;if(i.nodeName==="SELECT")i.focus(),a=i.value;else if(i.nodeName==="INPUT"||i.nodeName==="TEXTAREA"){var s=i.hasAttribute("readonly");s||i.setAttribute("readonly",""),i.select(),i.setSelectionRange(0,i.value.length),s||i.removeAttribute("readonly"),a=i.value}else{i.hasAttribute("contenteditable")&&i.focus();var f=window.getSelection(),c=document.createRange();c.selectNodeContents(i),f.removeAllRanges(),f.addRange(c),a=f.toString()}return a}n.exports=o},279:function(n){function o(){}o.prototype={on:function(i,a,s){var f=this.e||(this.e={});return(f[i]||(f[i]=[])).push({fn:a,ctx:s}),this},once:function(i,a,s){var f=this;function c(){f.off(i,c),a.apply(s,arguments)}return c._=a,this.on(i,c,s)},emit:function(i){var a=[].slice.call(arguments,1),s=((this.e||(this.e={}))[i]||[]).slice(),f=0,c=s.length;for(f;f{"use strict";/*! + * escape-html + * Copyright(c) 2012-2013 TJ Holowaychuk + * Copyright(c) 2015 Andreas Lubbe + * Copyright(c) 2015 Tiancheng "Timothy" Gu + * MIT Licensed + */var is=/["'&<>]/;Jo.exports=as;function as(e){var t=""+e,r=is.exec(t);if(!r)return t;var n,o="",i=0,a=0;for(i=r.index;i0&&i[i.length-1])&&(c[0]===6||c[0]===2)){r=0;continue}if(c[0]===3&&(!i||c[1]>i[0]&&c[1]=e.length&&(e=void 0),{value:e&&e[n++],done:!e}}};throw new TypeError(t?"Object is not iterable.":"Symbol.iterator is not defined.")}function W(e,t){var r=typeof Symbol=="function"&&e[Symbol.iterator];if(!r)return e;var n=r.call(e),o,i=[],a;try{for(;(t===void 0||t-- >0)&&!(o=n.next()).done;)i.push(o.value)}catch(s){a={error:s}}finally{try{o&&!o.done&&(r=n.return)&&r.call(n)}finally{if(a)throw a.error}}return i}function D(e,t,r){if(r||arguments.length===2)for(var n=0,o=t.length,i;n1||s(m,d)})})}function s(m,d){try{f(n[m](d))}catch(h){p(i[0][3],h)}}function f(m){m.value instanceof Xe?Promise.resolve(m.value.v).then(c,u):p(i[0][2],m)}function c(m){s("next",m)}function u(m){s("throw",m)}function p(m,d){m(d),i.shift(),i.length&&s(i[0][0],i[0][1])}}function mn(e){if(!Symbol.asyncIterator)throw new TypeError("Symbol.asyncIterator is not defined.");var t=e[Symbol.asyncIterator],r;return t?t.call(e):(e=typeof xe=="function"?xe(e):e[Symbol.iterator](),r={},n("next"),n("throw"),n("return"),r[Symbol.asyncIterator]=function(){return this},r);function n(i){r[i]=e[i]&&function(a){return new Promise(function(s,f){a=e[i](a),o(s,f,a.done,a.value)})}}function o(i,a,s,f){Promise.resolve(f).then(function(c){i({value:c,done:s})},a)}}function A(e){return typeof e=="function"}function at(e){var t=function(n){Error.call(n),n.stack=new Error().stack},r=e(t);return r.prototype=Object.create(Error.prototype),r.prototype.constructor=r,r}var $t=at(function(e){return function(r){e(this),this.message=r?r.length+` errors occurred during unsubscription: +`+r.map(function(n,o){return o+1+") "+n.toString()}).join(` + `):"",this.name="UnsubscriptionError",this.errors=r}});function De(e,t){if(e){var r=e.indexOf(t);0<=r&&e.splice(r,1)}}var Fe=function(){function e(t){this.initialTeardown=t,this.closed=!1,this._parentage=null,this._finalizers=null}return e.prototype.unsubscribe=function(){var t,r,n,o,i;if(!this.closed){this.closed=!0;var a=this._parentage;if(a)if(this._parentage=null,Array.isArray(a))try{for(var s=xe(a),f=s.next();!f.done;f=s.next()){var c=f.value;c.remove(this)}}catch(v){t={error:v}}finally{try{f&&!f.done&&(r=s.return)&&r.call(s)}finally{if(t)throw t.error}}else a.remove(this);var u=this.initialTeardown;if(A(u))try{u()}catch(v){i=v instanceof $t?v.errors:[v]}var p=this._finalizers;if(p){this._finalizers=null;try{for(var m=xe(p),d=m.next();!d.done;d=m.next()){var h=d.value;try{dn(h)}catch(v){i=i!=null?i:[],v instanceof $t?i=D(D([],W(i)),W(v.errors)):i.push(v)}}}catch(v){n={error:v}}finally{try{d&&!d.done&&(o=m.return)&&o.call(m)}finally{if(n)throw n.error}}}if(i)throw new $t(i)}},e.prototype.add=function(t){var r;if(t&&t!==this)if(this.closed)dn(t);else{if(t instanceof e){if(t.closed||t._hasParent(this))return;t._addParent(this)}(this._finalizers=(r=this._finalizers)!==null&&r!==void 0?r:[]).push(t)}},e.prototype._hasParent=function(t){var r=this._parentage;return r===t||Array.isArray(r)&&r.includes(t)},e.prototype._addParent=function(t){var r=this._parentage;this._parentage=Array.isArray(r)?(r.push(t),r):r?[r,t]:t},e.prototype._removeParent=function(t){var r=this._parentage;r===t?this._parentage=null:Array.isArray(r)&&De(r,t)},e.prototype.remove=function(t){var r=this._finalizers;r&&De(r,t),t instanceof e&&t._removeParent(this)},e.EMPTY=function(){var t=new e;return t.closed=!0,t}(),e}();var Or=Fe.EMPTY;function It(e){return e instanceof Fe||e&&"closed"in e&&A(e.remove)&&A(e.add)&&A(e.unsubscribe)}function dn(e){A(e)?e():e.unsubscribe()}var Ae={onUnhandledError:null,onStoppedNotification:null,Promise:void 0,useDeprecatedSynchronousErrorHandling:!1,useDeprecatedNextContext:!1};var st={setTimeout:function(e,t){for(var r=[],n=2;n0},enumerable:!1,configurable:!0}),t.prototype._trySubscribe=function(r){return this._throwIfClosed(),e.prototype._trySubscribe.call(this,r)},t.prototype._subscribe=function(r){return this._throwIfClosed(),this._checkFinalizedStatuses(r),this._innerSubscribe(r)},t.prototype._innerSubscribe=function(r){var n=this,o=this,i=o.hasError,a=o.isStopped,s=o.observers;return i||a?Or:(this.currentObservers=null,s.push(r),new Fe(function(){n.currentObservers=null,De(s,r)}))},t.prototype._checkFinalizedStatuses=function(r){var n=this,o=n.hasError,i=n.thrownError,a=n.isStopped;o?r.error(i):a&&r.complete()},t.prototype.asObservable=function(){var r=new U;return r.source=this,r},t.create=function(r,n){return new wn(r,n)},t}(U);var wn=function(e){ne(t,e);function t(r,n){var o=e.call(this)||this;return o.destination=r,o.source=n,o}return t.prototype.next=function(r){var n,o;(o=(n=this.destination)===null||n===void 0?void 0:n.next)===null||o===void 0||o.call(n,r)},t.prototype.error=function(r){var n,o;(o=(n=this.destination)===null||n===void 0?void 0:n.error)===null||o===void 0||o.call(n,r)},t.prototype.complete=function(){var r,n;(n=(r=this.destination)===null||r===void 0?void 0:r.complete)===null||n===void 0||n.call(r)},t.prototype._subscribe=function(r){var n,o;return(o=(n=this.source)===null||n===void 0?void 0:n.subscribe(r))!==null&&o!==void 0?o:Or},t}(E);var Et={now:function(){return(Et.delegate||Date).now()},delegate:void 0};var wt=function(e){ne(t,e);function t(r,n,o){r===void 0&&(r=1/0),n===void 0&&(n=1/0),o===void 0&&(o=Et);var i=e.call(this)||this;return i._bufferSize=r,i._windowTime=n,i._timestampProvider=o,i._buffer=[],i._infiniteTimeWindow=!0,i._infiniteTimeWindow=n===1/0,i._bufferSize=Math.max(1,r),i._windowTime=Math.max(1,n),i}return t.prototype.next=function(r){var n=this,o=n.isStopped,i=n._buffer,a=n._infiniteTimeWindow,s=n._timestampProvider,f=n._windowTime;o||(i.push(r),!a&&i.push(s.now()+f)),this._trimBuffer(),e.prototype.next.call(this,r)},t.prototype._subscribe=function(r){this._throwIfClosed(),this._trimBuffer();for(var n=this._innerSubscribe(r),o=this,i=o._infiniteTimeWindow,a=o._buffer,s=a.slice(),f=0;f0?e.prototype.requestAsyncId.call(this,r,n,o):(r.actions.push(this),r._scheduled||(r._scheduled=ut.requestAnimationFrame(function(){return r.flush(void 0)})))},t.prototype.recycleAsyncId=function(r,n,o){var i;if(o===void 0&&(o=0),o!=null?o>0:this.delay>0)return e.prototype.recycleAsyncId.call(this,r,n,o);var a=r.actions;n!=null&&((i=a[a.length-1])===null||i===void 0?void 0:i.id)!==n&&(ut.cancelAnimationFrame(n),r._scheduled=void 0)},t}(Ut);var On=function(e){ne(t,e);function t(){return e!==null&&e.apply(this,arguments)||this}return t.prototype.flush=function(r){this._active=!0;var n=this._scheduled;this._scheduled=void 0;var o=this.actions,i;r=r||o.shift();do if(i=r.execute(r.state,r.delay))break;while((r=o[0])&&r.id===n&&o.shift());if(this._active=!1,i){for(;(r=o[0])&&r.id===n&&o.shift();)r.unsubscribe();throw i}},t}(Wt);var we=new On(Tn);var R=new U(function(e){return e.complete()});function Dt(e){return e&&A(e.schedule)}function kr(e){return e[e.length-1]}function Qe(e){return A(kr(e))?e.pop():void 0}function Se(e){return Dt(kr(e))?e.pop():void 0}function Vt(e,t){return typeof kr(e)=="number"?e.pop():t}var pt=function(e){return e&&typeof e.length=="number"&&typeof e!="function"};function zt(e){return A(e==null?void 0:e.then)}function Nt(e){return A(e[ft])}function qt(e){return Symbol.asyncIterator&&A(e==null?void 0:e[Symbol.asyncIterator])}function Kt(e){return new TypeError("You provided "+(e!==null&&typeof e=="object"?"an invalid object":"'"+e+"'")+" where a stream was expected. You can provide an Observable, Promise, ReadableStream, Array, AsyncIterable, or Iterable.")}function Ki(){return typeof Symbol!="function"||!Symbol.iterator?"@@iterator":Symbol.iterator}var Qt=Ki();function Yt(e){return A(e==null?void 0:e[Qt])}function Gt(e){return ln(this,arguments,function(){var r,n,o,i;return Pt(this,function(a){switch(a.label){case 0:r=e.getReader(),a.label=1;case 1:a.trys.push([1,,9,10]),a.label=2;case 2:return[4,Xe(r.read())];case 3:return n=a.sent(),o=n.value,i=n.done,i?[4,Xe(void 0)]:[3,5];case 4:return[2,a.sent()];case 5:return[4,Xe(o)];case 6:return[4,a.sent()];case 7:return a.sent(),[3,2];case 8:return[3,10];case 9:return r.releaseLock(),[7];case 10:return[2]}})})}function Bt(e){return A(e==null?void 0:e.getReader)}function $(e){if(e instanceof U)return e;if(e!=null){if(Nt(e))return Qi(e);if(pt(e))return Yi(e);if(zt(e))return Gi(e);if(qt(e))return _n(e);if(Yt(e))return Bi(e);if(Bt(e))return Ji(e)}throw Kt(e)}function Qi(e){return new U(function(t){var r=e[ft]();if(A(r.subscribe))return r.subscribe(t);throw new TypeError("Provided object does not correctly implement Symbol.observable")})}function Yi(e){return new U(function(t){for(var r=0;r=2;return function(n){return n.pipe(e?_(function(o,i){return e(o,i,n)}):me,Oe(1),r?He(t):zn(function(){return new Xt}))}}function Nn(){for(var e=[],t=0;t=2,!0))}function fe(e){e===void 0&&(e={});var t=e.connector,r=t===void 0?function(){return new E}:t,n=e.resetOnError,o=n===void 0?!0:n,i=e.resetOnComplete,a=i===void 0?!0:i,s=e.resetOnRefCountZero,f=s===void 0?!0:s;return function(c){var u,p,m,d=0,h=!1,v=!1,B=function(){p==null||p.unsubscribe(),p=void 0},re=function(){B(),u=m=void 0,h=v=!1},z=function(){var T=u;re(),T==null||T.unsubscribe()};return g(function(T,Ke){d++,!v&&!h&&B();var We=m=m!=null?m:r();Ke.add(function(){d--,d===0&&!v&&!h&&(p=jr(z,f))}),We.subscribe(Ke),!u&&d>0&&(u=new et({next:function(Ie){return We.next(Ie)},error:function(Ie){v=!0,B(),p=jr(re,o,Ie),We.error(Ie)},complete:function(){h=!0,B(),p=jr(re,a),We.complete()}}),$(T).subscribe(u))})(c)}}function jr(e,t){for(var r=[],n=2;ne.next(document)),e}function K(e,t=document){return Array.from(t.querySelectorAll(e))}function V(e,t=document){let r=se(e,t);if(typeof r=="undefined")throw new ReferenceError(`Missing element: expected "${e}" to be present`);return r}function se(e,t=document){return t.querySelector(e)||void 0}function _e(){return document.activeElement instanceof HTMLElement&&document.activeElement||void 0}function tr(e){return L(b(document.body,"focusin"),b(document.body,"focusout")).pipe(ke(1),l(()=>{let t=_e();return typeof t!="undefined"?e.contains(t):!1}),N(e===_e()),Y())}function Be(e){return{x:e.offsetLeft,y:e.offsetTop}}function Yn(e){return L(b(window,"load"),b(window,"resize")).pipe(Ce(0,we),l(()=>Be(e)),N(Be(e)))}function rr(e){return{x:e.scrollLeft,y:e.scrollTop}}function dt(e){return L(b(e,"scroll"),b(window,"resize")).pipe(Ce(0,we),l(()=>rr(e)),N(rr(e)))}var Bn=function(){if(typeof Map!="undefined")return Map;function e(t,r){var n=-1;return t.some(function(o,i){return o[0]===r?(n=i,!0):!1}),n}return function(){function t(){this.__entries__=[]}return Object.defineProperty(t.prototype,"size",{get:function(){return this.__entries__.length},enumerable:!0,configurable:!0}),t.prototype.get=function(r){var n=e(this.__entries__,r),o=this.__entries__[n];return o&&o[1]},t.prototype.set=function(r,n){var o=e(this.__entries__,r);~o?this.__entries__[o][1]=n:this.__entries__.push([r,n])},t.prototype.delete=function(r){var n=this.__entries__,o=e(n,r);~o&&n.splice(o,1)},t.prototype.has=function(r){return!!~e(this.__entries__,r)},t.prototype.clear=function(){this.__entries__.splice(0)},t.prototype.forEach=function(r,n){n===void 0&&(n=null);for(var o=0,i=this.__entries__;o0},e.prototype.connect_=function(){!zr||this.connected_||(document.addEventListener("transitionend",this.onTransitionEnd_),window.addEventListener("resize",this.refresh),xa?(this.mutationsObserver_=new MutationObserver(this.refresh),this.mutationsObserver_.observe(document,{attributes:!0,childList:!0,characterData:!0,subtree:!0})):(document.addEventListener("DOMSubtreeModified",this.refresh),this.mutationEventsAdded_=!0),this.connected_=!0)},e.prototype.disconnect_=function(){!zr||!this.connected_||(document.removeEventListener("transitionend",this.onTransitionEnd_),window.removeEventListener("resize",this.refresh),this.mutationsObserver_&&this.mutationsObserver_.disconnect(),this.mutationEventsAdded_&&document.removeEventListener("DOMSubtreeModified",this.refresh),this.mutationsObserver_=null,this.mutationEventsAdded_=!1,this.connected_=!1)},e.prototype.onTransitionEnd_=function(t){var r=t.propertyName,n=r===void 0?"":r,o=ya.some(function(i){return!!~n.indexOf(i)});o&&this.refresh()},e.getInstance=function(){return this.instance_||(this.instance_=new e),this.instance_},e.instance_=null,e}(),Jn=function(e,t){for(var r=0,n=Object.keys(t);r0},e}(),Zn=typeof WeakMap!="undefined"?new WeakMap:new Bn,eo=function(){function e(t){if(!(this instanceof e))throw new TypeError("Cannot call a class as a function.");if(!arguments.length)throw new TypeError("1 argument required, but only 0 present.");var r=Ea.getInstance(),n=new Ra(t,r,this);Zn.set(this,n)}return e}();["observe","unobserve","disconnect"].forEach(function(e){eo.prototype[e]=function(){var t;return(t=Zn.get(this))[e].apply(t,arguments)}});var ka=function(){return typeof nr.ResizeObserver!="undefined"?nr.ResizeObserver:eo}(),to=ka;var ro=new E,Ha=I(()=>H(new to(e=>{for(let t of e)ro.next(t)}))).pipe(x(e=>L(Te,H(e)).pipe(C(()=>e.disconnect()))),J(1));function de(e){return{width:e.offsetWidth,height:e.offsetHeight}}function ge(e){return Ha.pipe(S(t=>t.observe(e)),x(t=>ro.pipe(_(({target:r})=>r===e),C(()=>t.unobserve(e)),l(()=>de(e)))),N(de(e)))}function bt(e){return{width:e.scrollWidth,height:e.scrollHeight}}function ar(e){let t=e.parentElement;for(;t&&(e.scrollWidth<=t.scrollWidth&&e.scrollHeight<=t.scrollHeight);)t=(e=t).parentElement;return t?e:void 0}var no=new E,Pa=I(()=>H(new IntersectionObserver(e=>{for(let t of e)no.next(t)},{threshold:0}))).pipe(x(e=>L(Te,H(e)).pipe(C(()=>e.disconnect()))),J(1));function sr(e){return Pa.pipe(S(t=>t.observe(e)),x(t=>no.pipe(_(({target:r})=>r===e),C(()=>t.unobserve(e)),l(({isIntersecting:r})=>r))))}function oo(e,t=16){return dt(e).pipe(l(({y:r})=>{let n=de(e),o=bt(e);return r>=o.height-n.height-t}),Y())}var cr={drawer:V("[data-md-toggle=drawer]"),search:V("[data-md-toggle=search]")};function io(e){return cr[e].checked}function qe(e,t){cr[e].checked!==t&&cr[e].click()}function je(e){let t=cr[e];return b(t,"change").pipe(l(()=>t.checked),N(t.checked))}function $a(e,t){switch(e.constructor){case HTMLInputElement:return e.type==="radio"?/^Arrow/.test(t):!0;case HTMLSelectElement:case HTMLTextAreaElement:return!0;default:return e.isContentEditable}}function Ia(){return L(b(window,"compositionstart").pipe(l(()=>!0)),b(window,"compositionend").pipe(l(()=>!1))).pipe(N(!1))}function ao(){let e=b(window,"keydown").pipe(_(t=>!(t.metaKey||t.ctrlKey)),l(t=>({mode:io("search")?"search":"global",type:t.key,claim(){t.preventDefault(),t.stopPropagation()}})),_(({mode:t,type:r})=>{if(t==="global"){let n=_e();if(typeof n!="undefined")return!$a(n,r)}return!0}),fe());return Ia().pipe(x(t=>t?R:e))}function Me(){return new URL(location.href)}function ot(e){location.href=e.href}function so(){return new E}function co(e,t){if(typeof t=="string"||typeof t=="number")e.innerHTML+=t.toString();else if(t instanceof Node)e.appendChild(t);else if(Array.isArray(t))for(let r of t)co(e,r)}function M(e,t,...r){let n=document.createElement(e);if(t)for(let o of Object.keys(t))typeof t[o]!="undefined"&&(typeof t[o]!="boolean"?n.setAttribute(o,t[o]):n.setAttribute(o,""));for(let o of r)co(n,o);return n}function fr(e){if(e>999){let t=+((e-950)%1e3>99);return`${((e+1e-6)/1e3).toFixed(t)}k`}else return e.toString()}function fo(){return location.hash.substring(1)}function uo(e){let t=M("a",{href:e});t.addEventListener("click",r=>r.stopPropagation()),t.click()}function Fa(){return b(window,"hashchange").pipe(l(fo),N(fo()),_(e=>e.length>0),J(1))}function po(){return Fa().pipe(l(e=>se(`[id="${e}"]`)),_(e=>typeof e!="undefined"))}function Nr(e){let t=matchMedia(e);return Zt(r=>t.addListener(()=>r(t.matches))).pipe(N(t.matches))}function lo(){let e=matchMedia("print");return L(b(window,"beforeprint").pipe(l(()=>!0)),b(window,"afterprint").pipe(l(()=>!1))).pipe(N(e.matches))}function qr(e,t){return e.pipe(x(r=>r?t():R))}function ur(e,t={credentials:"same-origin"}){return ve(fetch(`${e}`,t)).pipe(ce(()=>R),x(r=>r.status!==200?Tt(()=>new Error(r.statusText)):H(r)))}function Ue(e,t){return ur(e,t).pipe(x(r=>r.json()),J(1))}function mo(e,t){let r=new DOMParser;return ur(e,t).pipe(x(n=>n.text()),l(n=>r.parseFromString(n,"text/xml")),J(1))}function pr(e){let t=M("script",{src:e});return I(()=>(document.head.appendChild(t),L(b(t,"load"),b(t,"error").pipe(x(()=>Tt(()=>new ReferenceError(`Invalid script: ${e}`))))).pipe(l(()=>{}),C(()=>document.head.removeChild(t)),Oe(1))))}function ho(){return{x:Math.max(0,scrollX),y:Math.max(0,scrollY)}}function bo(){return L(b(window,"scroll",{passive:!0}),b(window,"resize",{passive:!0})).pipe(l(ho),N(ho()))}function vo(){return{width:innerWidth,height:innerHeight}}function go(){return b(window,"resize",{passive:!0}).pipe(l(vo),N(vo()))}function yo(){return Q([bo(),go()]).pipe(l(([e,t])=>({offset:e,size:t})),J(1))}function lr(e,{viewport$:t,header$:r}){let n=t.pipe(X("size")),o=Q([n,r]).pipe(l(()=>Be(e)));return Q([r,t,o]).pipe(l(([{height:i},{offset:a,size:s},{x:f,y:c}])=>({offset:{x:a.x-f,y:a.y-c+i},size:s})))}(()=>{function e(n,o){parent.postMessage(n,o||"*")}function t(...n){return n.reduce((o,i)=>o.then(()=>new Promise(a=>{let s=document.createElement("script");s.src=i,s.onload=a,document.body.appendChild(s)})),Promise.resolve())}var r=class{constructor(n){this.url=n,this.onerror=null,this.onmessage=null,this.onmessageerror=null,this.m=a=>{a.source===this.w&&(a.stopImmediatePropagation(),this.dispatchEvent(new MessageEvent("message",{data:a.data})),this.onmessage&&this.onmessage(a))},this.e=(a,s,f,c,u)=>{if(s===this.url.toString()){let p=new ErrorEvent("error",{message:a,filename:s,lineno:f,colno:c,error:u});this.dispatchEvent(p),this.onerror&&this.onerror(p)}};let o=new EventTarget;this.addEventListener=o.addEventListener.bind(o),this.removeEventListener=o.removeEventListener.bind(o),this.dispatchEvent=o.dispatchEvent.bind(o);let i=document.createElement("iframe");i.width=i.height=i.frameBorder="0",document.body.appendChild(this.iframe=i),this.w.document.open(),this.w.document.write(` + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + + + + + + + +

Example BIDS App

+

This section describes a BIDS Application named bids-app that can only operate +at the participant analysis leveland accepts a numeric seed for a random number +generator.

+

Interface descriptor

+
{
+  "name": "Example BIDS App",
+  "tool-version": "0.0.1",
+  "schema-version": "0.5",
+  "custom": {
+    "BIDSApplicationVersion": "2.0"
+  },
+  "command-line": "bids-app [InputDataset] [OutputLocation] [AnalysisLevel] [ParticipantLabel] [RandomSeed]",
+  "inputs": [
+    {
+      "id": "InputDataset",
+      "name": "Input datasets",
+      "value-key": "[InputDataset]",
+      "type": "File",
+      "list": true,
+      "optional": false,
+      "command-line-flag": "--input-dataset"
+    },
+    {
+      "id": "OutputLocation",
+      "name": "Output location",
+      "value-key": "[OutputLocation]",
+      "type": "File",
+      "optional": false,
+      "command-line-flag": "--output-location"
+    },
+    {
+      "id": "AnalysisLevel",
+      "name": "Analysis level",
+      "value-key": "[AnalysisLevel]",
+      "type": "String",
+      "optional": true,
+      "value-choices": ["participant"],
+      "default-value": "participant",
+      "command-line-flag": "--analysis-level"
+    },
+    {
+      "id": "SubjectLabel",
+      "name": "Participant labels",
+      "value-key": "[ParticipantLabel]",
+      "type": "String",
+      "list": true,
+      "optional": true,
+      "command-line-flag": "--participant-label"
+    },
+    {
+      "id": "OurRandomSeed",
+      "name": "Seed for pseudorandom number generator",
+      "description": "Example parameter that may be relevant.",
+      "value-key": "[OurRandomSeed]",
+      "type": "Number",
+      "optional": true,
+      "command-line-flag": "--random-seed"
+    }
+  ]
+}
+
+

Invocation definition

+

Two example input definitions follow:

+

input_params1.json

+
{
+  "InputDataset": ["/path/to/bids", "/path/to/derivatives"],
+  "OutputLocation": "/path/to/output",
+  "AnalysisLevel": "participant",
+  "SubjectLabel": ["01", "02"],
+  "RandomSeed": 2983578366
+}
+
+

input_params2.json

+
{
+  "InputDataset": ["/path/to/bids", "/path/to/derivatives"],
+  "OutputLocation": "/path/to/output",
+  "AnalysisLevel": "participant"
+}
+
+

BIDS App compatible example

+

Before the BIDS Application specification existed there were BIDS Apps. +Attention has been paid to ensure that BIDS Exec apps can be compatible with +existing BIDS Apps.

+

For example, the term participant was widely used in BIDS Apps, whereas subject +is the preferred term in BIDS. To allow backwards compatibility here you can +use:

+
{
+  "id": "SubjectLabel",
+  "name": "Participant labels",
+  "value-key": "[ParticipantLabel]",
+  "type": "String",
+  "list": true,
+  "optional": true,
+  "command-line-flag": "--participant-label"
+}
+
+ + + + + + +
+
+ + +
+ + + +
+ +
+ + +
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/images/favicon.png b/images/favicon.png new file mode 100644 index 0000000..1e9d318 Binary files /dev/null and b/images/favicon.png differ diff --git a/images/logo.png b/images/logo.png new file mode 100644 index 0000000..3f696ad Binary files /dev/null and b/images/logo.png differ diff --git a/index.html b/index.html new file mode 100644 index 0000000..7155ad8 --- /dev/null +++ b/index.html @@ -0,0 +1,573 @@ + + + + + + + + + + + + + + + + + + + + BIDS Apps execution specification + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + + + + + + + +

BIDS Apps execution specification

+

The Problem

+

Neuroimaging is a field with an enormous library of powerful tools +and openly available datasets that can be difficult to get to work together.

+

What is BIDS?

+

The Brain Imaging Data Structure (BIDS) is a community-driven +standardized data organization protocol that gives analysis tools a common +specification for data input, see this link. BIDS solves the dataset complexity +problem by providing a consistent representation for data sharing and adoption.

+

So why do we need the BIDS Application Specification?

+

While BIDS is great for +standardizing datasets, analytical tools can take a variety of forms, arguments, +and complexities, limiting their ability to be applied interchangeably. The BIDS +Application Specification solves this problem by creating a community-driven +standardized structure for software definitions and their execution.

+

What is this document?

+

This document is a draft for the BIDS Application +specification for the purposes of tool description, provenance and +reproducibility. This is a working document in draft stage and any comments are +welcome. This document inherits all components of the original specification +(for example how to store imaging data, events, stimuli and behavioral data), and +should be seen as an extension of it, not a replacement.

+

How can I help?

+

There are many open comments on the document, and all of them +would benefit from your input. As you read this document, please feel free to +ask questions, complete remaining tasks, or reach out to any of the listed +contributors and moderators.

+ + + + + + +
+
+ + +
+ + + +
+ +
+ + +
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/inputs.html b/inputs.html new file mode 100644 index 0000000..ade1f1e --- /dev/null +++ b/inputs.html @@ -0,0 +1,952 @@ + + + + + + + + + + + + + + + + + + + + + + + + Inputs - BIDS Apps execution specification + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + +
+
+
+ + + + + + + +
+
+ + + + + + + + + + + + + +

Input specification

+

Inputs to BIDS apps may be specified as JSON objects that map input ids to +values. The objects found within the required inputs list have the following +fields, described fully in +https://github.com/boutiques/boutiques/blob/0.5.25/schema/README.md#inputs +(source):

+

List of relevant inputs object properties for the BIDS Application specification

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field nameRequirement LevelData typeDescription
idREQUIREDStringThe argument ID. Alphanumeric values and underscores only. CamelCase is recommended.
nameREQUIREDStringPlain text name of input for display. Can contain spaces.
typeREQUIREDStringOne of {"String", "File", "Flag", "Number"}.
command-line-flagOPTIONALStringFor non-positional arguments, the flag which is associated with the argument on the command-line.
listOPTIONALBooleanIndicates whether or not the input field is a list of inputs. One of {true, false}. If omitted, it will be interpreted as false (for example non-list input).
optionalOPTIONALBooleanIndicates whether or not the input field is required. One of {true, false}. If omitted, will be interpreted as false (for example non-optional input).
value-choicesOPTIONALListList of possible values that the parameter may take.
value-keyOPTIONALStringString to replace in command-line template string. If specified, this MUST NOT be either a superset or subset of the value-key attribute associated with another object in the descriptor; to ensure this, brackets are typically used (for example "[value]").
+

List of group object properties and their role within the BIDS Application specification

+

In addition to describing inputs themselves, groups of inputs and their relationships can be defined as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field nameRequirement LevelData typeDescription
idREQUIREDStringA short, unique, informative identifier containing only alphanumeric characters and underscores.
membersREQUIREDListIDs of the input parameters belonging to this group.
nameREQUIREDStringA human-readable name for the input group.
descriptionRECOMMENDEDStringDescription of the input group.
all-or-noneOPTIONALBooleanTrue if all parameters included in this group need to be included together. .
mutually-exclusiveOPTIONALBooleanTrue if only one input in the group may be selected at runtime.
one-is-requiredOPTIONALBooleanTrue if at least one of the inputs in the group must be selected.
+

Required arguments

+

BIDS Applications MUST provide the following arguments. Notes that "Argument ID" +is what is required to exist as the state "id" in the Boutiques descriptor, and +will be validated, while the example CLI Flag provides a possible way this could +be expressed in the tool's interface.

+

List of custom object properties and roles within the BIDS Application specification

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Argument IDCLI FlagRequirement LevelData typeDescription
AnalysisLevel--analysis-levelREQUIREDStringString with value-choices which are a subset of {run, session, subject, dataset, meta}. The app may support one or more of these analysis levels. A default may be set, and unsupported analysis levels should return an exit code of 17, consistent with the definition in Table 7.
Help--helpREQUIREDFlagFlag that specifies whether or not to show the help-text that describes how the tool may be correctly used.
InputDataset--input-datasetREQUIREDListList of URIs/paths of the BIDS datasets to be processed. Whether or not the order of listed datasets is important MUST be specified in the parameter description. The tool MUST NOT reorder the user-specified list.
OutputLocation--output-locationREQUIREDListOne URI/path to the location where all outputs will be stored.
ToolVersion--versionREQUIREDFlagReturns the version of the tool being used.
+

Backwards compatibility

+

If an app wishes to maintain backwards compatibility with BIDS-Apps 1.0, +then the following command-line should be valid:

+
    bids-app InputDataset OutputLocation AnalysisLevel [options]
+
+

In this case, InputDataset is limited to a list of length one. It is worth +noting that all legacy apps can be supported in this spec, they just need to +write a descriptor which maps the inputs as they are expected and defined, here, +to their associated values in the original application.

+

Reserved arguments

+

The ability to filter BIDS entities (for example subject, session, or run) allows for +the selection of subsets of datasets. To be extensible as new entities are added +to the BIDS specification, the reserved arguments are defined here as a rule +which maps to BIDS entities, rather than specifying the moving goalpost of an +exhaustive list. The arguments may be specified as follows:

+
    +
  • +

    The argument ID SHOULD be in CamelCase, with the form <entity>Label or + <entity>Index, depending on whether the associated values are constrained + to be alphanumeric or numeric, respectively.

    +
  • +
  • +

    The argument MUST accept values referring to labels/indices, as consistent + with the above, in either the form of a list or a file containing a + line-delimited list. The items provided SHOULD NOT include the entity label in + addition to the labels/indices.

    +
  • +
+

While several examples exist within Table 5, to the following demonstrates how +the above rules can be applied for the BIDS entity "subject":

+

ID: SubjectLabel

+

CLI flag: --subject-label

+

Acceptable and equivalent usages:

+
    --subject-label 01 02 03
+    --subject-label subject_ids.txt
+
+

Contents of subject_ids.txt:

+
01
+02
+03
+
+

In all cases where such arguments are defined and applied, only files in the +BIDS dataset that have a value for the specified entities will be subject to +filtering. That is, if a file does not have a given entity (for example entity value +for it is <None>), the file will be included.

+

Applications are not required to support these arguments, but MUST NOT assign +these arguments to other meanings. To reduce conflicts, BIDS Applications SHOULD +avoid using this convention except for entities that are anticipated to be +standardized.

+

Example of an Interface descriptor: see 4.1.

+

For example, suppose we have an application with the following descriptor:

+

example_app.json:

+
{
+    "name": "Example BIDS App",
+    "command-line": "bids-app [InputDataset] [OutputLocation] [AnalysisLevel] [ParticipantLabel] [OurRandomSeed]""inputs": [
+        {
+            "id": "InputDataset",
+            "name": "Input datasets",
+            "value-key": "[InputDataset]",
+            "type": "File",
+            "list": true,
+            "optional": false,
+            "command-line-flag": "--input-datasets"
+        },
+        {
+            "id": "OutputLocation",
+            "name": "Output location",
+            "value-key": "[OutputLocation]",
+            "type": "File",
+            "optional": false,
+            "command-line-flag": "--output-location"
+        },
+        {
+            "id": "AnalysisLevel",
+            "name": "Analysis level",
+            "value-key": "[AnalysisLevel]",
+            "type": "String",
+            "optional": false,
+            "value-choices": [
+                "run",
+                "session",
+                "subject",
+                "dataset"
+            ],
+            "default": "session",
+            "command-line-flag": "--analysis-level"
+        },
+        {
+            "id": "SubjectLabel",
+            "name": "Subject labels",
+            "value-key": "[SubjectLabel]",
+            "type": "String",
+            "list": true,
+            "optional": true,
+            "command-line-flag": "--subject-label"
+        },
+        {
+            "id": "RandomSeed",
+            "name": "Seed for pseudorandom number generator",
+            "value-key": "[RandomSeed]",
+            "type": "Number",
+            "optional": true,
+            "command-line-flag": "--random-seed"
+        }
+    ]
+}
+
+

input_params.json

+
{
+  "InputDataset": ["/path/to/bids", "/path/to/derivatives"],
+  "OutputLocation": "/path/to/output",
+  "AnalysisLevel": "subject",
+  "SubjectLabel": ["01", "02"],
+  "RandomSeed": "0xB1D5CAF3"
+}
+
+ + + + + + +
+
+ + +
+ + + +
+ +
+ + +
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/outputs.html b/outputs.html new file mode 100644 index 0000000..c86dc3e --- /dev/null +++ b/outputs.html @@ -0,0 +1,894 @@ + + + + + + + + + + + + + + + + + + + + + + + + Outputs - BIDS Apps execution specification + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + +
+
+
+ + + + + + + +
+
+ + + + + + + + + + + + + +

Outputs

+

File formats for the application specification and report

+

BIDS Apps MUST be able to be called via the BIDS Application Boutiques +descriptor and corresponding input parameter dictionary files, commonly referred +to in the Boutiques parlance as "invocations", and accept any BIDS dataset. +It is RECOMMENDED that BIDS Applications produce BIDS-Derivatives-compliant datasets.

+

List of relevant output-files object properties for the BIDS Application specification

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field nameRequirement LevelData typeDescription
idREQUIREDStringA short, unique, informative identifier containing only alphanumeric characters and underscores. Typically used to generate variable names. (should conform ^[0-9,_,a-z,A-Z]*$). Example: "data_file"
nameREQUIREDStringA human-readable output name. Example: 'Supplementary input file for X task'.
descriptionRECOMMENDEDStringA plain-text description of the output-files of the BIDS Application.
command-line-flagOPTIONALStringFlag associated with the argument on the command-line. Examples: -o, --output
file-templateOPTIONALArray of stringsAn array of strings that may contain value keys and together populate the self-contained structure of a configuration file.
listOPTIONALBooleanTrue if output is a list of values.
optionalOPTIONALBooleanTrue if output may not be produced by the tool.
path-templateOPTIONALStringDescribes the output file path relative to the execution directory. May contain input value keys and wildcards. Example: "xx".
path-template-stripped-extensionsOPTIONALListList of file extensions that will be stripped from the input values before being substituted in the path template. Example: [". nii",". nii. gz"].
value-keyOPTIONALStringA string contained in command-line, substituted by the output value and/or flag at runtime.
+

Execution Report & Updating Dataset Description

+

When generated, an execution report that completely describes the processing +that was executed and the dataset MUST comply with the BIDS Provenance Extension +Proposal (BEP28). These outputs are OPTIONAL, and if provided, should be +specified in the output-files of the tool descriptor.

+

Similarly, the dataset_description.json file SHOULD be updated to reflect the +processing that has occurred by the BIDS Application.

+

Behaviors

+

For a given set of arguments, the behavior of a BIDS Application will typically +vary based on the contents of the input dataset. The dataset may be +BIDS-compliant, or it may not; and it may contain the file types the BIDS App +requires, or it may not. This section describes the expected behavior under each +combination of cases, and describes RECOMMENDED exit codes on systems that +support them.

+

Valid BIDS datasets

+

If the dataset is BIDS-compliant and contains the files required by the application, +then the application should make a best effort to perform its task to completion.

+

If the dataset is BIDS-compliant but does not contain the files required by the application, +then the application MAY fail immediately or when attempting to open a missing file. +In this case, it is RECOMMENDED to use exit code 66 (NOINPUT).

+

Invalid BIDS datasets

+

If the dataset is not BIDS-compliant, then the BIDS App MAY fail immediately with exit code 16.

+

If the dataset contains the required files but is not BIDS-compliant +(for example a "dirty" dataset that has more files than needed), +then the BIDS App MAY treat the dataset as valid.

+

Exit codes

+

An exit code or exit status is an +integer indicating the reason for termination for use by the parent program or +operating system. The interpretation of exit codes varies across systems, and +programmers SHOULD follow the conventions of the systems for which they are +programming.

+

Most operating systems, including POSIX (Linux, Mac OSX) and Windows use 0 to +indicate success and >0 to indicate failure. POSIX systems are limited to an +unsigned byte (range: 0-255), so these recommendations are limited to that +range. Exit codes 64-78 are specified in BSD +sysexits(3), and +should be avoided unless applicable. Exit codes 2 and 126-165 may be set by +Bash, and so will be +reserved.

+

The following exit codes are RECOMMENDED for consistent error handling +under POSIX and Windows environments:

+

Reserved exit codes and their definitions

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Exit codeDefinition
0SUCCESS. The program completed successfully.
1FAILURE. The program failed for unspecified reasons.
2Reserved
16-31BIDS-related codes. Reserved except the following
16An input dataset failed BIDS validation.
17Unknown analysis level.
18Entity-based filtering options selected no files.
19Both command-line arguments and a parameter invocation file were passed to the application.
64-78BSD codes - Reserved except the following.
64USAGE. The command was used incorrectly.
65DATAERR. The input data was incorrect in some way.
66NOINPUT. The input data was missing or unreadable.
73CANTCREAT. An output file/directory cannot be created.
74IOERR. Failure during file reading/writing.
75TEMPFAIL. Temporary failure. Another run is expected to succeed.
126-165BASH codes - Reserved
+ + + + + + +
+
+ + +
+ + + +
+ +
+ + +
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/scope.html b/scope.html new file mode 100644 index 0000000..21ff8c3 --- /dev/null +++ b/scope.html @@ -0,0 +1,660 @@ + + + + + + + + + + + + + + + + + + + + + + Scope - BIDS Apps execution specification + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + + + + + + + +

Scope

+

While the BIDS format is great for standardizing datasets, analytical tools +operating on that structure can take a variety of forms, arguments, and +complexities, limiting their ability to be applied interchangeably. The BIDS +Application Specification solves this problem by creating a community-driven +standardized structure for software definitions and their execution.

+

This specification extends the Brain Imaging Data Structure (BIDS) Specification +to describe how software pipelines and analytic tools should interact with +BIDS-formatted datasets. These tools will be referred to as "BIDS Apps" or "BIDS +Applications", and can accept any valid BIDS dataset prior to producing some +result (including a message of inaction, as may be applicable in some cases).

+

Goals

+

This extension is motivated by a desire to automatically and reproducibly +process neuroscientific data. It seeks to specify file types and metadata for +describing the execution of command-line programs that operate upon BIDS +datasets. Graphical and web-based interfaces are outside the scope of this +extension, though it is expected that this specification will simplify the +integration of BIDS datasets and applications into such platforms.

+

This is guided by the following requirements and desiderata:

+
    +
  • A tool's parameters should be easily translatable to the BIDS application input specification.
  • +
  • A specification should be maximally descriptive rather than prescriptive.
  • +
  • A structured execution specification should be produced as a result of using an application.
  • +
  • The specification should be sufficiently descriptive to perfectly reproduce analyses.
  • +
  • A structured set of input parameters should be usable in place of command-line arguments.
  • +
  • It should be possible to make multiple BIDS datasets available to an application.
  • +
+

Relation to BIDS

+

The core principles of the original BIDS-Raw specification are inherited by the +BIDS Application specification. This specification is a successor to BIDS-Apps, +which were described in Gorgolewski, et al. 2017 +(doi:10.1371/journal.pcbi.1005209), +here referred to as BIDS-Apps 1.0. Backwards compatibility with BIDS-Apps 1.0 is +not an explicit goal, but can be achieved in many cases as is discussed in +the section on backwards-compatibility. A summary of changes from +BIDS-Apps 1.0 is included in the CHANGELOG.

+

This specification is seen as complementary to BIDS-Derivatives, which is part +of BIDS as of version 1.4.0, and the most recent stable version may be found at +https://bids-specification.readthedocs.io/en/stable/05-derivatives/01-introduction.html. +It is not required that every BIDS Application produce a +BIDS-Derivatives-compliant result dataset, but any outputs that may be required +by the BIDS Application specification must be compliant with the +BIDS-Derivatives specification.

+

Please refer to general BIDS specification document for context and general +guidelines (definitions, units, directory structure, missing values, stimulus +and event information and so on): +https://bids-specification.readthedocs.io/en/stable/

+

The keywords +"MUST", "MUST NOT", "REQUIRED", +"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", +"MAY", and "OPTIONAL" in this document +are to be interpreted as described in [RFC2119.

+

The terminology that will be used is inherited from BIDS-Raw +and includes the following:

+
    +
  • +

    Dataset — a set of neuroimaging and behavioral data acquired for a purpose + of a particular study. A dataset consists of data acquired from one or more + subjects and/or sessions.

    +
  • +
  • +

    Subject — a person or animal participating in the study. + Interchangeable with "Participant".

    +
  • +
  • +

    Session — a consistent logical grouping of neuroimaging and other data across subjects.

    +
  • +
  • +

    Run — an uninterrupted repetition of data acquisition that has the same + acquisition parameters and task (however events can change from run to run due + to different subject response or randomized nature of the stimuli).

    +
  • +
  • +

    - a nonnegative integer, possibly prefixed with arbitrary + number of 0s for consistent indentation, for example, it is 01 in run-01 + following run- specification.

    +
  • +
  • +

    - an alphanumeric value, possibly prefixed with arbitrary + number of 0s for consistent indentation, for example, it is rest in task-rest + following task-

    +
  • +
+ + + + + + +
+
+ + +
+ + + +
+ +
+ + +
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/search/search_index.json b/search/search_index.json new file mode 100644 index 0000000..a506f26 --- /dev/null +++ b/search/search_index.json @@ -0,0 +1 @@ +{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"index.html","title":"BIDS Apps execution specification","text":""},{"location":"index.html#the-problem","title":"The Problem","text":"

Neuroimaging is a field with an enormous library of powerful tools and openly available datasets that can be difficult to get to work together.

"},{"location":"index.html#what-is-bids","title":"What is BIDS?","text":"

The Brain Imaging Data Structure (BIDS) is a community-driven standardized data organization protocol that gives analysis tools a common specification for data input, see this link. BIDS solves the dataset complexity problem by providing a consistent representation for data sharing and adoption.

"},{"location":"index.html#so-why-do-we-need-the-bids-application-specification","title":"So why do we need the BIDS Application Specification?","text":"

While BIDS is great for standardizing datasets, analytical tools can take a variety of forms, arguments, and complexities, limiting their ability to be applied interchangeably. The BIDS Application Specification solves this problem by creating a community-driven standardized structure for software definitions and their execution.

"},{"location":"index.html#what-is-this-document","title":"What is this document?","text":"

This document is a draft for the BIDS Application specification for the purposes of tool description, provenance and reproducibility. This is a working document in draft stage and any comments are welcome. This document inherits all components of the original specification (for example how to store imaging data, events, stimuli and behavioral data), and should be seen as an extension of it, not a replacement.

"},{"location":"index.html#how-can-i-help","title":"How can I help?","text":"

There are many open comments on the document, and all of them would benefit from your input. As you read this document, please feel free to ask questions, complete remaining tasks, or reach out to any of the listed contributors and moderators.

"},{"location":"CHANGELOG.html","title":"Changelog","text":"

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

"},{"location":"CHANGELOG.html#010dev","title":"[0.1.0.dev]","text":""},{"location":"CHANGELOG.html#added","title":"Added","text":"
  • Adopted Boutiques validatable and runnable descriptive standard
  • Increased flexibility for runtime arguments and command-line formatting
  • Defined exit codes to indicate various application outcomes
  • Link between application descriptions and data specification versions
  • Extensible definition which will scale with the BIDS standards as new entities are added
"},{"location":"CHANGELOG.html#changed","title":"Changed","text":""},{"location":"CHANGELOG.html#deprecated","title":"Deprecated","text":"
  • Position arguments are no longer supported.
"},{"location":"CHANGELOG.html#removed","title":"Removed","text":""},{"location":"CHANGELOG.html#fixed","title":"Fixed","text":""},{"location":"CHANGELOG.html#security","title":"Security","text":""},{"location":"CONTRIBUTING.html","title":"Contributing","text":""},{"location":"CONTRIBUTING.html#lead-contributors","title":"Lead Contributors","text":"
  • Christopher J Markiewicz markiewicz@stanford.edu
  • Gregory Kiar gregory.kiar@childmind.org
"},{"location":"CONTRIBUTING.html#contributors","title":"Contributors","text":"
  • Tristan Glatard: tristan.glatard@concordia.ca
  • Pierre Rioux: pierre.rioux@mcgill.ca
  • Yaroslav O. Halchenko yoh@dartmouth.edu
  • Eric Earl eric.earl@nih.gov
  • Pradeep Reddy Raamana raamanap@pitt.edu
  • Aki Nikolaidis aki.nikolaidis@childmind.org
  • Guiomar Niso guiomar.niso@ctb.upm.es,
  • Lennart Walger lennart.walger@ukbonn.de
  • Sebastien Tourbier sebastien.tourbier1@gmail.com
  • Alejandro de la Vega delavega@utexas.edu
  • Robert Luke robert.luke@mq.edu.au
"},{"location":"examples.html","title":"Example BIDS App","text":"

This section describes a BIDS Application named bids-app that can only operate at the participant analysis leveland accepts a numeric seed for a random number generator.

"},{"location":"examples.html#interface-descriptor","title":"Interface descriptor","text":"
{\n\"name\": \"Example BIDS App\",\n\"tool-version\": \"0.0.1\",\n\"schema-version\": \"0.5\",\n\"custom\": {\n\"BIDSApplicationVersion\": \"2.0\"\n},\n\"command-line\": \"bids-app [InputDataset] [OutputLocation] [AnalysisLevel] [ParticipantLabel] [RandomSeed]\",\n\"inputs\": [\n{\n\"id\": \"InputDataset\",\n\"name\": \"Input datasets\",\n\"value-key\": \"[InputDataset]\",\n\"type\": \"File\",\n\"list\": true,\n\"optional\": false,\n\"command-line-flag\": \"--input-dataset\"\n},\n{\n\"id\": \"OutputLocation\",\n\"name\": \"Output location\",\n\"value-key\": \"[OutputLocation]\",\n\"type\": \"File\",\n\"optional\": false,\n\"command-line-flag\": \"--output-location\"\n},\n{\n\"id\": \"AnalysisLevel\",\n\"name\": \"Analysis level\",\n\"value-key\": \"[AnalysisLevel]\",\n\"type\": \"String\",\n\"optional\": true,\n\"value-choices\": [\"participant\"],\n\"default-value\": \"participant\",\n\"command-line-flag\": \"--analysis-level\"\n},\n{\n\"id\": \"SubjectLabel\",\n\"name\": \"Participant labels\",\n\"value-key\": \"[ParticipantLabel]\",\n\"type\": \"String\",\n\"list\": true,\n\"optional\": true,\n\"command-line-flag\": \"--participant-label\"\n},\n{\n\"id\": \"OurRandomSeed\",\n\"name\": \"Seed for pseudorandom number generator\",\n\"description\": \"Example parameter that may be relevant.\",\n\"value-key\": \"[OurRandomSeed]\",\n\"type\": \"Number\",\n\"optional\": true,\n\"command-line-flag\": \"--random-seed\"\n}\n]\n}\n
"},{"location":"examples.html#invocation-definition","title":"Invocation definition","text":"

Two example input definitions follow:

input_params1.json

{\n\"InputDataset\": [\"/path/to/bids\", \"/path/to/derivatives\"],\n\"OutputLocation\": \"/path/to/output\",\n\"AnalysisLevel\": \"participant\",\n\"SubjectLabel\": [\"01\", \"02\"],\n\"RandomSeed\": 2983578366\n}\n

input_params2.json

{\n\"InputDataset\": [\"/path/to/bids\", \"/path/to/derivatives\"],\n\"OutputLocation\": \"/path/to/output\",\n\"AnalysisLevel\": \"participant\"\n}\n
"},{"location":"examples.html#bids-app-compatible-example","title":"BIDS App compatible example","text":"

Before the BIDS Application specification existed there were BIDS Apps. Attention has been paid to ensure that BIDS Exec apps can be compatible with existing BIDS Apps.

For example, the term participant was widely used in BIDS Apps, whereas subject is the preferred term in BIDS. To allow backwards compatibility here you can use:

{\n\"id\": \"SubjectLabel\",\n\"name\": \"Participant labels\",\n\"value-key\": \"[ParticipantLabel]\",\n\"type\": \"String\",\n\"list\": true,\n\"optional\": true,\n\"command-line-flag\": \"--participant-label\"\n}\n
"},{"location":"inputs.html","title":"Input specification","text":"

Inputs to BIDS apps may be specified as JSON objects that map input ids to values. The objects found within the required inputs list have the following fields, described fully in https://github.com/boutiques/boutiques/blob/0.5.25/schema/README.md#inputs (source):

"},{"location":"inputs.html#list-of-relevant-inputs-object-properties-for-the-bids-application-specification","title":"List of relevant inputs object properties for the BIDS Application specification","text":"Field name Requirement Level Data type Description id REQUIRED String The argument ID. Alphanumeric values and underscores only. CamelCase is recommended. name REQUIRED String Plain text name of input for display. Can contain spaces. type REQUIRED String One of {\"String\", \"File\", \"Flag\", \"Number\"}. command-line-flag OPTIONAL String For non-positional arguments, the flag which is associated with the argument on the command-line. list OPTIONAL Boolean Indicates whether or not the input field is a list of inputs. One of {true, false}. If omitted, it will be interpreted as false (for example non-list input). optional OPTIONAL Boolean Indicates whether or not the input field is required. One of {true, false}. If omitted, will be interpreted as false (for example non-optional input). value-choices OPTIONAL List List of possible values that the parameter may take. value-key OPTIONAL String String to replace in command-line template string. If specified, this MUST NOT be either a superset or subset of the value-key attribute associated with another object in the descriptor; to ensure this, brackets are typically used (for example \"[value]\")."},{"location":"inputs.html#list-of-group-object-properties-and-their-role-within-the-bids-application-specification","title":"List of group object properties and their role within the BIDS Application specification","text":"

In addition to describing inputs themselves, groups of inputs and their relationships can be defined as follows:

Field name Requirement Level Data type Description id REQUIRED String A short, unique, informative identifier containing only alphanumeric characters and underscores. members REQUIRED List IDs of the input parameters belonging to this group. name REQUIRED String A human-readable name for the input group. description RECOMMENDED String Description of the input group. all-or-none OPTIONAL Boolean True if all parameters included in this group need to be included together. . mutually-exclusive OPTIONAL Boolean True if only one input in the group may be selected at runtime. one-is-required OPTIONAL Boolean True if at least one of the inputs in the group must be selected."},{"location":"inputs.html#required-arguments","title":"Required arguments","text":"

BIDS Applications MUST provide the following arguments. Notes that \"Argument ID\" is what is required to exist as the state \"id\" in the Boutiques descriptor, and will be validated, while the example CLI Flag provides a possible way this could be expressed in the tool's interface.

"},{"location":"inputs.html#list-of-custom-object-properties-and-roles-within-the-bids-application-specification","title":"List of custom object properties and roles within the BIDS Application specification","text":"Argument ID CLI Flag Requirement Level Data type Description AnalysisLevel --analysis-level REQUIRED String String with value-choices which are a subset of {run, session, subject, dataset, meta}. The app may support one or more of these analysis levels. A default may be set, and unsupported analysis levels should return an exit code of 17, consistent with the definition in Table 7. Help --help REQUIRED Flag Flag that specifies whether or not to show the help-text that describes how the tool may be correctly used. InputDataset --input-dataset REQUIRED List List of URIs/paths of the BIDS datasets to be processed. Whether or not the order of listed datasets is important MUST be specified in the parameter description. The tool MUST NOT reorder the user-specified list. OutputLocation --output-location REQUIRED List One URI/path to the location where all outputs will be stored. ToolVersion --version REQUIRED Flag Returns the version of the tool being used."},{"location":"inputs.html#backwards-compatibility","title":"Backwards compatibility","text":"

If an app wishes to maintain backwards compatibility with BIDS-Apps 1.0, then the following command-line should be valid:

    bids-app InputDataset OutputLocation AnalysisLevel [options]\n

In this case, InputDataset is limited to a list of length one. It is worth noting that all legacy apps can be supported in this spec, they just need to write a descriptor which maps the inputs as they are expected and defined, here, to their associated values in the original application.

"},{"location":"inputs.html#reserved-arguments","title":"Reserved arguments","text":"

The ability to filter BIDS entities (for example subject, session, or run) allows for the selection of subsets of datasets. To be extensible as new entities are added to the BIDS specification, the reserved arguments are defined here as a rule which maps to BIDS entities, rather than specifying the moving goalpost of an exhaustive list. The arguments may be specified as follows:

  • The argument ID SHOULD be in CamelCase, with the form <entity>Label or <entity>Index, depending on whether the associated values are constrained to be alphanumeric or numeric, respectively.

  • The argument MUST accept values referring to labels/indices, as consistent with the above, in either the form of a list or a file containing a line-delimited list. The items provided SHOULD NOT include the entity label in addition to the labels/indices.

While several examples exist within Table 5, to the following demonstrates how the above rules can be applied for the BIDS entity \"subject\":

ID: SubjectLabel

CLI flag: --subject-label

Acceptable and equivalent usages:

    --subject-label 01 02 03\n--subject-label subject_ids.txt\n

Contents of subject_ids.txt:

01\n02\n03\n

In all cases where such arguments are defined and applied, only files in the BIDS dataset that have a value for the specified entities will be subject to filtering. That is, if a file does not have a given entity (for example entity value for it is <None>), the file will be included.

Applications are not required to support these arguments, but MUST NOT assign these arguments to other meanings. To reduce conflicts, BIDS Applications SHOULD avoid using this convention except for entities that are anticipated to be standardized.

Example of an Interface descriptor: see 4.1.

For example, suppose we have an application with the following descriptor:

example_app.json:

{\n\"name\": \"Example BIDS App\",\n\"command-line\": \"bids-app [InputDataset] [OutputLocation] [AnalysisLevel] [ParticipantLabel] [OurRandomSeed]\"\"inputs\": [\n{\n\"id\": \"InputDataset\",\n\"name\": \"Input datasets\",\n\"value-key\": \"[InputDataset]\",\n\"type\": \"File\",\n\"list\": true,\n\"optional\": false,\n\"command-line-flag\": \"--input-datasets\"\n},\n{\n\"id\": \"OutputLocation\",\n\"name\": \"Output location\",\n\"value-key\": \"[OutputLocation]\",\n\"type\": \"File\",\n\"optional\": false,\n\"command-line-flag\": \"--output-location\"\n},\n{\n\"id\": \"AnalysisLevel\",\n\"name\": \"Analysis level\",\n\"value-key\": \"[AnalysisLevel]\",\n\"type\": \"String\",\n\"optional\": false,\n\"value-choices\": [\n\"run\",\n\"session\",\n\"subject\",\n\"dataset\"\n],\n\"default\": \"session\",\n\"command-line-flag\": \"--analysis-level\"\n},\n{\n\"id\": \"SubjectLabel\",\n\"name\": \"Subject labels\",\n\"value-key\": \"[SubjectLabel]\",\n\"type\": \"String\",\n\"list\": true,\n\"optional\": true,\n\"command-line-flag\": \"--subject-label\"\n},\n{\n\"id\": \"RandomSeed\",\n\"name\": \"Seed for pseudorandom number generator\",\n\"value-key\": \"[RandomSeed]\",\n\"type\": \"Number\",\n\"optional\": true,\n\"command-line-flag\": \"--random-seed\"\n}\n]\n}\n

input_params.json

{\n\"InputDataset\": [\"/path/to/bids\", \"/path/to/derivatives\"],\n\"OutputLocation\": \"/path/to/output\",\n\"AnalysisLevel\": \"subject\",\n\"SubjectLabel\": [\"01\", \"02\"],\n\"RandomSeed\": \"0xB1D5CAF3\"\n}\n
"},{"location":"outputs.html","title":"Outputs","text":""},{"location":"outputs.html#file-formats-for-the-application-specification-and-report","title":"File formats for the application specification and report","text":"

BIDS Apps MUST be able to be called via the BIDS Application Boutiques descriptor and corresponding input parameter dictionary files, commonly referred to in the Boutiques parlance as \"invocations\", and accept any BIDS dataset. It is RECOMMENDED that BIDS Applications produce BIDS-Derivatives-compliant datasets.

"},{"location":"outputs.html#list-of-relevant-output-files-object-properties-for-the-bids-application-specification","title":"List of relevant output-files object properties for the BIDS Application specification","text":"Field name Requirement Level Data type Description id REQUIRED String A short, unique, informative identifier containing only alphanumeric characters and underscores. Typically used to generate variable names. (should conform ^[0-9,_,a-z,A-Z]*$). Example: \"data_file\" name REQUIRED String A human-readable output name. Example: 'Supplementary input file for X task'. description RECOMMENDED String A plain-text description of the output-files of the BIDS Application. command-line-flag OPTIONAL String Flag associated with the argument on the command-line. Examples: -o, --output file-template OPTIONAL Array of strings An array of strings that may contain value keys and together populate the self-contained structure of a configuration file. list OPTIONAL Boolean True if output is a list of values. optional OPTIONAL Boolean True if output may not be produced by the tool. path-template OPTIONAL String Describes the output file path relative to the execution directory. May contain input value keys and wildcards. Example: \"xx\". path-template-stripped-extensions OPTIONAL List List of file extensions that will be stripped from the input values before being substituted in the path template. Example: [\". nii\",\". nii. gz\"]. value-key OPTIONAL String A string contained in command-line, substituted by the output value and/or flag at runtime."},{"location":"outputs.html#execution-report-updating-dataset-description","title":"Execution Report & Updating Dataset Description","text":"

When generated, an execution report that completely describes the processing that was executed and the dataset MUST comply with the BIDS Provenance Extension Proposal (BEP28). These outputs are OPTIONAL, and if provided, should be specified in the output-files of the tool descriptor.

Similarly, the dataset_description.json file SHOULD be updated to reflect the processing that has occurred by the BIDS Application.

"},{"location":"outputs.html#behaviors","title":"Behaviors","text":"

For a given set of arguments, the behavior of a BIDS Application will typically vary based on the contents of the input dataset. The dataset may be BIDS-compliant, or it may not; and it may contain the file types the BIDS App requires, or it may not. This section describes the expected behavior under each combination of cases, and describes RECOMMENDED exit codes on systems that support them.

"},{"location":"outputs.html#valid-bids-datasets","title":"Valid BIDS datasets","text":"

If the dataset is BIDS-compliant and contains the files required by the application, then the application should make a best effort to perform its task to completion.

If the dataset is BIDS-compliant but does not contain the files required by the application, then the application MAY fail immediately or when attempting to open a missing file. In this case, it is RECOMMENDED to use exit code 66 (NOINPUT).

"},{"location":"outputs.html#invalid-bids-datasets","title":"Invalid BIDS datasets","text":"

If the dataset is not BIDS-compliant, then the BIDS App MAY fail immediately with exit code 16.

If the dataset contains the required files but is not BIDS-compliant (for example a \"dirty\" dataset that has more files than needed), then the BIDS App MAY treat the dataset as valid.

"},{"location":"outputs.html#exit-codes","title":"Exit codes","text":"

An exit code or exit status is an integer indicating the reason for termination for use by the parent program or operating system. The interpretation of exit codes varies across systems, and programmers SHOULD follow the conventions of the systems for which they are programming.

Most operating systems, including POSIX (Linux, Mac OSX) and Windows use 0 to indicate success and >0 to indicate failure. POSIX systems are limited to an unsigned byte (range: 0-255), so these recommendations are limited to that range. Exit codes 64-78 are specified in BSD sysexits(3), and should be avoided unless applicable. Exit codes 2 and 126-165 may be set by Bash, and so will be reserved.

The following exit codes are RECOMMENDED for consistent error handling under POSIX and Windows environments:

"},{"location":"outputs.html#reserved-exit-codes-and-their-definitions","title":"Reserved exit codes and their definitions","text":"Exit code Definition 0 SUCCESS. The program completed successfully. 1 FAILURE. The program failed for unspecified reasons. 2 Reserved 16-31 BIDS-related codes. Reserved except the following 16 An input dataset failed BIDS validation. 17 Unknown analysis level. 18 Entity-based filtering options selected no files. 19 Both command-line arguments and a parameter invocation file were passed to the application. 64-78 BSD codes - Reserved except the following. 64 USAGE. The command was used incorrectly. 65 DATAERR. The input data was incorrect in some way. 66 NOINPUT. The input data was missing or unreadable. 73 CANTCREAT. An output file/directory cannot be created. 74 IOERR. Failure during file reading/writing. 75 TEMPFAIL. Temporary failure. Another run is expected to succeed. 126-165 BASH codes - Reserved"},{"location":"scope.html","title":"Scope","text":"

While the BIDS format is great for standardizing datasets, analytical tools operating on that structure can take a variety of forms, arguments, and complexities, limiting their ability to be applied interchangeably. The BIDS Application Specification solves this problem by creating a community-driven standardized structure for software definitions and their execution.

This specification extends the Brain Imaging Data Structure (BIDS) Specification to describe how software pipelines and analytic tools should interact with BIDS-formatted datasets. These tools will be referred to as \"BIDS Apps\" or \"BIDS Applications\", and can accept any valid BIDS dataset prior to producing some result (including a message of inaction, as may be applicable in some cases).

"},{"location":"scope.html#goals","title":"Goals","text":"

This extension is motivated by a desire to automatically and reproducibly process neuroscientific data. It seeks to specify file types and metadata for describing the execution of command-line programs that operate upon BIDS datasets. Graphical and web-based interfaces are outside the scope of this extension, though it is expected that this specification will simplify the integration of BIDS datasets and applications into such platforms.

This is guided by the following requirements and desiderata:

  • A tool's parameters should be easily translatable to the BIDS application input specification.
  • A specification should be maximally descriptive rather than prescriptive.
  • A structured execution specification should be produced as a result of using an application.
  • The specification should be sufficiently descriptive to perfectly reproduce analyses.
  • A structured set of input parameters should be usable in place of command-line arguments.
  • It should be possible to make multiple BIDS datasets available to an application.
"},{"location":"scope.html#relation-to-bids","title":"Relation to BIDS","text":"

The core principles of the original BIDS-Raw specification are inherited by the BIDS Application specification. This specification is a successor to BIDS-Apps, which were described in Gorgolewski, et al. 2017 (doi:10.1371/journal.pcbi.1005209), here referred to as BIDS-Apps 1.0. Backwards compatibility with BIDS-Apps 1.0 is not an explicit goal, but can be achieved in many cases as is discussed in the section on backwards-compatibility. A summary of changes from BIDS-Apps 1.0 is included in the CHANGELOG.

This specification is seen as complementary to BIDS-Derivatives, which is part of BIDS as of version 1.4.0, and the most recent stable version may be found at https://bids-specification.readthedocs.io/en/stable/05-derivatives/01-introduction.html. It is not required that every BIDS Application produce a BIDS-Derivatives-compliant result dataset, but any outputs that may be required by the BIDS Application specification must be compliant with the BIDS-Derivatives specification.

Please refer to general BIDS specification document for context and general guidelines (definitions, units, directory structure, missing values, stimulus and event information and so on): https://bids-specification.readthedocs.io/en/stable/

The keywords \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in [RFC2119.

The terminology that will be used is inherited from BIDS-Raw and includes the following:

  • Dataset \u2014 a set of neuroimaging and behavioral data acquired for a purpose of a particular study. A dataset consists of data acquired from one or more subjects and/or sessions.

  • Subject \u2014 a person or animal participating in the study. Interchangeable with \"Participant\".

  • Session \u2014 a consistent logical grouping of neuroimaging and other data across subjects.

  • Run \u2014 an uninterrupted repetition of data acquisition that has the same acquisition parameters and task (however events can change from run to run due to different subject response or randomized nature of the stimuli).

  • - a nonnegative integer, possibly prefixed with arbitrary number of 0s for consistent indentation, for example, it is 01 in run-01 following run- specification.

  • - an alphanumeric value, possibly prefixed with arbitrary number of 0s for consistent indentation, for example, it is rest in task-rest following task- specification."},{"location":"specification.html","title":"BIDS execution specification","text":"

    There are three domains of requirements that BIDS Applications must specify:

    1. User interface components
    2. Required application behaviors
    3. Required application outputs

    BIDS contains \"required\", \"recommended\" and \"optional\" fields. These are indicated throughout the document:

    • REQUIRED: essential to be BIDS compliant (meaning MUST as per RFC2199)
    • RECOMMENDED: gives a warning if not present (meaning SHOULD as per RFC2199)
    • OPTIONAL: no warning if missing (meaning MAY as per RFC2199)

    Ultimately, through using Boutiques to define tools and their parameters, the goal is that each tool can be interacted with as follows:

    $ # Using Boutiques directly, the \"exec launch\" commands will run the app\n$ bosh exec launch bids-app --invocation input_params.json\n$ # Eventually, we envision that BIDS Application interface will also support\n$ # simple, lightweight overrides to provide some of these common values via\n$ # the command line directly.\n$ bids-launch bids-app --input-dataset /path/to/bids /path/to/derivatives \\\n--output-location /path/to/output \\\n--analysis-level subject--subject-label 01 02 \\\n--random-seed 0xBID5CAFE\n

    In the next sections, the bids-app tool, a Boutiques descriptor, and the input_params.json, a set of invocation parameters corresponding to this app, will be defined.

    "},{"location":"ui.html","title":"User interface","text":"

    A uniform user interface is essential to scalable deployment of BIDS Applications. This section describes the common interface components that may be relied upon by users or platforms running these applications (callers). Command-line interfaces map between positional or flag arguments provided through an interactive shell program (for example Bash) to a program and program behavior. However, tools written in different languages or following different conventions may represent and parse these arguments distinctly. For the purposes of automated execution of diverse tools, a more useful interface is a mapping of parameter identifiers to their values, abstracting the way they are represented on the command-line (CLI). Boutiques is a standard developed for this mapping. Boutiques provides a JSON schema and related tools to describe, validate, execute and share command-line tools, among other utilities. The Boutiques toolkit, named bosh, will be referred to when discussing examples throughout this specification.

    Instead of requiring specific positional arguments and flags which assign common names to expected options (for example \"subject-label\") in the command-line interfaces themselves, BIDS Applications should provide a Boutiques descriptor \u2014 a standardized JSON file that describes the command line behavior and operation of a tool \u2014 that map the tool-specific common arguments to these common names, without requiring rewriting of the command-line tools. In the sections below, the identifiers assigned in the Boutiques descriptor are described in the \"Argument ID\" column of relevant tables.

    The Boutiques descriptor for a program SHOULD be retrievable by calling the application with the --bids-exec-spec flag and no other arguments.

    "},{"location":"ui.html#interface-descriptor","title":"Interface descriptor","text":"

    A human-readable schema for a Boutiques descriptor may be found at https://github.com/boutiques/boutiques/blob/0.5.25/schema/README.md. This section attempts to summarize the salient points of that document, but the Boutiques schema is authoritative and complete. In addition to the Boutiques fields (see Tables 1\u20134, 6), BIDS conformant descriptors MUST include a custom object (see Table 2) containing the BIDSApplicationVersion key and associated value which indicates the version of the BIDS application specification to which they conform, together with some additional optional fields. Descriptors SHOULD be simply named as name.json.

    "},{"location":"ui.html#list-of-relevant-base-boutiques-properties-and-their-role-within-bids-applications","title":"List of relevant base Boutiques properties and their role within BIDS Applications","text":"Field name Requirement Level Data type Description command-line REQUIRED String A template string including the command and references to the value-keys of all possible inputs. The ordering imposed here may be significant, in particular for non-optional arguments. custom REQUIRED Object Object which can contain extensible metadata. This has a single required element, as described in Table 2. inputs REQUIRED List List of objects which contain input parameter definitions. Described in Table 3. name REQUIRED String The name of the BIDS Application. output-files REQUIRED List List of objects which contain output parameter definitions. Described in Table 6. schema-version REQUIRED String Boutiques schema version. Must be \"\u22650. 5\". This is not to be confused with the BIDS Application schema and associated version. tool-version REQUIRED String Version of the BIDS Application. description RECOMMENDED String A plain-text description of the BIDS Application. descriptor-url RECOMMENDED String Link to the descriptor itself. Likely a GitHub repo alongside the described tool, for example. doi RECOMMENDED String DOI of the descriptor returned once published via Boutiques. (Note: This is not the DOI of the tool itself. ) suggested-resources RECOMMENDED Object Contains an execution walltime-estimate in seconds, memory usage in MB, and CPU/GPU usage in number of core threads/devices. container-image OPTIONAL Object The name and location of a container image, such as those in Docker or Singularity formats, containing the configured application. error-codes OPTIONAL List List of objects that contain error code information. The reserved error conditions are described in Table 7. groups OPTIONAL List List of objects that contain relational information among input parameters as described in Table 4. This is not to be confused with any other BIDS-relevant definition of groups."},{"location":"ui.html#list-of-custom-object-properties-and-roles-within-the-bids-application-specification","title":"List of custom object properties and roles within the BIDS Application specification","text":"

    The custom object has the following defined fields for use in the context of BIDS Applications.

    Field name Requirement Level Data type Description BIDSAppSpecVersion REQUIRED String The version of the BIDS application specification with which the application complies. OutputDataSpecification OPTIONAL List If output data conforms to a standard definition (for example NIDM-1. 1. 0), these data standards may be included as a list of strings. <unspecified> OPTIONAL Any Any key referring to arbitrary metadata that may be relevant or of interest to the application and its users."}]} \ No newline at end of file diff --git a/sitemap.xml b/sitemap.xml new file mode 100644 index 0000000..da88a05 --- /dev/null +++ b/sitemap.xml @@ -0,0 +1,48 @@ + + + + https://bids-standard.github.io/execution-spec/index.html + 2023-12-26 + daily + + + https://bids-standard.github.io/execution-spec/CHANGELOG.html + 2023-12-26 + daily + + + https://bids-standard.github.io/execution-spec/CONTRIBUTING.html + 2023-12-26 + daily + + + https://bids-standard.github.io/execution-spec/examples.html + 2023-12-26 + daily + + + https://bids-standard.github.io/execution-spec/inputs.html + 2023-12-26 + daily + + + https://bids-standard.github.io/execution-spec/outputs.html + 2023-12-26 + daily + + + https://bids-standard.github.io/execution-spec/scope.html + 2023-12-26 + daily + + + https://bids-standard.github.io/execution-spec/specification.html + 2023-12-26 + daily + + + https://bids-standard.github.io/execution-spec/ui.html + 2023-12-26 + daily + + \ No newline at end of file diff --git a/sitemap.xml.gz b/sitemap.xml.gz new file mode 100644 index 0000000..7f2bc90 Binary files /dev/null and b/sitemap.xml.gz differ diff --git a/specification.html b/specification.html new file mode 100644 index 0000000..2e5c0de --- /dev/null +++ b/specification.html @@ -0,0 +1,548 @@ + + + + + + + + + + + + + + + + + + + + + + + + Specification - BIDS Apps execution specification + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + +
    + + + + +
    + + +
    + +
    + + + + + + +
    +
    + + + +
    +
    +
    + + + + +
    +
    +
    + + + +
    +
    +
    + + + +
    +
    +
    + + + +
    +
    + + + + + + + + + + + + + +

    BIDS execution specification

    +

    There are three domains of requirements that BIDS Applications must specify:

    +
      +
    1. User interface components
    2. +
    3. Required application behaviors
    4. +
    5. Required application outputs
    6. +
    +

    BIDS contains "required", "recommended" and "optional" fields. +These are indicated throughout the document:

    +
      +
    • REQUIRED: essential to be BIDS compliant (meaning MUST as per RFC2199)
    • +
    • RECOMMENDED: gives a warning if not present (meaning SHOULD as per RFC2199)
    • +
    • OPTIONAL: no warning if missing (meaning MAY as per RFC2199)
    • +
    +

    Ultimately, through using Boutiques to define tools and their parameters, +the goal is that each tool can be interacted with as follows:

    +
    $ # Using Boutiques directly, the "exec launch" commands will run the app
    +$ bosh exec launch bids-app --invocation input_params.json
    +$ # Eventually, we envision that BIDS Application interface will also support
    +$ # simple, lightweight overrides to provide some of these common values via
    +$ # the command line directly.
    +$ bids-launch bids-app --input-dataset /path/to/bids /path/to/derivatives \
    +    --output-location /path/to/output \
    +    --analysis-level subject--subject-label 01 02 \
    +    --random-seed 0xBID5CAFE
    +
    +

    In the next sections, the bids-app tool, a Boutiques descriptor, +and the input_params.json, a set of invocation parameters corresponding to this app, +will be defined.

    + + + + + + +
    +
    + + +
    + + + +
    + +
    + + +
    + +
    +
    +
    +
    + + + + + + + + + \ No newline at end of file diff --git a/ui.html b/ui.html new file mode 100644 index 0000000..dc06558 --- /dev/null +++ b/ui.html @@ -0,0 +1,770 @@ + + + + + + + + + + + + + + + + + + + + + + + + User interface - BIDS Apps execution specification + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + +
    + + + + +
    + + +
    + +
    + + + + + + +
    +
    + + + +
    +
    +
    + + + + +
    +
    +
    + + + + + + + +
    +
    + + + + + + + + + + + + + +

    User interface

    +

    A uniform user interface is essential to scalable deployment of BIDS +Applications. This section describes the common interface components that may be +relied upon by users or platforms running these applications (callers). +Command-line interfaces map between positional or flag arguments provided +through an interactive shell program (for example Bash) to a program and program +behavior. However, tools written in different languages or following different +conventions may represent and parse these arguments distinctly. For the purposes +of automated execution of diverse tools, a more useful interface is a mapping of +parameter identifiers to their values, abstracting the way they are represented +on the command-line (CLI). Boutiques is a standard developed for this mapping. +Boutiques provides a +JSON schema and +related tools to describe, validate, execute and share command-line tools, among +other utilities. The Boutiques toolkit, named bosh, will be referred to when +discussing examples throughout this specification.

    +

    Instead of requiring specific positional arguments and flags which assign common +names to expected options (for example "subject-label") in the command-line interfaces +themselves, BIDS Applications should provide a Boutiques descriptor — a +standardized JSON file that describes the command line behavior and operation of +a tool — that map the tool-specific common arguments to these common names, +without requiring rewriting of the command-line tools. In the sections below, +the identifiers assigned in the Boutiques descriptor are described in the +"Argument ID" column of relevant tables.

    +

    The Boutiques descriptor for a program SHOULD be retrievable by calling the +application with the --bids-exec-spec flag and no other arguments.

    +

    Interface descriptor

    +

    A human-readable schema for a Boutiques descriptor may be found at +https://github.com/boutiques/boutiques/blob/0.5.25/schema/README.md. +This section attempts to summarize the salient points of that document, but the +Boutiques schema is authoritative and complete. In addition to the Boutiques +fields (see Tables 1–4, 6), BIDS conformant descriptors MUST include a custom +object (see Table 2) containing the BIDSApplicationVersion key and associated +value which indicates the version of the BIDS application specification to which +they conform, together with some additional optional fields. Descriptors SHOULD +be simply named as name.json.

    +

    List of relevant base Boutiques properties and their role within BIDS Applications

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Field nameRequirement LevelData typeDescription
    command-lineREQUIREDStringA template string including the command and references to the value-keys of all possible inputs. The ordering imposed here may be significant, in particular for non-optional arguments.
    customREQUIREDObjectObject which can contain extensible metadata. This has a single required element, as described in Table 2.
    inputsREQUIREDListList of objects which contain input parameter definitions. Described in Table 3.
    nameREQUIREDStringThe name of the BIDS Application.
    output-filesREQUIREDListList of objects which contain output parameter definitions. Described in Table 6.
    schema-versionREQUIREDStringBoutiques schema version. Must be "≥0. 5". This is not to be confused with the BIDS Application schema and associated version.
    tool-versionREQUIREDStringVersion of the BIDS Application.
    descriptionRECOMMENDEDStringA plain-text description of the BIDS Application.
    descriptor-urlRECOMMENDEDStringLink to the descriptor itself. Likely a GitHub repo alongside the described tool, for example.
    doiRECOMMENDEDStringDOI of the descriptor returned once published via Boutiques. (Note: This is not the DOI of the tool itself. )
    suggested-resourcesRECOMMENDEDObjectContains an execution walltime-estimate in seconds, memory usage in MB, and CPU/GPU usage in number of core threads/devices.
    container-imageOPTIONALObjectThe name and location of a container image, such as those in Docker or Singularity formats, containing the configured application.
    error-codesOPTIONALListList of objects that contain error code information. The reserved error conditions are described in Table 7.
    groupsOPTIONALListList of objects that contain relational information among input parameters as described in Table 4. This is not to be confused with any other BIDS-relevant definition of groups.
    +

    List of custom object properties and roles within the BIDS Application specification

    +

    The custom object has the following defined fields for use in the context of BIDS Applications.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Field nameRequirement LevelData typeDescription
    BIDSAppSpecVersionREQUIREDStringThe version of the BIDS application specification with which the application complies.
    OutputDataSpecificationOPTIONALListIf output data conforms to a standard definition (for example NIDM-1. 1. 0), these data standards may be included as a list of strings.
    <unspecified>OPTIONALAnyAny key referring to arbitrary metadata that may be relevant or of interest to the application and its users.
    + + + + + + +
    +
    + + +
    + + + +
    + +
    + + +
    + +
    +
    +
    +
    + + + + + + + + + \ No newline at end of file