--- a/bp/index.html Thu Dec 05 22:15:50 2013 +0000
+++ b/bp/index.html Fri Dec 06 09:15:45 2013 +0100
@@ -13,7 +13,7 @@
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
- specStatus: "ED",
+ specStatus: "NOTE",
copyrightStart: "2012",
//lcEnd: "2013-04-08",
@@ -153,12 +153,15 @@
<body>
<!--ACTION TO Bernadette :Indicate in the bp abstract that the document is unfinished and is subject to change -->
+<!-- Comments of Dave to have only one abstract
<section id="abstract">
<p>
-This document provides best practices for creating, publishing and announcing open government content as Linked Data. Guidance on the life cycle of a Linked Data project, beginning with identification of suitable data sets, vocabulary selection, URI naming conventions through publication of data sets is included. The goal of this document is to aid the publication of high quality Linked Open Data (LOD) from government authorities. This document aims to compile the most relevant data management practices, promoting best practices for publishing Linked Open Data and warns against practices that are considered harmful.
+This document provides best practices for creating, publishing and announcing open government content as Linked Data. Guidance on the life cycle of a Linked Data project, beginning with identification of suitable data sets, vocabulary selection, URI naming conventions for publication of data sets is included. The goal of this document is to aid the publication of high quality Linked Open Data (LOD) from government authorities. This document aims to compile the most relevant data management practices, promoting best practices for publishing Linked Open Data and warns against practices that are considered harmful.
</p>
</section>
+ -->
+<!--todo: add here that any further WG could take the doc and reuse it -->
<section id="sotd">
<p>This document is work in progress.</p>
</section>
@@ -170,10 +173,10 @@
</p>
-->
-<section class="introductory">
+<section id="abstract">
<h2>Purpose of the Document</h2>
<p>
-This document sets out a series of best practices designed to facilitate development and delivery of open government data as Linked Data. The following recommendations are offered to creators, maintainers and operators of Web sites publishing open government data.
+This document sets out a series of best practices designed to facilitate development and delivery of open government data as Linked Data. The goal of this document is to aid the publication of high quality Linked Open Data (LOD) from government authorities. This document aims to compile the most relevant data management practices, promoting best practices for publishing Linked Open Data and warns against practices that are considered harmful. The following recommendations are offered to creators, maintainers and operators of Web sites publishing open government data.
</p>
<h2>Audience</h2>
@@ -859,7 +862,7 @@
</li>
<li><b>Domain names and phishing:</b> One of the problems associated with IDN support in browsers is that it can facilitate phishing through what are called 'homograph attacks'. Consequently, most browsers that support IDN also put in place some safeguards to protect users from such fraud.
</li>
- <li><b>Encoding problems:</b> IRI provides a standard way for creating and handling international identifiers, however the support for IRIs among the various semantic Web technology stacks and libraries is not homogenic and may lead to difficulties for applications working with this kind of identifiers. A good reference on this subject can be found in [[i18n-web]] .
+ <li><b>Encoding problems:</b> IRI provides a standard way for creating and handling international identifiers, however the support for IRIs among the various semantic Web technology stacks and libraries is not uniformly and may lead to difficulties for applications working with this kind of identifiers. A good reference on this subject can be found in [[i18n-web]] .
</li>
</ul>
@@ -886,10 +889,11 @@
<h2>Security and Hosting</h2>
-<!-- <p class='todo'>To Review: Michael Pendleton (US EPA)</p> -->
+<!-- <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 following guidelines and best practices are considered:</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 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>
@@ -903,10 +907,14 @@
<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>
-<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>
+<p> Detailed considerations of security issues are beyond the scope of this document. </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> -->
</section>
@@ -920,9 +928,9 @@
<p>
Publishers of Linked Data enter into an implicit social contract with users of their data. Publishers should recognize the responsibility to maintain data once it is published by a government authority. Ensure that the Linked Open Data set(s) your organization publishes remains available where you say it will be. Here is a summary of best practices that relate to the implicit "social contract". Additional informational details are included for reference.
</p>
-<div class="note">
+<div class="note">
<ul class="highlight">
-+ Publish a [[void]] description for each published data set;<br/>
++ Publish a description for each published data set using [[!vocab-dcat]] or [[void]] vocabulary;<br/>
+ Associate metadata on the frequency of data updates;<br/>
+ Associate a government appropriate license with all content your agency publishes if you wish to encourage re-use;<br/>
+ Plan and implement a persistence strategy;<br/>
@@ -937,15 +945,14 @@
</section>
-<!-- Pragmatic Provenance -->
-<!-- Note to Editors: This section is NOT part of our charter and should be folded into other section(s). -->
+
<section id="PROV">
<h2>Provenance</h2>
<!-- <p class='todo'>John Erickson (RPI)</p> -->
<p>
-Provenance is information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness. The PROV Family of Documents [[!prov-o]] defines a model, corresponding serializations and other supporting defintions to enable the inter-operable interchange of provenance information in heterogeneous environments such as the Web.
+Provenance is information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness. The <code>PROV</code> Family of Documents [[!prov-o]] defines a model, corresponding serializations and other supporting defintions to enable the inter-operable interchange of provenance information in heterogeneous environments such as the Web.
</p>
<!-- todo: Talk to John Erickson to develop this more for possible inclusion
@@ -971,39 +978,11 @@
-->
-</section> <!-- Pragmatic Provenance >> -->
-<!-- <p class="todo">To Review: John Erickson (RPI), Ghislain Atemezing (INSTITUT TELECOM), Hadley Beeman (LinkedGov)</p> -->
-<!--
-<p>
-The Digital Library community has faced the problem of versions in digital repositories for more than a decade. One useful summary of thinking in this space can be found at the Version Identification Framework (VIF) Project site. See especially:
-</p>
-<ul>
- <li><a href="http://www2.lse.ac.uk/library/vif/Framework/Essential/index.html">Essential Versioning Information</a></li>
- <li><a href="http://www2.lse.ac.uk/library/vif/Framework/Object/index.html">Embedding Versioning Information in an Object</a></li>
- <li><a href="http://www2.lse.ac.uk/library/vif/Framework/SoftwareDevelopment/index.html">Recommendations for Repository Developers</a></li>
-</ul>
-
-<p>The Resourcing IDentifier Interoperability for Repositories (RIDIR) project (2007-2008) considered in depth the relationship between identifiers and finding versions of objects. See RIDIR Final Report. In their words, RIDIR set out to investigate how the appropriate use of identifiers for digital objects might aid interoperability between repositories and to build a self-contained software demonstrator that would illustrate the findings. A number of related projects are listed at JISC's RIDIR information page.</p>
-<p>In addition, at RPI we have adopted an ad hoc approach to denoting versions of published linked data:</p>
-<ul>
- <li>
- The URI for the "abstract" dataset has no version information, e.g. http://logd.tw.rpi.edu/source/data-gov/dataset/1017
- </li>
- <li>The URI for a particular version appends this, e.g. http://logd.tw.rpi.edu/source/data-gov/dataset/1017/version/1st-anniversary</li>
- <li>The version indicator (e.g. "1st-anniversary") is arbitrary; a date code may be used. We sometimes use NON-ISO 8601 (e.g. "12-Jan-2012" to make it clear this is (in our case) not necessarily machine produced.</li>
-</ul>
-
--->
-
-</section>
-
-
+<!-- << STABILITY.overview -->
<section id="stability-prop">
-<!-- << STABILITY.overview -->
-
<h3>Stability Properties</h3>
@@ -1019,30 +998,6 @@
-<!--
-<p>Use case</p>
-<p>Suppose a city is considering opening up its data. It has certain concerns:</p>
-<ul>
- <ol type="1">
- Business and legal level
- <li>What are the privacy considerations in publishing data? On one hand, city will like to respect the privacy of citizens and businesses, and on the other, it will like the data to be valuable enough to lead to positive change.</li>
- <li>How to pay for the cost of opening up data? Cities may or may not have legal obligations to open up data. Accordingly, they will look for guidance on how to account for the costs. Further, can they levy a license fee if they are not obligated to open data.</li>
- <li>Which data should be opened and when? Should it be by phases? What data should not be shared?</li>
- <li>What policies / laws are needed from the city so that businesses can collaborate on open data, while preserving their IP?</li>
- </ol>
- <ol type="1">
- Technical level
- <li>What should be architecture to share large-scale public data? How do we ensure performance and security?</li>
- <li>What visualization should be supported for different types of data?</li>
- <li>Can we provide a template implementation for the reference architecture?</li>
- </ol>
-</ul>
-
-!-->
-
-</section>
-
-
<!-- REFERENCE: LINKED DATA COOKBOOK -->
<!-- <section>
<h2>References</h2>