<h1>About from-object-to-icf model</h1>
<h2>In a nutshell</h2>
<p>The model <strong>from-object-to-icf</strong> allows one to deduce, if an object (synonym for structure, situation etc.) impedes someone. It does that by defining a mapping from objects to requirements to ICF components. One could use it to make implications such as "A Swing door impedes everybody who has no gripping ability / no b7301 (ICF)".</p>
<h2>Research questions</h2>
<p>This work is driven by the following research questions:</p>
<ol>
<li>How can one detect, if something (e.g. object) is a barrier?</li>
<li>Why is something becoming a barrier?</li>
<li>How to detect, which groups of people are getting impede by something?</li>
<li>How to detect, what a barrier impedes?</li>
<li>How to prove, that something is becoming less/more accessible?</li>
</ol>
<p>See section "Regarding the research questions" to get answers to questions.</p>
<h2>The model in more detail</h2>
<p>The model is based on a mapping of objects to requirements and requirements to ICF-components. Please see the following illustration:</p>
<p><img alt="" src="https://mfr.osf.io/export?url=https://osf.io/sjdqu/?action=download%26mode=render%26direct%26public_file=True&initialWidth=848&childId=mfrIframe&format=1200x1200.jpeg"></p>
<p>The mapping implies, that if at least one requirement of something is not meet by the user, this something becomes a barrier.</p>
<h3>Underlying principles</h3>
<p><strong>Transitive dependencies:</strong> Elements which are not linked directly are related regardless. The relation between an object, its requirements and related ICF components consists of transitive dependencies.</p>
<p><strong>Measurable requirements</strong>: Requirements must be measurable. Empirical values are not allowed, because they are subjective and therefor depend on a specific person. To be more precise: a requirement needs to be available/not available or represented by a number (e.g. maximum user width).</p>
<p><strong>Non-ambiguous definition of an object:</strong> Objects need to be defined precisely and non-ambiguous. Unclear definition could lead to false assumptions or deductions.</p>
<h3>Formal definitions</h3>
<p><strong>Important terms</strong>:</p>
<ul>
<li>o - An <strong>object</strong> is a synonym/placeholder for something, which could be part of the environment. Usually a physical structure, but could also be non-physical, like a situation, talk, law, rule, website etc.</li>
<li>O - A <strong>set</strong> of objects o, so that O = {o_1, ..., o_n}.</li>
<li>r - A <strong>requirement</strong> defines a certain skill or property an user has to have, if he wants to use something.</li>
<li>R - A set of requirements r, so that R = {r_1, ..., r_n}.</li>
<li>icf - An <strong>ICF component</strong> icf describes a part of the human body or abilities.</li>
<li><strong>ICF</strong> is a set of ICF-components, so that ICF = {icf_1, ... icf_n}.</li>
<li>u - A <strong>user</strong> is a person with his/her utilities, if available, for instance a wheelchair.</li>
<li><strong>U</strong> is a <strong>set of users</strong> u, so that U = {u_1, ..., u_n}. These users are defined by ICF.</li>
</ul>
<p><strong>Definitions:</strong></p>
<ol>
<li>
<p>Each o has a list of requirements R={r_1, ..., r_n}. The set could be empty, but this means the object is accessible.</p>
</li>
<li>
<p>If o has r_1 and r_1 is related to an icf, than o can impede U.</p>
</li>
<li>
<p>If an icf is related to a r in R, all objects O having at least one of the r in R, are related to the icf. That means, that for a given ICF-component you can deduce objects of interest for further checks.</p>
</li>
</ol>
