--- a/org/index.html Fri Oct 05 11:37:52 2012 +0100
+++ b/org/index.html Fri Oct 05 11:38:35 2012 +0100
@@ -37,11 +37,10 @@
</head>
<body>
-
<section id="abstract">
<p> This document describes a core ontology for organizational structures, aimed
-at supporting linked-data publishing of organizational information across
+at supporting linked data publishing of organizational information across
a number of domains. It is designed to allow domain-specific extensions to add classification
of organizations and roles, as well as extensions to support neighbouring information
such as organizational activities.
@@ -55,21 +54,14 @@
developed within the Government Linked Data Working group.
</section>
-<section class="introductory">
-<h2>Scope</h2>
-
-<p>
-This document is aimed at assisting government IT managers, procurement officers, Web developers, vendors, and researchers who are interested in publishing open government data using W3C standards. The benefits of using international standards for data exchange is to significantly increase interoperability of data.
-</p>
-</section>
-
<!-- INTRODUCTION -->
-<section class="informative">
+
+<section class="introductory">
<h2>Introduction</h2>
<p>This document describes a core ontology for organizational
structures (ORG), aimed
-at supporting linked-data publishing of organizational information across
+at supporting linked data publishing of organizational information across
a number of domains. It is designed to allow domain-specific extensions to add classification
of organizations and roles, as well as extensions to support neighbouring information
such as organizational activities.</p>
@@ -83,6 +75,187 @@
</section>
+<!-- Overview of ontology -->
+
+<section class="informative">
+<h2>Overview of ontology</h2>
+
+<p>This ontology is designed to enable publication of information on
+ organizations and organizational structure including governmental
+ organizations. It is intended to provide a generic, reusable core
+ ontology that can be extended or specialized for use in particular situations.</p>
+
+<p>The ontology gives terms to support representation of:</p>
+<ul>
+ <li><a href="#organizational_structure">organizational structure</a>
+ <ul>
+ <li>notion of an organization</li>
+ <li>decomposition into sub-organizations and units</li>
+ <li>posts within an organization</li>
+ <li>purpose of an organization</li>
+ </ul>
+ </li>
+ <li><a href="#reporting_structure">reporting structure</a>
+ <ul>
+ <li>people reporting structure within an organization</li>
+ <li>roles, relationship between person and organization</li>
+ </ul>
+ </li>
+ <li><a href="#location_information">location information</a>
+ <ul>
+ <li>sites or buildings, locations within sites</li>
+ </ul>
+ </li>
+ <li><a href="#organizational_history">organizational history (merger, renaming, repurposing)</a></li>
+</ul>
+
+<p>This coverage corresponds to the type of information typically
+ found in organizational charts. As such it does not offer a
+ complete representation for all the nuances of organizational
+ control structures and flows of accountability and empowerment.
+ Developers are encouraged to create extension vocabularies for such
+ purposes, building upon this generic foundation.</p>
+
+<p>The ontology does not provide category structures for organization
+type, organization purpose or roles. Different domains will have different
+requirements for classification of such concepts. Instead the ontology
+provides just the core base concepts needed to allow extensions to add specific
+sub-class structures or classification schemes as required. Users of
+ the ontology are encouraged to define <strong>profiles</strong>
+ which strengthen interoperability by specifying particular
+ controlled vocabularies to use for these concepts.
+</p>
+
+<img src="img/diagram.png" alt="Diagram depicting core classes and relationships">
+
+<h3 id="example">Example</h3>
+<p>This example illustrates a small fragment of the organizational
+ structure of the UK Cabinet Office:</p>
+
+<pre>
+<http://reference.data.gov.uk/id/department/co>
+ rdf:type org:Organization , central-government:Department;
+ skos:prefLabel "Cabinet Office" ;
+ org:hasUnit <http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications> .
+
+<http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications>
+ rdf:type org:OrganizationalUnit ;
+ skos:prefLabel "Cabinet Office Communications" ;
+ org:unitOf <http://reference.data.gov.uk/id/department/co> ;
+ org:hasPost <http://reference.data.gov.uk/id/department/co/post/246> .
+
+<http://reference.data.gov.uk/id/department/co/post/246>
+ skos:prefLabel "Deputy Director, Deputy Prime Minister's Spokesperson/Head of Communications" .
+ org:postIn <http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications> ;
+ org:heldBy <#person161> .
+ </pre>
+
+</section>
+
+
+<!-- Descriptive section -->
+
+<section id="description">
+
+<h2>Description and commentary</h2>
+
+<section id="organizational_structure" class="informative">
+<h3>Organizational structure</h3>
+
+<section class="informative">
+<h3>Notes on formal organizations</h3>
+<p>Note that the subclass hierarchy
+ below <code>org:Organization</code> is not a full covering. There
+ can be <code>org:Organization</code>s which are in
+ neither <code>org:FormalOrganization</code>
+ nor in <code>org:OrganizationalUnit</code>. Note also
+ that the containment hierarchy is completely open
+ - <code>org:FormalOrganization</code>s are free to contain
+ other <code>org:FormalOrganization</code>s (e.g. subsidiaries of
+ large corporations).</p>
+</section>
+
+<section class="informative">
+<h3>Notes on organizational hierarchy</h3>
+
+<p>In many organizations there is a hierarchy of unit structures. For example we might see a containment hierarchy like:</p>
+
+<pre class="code">Corporation
+ BusinessUnit
+ Division
+ Function
+</pre>
+
+<p>Such hierarchies are specific to the organization, or class of
+ organization being modelled. Profiles of ORG may include
+ sub-classes of <code>org:OrganizationalUnit</code> to
+ represent such structures and specialize or restrict the use
+ of <code>org:hasSubOrganization</code> to match the desired hierarchy.</p>
+</section>
+
+<section class="informative">
+<h3>Notes on organizational classification</h3>
+
+<p>In a number of circumstances we wish to classify organizations. There are many approaches that could be
+taken for this. It can be based on the legal structure under which the organization operates.
+For example in UK legislation there are defined notions of Partnership, Limited Company (public, private) etc
+that can be used as a basis for classification.
+Alternatively organizations can be classified by the service they provide (e.g. Educational, Manufacturing, LegalService etc).</p>
+
+<p>The core organization ontology is neutral with respect to such choices.
+It is anticipated that profiles will either introduce
+subclasses of <code>org:Organization</code> or define a classification
+ scheme to use with the <code>org:classification</code>
+ property. </p>
+
+<p>Which of these mechanisms to use depends on the nature of the
+ profile. If the classification is not intrinsic to the organization
+ but simply some way to group organizations, for example as part of a
+ directory, then <code>org:classification</code> should be used. If the
+ classification is a reflection of the intrinsic nature of the
+ organization and affects other properties then the sub-class
+ approach should be used.
+ For example, only Charities have CharityNumbers so it would be better to represent a
+ Charity as a subClassOf <code>org:FormalOrganization</code> rather
+ than via a taxonomic labelling.</p>
+</section>
+
+</section>
+
+<section id="reporting_structure" class="informative">
+<h3>Reporting structure</h3>
+</section>
+
+<section id="location_information" class="informative">
+<h3>Location information</h3>
+</section>
+
+<section id="organizational_history" class="informative">
+<h3>Organizational history</h3>
+</section>
+
+<section class="informative">
+<h3>Notes on style</h3>
+
+<p><em>Use of inverses:</em> designers differ on whether providing pairs of inverse relationships between
+concepts is good practice compared to declaring each relationship in just one direction. In this design we
+provide inverses for most relations (omitting attribute-like relations). This makes it easier to query
+the data in linked data settings where a (non-symmetric) closed bounded description is often the
+default description of each resource. This does incur a cost in terms
+ of maintenance of those relationships.
+Particular applications of the ontology may adopt a profile in which only certain directions are asserted in the
+ data and leave it up to clients to apply any inverseOf reasoning they require.</p>
+
+<p><em>Naming:</em> some designers prefer to name properties by nouns which describe the object
+of the property, others prefer to treat property names as names of the link and use a pattern
+to indicate the direction of the link. Here we adopt the latter approach for those properties
+which are relational and especially when the direction is ambiguous.
+We use the URI pattern <code>org:hasFoo/org:fooOf</code> for this but simplify the labels to "foo"
+and "foo of" to improve readability in linked data viewers.</p>
+</section>
+
+</section> <!-- End of descriptive section -->
+
<section id="conformance">
<p>A data interchange, however that interchange occurs, is conformant
with ORG if:
@@ -141,106 +314,11 @@
</table>
</section>
-<!-- Overview of ontology -->
-<section class="informative">
-<h2>Overview of ontology</h2>
-
-
-<p>This ontology was original motivated by a need to publish information
-relating to government organizational structure as part of
- the <em>data.gov.uk</em> initiative.
-The approach adopted was to develop a small, generic, reusable core
-ontology for organizational information and then let developers extend
-and specialize it to particular domains. </p>
-
-<p>The ontology gives terms to support representation of:</p>
-<ul>
- <li>organizational structure
- <ul>
- <li>notion of an organization</li>
- <li>decomposition into sub-organizations and units</li>
- <li>posts within an organization</li>
- <li>purpose of an organization</li>
- </ul>
- </li>
- <li>reporting structure
- <ul>
- <li>people reporting structure within an organization</li>
- <li>roles, relationship between person and organization</li>
- </ul>
- </li>
- <li>location information
- <ul>
- <li>sites or buildings, locations within sites</li>
- </ul>
- </li>
- <li>organizational history (merger, renaming, repurposing)</li>
-</ul>
-
-<p>This coverage corresponds to the type of information typically
- found in organizational charts. As such it does not offer a
- complete representation for all the nuances of organizational
- control structures and flows of accountability and empowerment.
- Developers are encouraged to create extension vocabularies for such
- purposes, building upon this generic foundation.</p>
-<p>The ontology does not provide category structures for organization
-type, organization purpose or roles. Different domains will have different
-requirements for classification of such concepts. Instead the ontology
-provides just the core base concepts needed to allow extensions to add specific
-sub-class structures or classification schemes as required. Users of
- the ontology are encouraged to define <strong>profiles</strong>
- which strengthen interoperability by specifying particular
- controlled vocabularies to use for these concepts.
-</p>
-
-<img src="img/diagram.png" alt="Diagram dipicting core classes and relationships">
-
-
-
-<h2 id="example">Example</h2>
-<p>This example illustrates a small fragment of the organizational
- structure of the UK Cabinet Office:</p>
+<!-- Ontology section -->
-<pre>
-<http://reference.data.gov.uk/id/department/co>
- rdf:type org:Organization , central-government:Department;
- skos:prefLabel "Cabinet Office" ;
- org:hasUnit <http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications> .
-
-<http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications>
- rdf:type org:OrganizationalUnit ;
- skos:prefLabel "Cabinet Office Communications" ;
- org:unitOf <http://reference.data.gov.uk/id/department/co> ;
- org:hasPost <http://reference.data.gov.uk/id/department/co/post/246> .
-
-<http://reference.data.gov.uk/id/department/co/post/246>
- skos:prefLabel "Deputy Director, Deputy Prime Minister's Spokesperson/Head of Communications" .
- org:postIn <http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications> ;
- org:heldBy <#person161> .
- </pre>
-
-</section>
-
-<section class="informative">
-<h3>Notes on style</h3>
-
-<p><em>Use of inverses:</em> designers differ on whether providing pairs of inverse relationships between
-concepts is good practice compared to declaring each relationship in just one direction. In this design we
-provide inverses for most relations (omitting attribute-like relations). This makes it easier to query
-the data in linked-data settings where a (non-symmetric) closed bounded description is often the
-default description of each resource. This does incur a cost in terms
- of maintenance of those relationships.
-Particular applications of the ontology may adopt a profile in which only certain directions are asserted in the
- data and leave it up to clients to apply any inverseOf reasoning they require.</p>
-
-<p><em>Naming:</em> some designers prefer to name properties by nouns which describe the object
-of the property, others prefer to treat property names as names of the link and use a pattern
-to indicate the direction of the link. Here we adopt the latter approach for those properties
-which are relational and especially when the direction is ambiguous.
-We use the URI pattern <code>org:hasFoo/org:fooOf</code> for this but simplify the labels to "foo"
-and "foo of" to improve readability in linked data viewers.</p>
-</section>
+<!-- <section id="description" class="informative"> -->
+<1-- </section> <!-- end of ontology section -->
<!-- Organizational structure -->
<section>
@@ -339,7 +417,7 @@
classification scheme. </p>
<p>Note that it also permissible for applications to define
sub-classes of <code>org:Organization</code> as a means to represent
- orgnanizational categories.</p>
+ organizational categories.</p>
<table class="definition">
<thead><tr><th>RDF Property:</th><th><a href="http://www.w3.org/ns/org#classification">org:classification</a></th></tr></thead>
@@ -369,7 +447,7 @@
<tr><td class="prop">Domain:</td><td><a href="http://www.w3.org/ns/org#Organization">org:Organization</a></td></tr>
<tr><td class="prop">subPropertyOf:</td><td> <a href="http://www.w3.org/2004/02/skos/core#notation">skos:notation</a></td></tr>
<tr><td class="prop">Usage note:</td><td>
- Many different national and international identier schemes are available from other
+ Many different national and international identifier schemes are available from other
vocabularies. The ORG ontology is neutral to which schemes are used. The particular identifier
scheme should be indicated by the datatype of the identifier value.
Using datatypes to distinguish the notation scheme used is consistent
@@ -481,63 +559,6 @@
</section> <!-- end of Class OrganizationalUnit-->
-<section class="informative">
-<h3>Notes on formal organizations</h3>
-<p>Note that the subclass hierarchy
- below <code>org:Organization</code> is not a full covering. There
- can be <code>org:Organization</code>s which are in
- neither <code>org:FormalOrganization</code>
- nor in <code>org:OrganizationalUnit</code>. Note also
- that the containment hierarchy is completely open
- - <code>org:FormalOrganization</code>s are free to contain
- other <code>org:FormalOrganization</code>s (e.g. subsidiaries of
- large corporations).</p>
-</section>
-
-<section class="informative">
-<h3>Notes on organizational hierarchy</h3>
-
-<p>In many organizations there is a hierarchy of unit structures. For example we might see a containment hierarchy like:</p>
-
-<pre class="code">Corporation
- BusinessUnit
- Division
- Function
-</pre>
-
-<p>Such hierarchies are specific to the organization, or class of
- organization being modelled. Profiles of ORG may include
- sub-classes of <code>org:OrganizationalUnit</code> to
- represent such structures and specialize or restrict the use
- of <code>org:hasSubOrganization</code> to match the desired hierarchy.</p>
-</section>
-
-<section class="informative">
-<h3>Notes on organizational classification</h3>
-
-<p>In a number of circumstances we wish to classify organizations. There are many approaches that could be
-taken for this. It can be based on the legal structure under which the organization operates.
-For example in UK legislation there are defined notions of Partnership, Limited Company (public, private) etc
-that can be used as a basis for classification.
-Alternatively organizations can be classified by the service they provide (e.g. Educational, Manufacturing, LegalService etc).</p>
-
-<p>The core organization ontology is neutral with respect to such choices.
-It is anticipated that profiles will either introduce
-subclasses of <code>org:Organization</code> or define a classification
- scheme to use with the <code>org:classification</code>
- property. </p>
-
-<p>Which of these mechanisms to use depends on the nature of the
- profile. If the classification is not intrinsic to the organization
- but simply some way to group organizations, for example as part of a
- directory, then <code>org:classification</code> should be used. If the
- classification is a reflection of the intrinsic nature of the
- organization and affects other properties then the sub-class
- approach should be used.
- For example, only Charities have CharityNumbers so it would be better to represent a
- Charity as a subClassOf <code>org:FormalOrganization</code> rather
- than via a taxonomic labelling.</p>
-</section>
</section>
<!-- End of section Organizational structure -->
@@ -603,7 +624,7 @@
</pre>
<p>Since this representation can be a little less convenient to query and
-explore via linked-data browsing tools the core allows both explicit roles and
+explore via linked data browsing tools the core allows both explicit roles and
simple direct relations to be used simultaneously. The relationship between
the Role resource and the corresponding property can be indicated through
the <code>org:roleProperty</code> annotation. Thus we might extend the above example with:</p>
@@ -619,7 +640,7 @@
eg:ctoOf <http://example.com/org#id> .
</pre>
-<p>In practice we antipate tool chains generating the <code>org:Membership</code> instances
+<p>In practice we anticipate tool chains generating the <code>org:Membership</code> instances
and a simple closure rule being used to add any corresponding
short-cut specializations of <code>org:memberOf</code>.</p>
@@ -707,8 +728,8 @@
indication of the nature of that membership or the role
played. Note that the choice of property name is not meant to
limit the property to only formal membership arrangements, it
- is also indended to cover related concepts such as
- affilliation or other involvement in the
+ is also intended to cover related concepts such as
+ affiliation or other involvement in the
organization. Extensions can specialize this relationship to
indicate particular roles within the organization or more
nuanced relationships to the organization.
@@ -1461,7 +1482,7 @@
</section>
<section class="appendix">
<h2>Acknowledgments</h2>
-<p>This ontology was originally developed as part of the UK Linked Data Kernel project
+<p>This ontology was originally developed for use by data.gov.uk as part of the UK Linked Data Kernel project
under the leadership and guidance of John Sheridan (The National Archives).
Jeni Tennison provided immensely useful feedback and suggestions on the first draft,
which greatly improved its design. The work also took inspiration from a