--- a/bp/index.html Mon Dec 09 23:06:51 2013 +0100
+++ b/bp/index.html Thu Dec 12 11:18:29 2013 +0100
@@ -743,25 +743,24 @@
URIs SHOULD be constructed in accordance with the guidance provided in this document to ensure ease of use during development and proper consideration to the guidelines given herein. However, Web clients accessing such URIs SHOULD NOT parse or otherwise read into the meaning of URIs.
</p>
-<!--
-<p class="highlight"><b>Compliance with http-range-14</b><br>
-The World Wide Web Consortium's (W3C) Technical Architecture Group (TAG) attempted to settle a long standing debate about the use of URL resolution on 15 June 2005. Specifically, they decided: <p class="todo"> Statement not finished </p>
- -->
-<p class="note"><b>TAG advices on http issues</b><br>
+<p class="note"><b>W3C Technical Architecture Group (TAG)</b><br>
+The World Wide Web Consortium's (W3C) <a href="http://www.w3.org/2001/tag/" target="_blank">Technical Architecture Group (TAG)</a> is a special working group within the W3C, in charge of resolving issues involving general Web architecture. The group maintains a list of <a href="http://www.w3.org/2001/tag/#publications" target="_blank">publications</a> and findings, such as the architecture of the World Wide Web [[!webarch]]</p>
+
+<p ><b>TAG advices on http issues</b><br>
The TAG provides advice to the community that they may mint "http" URIs for any resource provided that they follow this simple rule for the sake of removing ambiguity as below:
<div class="highlight">
<ul>
- <li> If an "http" resource responds to a GET request with a 2xx response, then the resource identified by that URI is an information resource;</li>
- <li> If an "http" resource responds to a GET request with a 303 (See Other) response, then the resource identified by that URI could be any resource;</li>
- <li> If an "http" resource responds to a GET request with a 4xx (error) response, then the nature of the resource is unknown.
+ <li> If an <code>"http"</code> resource responds to a <pre>GET</pre> request with a <code>2xx</code> response, then the resource identified by that URI is an information resource;</li>
+ <li> If an <code>"http"</code> resource responds to a <pre>GET</pre> request with a <code>303</code> (See Other) response, then the resource identified by that URI could be any resource;</li>
+ <li> If an <code>"http"</code> resource responds to a <pre>GET</pre> request with a 4xx (error) response, then the nature of the resource is unknown.
</li>
</ul>
</div>
<p>
-The practical implication of http-range-14 for Linked Data and Semantic Web implementors is the requirement to return an HTTP 303 (See Other) response when resolving HTTP URI identifiers for conceptual or physical resources (that is, for resources whose canonical content is non-informational in nature. Current implementations of the Persistent URL (PURL) server provide support for 303 URIs [[Wood2010]]. Although the issue remains unsettled, and occasional attempts have been (and probably will be) made to revisit the TAG’s decision, however compliance with the http-range-14 decision until such time as it may be updated is recommended.
+ Linked Data and Semantic Web implementors have the requirement to return an HTTP 303 (See Other) response when resolving HTTP URI identifiers for conceptual or physical resources (that is, for resources whose canonical content is non-informational in nature. Current implementations of the Persistent URL (PURL) server provide support for 303 URIs [[Wood2010]]. Some issues remain unsettled and the TAG is most of the time involved to coordinate and make recommendations to implementors.
</p>
</section>
@@ -911,23 +910,9 @@
<!-- <p class='todo'>To drop must part of this section, Dave comments</p> -->
-<p>Within government agencies, hosting linked data may require submission and review of a security plan to the authority's security team. 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 aapropriate advisors are involved early on in the process</p>
+<p>Within government agencies, hosting linked data may require submission and review of a security plan to the authority's security team. 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 appropriate advisors are involved early on in the process</p>
-<!--
-<p class="highlight"><b>1- Notify your security official of your intent to publish open government data.</b></p>
-<ul class="note">
- <li>Provide an overview of the Linked Data project</li>
- <li>Describe how you plan to host the data (e.g., cloud, agency data center), and provide implementation timelines</li>
- <li>Consider including your hosting service/software vendor in discussion(s)</li>
-</ul>
-<p class="highlight"><b>2- Solicit assistance from the security official</b></p>
-<ul class="note">
- <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, that can range from 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>
@@ -976,28 +961,7 @@
</p>
</section>
-<!-- todo: Talk to John Erickson to develop this more for possible inclusion
-<p>W3C GLD could recommend a simple <b>provenance scoring system</b> for GLD analogous to TBL's 5 stars for linked data. Such a system might include:</p>
-<ul>
- <li><b>One star:</b> Using the basic <a href="http://bit.ly/imvRX1" target="_blank">W3C DCAT</a> for Linked Data at the catalogs and dataset level</li>
- <li><b>Two stars:</b> DCAT enhanced with more complete Dublin Core and other metadata</li>
- <li><b>Three stars:</b> Above, but with based provenance metadata "within" the datasets</li>
- <li><b>More stars:</b> More rigorous use of PROV DM</li>
-</ul>
-
-<h3>Use cases for provenance in GLD</h3>
-<ul>
- <li>Specifying catalog- and dataset-level provenance</li>
- <li>Specifying provenance within datasets</li>
- <ul>
- <li>Preserving and encoding pre-existing provenance data</li>
- <li>Generating provenance when processing data (e.g. during the Linked Data creation process)</li>
- </ul>
-</ul>
-<p>Possible organization of use cases (Adapted from <a href="http://bit.ly/wlKOEF" target="_blank">Trust and Linked Data</a>):</p>
-
--->