Commented out stuff that I don't think belongs in the BP document, including choosing entity URIs, discussion of what the TAG does, and a checklist for constructing URIs. All interesting stuff but not in a BP doc for people new to the world of LOD. Added anchor points to link correctly in body of doc.
authorbhyland
Thu, 12 Dec 2013 17:50:11 -0500
changeset 730 703fb36c9a1c
parent 729 cef466d6414a
child 731 bdc1d310a873
Commented out stuff that I don't think belongs in the BP document, including choosing entity URIs, discussion of what the TAG does, and a checklist for constructing URIs. All interesting stuff but not in a BP doc for people new to the world of LOD. Added anchor points to link correctly in body of doc.
bp/index.html
--- a/bp/index.html	Thu Dec 12 13:48:48 2013 -0500
+++ b/bp/index.html	Thu Dec 12 17:50:11 2013 -0500
@@ -242,10 +242,6 @@
 
 <p class='stmt'><a href="#PERSONAL">PERSONALLY IDENTIFIABLE DATA:</a><br /> Do not publish personally identifiable information as Linked Open Data as it can potentially be misused.</p>
 
-<p class='stmt'><a href="#LICENSE">ASSOCIATE A LICENSE:</a> <br />Associate an appropriate open 
-license with the published data.  People will only reuse data when there is a clear, acceptable license associated with it.
-</p>
-
 <p class='stmt'><a href="#MODEL">MODEL:</a> <br /><a href="http://www.w3.org/TR/ld-glossary/#modeling-process">Model</a> the 
 data in an application-independent way.</p>
 
@@ -258,6 +254,9 @@
 organization and/or agency, creation date, modification date, version, frequency of updates, contact email for the data steward(s). 
 </p>
 
+<p class='stmt'><a href="#LICENSE">SPECIFY A LICENSE:</a> <br />Specify an appropriate open 
+license with the published data.</p>
+
 <p class='stmt'><a href="#HUMAN">HUMAN READABLE:</a> <br />Provide human readable descriptions with your Linked Data.
 </p>
 
@@ -297,10 +296,6 @@
 to handle the customer service and technical support required to support the global Web audience.
 </p>
 
-<p class='stmt'><a href="#NETWORK">NETWORK EFFECT:</a><br /> Establish and manage the 
-network effect by helping other data stewards.  Support the use of Linked Open Data through guidance, 
-pilot funding or technical assistance and know how.</p>
-
 <p class='stmt'><a href="#SOCIAL-CONTRACT">SOCIAL_CONTRACT:</a> <br />Publishing Linked Open Data on the Web 
 implies a social contract.  Associating a good open data license is necessary.  Regular updates and 
 maintenance is a requirement. A permanent identifier scheme is highly recommended.  If authorities move 
@@ -371,7 +366,7 @@
 <h2>Select a Dataset</h2>
 
 <p>
-Consider publishing a dataset that is uniquely collected by your organization. Ideally, this information when combined with other open data provides greater value.  Government agencies are in a unique position to collect and curate valuable datasets.  Since there is effort and cost associated with modeling, publishing and maintaining any data set as a public service, selection of high value data sets may be guided re-use potential and popularity, among other factors.  Data about geographic features, human health, legislation, population and demographics, and the environmental data are just some of the popular open government data sets that have been published as Linked Open Data.
+When publishing a dataset, select data that is uniquely collected or created by your organization. Ideally, this information when combined with other open data provides greater value.  Government agencies are in a unique position to collect and curate valuable datasets.  Since there is effort and cost associated with modeling, publishing and maintaining any data set as a public service, selection of high value data sets may be guided re-use potential and popularity, among other factors.  Data about geographic features, human health, legislation, population and demographics, and the environmental data are just some of the popular open government data sets that have been published as Linked Open Data.
 </p>
 
 <p>
@@ -402,6 +397,52 @@
 </section>
 
 
+<!--   BASIC METADATA   -->
+<section id="BASIC-METADATA">
+<h2>Basic Metadata for Linked Datasets</h2>
+
+<!-- NOTE TO EDITORS: Link summary to right place -->
+
+</section>
+
+
+<!--   MACHINE ACCESSIBLE   -->
+<section id="MACHINE-ACCESSIBLE">
+<h2>Machine Accessible Access to Data</h2>
+
+<!-- NOTE TO EDITORS: Link summary to right place -->
+
+</section>
+
+
+<!--   DATA CONVERSION   -->
+<section id="DATA CONVERSION">
+<h2>Converting Data to Linked Data</h2>
+
+<!-- NOTE TO EDITORS: (BOH) @@[email protected]@ -->
+
+</section>
+
+
+<!--   LINKS ARE KEY   -->
+<section id="LINKS">
+<h2>Links are Key</h2>
+
+<!-- NOTE TO EDITORS: (BOH) Link summary to right place with all the vocab stuff -->
+
+</section>
+
+
+<!--   ANNOUNCE   -->
+<section id="LINKS">
+<h2>Announcing to the Public</h2>
+
+<!-- NOTE TO EDITORS: (BOH) Link summary to right place -->
+
+</section>
+
+
+
 <!--   VOCABULARY SELECTION   -->
 <section id="STANDARD-VOCABULARIES">
 <h2>Vocabulary Selection</h2>
@@ -437,8 +478,10 @@
 
 </section>
 
-<!-- section conformance -->
+
+<!-- Conformance for Vocabularies -->
 <section id='conformanceForVocabs'>
+
 <h2>Conformance for Vocabularies</h2>
 A data interchange, however that interchange occurs, is <b>conformant</b> with a vocabulary if:
 
@@ -508,9 +551,7 @@
 </section>
 
 
-
-
-<!-- << Vocabulary Selection Criteria checklist -->
+<!-- Vocabulary Selection Criteria -->
 <section id="vocab-checklist">
 <h2>Vocabulary Selection Criteria</h2>
 
@@ -748,51 +789,22 @@
         <li>Provide multilingual labels for the terms.</li>
     </ul>
 </div> 
-
-
-<p><i>Let's consider a list of equipment where the codes used are: A101="Police", 
-A206="Post Office" and A504="Restaurant". With SKOS, we could define the following structure:</i></p>
-
-
-<pre class="example">
-    &lt;http://example.org/codes/typeEquipment/A101> 
-    rdf:type skos:Concept, ex:TypeEquipmentA ;
-    skos:notation "A101"
-    skos:prefLabel "Police"@en ;
-    skos:inScheme &lt;http://example.org/codes/typeEquipment> .
+</section>
 
-    &lt;http://example.org/codes/typeEquipment/A206> 
-    rdf:type skos:Concept, ex:TypeEquipmentA ;
-    skos:notation "A206"
-    skos:prefLabel "Post office"@en ;
-    skos:inScheme &lt;http://example.org/codes/typeEquipment> .
-
-    &lt;http://example.org/codes/typeEquipment/A504> 
-    rdf:type skos:Concept, ex:TypeEquipmentA ;
-    skos:notation "A504"
-    skos:prefLabel "Restaurant"@en ;
-    skos:inScheme &lt;http://example.org/codes/typeEquipment> .
-
-    &lt;http://example.org/codes/typeEquipment> 
-    rdf:type skos:ConceptScheme ;
-    rdfs:label "Type of Equipments"@en;
-    rdfs:label "Type d'equipements"@fr .
-  </pre>
-</section>
+<!-- NOTE TO EDITORS:  These are notes, not cogent content for a BP doc.  Major editing required!
 
 
 <section id="howto">
 <h2>Best Practice for choosing entity URIs</h2>
-<p class="informative"> <i>This is intended to be a best-practice guide for data publishers who 
-map existing data to RDF. Assuming they have identified their entity types, and what 
-attributes and relationships are in the data for each entity types, the question is what 
-URIs to choose for the entities. The step-by-step guide should be followed for each entity type individually</i>.</p>
+<p class="informative"> <i>This is guidance for data publishers seeking to map existing data to RDF. Assuming they have identified their entity types, and what attributes and relationships are in the data for each entity types, the question is what URIs to choose for the entities. The step-by-step guide should be followed for each entity type individually</i>.</p>
 
  <p class="highlight"><b>Scope note:</b> <br />
  This is only for choosing identifiers for existing data that is to be translated from a different format or 
-storage technology to RDF. This isn't applicable for authoring fresh data.<br />
+storage technology to RDF.<br />
  <b>Assumption:</b> <br />
- The input data may change. Therefore, if there are no reliable identifiers/keys in the input, one may 
+ 
+ 
+The input data may change. Therefore, if there are no reliable identifiers/keys in the input, one may 
 not be able to track identity over updates. For the same reason, creating synthetic keys in the 
 conversion process is not possible &mdash; if they're arbitrary, they won't survive inserts/deletes, 
 and if they're based on the input (e.g., hashing some fields) then they won't survive updates to those fields.</p>
@@ -800,7 +812,7 @@
 <div class="note">
 <ul >
     <li>If the Unique Name Assumption doesn't hold for an ID, then don't rely on it too much. Example: a person may have multiple email addresses.</li>
-    <li>Discuss "authority files", "master data", and how those should be RDFized first. Q: Does your 
+    <li>Discuss "authority files", "master data", and how those should be modeled in RDF. Q: Does your 
 organization or some other reputable body maintain master data or an authority file for the entity type? If 
 so, is it RDFized? If not, can you get that RDFized first? Use their IDs if you can. Otherwise, <b>make 
 your own and do a best-effort mapping.</b></li>
@@ -854,7 +866,7 @@
 </p>
 
 </section>
-
+-->
 
 <!-- << URI CONSTRUCTION   -->
 <section id="HTTPURIS">
@@ -897,6 +909,10 @@
 URIs. This section provides a set of general principles aimed at helping government stakeholders 
 to define and manage URIs for their resources.</p>
 
+<!--
+
+NOTE TO EDITORS: (BOH) suggests this does not belong in a best practices document.
+
 <p class="highlight"><b>Use HTTP URIs</b><br />
 <i>What it means:</i> To benefit from and increase the value of the World Wide Web, governments and 
 agencies SHOULD provide HTTP URIs as identifiers for their resources. There are many 
@@ -937,6 +953,11 @@
 However, Web clients accessing such URIs SHOULD NOT parse or otherwise read into the meaning of URIs.
 </p>
 
+-->
+
+<!--
+
+NOTE TO EDITORS: (BOH) I do not think discussion of the TAG belongs in a BP document.
 
 <p class="note"><b>W3C Technical Architecture Group (TAG)</b><br />
 The World Wide Web Consortium's (W3C's) <a href="http://www.w3.org/2001/tag/">Technical Architecture 
@@ -968,8 +989,9 @@
 
 </section>
 
+-->
 
-<!-- NOTE TO EDITORS: If we provide a list of questions, we must provide answers too! This is incomplete 'as is' (Bernadette) 
+<!-- NOTE TO EDITORS: (Bernadette) If we provide a list of questions, we must provide answers too! This is incomplete 'as is' 
 
 <section>
 <h5>A Checklist for Constructing URIs</h5>
@@ -1132,16 +1154,16 @@
 </section> 
 
 
-
 <!-- SPECIFY LICENSE -->
 <section id="LICENSE">
 <h2>Specifying an Appropriate License</h2>
-<!-- <p class='todo'>To Review: Bernadette Hyland</p> -->
 
 <p>
-It is best practice to explicitly attach a license statement to each dataset. Governments typically 
-define ownership of works produced by government employees or contractors in legislation.  It is 
-beyond the charter of this working group to describe and recommend appropriate licenses for 
+Specify an appropriate open license with the published data.  People will only reuse data when there is a clear, acceptable license associated with it.  Governments typically define ownership of works produced by government employees or contractors in legislation.  
+</p>
+
+<p>
+It is beyond the charter of this working group to describe and recommend appropriate licenses for 
 Open Government content published as Linked Data, however there are useful Web sites that 
 offer detailed guidance and licenses.  One valuable resource is the <a href="http://creativecommons.org/">Creative 
 Commons</a> Web site.  Creative Commons develops, supports, and stewards legal 
@@ -1162,10 +1184,10 @@
 </p>
 </section>
 
-<!--   SECURITY AND HOSTING -->
+<!--   DOMAIN AND HOSTING -->
 <section id="HOST">
 
-<h2>Security and Hosting</h2>
+<h2>Domain and Hosting</h2>
 
 <!-- <p class='todo'>To drop must part of this section, Dave comments</p> -->
 
@@ -1184,9 +1206,6 @@
 
 <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>