--- a/bp/index.html Fri Jan 20 15:43:12 2012 +0100
+++ b/bp/index.html Wed Jan 25 02:47:51 2012 +0100
@@ -65,6 +65,11 @@
Specific products and services involved in governments publishing linked data will be defined, suitable for use during government procurement. Just as the <a href="http://www.w3.org/WAI/intro/wcag" title="WCAG Overview">Web Content Accessibility Guidelines</a> allow governments to easily specify what they mean when they contract for an accessible Website, these definitions will simplify contracting for data sites and applications.
</p>
+<h4>Status</h4>
+<p>21-Dec-2011 - MikeP and George reaching out to John Sheridan to discuss over the last two weeks of December. Possible that John has already taken leave for the holidays. Needs to get jump started asap.
+</p>
+<p>23-Jan-2012 - Major revision by MikeP
+</p>
<p>
Linked Open Data (LOD) offers novel approaches for publishing and consuming data on the Web. This procurement overview and companion glossary is intended to help contract officers and their technical representatives understand LOD activities, and their associated products and services. It is hoped that this will aid government officials in procuring LOD related products and services.
</p>
@@ -90,6 +95,8 @@
Development and maintenance of linked data is supported by the Semantic Web/Semantic Technologies industry. Useful information about industry vendors/contractors, and their associated products and services, is available from the World Wide Web Consortium’s Government Linked Data (W3C/GLD) workgroup Community Directory.
<p>
+<h5>LOD Production through Consumption Lifecycle</h5>
+
<p>
The following categorizes activities associated with LOD development and maintenance, and identifies products and services and associated with these activities:
</p>
@@ -114,7 +121,7 @@
<h4>Procurement Checklist</h4>
<p>
-Note: This portion of Procurement Best Practices was moved here from the LOD Cookbook?
+Credit: This section of Procurement Best Practices was taken from the <a href="http://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook">Linked Data Cookbook</a>.
The following is an outline of questions a department/agency should consider reviewing as part of their decision to choose a service provider:
<ul>
@@ -140,10 +147,31 @@
<li>Is the vendor or provider an active contributor to Open Source Software, Standards groups, activities associated with data.gov and Linked Open Data projects at the enterprise and/or government level.</li>
-<li>Does the vendor or provider comply with the department/agency’s published Open Source Policy?</li>
+<li>Does the department/agency have a published Open Source Policy?</li>
+
+<li>If so, does the vendor or provider comply with the department/agency’s published Open Source Policy?</li>
</ul>
</p>
+<h4>Security Planning for LOD</h4>
+<p>Within government agencies, hosting linked data may require submission/review of a security plan to Security Officer. While security plan specifics will vary widely based on a range of factors like hosting environment and software configuration, the process for developing and getting a security plan approved can be streamlined if the following guidelines and best practices are considered:</p>
+<p>Notify your security official of your intent to host linked data (earlier is better)</p>
+<ul>
+ <li>Provide an overview of linked data</li>
+ <li>Describe how you plan to host the data (e.g., cloud, agency data center), implementation timelines</li>
+ <li>Consider including your hosting service/software vendor in discussion(s)</li>
+</ul>
+<p>Solicit assistance from the security official:</p>
+<ul>
+ <li>Identify guidance that should be used (e.g. for US Federal Agencies this typically would entail compliance with security control recommendations from NIST Special Publication 800-53)</li>
+ <li>Request clarification on regarding specific content/areas that the plan should address</li>
+ <li>Request a system security plan template to ensure the plan is organized to facilitate the review process (if a vendor is contributing information on controls related to their service/software, the vendor needs to adhere to the template in their response)</li>
+</ul>
+
+<p>Security plans are typically comprised of a set of security controls, describing physical, procedural, technical and other processes and controls in a system which are in place to protect information access, availability and integrity, and for avoiding, counteracting and minimizing security risks. These are typically comprised of several layers, such as physical facility security, network and communications, to considerations of operating system, software, integration and many other elements. As such, there will typically be some common security controls which are inherited, and which may not be specific or unique to the linked data implementation, such as controls inherited from the hosting environment, whether cloud hosting provider, agency data center, et cetera. Additionally, some security controls will be inherited from the software vendors.</p>
+
+<p>As such, opportunities may exist to streamline the development of a security plan, or conversely, to identify potential project security vulnerabilities and risks, through early engagement with hosting providers, software vendors and others who may be responsible for those common, inherited controls. If the inherited controls meet the recommendations, they can then be assembled following the requisite templates, and the system security plan can be completed through addition of any applicable controls specific or unique to the linked data application's configuration, implementation, processes or other elements described in the security control and security plan guidance.</p>
+
<h4>Glossary</h4>
<ul>
<li>
@@ -174,7 +202,7 @@
<!-- VOCABULARY SELECTION -->
<section>
<h3>Vocabulary Selection</h3>
-<p class='responsible'>Michael Hausenblas (DERI), Ghislain Atemezing (INSTITUT TELECOM), David Price (TopQuadrant), Boris Villazon-Terrazas (UPM)</p>
+<p class='responsible'>Michael Hausenblas (DERI), Ghislain Atemezing (INSTITUT TELECOM), Boris Villazon-Terrazas (UPM), George Thomas (Health & Human Services, US), John Erickson (RPI), Biplav Srivastava (IBM)</p>
<p>
The group will provide advice on how governments should select RDF vocabulary terms (URIs), including advice as to when they should mint their own. This advice will take into account issues of stability, security, and long-term maintenance commitment, as well as other factors that may arise during the group's work.
</p>
@@ -233,7 +261,7 @@
<!-- URI CONSTRUCTION -->
<section>
<h3>URI Construction</h3>
-<p class='responsible'>Ghislain Atemezing (INSTITUT TELECOM), Michael Hausenblas (DERI), Boris Villazon-Terrazas (UPM), John Erickson (RPI)</p>
+<p class='responsible'>Ghislain Atemezing (INSTITUT TELECOM), Michael Hausenblas (DERI), Boris Villazon-Terrazas (UPM), Daniel Vila (UPM), John Erickson (RPI), Martin Alvarez (CTIC), Cory Casanove (OMG)</p>
<p>
This section specifies how to create good URIs for use in government linked data. Inputs include <a href="http://www.w3.org/TR/cooluris/" title="Cool URIs for the Semantic Web">Cool URIs for the Semantic Web</a>, <a href="http://www.cabinetoffice.gov.uk/media/308995/public_sector_uri.pdf">Designing URI Sets for the UK Public Sector</a> (PDF), and <a href="http://data.gov.uk/resources/uris" title="Creating URIs | data.gov.uk">Creating URIs</a> (data.gov.uk). Guidance will be produced not only for minting URIs for governmental entities, such as schools or agencies, but also for vocabularies, concepts, and datasets.
</p>
@@ -243,7 +271,7 @@
<!-- VERSIONING -->
<section>
<h3>Versioning</h3>
-<p class='responsible'>Dean Allemang (TopQuadrant), Cory Casanave (OMG), Hadley Beeman (LinkedGov)</p>
+<p class='responsible'>John Erickson (RPI), Ghislain Atemezing (INSTITUT TELECOM), Cory Casanave (OMG), Hadley Beeman (LinkedGov)</p>
<p>
This section specifies how to publish data which has multiple versions, including variations such as:
<ul>
@@ -259,7 +287,7 @@
<!-- STABILITY -->
<section>
<h3>Stability</h3>
-<p class='responsible'>TBD</p>
+<p class='responsible'>Anne Washington (GMU), Ron Reck</p>
<p>
This section specifies how to publish data so that others can rely on it being available in perpetuity, persistently archived if necessary.
</p>
@@ -269,7 +297,7 @@
<!-- LEGACY DATA -->
<section>
<h3>Legacy Data</h3>
-<p class='responsible'>David Price (TopQuadrant), Michael Hausenblas (DERI)</p>
+<p class='responsible'>Michael Hausenblas (DERI), Biplav Srivastava (IBM)</p>
<p>
This section contains advices concerning how to expose legacy data, data which is being maintained in pre-existing (non-linked-data) systems.
</p>
@@ -279,13 +307,19 @@
<!-- COOKBOOK -->
<section>
<h3>Cookbook</h3>
-<p class='responsible'>Bernadette Hyland (3 Round Stones)</p>
+<p class='responsible'>Bernadette Hyland (3 Round Stones), Sarven Capadisli (DERI)</p>
<p>
This section provides a collection of advice on smaller, more specific issues, where known solutions exist to problems collected for the Community Directory. This part is going to be separated out as a Working Group Note, or website, rather than a Recommendation. It may, instead, become part of the Community Directory site.
</p>
<p class='todo'><a href="http://www.w3.org/2011/gld/track/issues/1" title="ISSUE-1: Where should the BP cookbook go? - Government Linked Data Working Group Tracker">ISSUE-1</a>: decide how to proceed with this section; maybe intro here and then link to website?</p>
</section>
+<!-- Pragmatic Provenance -->
+<section>
+<h3>Pragmatic Provenance</h3>
+<p class='responsible'>John Erickson (RPI)</p>
+<p></p>
+</section>
<!-- ACK -->
<section class="appendix">