--- a/bp/index.html Sun Apr 29 23:08:07 2012 -0400
+++ b/bp/index.html Mon Apr 30 02:12:35 2012 -0400
@@ -13,8 +13,6 @@
</head>
<body>
-<p class="todo">Make sure all contributors are acknowledged.</p>
-
<section id="abstract">
<p>
This document provides best practices for creating, publishing and announcing 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 collects the most relevant data management practices, promoting best practices for publishing Linked Open Data and warning against practices that are considered harmful.
@@ -41,6 +39,7 @@
<li>Related Reading</li>
<li>Acknowledgements</li>
</ol>
+</section>
<!-- INTRODUCTION -->
@@ -70,8 +69,12 @@
</section>
+
<!-- List of Best Practices -->
+<section class="summary">
+<h2>Summary of Best Practices</h2>
+
The following best practices are discussed in this document and listed here for convenience.
<p class='stmt'><a href="#IDENTIFY">IDENTIFY</a> The first step is indentifying data sets that other people may wish to re-use.
@@ -86,6 +89,9 @@
<p class='stmt'><a href="#STANDARD_VOCABULARIES">STANDARD_VOCABULARIES</a> Describe objects with standard vocabularies whenever possible.
</p>
+<p class='stmt'><a href="#CONSISTENT_REPRESENTATION">CONSISTENT_REPRESENTATION</a> Provide representations of a resource consistently and predictably.
+</p>
+
<p class='stmt'><a href="#DESCRIPTIONS">DESCRIPTIONS</a> Publish human and machine readable descriptions with your Linked Data.
</p>
@@ -102,13 +108,14 @@
</p>
+<!-- Diagrams -->
+
<h3> Linked Open Data Lifecycle </h3>
<p class='issue'>Does it make sense to base the GLD life cycle on one of the general LD life cycles? See <a href="https://www.w3.org/2011/gld/track/issues/15">ISSUE-15</a></p>
-</section>
-<section>
-<p class="todo"> Include a brief description for each one of them.
+<p class="todo"> To Review: Bernadette, Michael, Boris - Please add a brief description for your lifecycle diagrams.
</p>
+
<p>Hyland et al.</p>
<div id="centerImg">
</div>
@@ -122,12 +129,13 @@
<!-- PROCUREMENT -->
<section>
-<h3>Procurement</h3>
+<h2>Procurement</h2>
<p>
-This procurement overview and companion glossary is intended to assist contract officers understand the requirements associated with publishing open government content as Linked Data.</p>
+This procurement overview and companion glossary is intended to assist contract officers understand the requirements associated with publishing open government content as Linked Data.
+</p>
-<h4>Overview</h4>
+<h3>Overview</h3>
<p>
The majority of structured data collected and curated by governments worldwide resides in relational data systems. The general activities associated with Linked Open Data development and maintenance include:
@@ -151,7 +159,7 @@
<p>Services: Various private companies and universities offer training related to linked open data. These offerings vary widely. Trainings vary from high-level informational trainings intended to provide managers/decision makers with general understanding, to in-depth, hands-on instruction for the tech savvy on how to prepare, publish and consume linked data.</p>
</ol>
-<h4>Procurement Checklist</h4>
+<h3>Procurement Checklist</h3>
The following is an outline of questions a department/agency should consider reviewing as part of their decision to choose a service provider:
<ul>
@@ -181,41 +189,24 @@
</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>
-
</section>
-<!-- << VOCABULARY SELECTION -->
+<!-- VOCABULARY SELECTION -->
<section>
-<h3>Vocabulary Selection</h3>
-<p class='responsible'>Michael Hausenblas (DERI), Ghislain Atemezing (INSTITUT TELECOM), Boris Villazon-Terrazas (UPM), Daniel Vila-Suero (UPM)</p>
+<h2>Vocabulary Selection</h2>
+
+<p class="todo">Please Review: Michael Hausenblas (DERI), Ghislain Atemezing (INSTITUT TELECOM), Boris Villazon-Terrazas (UPM), Daniel Vila-Suero (UPM)</p>
<p>
Reuse standard, vetted vocabularies to encourage others to use your data. Guidance on finding standard, vetted vocabularies is described in the Vocabulary Discovery Checklist below.
-
-<section> <!-- Discovery checklist -->
+</section>
- <h4>Discovery checklist</h4>
- <p>This checklist provides some considerations when trying to find out existing vocabularies that could best fit the needs of a government authority.
- </p>
+
+<!-- Discovery checklist -->
+<h3>Vocabuarly Discovery Checklist</h3>
+
+<p>This checklist provides some considerations when trying to find out existing vocabularies that could best fit the needs of a government authority.
+</p>
<p class="highlight"><b>Specify the domain</b><br/>
<i>What it means:</i>
@@ -241,22 +232,22 @@
Some existing catalogues are: <a href="http://thedatahub.org/" target="_blank">Data Hub</a> (former CKAN), <a href="http://labs.mondeca.com/dataset/lov/" target="_blank">LOV</a> directory, etc.
</p>
-</section> <!-- Discovery checklist >> -->
-
-<section> <!-- << Vocabulary Selection Criteria checklist -->
-<h4>Vocabulary Selection Criteria checklist</h4>
-<p>This checklist aims at giving some advices to better assess and select the vocabulary that best fits your needs, according to the output of the vocabularies discovered in the Discovery section. The final result should be one or two vocabularies that could be reused for your own purpose (mappings, extension, etc.)
-</p>
+<!-- << Vocabulary Selection Criteria checklist -->
-<p>
-Ensure vocabularies you choose pass the "Vocabulary Selection Criteria Checklist"
+<h3>Vocabulary Selection Criteria</h3>
+
+This checklist aims to help in vocabulary selection, in summary:
<li>Ensure vocabularies you use are published by a trusted group or organization</li>
<li>Ensure vocabularies have permanent URI</li>
<li>Confirm the versioning policy </li>
</p>
-<p class="highlight"><b>Vocabularies should be self-descriptive</b><br/>
+<p class="highlight"><b>Vocabularies MUST be documented</b><br/>
+ <i>What it means:</i> A vocabulary MUST be documented. This includes the liberal use of labels and comments; tags to language used. Human-readable pages must be provided by the publisher describe the classes and properties, preferably with use cases defined.
+</p>
+
+<p class="highlight"><b>Vocabularies SHOULD be self-descriptive</b><br/>
<i>What it means:</i> Each property or term in a vocabulary should have a Label, Definition and Comment defined.
Self-describing data suggests that information about the encodings used for each representation is provided explicitly within the representation. The ability for Linked Data to describe itself, to place itself in context, contributes to the usefulness of the underlying data.<br/><br/>
For example, popular vocabulary called DCMI Metadata Terms has a Term Name <a href="http://dublincore.org/documents/dcmi-terms/#terms-contributor" target="_blank">Contributor</a> which has a:</br>
@@ -265,55 +256,56 @@
Comment: Examples of a Contributor include a person, an organization, or a service.<br/>
</p>
-<p class="highlight"><b>Vocabularies should be described in more than one language</b><br/>
- <i>What it means:</i> EMultilingualism should be supported by the vocabulary, i.e., all the elements of the vocabulary should have labels, definitions and comments available in the government's official language, e.g., Spanish, and at least in English.
+<p class="highlight"><b>Vocabularies SHOULD be described in more than one language</b><br/>
+ <i>What it means:</i> Multilingualism should be supported by the vocabulary, i.e., all the elements of the vocabulary should have labels, definitions and comments available in the government's official language, e.g., Spanish, and at least in English.
That is also very important as the documentation should be clear enough with appropriate tag for the language used for the comments or labels.<br/><br/>
For example, for the same term <a href="http://dublincore.org/documents/dcmi-terms/#terms-contributor" target="_blank">Contributor</a></br>
rdfs:label "Contributor"@en, "Colaborador"@es<br/>
rdfs:comment "Examples of a Contributor include a person, an organization, or a service"@en , "Ejemplos de collaborator incluyen persona, organización o servicio"@es<br/>
</p>
-<p class="highlight"><b>Vocabulary reusability</b><br/>
- <i>What it means:</i> It is always better to check how the vocabulary is used by others initiatives around and its popularity.<br/><br/>
-For example: The recent <a href="http://stats.lod2.eu/vocabularies" target="_blank">statistics</a> of the use of vocabularies in the cloud reveals that <a href="http://xmlns.com/foaf/0.1" target="_blank">foaf</a> is reused by more than 55 other vocabularies.
+<p class="highlight"><b>Vocabularies SHOULD be used by other data sets</b><br/>
+ <i>What it means:</i> If the vocabulary is used by other authoritative Linked Open Data sets that is helpful. It is in re-use of vocabularies that we achieve the benefits of Linked Open Data. For example: An analysis on the <a href="http://stats.lod2.eu/vocabularies" target="_blank">use of vocabularies</a> on the Linke Data cloud reveals that <a href="http://xmlns.com/foaf/0.1" target="_blank">FOAF</a> is reused by more than 55 other vocabularies.
</p>
-<p class="highlight"><b>Vocabularies should be accessible for a long period</b><br/>
- <i>What it means:</i> The vocabulary selected should have a guarantee of maintenance in a long term, or at least the editors should be aware of that issue.
- It also include here checking the permanence of the URIs, and how is the policy of vocabulary versioning. This is strongly related to the best practices described in the Stability section.
+<p class="highlight"><b>Vocabularies SHOULD be accessible for a long period</b><br/>
+ <i>What it means:</i> The vocabulary selected should provide some guarantee of maintenance over a specified period, ideally indefinitely.
</p>
-<p class="highlight"><b>Vocabularies should be published by a trusted group or organization</b><br/>
- <i>What it means:</i> Although anyone can create a vocabulary, it is always better to check if it is one person, group or organization that is responsible for publishing and maintaining the vocabulary.
- It is recommended to better trust a well-known organization than a single person.
+<p class="highlight"><b>Vocabularies SHOULD be published by a trusted group or organization</b><br/>
+ <i>What it means:</i> Although anyone can create a vocabulary, it is always better to check if it is one person, group or authoritative organization that is responsible for publishing and maintaining the vocabulary.
</p>
-<p class="highlight"><b>Vocabularies should have permanent URIs</b><br/>
- <i>What it means:</i> It refers here to not have a 404 http error when trying to access at any *thing* of the vocabulary. It also refers to the permanent access to the server hosting the vocabulary, facilitating reusability and consumption of the data build upon them.<br/><br/>
- Example: The <a href="http://www.w3.org/2003/01/geo/wgs84_pos#/" target="_blank">Geo W3C vocabulary</a> is one of the most used vocabulary for basic representation of geometry points (latitute/longitude) and has been around since 2009, always available at the same namespace. This is strongly related to the best practices described in the Stability section.
+<p class="highlight"><b>Vocabularies SHOULD have persistent URLs</b><br/>
+ <i>What it means:</i> Persistent access to the server hosting the vocabulary, facilitating reusability is necessary.<br/><br/>
+ Example: The <a href="http://www.w3.org/2003/01/geo/wgs84_pos#/" target="_blank">Geo W3C vocabulary</a> is one of the most used vocabulary for basic representation of geometry points (latitute/longitude) and has been around since 2009, always available at the same namespace.
</p>
<p class="highlight"><b>Vocabularies should provide a versioning policy</b><br/>
- <i>What it means:</i> It refers to the mechanism put in place by the publisher to always take care of backward compatibilities of the versions, the ways those changes affected the previous versions.
- Major changes of the vocabularies should be reflected on the documentation, in both machine or human-readable formats. This is strongly related to the best practices described in the Versioning section.
+ <i>What it means:</i> The publisher ideally will address compatibility of versions over time. Major changes to the vocabularies should be reflected on the documentation.
</p>
-<p class="highlight"><b>Vocabularies must be documented</b><br/>
- <i>What it means:</i> A vocabulary must be documented. This includes the liberal use of labels and comments; tags to language used. Human-readable pages must be provided by the publisher describe the classes and properties, preferably with use cases defined.
-</p>
-</section> <!-- Vocabulary Selection Criteria checklist >> -->
-
-<section> <!-- << Vocabulary management/creation -->
-<h4>Vocabulary management/creation</h4>
-<p>As we already mentioned, we have to take into account that there may be cases in which Governments will need to mint their own vocabulary terms. This section provides a set of considerations aimed at helping to government stakeholders to mint their own vocabulary terms. This section includes some items of the previous section because some recommendations for vocabulary selection also apply to vocabulary creation.
-</p>
+<!-- << Vocabulary management/creation -->
-<p>
-Ensure new vocabularies you create pass the "Vocabulary Creation Criteria Checklist"
-<li>Vocabulary is self-descriptive </li>
-<li>Vocabulary is described in more than one language, ideally </li>
-<li>Vocabulary will be accessible for a long period (has longevity) </li>
+<h3>Vocabulary Creation</h3>
+
+<!-- Editorial notes for creators/maintainers:
+
+Creation Namespace management
+stability (PURL)
+longevity (hit by bus)
+Available ontology development methodologies (Informative)
+Usage (instance-level, SPARQL, etc.)
+Versioning
+go back to creation
+Partial or full deprecation
+Cross-cutting issues: "Hit-by-bus" -->
+
+<p>There will be cases in which authorities will need to mint their own vocabulary terms. This section provides a set of considerations aimed at helping to government stakeholders to mint their own vocabulary terms. This section includes some items of the previous section because some recommendations for vocabulary selection also apply to vocabulary creation. Ensure new vocabularies you create are:
+<li>Self-descriptive </li>
+<li>Described in more than one language, ideally </li>
+<li>Accessible for a long period</li>
</p>
<p class="highlight"><b>Define the URI of the vocabulary.</b><br/>
@@ -331,33 +323,31 @@
</p>
<p class="highlight"><b>Vocabularies should be described in more than one language</b><br/>
- <i>What it means:</i> EMultilingualism should be supported by the vocabulary, i.e., all the elements of the vocabulary should have labels, definitions and comments available in the government's official language, e.g., Spanish, and at least in English.
- That is also very important as the documentation should be clear enough with appropriate tag for the language used for the comments or labels.<br/><br/>
+ <i>What it means:</i> Multilingualism should be supported by the vocabulary, i.e., all the elements of the vocabulary should have labels, definitions and comments available in the government's official language, e.g., Spanish, and at least in English. That is also very important as the documentation should be clear enough with appropriate tag for the language used for the comments or labels.<br/><br/>
For example, for the same term <a href="http://dublincore.org/documents/dcmi-terms/#terms-contributor" target="_blank">Contributor</a></br>
rdfs:label "Contributor"@en, "Colaborador"@es<br/>
rdfs:comment "Examples of a Contributor include a person, an organization, or a service"@en , "Ejemplos de collaborator incluyen persona, organización o servicio"@es<br/>
</p>
<p class="highlight"><b>Vocabularies should provide a versioning policy</b><br/>
- <i>What it means:</i> It refers to the mechanism put in place by the publisher to always take care of backward compatibilities of the versions, the ways those changes affected the previous versions.
- Major changes of the vocabularies should be reflected on the documentation, in both machine or human-readable formats. This is strongly related to the best practices described in the Versioning section.
+ <i>What it means:</i> It refers to the mechanism put in place by the publisher to always take care of backward compatibilities of the versions, the ways those changes affected the previous versions. Major changes of the vocabularies should be reflected on the documentation, in both machine or human-readable formats. This is strongly related to the best practices described in the Versioning section.
</p>
<p class="highlight"><b>Vocabularies should provide documentations</b><br/>
- <i>What it means:</i> A vocabulary should be well-documented for machine readable (use of labels and comments; tags to language used).
- Also for human-readable, an extra documentation should be provided by the publisher to better understand the classes and properties, and if possible with some valuable use cases.
+ <i>What it means:</i> A vocabulary should be well-documented for machine readable (use of labels and comments; tags to language used). Also for human-readable, an extra documentation should be provided by the publisher to better understand the classes and properties, and if possible with some valuable use cases.
</p>
<p class="highlight"><b>Vocabulary should be published following available best practices</b><br/>
<i>What it means:</i> One of the goals is to contribute to the community by sharing the new vocabulary. To this end, it is recommended to follow available recipes for publishing RDF vocabularies, e.g., <a href="http://www.w3.org/TR/swbp-vocab-pub/" target="_blank">Best Practice Recipes for Publishing RDF Vocabularies</a>.
</p>
-</section> <!-- Vocabulary management/creation -->
+<!-- Vocabulary Creation -->
-<section> <!-- << Multilingualism in vocabs -->
-<!-- TODO add references to Felix Sasaka's work on multilingual Web and new W3C WG -->
+<!-- TODO -->
- <h4>Multilingualism in vocabs</h4>
+<p class="todo">Add references to Felix Sasaka's work on multilingual Web and new W3C WG
+
+<h3>Multilingual Vocabularies</h3>
<p>
This section provides some considerations when we are dealing with multilingualism in vocabularies. We have identified that multilingualism in vocabularies can be found nowadays in the following formats:
</p>
@@ -369,72 +359,77 @@
</ul>
The current trend is to follow the first approach, i.e., to use rdfs:label and rdfs:comment for each term in the vocabulary.
-</section> <!-- Multilingualism in vocabs >> -->
-
-
-
-<!-- Editorial notes for creators/maintainers:
+<!-- Multilingualism in vocabs >> -->
-Creation Namespace management
-stability (PURL)
-longevity (hit by bus)
-Available ontology development methodologies (Informative)
-Usage (instance-level, SPARQL, etc.)
-Versioning
-go back to creation
-Partial or full deprecation
-Cross-cutting issues: "Hit-by-bus" -->
-
-@@TO DO@@ Add references
-</section>
-<!-- VOCABULARY SELECTION >> -->
+</section> <!-- VOCABULARY SELECTION >> -->
<!-- << URI CONSTRUCTION -->
<section>
-<h3>URI Construction</h3>
-<p class='responsible'>Ghislain Atemezing (INSTITUT TELECOM), Michael Hausenblas (DERI), Boris Villazon-Terrazas (UPM), Daniel Vila (UPM), John Erickson (RPI), Martin Alvarez (CTIC)</p>
+<h2>URI Construction</h2>
+<p class="todo">To Review: Ghislain Atemezing (INSTITUT TELECOM), Boris Villazon-Terrazas (UPM), Daniel Vila (UPM), John Erickson (RPI), Bernadette Hyland (3 Round Stones)</p>
<p>
-This section specifies how to create good URIs for use in government linked data. Inputs include
+Guidance in this document is minting URIs for vocabularies, concepts, and datasets. This section specifies how to create good URIs for use in government linked data. Inputs include
<ul>
<li><a href="http://www.w3.org/TR/cooluris/" title="Cool URIs for the Semantic Web">Cool URIs for the Semantic Web</a></li>
<li><a href="http://www.cabinetoffice.gov.uk/media/308995/public_sector_uri.pdf">Designing URI Sets for the UK Public Sector</a> (PDF)</li>
<li><a href="http://data.gov.uk/resources/uris" title="Creating URIs | data.gov.uk">Creating URIs</a> (data.gov.uk).</li>
</ul>
-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>The purpose of URIs is to uniquely and reliably name resources on the Web. According to <a href="http://www.w3.org/TR/cooluris/" target="_blank">Cool URIs for the Semantic Web</a> (W3C IG Note), URIs should be designed with simplicity, stability and manageability in mind, thinking about them as identifiers rather than as names for Web resources.
</p>
-<section>
-<h4>Design principles</h4>
+<p>
+Many general-purpose guidelines exist for the URI designer to consider, including <a href="http://www.w3.org/TR/cooluris/" target="_blank">Cool URIs for the Semantic Web</a>, which provides guidance on how to use URIs to describe things that are not Web documents; <a href="http://www.cabinetoffice.gov.uk/resource-library/designing-uri-sets-uk-public-sector" target="_blank">Designing URI Sets for the UK Public Sector</a>, a document from the UK Cabinet offices that defines the design considerations on how to URIs can be used to publish public sector reference data; and (3) <a href="http://bit.ly/xJwA9g" target="_blank">Style Guidelines for Naming and Labelling Ontologies in the Multilingual Web</a> (PDF), which proposes guidelines for designing URIs in a multilingual scenario.
+</p>
+
+<h3>URI Design Principles</h3>
<p>The Web makes use of the URI (Uniform Resource Identifiers) as a single global identification system. The global scope of URIs promotes large-scale "network effects", in order to benefit from the value of Linked Data government and governmental agencies need to identify their resources using URIs. This section provides a set of general principles aimed at helping to government stakeholders to define and manage URIs for their resources.</p>
+
<p class="highlight"><b>Use HTTP URIs</b><br>
What it means: 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 benefits to participating in the existing network of URIs, including linking, caching, and indexing by search engines. As stated in [LDPrinciples], HTTP URIs enable people to "look-up" or "dereference" a URI in order to access a representation of the resource identified by that URI.
To benefit from and increase the value of the World Wide Web, data publishers SHOULD provide URIs as identifiers for their resources.
</p>
+
<p class="highlight"><b>Provide at least one machine-readable representation of the resource identified by the URI</b><br>
What it means: In order to enable HTTP URIs to be "dereferenced", data publishers have to set up the neccesary infraestructure elements (e.g. TCP-based HTTP servers) to serve representations of the resources they want to make available (e.g. a human-readable HTML representation or a machine-readable RDF/XML). A publisher may supply zero or more representations of the resource identified by that URI. However, there is a clear benefit to data users in providing at least one machine-readable representation. More information about serving different representations of a resource can be found in <a href="http://www.w3.org/TR/cooluris/" target="_blank">Cool URIs for the Semantic Web</a>.
</p>
+
<p class="highlight"><b>A URI structure will not contain anything that could change</b><br>
What it means: It is good practice that URIs do not contain anything that could easily change or that is expected to change like session tokens or other state information. URIs should be stable and reliable in order to maximize the possibilities of reuse that Linked Data brings to users. There must be a balance between making URIs readable and keeping them more stable by removing descriptive information that will likely change. For more information on this see [MDinURI] and <a href="http://www.w3.org/TR/cooluris/" target="_blank">Architecture of the World Wide Web: URI Opacity</a>.
</p>
+
+<p class="highlight"><b>URI Opacity</b><br>
+The Architecture of the World Wide Web [Jacobs], provides best practice for the treatment of URIs at the time they are resolved by a Web client:
+
+<i>Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource.</i>
+
+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:
+
+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:
+
+<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>
+</ul>
+
+<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, c.f. [Wood2007]). 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.
+</p>
+
</section>
-<section>
-<h4>Best Practices Checklist</h4>
-<section>
-<h5>High-level Considerations for Constructing URIs</h5>
-<p>The purpose of URIs is to uniquely and reliably name resources on the Web. According to <a href="http://www.w3.org/TR/cooluris/" target="_blank">Cool URIs for the Semantic Web</a> (W3C IG Note), URIs should be designed with simplicity, stability and manageability in mind, thinking about them as identifiers rather than as names for Web resources.
-</p>
-<p>
-Many general-purpose guidelines exist for the URI designer to consider, including <a href="http://www.w3.org/TR/cooluris/" target="_blank">Cool URIs for the Semantic Web</a>, which provides guidance on how to use URIs to describe things that are not Web documents; <a href="http://www.cabinetoffice.gov.uk/resource-library/designing-uri-sets-uk-public-sector" target="_blank">Designing URI Sets for the UK Public Sector</a>, a document from the UK Cabinet offices that defines the design considerations on how to URIs can be used to publish public sector reference data; and (3) <a href="http://bit.ly/xJwA9g" target="_blank">Style Guidelines for Naming and Labelling Ontologies in the Multilingual Web</a> (PDF), which proposes guidelines for designing URIs in a multilingual scenario.
-</p>
-<p>The purpose of this subsection is to provide specific, practical guidance to government stakeholders who are planning to create systems for publishing government Linked Data and therefore must create sensible, sustainable URI designs that fit their specific requirements.
-</p>
-</section>
-
+<!-- NOTE TO EDITORS: If we provide a list of questions, we must provide answers too! This is incomplete 'as is' (Bernadette)
+
<section>
-<h5>A Checklist for Constructing Government URIs</h5>
+<h5>A Checklist for Constructing URIs</h5>
<p>The following checklist is based in part on <a href="http://data.gov.uk/resources/uris" target="_blank">Creating URIs</a> (short; on the Web) and <a href="http://www.cabinetoffice.gov.uk/sites/default/files/resources/designing-URI-sets-uk-public-sector.pdf" target="_blank">Designing URI Sets for the UK Public Sector</a> (long; in PDF).
</p>
<ol type="1">
@@ -487,47 +482,60 @@
<li>Will informal or equivalent sector names also be used?</li>
</ul>
</li>
- <li>Is sensible resolution of partial/incomplete URIs necessary or anticipated?</li>
</ol>
</section>
</section>
+-->
+
<section>
-<h4>URI Persistence</h4>
-<p class='responsible'>Bernadette Hyland (3 Round Stones), John Erickson (RPI)</p>
+<h3>URI Policy for Persistence</h3>
+<p class="todo">To Review: Bernadette Hyland, John Erickson</p>
-<p><i>Advice, info related to persistent URIs</i></p>
-<p>As is the case with many human interactions, confidence in interactions via the Web depends on stability and predictability. For an information resource, persistence depends on the consistency of representations. The representation provider decides when representations are sufficiently consistent (although that determination generally takes user expectations into account).</p>
+<!-- Acknowledge D. Wood, "Reliable and Persistent Identification of Linked Data Elements" LED chapter, 2010 -->
+
+<p>Persistent identifiers are used by organizations interested in retaining addresses to information resources over the long term. Today, persistent identifiers are used to uniquely identify objects in the real world and concepts, in addition to information resources. For example, persistent identifiers have been created by the United Nations Food and Agriculture Organization (FAO) to provide URIs for major food crops. The National Center for Biomedical Ontology provides persistent identifiers to unify and address the terminology used in many existing biomedical databases.
+</p>
+
<p>
-Although persistence in this case is observable as a result of representation retrieval, the term URI persistence is used to describe the desirable property that, once associated with a resource, a URI should continue indefinitely to refer to that resource.
+A Persistent URL is an address on the World Wide Web that causes a redirection to another Web resource. If a Web resource changes location (and hence URL), a PURL pointing to it can be updated. A user of a PURL always uses the same Web address, even though the resource in question may have moved. PURLs may be used by publishers to manage their own information space or by Web users to manage theirs; a PURL service is independent of the publisher of information. PURL services thus allow the management of hyperlink integrity. Hyperlink integrity is a design trade-off of the World Wide Web, but may be partially restored by allowing resource users or third parties to influence where and how a URL resolves. A simple PURL works by responding to an HTTP GET request with a response
+of type 302 (“Found”). The response contains an HTTP “Location” header, the value of which is a URL that the client should subsequently retrieve via a new HTTP GET request.
</p>
-<p class="highlight"><b>Consistent representation</b><br>
-A URI owner SHOULD provide representations of the identified resource consistently and predictably.
+
+<p>
+PURLs implement one form of persistent identifier for virtual resources. Other persistent identifier schemes include Digital Object Identifiers (DOIs), Life Sciences Identifiers (LSIDs) and INFO URIs. All persistent identification
+schemes provide unique identifiers for (possibly changing) virtual resources, but not all schemes provide curation opportunities. Curation of virtual resources has been defined as, “the active involvement of information professionals in the management, including the preservation, of digital data for future use.” [Yakel, E (2007)] For a persistent identification scheme to provide a curation opportunity for a virtual resource, it must allow real-time resolution of that resource and also allow real-time administration of the identifier.
</p>
-<p>URI persistence is a matter of policy and commitment on the part of the URI owner. The choice of a particular URI scheme provides no guarantee that those URIs will be persistent or that they will not be persistent.
+
+<p>URI persistence is a matter of policy and commitment on the part of the URI owner. The choice of a particular URI scheme provides no guarantee that those URIs will be persistent or that they will not be persistent. HTTP [RFC2616] has been designed to help manage URI persistence. For example, HTTP redirection (using the 3xx response codes) permits servers to tell an agent that further action needs to be taken by the agent in order to fulfill the request (for example, a new URI is associated with the resource).
</p>
-<p>HTTP [RFC2616] has been designed to help manage URI persistence. For example, HTTP redirection (using the 3xx response codes) permits servers to tell an agent that further action needs to be taken by the agent in order to fulfill the request (for example, a new URI is associated with the resource).
-</p>
+
<p>In addition, content negotiation also promotes consistency, as a site manager is not required to define new URIs when adding support for a new format specification. Protocols that do not support content negotiation (such as FTP) require a new identifier when a new data format is introduced. Improper use of content negotiation can lead to inconsistent representations.
</p>
+
</section>
<section>
-<h4>Internationalized Resource Identifiers: Using non-ASCII characters in URIs<h4>
-</section>
-<p><i>Guidelines for those interested in minting URIs in their own languages (German, Dutch, Spanish, Chinese, etc.)</i></p>
+<h3>Internationalized Resource Identifiers</h3>
+
+<p><i>This section on Internationalized Resource Identifiers focuses on using non-ASCII characters in URIs and provides guidelines for those interested in minting URIs in their own languages (German, Dutch, Spanish, Chinese, etc.)</i></p>
+
<p>The URI syntax defined in <a href="http://tools.ietf.org/html/rfc3986" target="_blank">RFC 3986</a> STD 66 (Uniform Resource Identifier (URI): Generic Syntax) restricts URIs to a small number of characters: basically, just upper and lower case letters of the English alphabet, European numerals and a small number of symbols. There is now a growing need to enable use of characters from any language in URIs.
</p>
+
<p>The purpose of this section is to provide guidance to government stakeholders who are planning to create URIs using characters that go beyond the subset defined in <a href="http://tools.ietf.org/html/rfc3986" target="_blank">RFC 3986</a>.
</p>
-<p>First we provide two important definitions:</p>
+
<p>
IRI (<a href="http://tools.ietf.org/html/rfc3987" target="_blank">RFC 3987</a>) is a new protocol element, that represents a complement to the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646) that can be therefore be used to mint identifiers that use a wider set of characters than the one defined in <a href="http://tools.ietf.org/html/rfc3986" target="_blank">RFC 3986</a>.
</p>
+
<p>The Internationalized Domain Name or IDN is a standard approach to dealing with multilingual domain names was agreed by the IETF in March 2003.
</p>
+
<p>Althought there exist some standards focused on enabling the use of international characters in Web identifiers, government stakeholders need to take into account several issues before constructing such internationalized identifiers. This section is not meant to be exhaustive and we point the interested audience to <a ref="http://www.w3.org/International/articles/idn-and-iri/" target="_blank">An Introduction to Multilingual Web Addresses</a>, however some of the most relevant issues are following:
</p>
+
<ul>
<li><b>Domain Name lookup:</b> Numerous domain name authorities already offer registration of internationalized domain names. These include providers for top level country domains as .cn, .jp, .kr, etc., and global top level domains such as .info, .org and .museum.
</li>
@@ -535,308 +543,59 @@
</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 of Semantic Web Applications" by Auer et al.
</li>
-
</ul>
-@@ TODO: include references
-<!-- <p class="todo">Integrate Wiki <a href="http://www.w3.org/2011/gld/wiki/223_Best_Practices_URI_Construction">content</a>.</p> -->
+
</section> <!-- URI CONSTRUCTION >> -->
-<!-- VERSIONING -->
+<!-- SPECIFY LICENSE -->
<section>
-<h3>Versioning</h3>
-<p class='responsible'>John Erickson (RPI), Ghislain Atemezing (INSTITUT TELECOM), Hadley Beeman (LinkedGov)</p>
-<p>
-This section specifies how to publish data which has multiple versions, including variations such as:
-<ul>
- <li>data covering different time periods</li>
- <li>corrected data about the same time period</li>
- <li>the same data published using different vocabularies, formats, and presentation styles</li>
- <li>retracting published data</li>
-</ul>
-</p>
-<p>The group will specify how to publish data which has multiple versions, including variations such as:</p>
-<ul>
- <li>data covering different time periods</li>
- <li>corrected data about the same time period</li>
- <li>the same data published using different vocabularies, formats, and presentation styles</li>
- <li>retracting published data</li>
-</ul>
+<h2>Specifying an Appropriate License</h2>
+<p class='todo'>To Review: Bernadette Hyland</p>
-<b>By John Erickson(RPI)*</b>
<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:
+It is best practice to explicitly attach a license statement to each data set. 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 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> website. Creative Commons develops, supports, and stewards legal and technical infrastructure for digital content publishing.
</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 TWC 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>
-
-<!-- <p class="todo">Integrate Wiki <a href="http://www.w3.org/2011/gld/wiki/Best_Practices_Discussion_Summary#Versioning">content</a>.</p>
--->
+<p>
+As an informative note, the UK and many former Commonwealth countries maintain the concept of the Crown Copyright. It is important to know who owns your data and to say so. The US Government designates information produced by civil servants as a U.S. Government Work, whereas contractors may produce works under a variety of licenses and copyright assignments. U.S. Government Works are not subject to copyright restrictions in the United States. It is critical for US government officials to know their rights and responsibilities under the Federal Acquisition Regulations (especially FAR Subpart 27.4, the Contract Clauses in 52.227-14, -17 and -20 and any agency-specific FAR Supplements) and copyright assignments if data is produced by a government contractor. It is recommended that governmental authorities publishing Linked Data review the relevant guidance for data published on the Web.
+</p>
</section>
-
-<!-- << STABILITY -->
+<!-- SECURITY AND HOSTING -->
<section>
-<h3>Stability</h3>
-<p class='responsible'>Anne Washington (GMU), Ron Reck</p>
-
-<section> <!-- << STABILITY.overview -->
-<h4>Overview</h4>
-<p>This section will focus how to publish data so that others can rely on it being available in perpetuity, persistently archived if necessary.</p>
+<h2>Security and Hosting</h2>
-<h5>Definition</h5>
-<p><i>The scope, limits and explanation of stability.</i></p>
-<p>The following definition describes stability of LOD.</p>
-<p>
-<b>Stability.</b> <u>Stable</u> LOD is persistent, predictable and machine accessible from externally visible locations.
-</p>
+<p class='todo'>To Review: Michael Pendleton (US EPA)</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>Notify your security official of your intent to publish open government data.</p>
<ul>
- <li>Persistent = Information accessible for an unbounded period of time.</li>
- <li>Predictable = Names and information follow a logical format.</li>
- <li>Stable location = Externally visible locations are consistent in name, and availability.</li>
- <li>Other things that impact stability
- <ul>
- <li>legacy = earlier naming schemes, formats, data storage devices</li>
- <li>steward = people who are committed to consistently maintain specific datasets, either individuals or roles in organizations</li>
- <li>provenance = the sources that establish a context for the production and/or use of an artifact. See <a href="http://www.w3.org/2011/prov/wiki/Main_Page" target="_blank">W3C Provenance working group</a></li>
- </ul>
- </li>
+ <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), implementation timelines</li>
+ <li>Consider including your hosting service/software vendor in discussion(s)</li>
</ul>
-<h5>Goals</h5>
-<p><i>The purpose of having a best practice for stability</i></p>
-<p>The length of time information is available is inherently connected to the value placed upon it.
-If information is deemed valuable, it is likely to persist for a longer period of time.
-Value, which can change over time, is always determined based on a cost-benefit relationship;
-Any benefit derived from information is reduced by the cost(s) associated with using it.
-Increasing stability requires the adoption of a strategy to allocate limited resources for achieving a goal.
-Goals drive data providers' criteria to make a selection of what is best preserved.</b>
-<p>We believe that <b>preservation of content</b> is the main goal for stability, possible goals include:</p>
-<ol type="1">
- <li><b>Preservation of content.</b> It might be important to have raw data available for analysis ad infinitum. This means the overall objective is to preserve only the scientific content.</li>
- <li><b>Preservation of access.</b> It might be important to have information available immediately at all times.</li>
- <li><b>Conservation.</b> From a historical perspective one could seek to preserve all information in the format and modality in which it was originally conveyed. The most demanding is conservation of the full look and feel of the publication.</li>
-</ol>
-
-<h5>Success Factors</h5>
-<p>ORGANIZATIONAL CONSIDERATIONS Without internal stability from the data stewards, any external technology stability is a challenge. These following are some organization characteristics for stable data.</p>
+<p>Solicit assistance from the security official:</p>
<ul>
- <li>Consistent human skills</li>
- <li>Consistent infrastructure</li>
- <li>Data related to organizational values or business needs</li>
- <li>Internal champion or consistent business process</li>
- <li>Internal politics on variation names do not impact external locations</li>
-</ul>
-<p>Mark metadata based on its intended audience</p>
-<ul>
- <li>Internal-audience : management of the process</li>
- <li>External-audience : final state, or no-update needed.</li>
+ <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>
-</section> <!-- STABILITY.overview >> -->
-
-<section> <!-- << STABILITY.examples -->
-<h4>Examples</h4>
-<p><i>These are a few representative samples to generate discussion and comment. Additional suggestions are encouraged.</i></p>
-<p>These examples were discussed on the <a href="http://lists.w3.org/Archives/Public/public-gld-wg/" target="_blank">public-gld email listserv</a></p>
-
-<p><b>Technical examples</b> What existing examples can we point to? (Need international ones...)</p>
-<ol type="1">
- <li>Internet Archive - <a href="http:www.archive.org">http:www.archive.org</a></li>
-</ol>
-<p><b>Institutional examples</b> Who has the incentive to provide stable persistent data? Some real possibilities and some metaphors for discussion.</p>
-<ol type="1">
- <li>Archives
- <ol type="i">
- <li>Third party entities that document provenance and provide access</li>
- </ol>
- </li>
- <li>Estate Lawyer
- <ol type="i">
- <li>Someone responsible for tracking down heirs for an inheritance</li>
- </ol>
- </li>
- <li>Private Foundation
- <ol type="i">
- <li>A philanthropic entity who is interested in the value proposition of stability and acts as archive</li>
- </ol>
- </li>
- <li>Government
- <ol type="i">
- <li>A government organization which has the funds to steward others' data</li>
- </ol>
- </li>
- <li>Internet organization
- <ol type="i">
- <li>A global open organization like W3C or IKAN</li>
- </ol>
- </li>
-</ol>
-</section> <!-- STABILITY.examples >> -->
-
-<section> <!-- << STABILITY.Properties -->
-<h4>Properties</h4>
-<p><i>These are characteristics that influence the stability or longevity. Many of these properties are not unique to LOD, yet they influence data cost and therefore data value.</i></p>
-<ul>
- <li><b><u>Integrity.</u></b>Provide checksums of downloads so that consumers can be assured that they have received the entire dataset. Data that is unreliable should not used for critical decisions and is therefore of less value than data that is deemed complete. Possible checksum types include MD5 and SHA.</li>
- <li><b><u>Consistency.</u></b>Any design of a data format should recognize that change is necessary and will happen. Recognition that change is enviable while providing a mechanism for embracing modification increases continuity and longevity.
- The following types of changes can be anticipated. Therefore, data design should be made to accommodate them:
- <ol type="1">
- <li>The person who published the data changes jobs - For <u>Contact Consistency</u> - Any support contact information should be published using a data steward so that the inherent transition of responsibility does not introduce inconsistency to consumers.</li>
- <li>Departments, Agencies and Governments are reorganized - For <u>File Naming and Data Consistency</u> - Discourage the use of the originating source as component in the name of the data file, or the URIs it contains.The information can appropriately be contained within the file as metadata.</li>
- <li>IT infrastructure overhaul - <u>For File Naming Consistency</u> - Discourage the use of the server or system as component in the name of the data file.</li>
- <li>Merger/acquisition - For <u>Data Consistency</u> - Discourage the use of branding as it inherently and needlessly increases cost for new owners while providing no value at all to consumers.</li>
- <li>Primary stakeholder loses interest in the data - As above For <u>Data Consistency</u> - Discourage the use of branding as it inherently increase cost for new owners.</li>
- </ol>
- </li>
-<li><b><u>Data Repository Consistency.</u></b>As new data is produced, old data becomes legacy data. Consumers of data will write programs to automate processing of legacy data and the number of changes in format directly effects the cost incurred by data consumers. Data providers should carefully consider whether the benefit of the change exceeds the incurred cost of modifying ingestion procedures. Even changing formats between different serializations has a cost to consumers as they need to anticipate and provide for the change. Data providers should consider lifecycle workflow and when at all possible they should modify legacy data themselves so that all provided data is consistent and each consumer will not be required to perform exactly the same data conversion task to create a homogeneous data repository.</li>
+<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>
-<li><b><u>Manageability.</u></b>
- <ul>
- <li><b><u>Discrete</u></b> It is best to have a greater number of small files rather than fewer larger files. Smaller files reduce the cost on consumers. Files should be comprised of meaningful discrete units based on a time period, locality or other logical unit.</li>
- <li><b><u>File names</u></b> Files should be meaningfully named without using non-printable characters.</li>
- <li><b><u>Archive structure</u></b> Data archives should be nested in least a single directory. The directory name should be unique to accommodate multiple archives to be uncompressed without introducing collisions.</li>
- </ul>
-</li>
-<li><b><u>Organization.</u></b>The minimum metadata accompanying each data offering should include:
- <ol type="1">
- <li>Serialization type (such as NTriples or RDF/XML)</li>
- <li>Publisher</li>
- <li>Creation Date</li>
- <li>Modification Date</li>
- <li>Version</li>
- <li>Email address for data steward</li>
- </ol>
-</li>
-<li><b><u>Complexity.</u></b>All serializations are equal to a back-end system, therefore providers should serialize RDF in either
- <ul>
- <li>turtle - The turtle serialization minimizes the disk space expenditure while also increasing human readability.</li>
- <li>NTriples - The NTriples serialization increases integrity in that re-ordering will have no effect on semantics, and damaged lines only effect the assertion on those lines. NTriples also increases flexibility because files can be split into smaller files as long as the division happen at the end of the line.</li>
- </ul>
-</li>
-<li><b><u>Diskspace Resource.</u></b>Different serializations represent the same semantics but require varying amounts of characters (diskspace). While Turtle provides the most concise serialization and is arguably the easiest for humans to read. Turtle does not provide the integrity that NTriples does because NTriples can be reordered or split up based on size or line count without effecting the integrity of the dataset. In general NTriples will provide the greatest overall stability for LOD. Compression of data should be done using either GZIP or ZIP, do not choose to adopt other compression approaches just because they are "free". The maximum data compression should be chosen.</li>
-</ul>
-</section> <!-- STABILITY.Properties >> -->
-
-<section> <!-- << STABILITY.Interconnections -->
-<h4>Interconnections</h4>
-<p><i>Ways that this best practice is connected to others.</i></p>
-<p><b>STABIILTY, URL, and URIs.</b> The identifiers used in LOD are a possible point of failure, therefore use URIs that dereference under DNS that you control or that have greatest likeliness to persist. Use URI's according to the best practices stated <b>elsewhere in this document</b> increases value. Other strategies for maximizing the longevity of URI's include:</p>
-<ol type="1">
- <li>PURLs (Persistent Uniform Resource Locators) <a href="http://purl.oclc.org/docs/index.html" target="_blank">purl.oclc.org</a></li>
- <li>Handle System <a href="http://www.handle.net/" target="_blank">http://www.handle.net/</a> and its commercial cousin <a href="http://www.doi.org/" target="_blank">Digital Object Identifier</a></li>
-</ol>
-<p><b>Vocabulary Choices Effect Value</b> When LOD uses or references vocabularies or vocabulary items it is a point of frailty, which therefore can effect cost. Vocabulary use according to the best practices stated <b>elsewhere in this document</b> increases value.</p>
-</section> <!-- STABILITY.Interconnections >> -->
-
-<!-- <p class="todo">Integrate Wiki <a href="http://www.w3.org/2011/gld/wiki/225_Best_Practices_for_Stability">content</a>.</p> -->
-@@ TODO: Include references
-
-</section> <!-- STABILITY >> -->
-
-
-<!-- SOURCE DATA -->
-<section>
-<h3>Source Data - Michael</h3>
-<p class='responsible'>Michael Hausenblas (DERI), Spyros Kotoulas(IBM/SCTC), Biplav Srivastava (IBM)</p>
-<p>
-This section contains advices concerning how to expose source data, data which is being maintained in pre-existing (non-linked-data) systems such as RDBs or spreadsheets.
-</p>
-
-<p class="todo">Integrate Wiki <a href="http://www.w3.org/2011/gld/wiki/Best_Practices_Discussion_Summary#Source_Data">content</a> as well as Spyros' <a href="http://www.w3.org/2011/gld/wiki/images/0/08/LegacyData.pdf">slides</a> from the F2F2</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>
-<!-- COOKBOOK -->
+<!-- SOCIAL_CONTRACT -->
<section>
-<h3>Linked Open Data Cookbook</h3>
-<p class='responsible'>Bernadette Hyland (3 Round Stones)</p>
-<p>
-See <a href="http://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook">Cookbook for Open Government Linked Data</a>.
-</p>
-</section>
-
-<!-- Pragmatic Provenance -->
-<!-- Note to Editors: This section is not part of our charter and probably will be folded into another section. Yet to be determined. -->
-
-<section><!-- << Pragmatic Provenance -->
-<h3>Pragmatic Provenance - Boris</h3>
-<p class='responsible'>John Erickson (RPI)</p>
-
-<p>Provide best practice recommendations for stakeholders on documenting the provenance of their linked government data and how to interpret that data so that consumers know what they are looking at.</p>
-
-<section><h4>Background</h4>
-<p>In 1997 Tim Berners-Lee called for pervasive provenance on the Web:</p>
-<p class="highlight">
-<i>At the toolbar (menu, whatever) associated with a document there is a button marked "Oh, yeah?". You press it when you lose that feeling of trust. It says to the Web, 'so how do I know I can trust this information?'. The software then goes directly or indirectly back to metainformation about the document, which suggests a number of reasons.</i>
-</p>
-<p>W3C GLD therefore seeks to recommend practices that enable government providers to create the metadata necessary to answer their users' "oh yeah?" questions about the linked data they publish. Our recommendations may include processes as well as the application of specific vocabularies/ontologies.
-</p>
-
-<section><h3>What do we mean by "Provenance?"</h3>
-<p>The W3C's Provenance Incubator Group (2010) <a href="http://www.w3.org/2005/Incubator/prov/XGR-prov-20101214/#What_is_provenance" target="_blank">provides</a> this simple definition of provenance:</p>
-<p class="highlight">Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance.</p>
-<p>More recently the W3C Provenance WG (PROV-WG) defines "provenance" for their work:</p>
-<p class="highlight"><i>The <b>provenance</b> of digital objects represents their origins. The PROV Data Model (<a href="http://www.w3.org/TR/2012/WD-prov-primer-20120110/#bib-PROV-DM" target="_blank">PROV-DM</a>) is a proposed standard to represent provenance records, which contain assertions about the entities and activities involved in producing and delivering or otherwise influencing a given object. By knowing the provenance of an object, we can make determinations about how to use it. Provenance records can be used for many purposes, such as understanding how data was collected so it can be meaningfully used, determining ownership and rights over an object, making judgments about information to determine whether to trust it, verifying that the process and steps used to obtain a result complies with given requirements, and reproducing how something it was generated...As a standard for provenance, PROV-DM accommodates all those different uses of provenance. Different people may have different perspectives on provenance, and as a result different types of information might be captured in provenance records.</i></p>
-</section>
-
+<h2>Publishers' "Social Contract"</h2>
-<section><h3>What do we mean by "Pragmatic Provenance?"</h3>
-<p>The W3C Government Linked Data WG accepts PROV WG's definition of provenance but recognizes that PROV-DM is a powerful tool. W3C GLD WG seeks to provide best practice recommendations that will be useful to government data stakeholders, that make sense for GLD use cases and are easily adopted by practitioners.</p>
-<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>
-</section>
-
-<section><h3>Use cases for provenance in GLD</h3>
-<p>Provide use cases here...</p>
-<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>
-
-</section>
-
-
-</section> <!-- Pragmatic Provenance >> -->
-
-
-<!-- Epilogue: The Social Contract of a Linked Open Data Publisher -->
-<!-- Note to Editors: This section is not part of our charter and probably will be folded into another section. Yet to be determined. -->
-
-<section>
-<h3>TBD - The Social Contract - Bernadette</h3>
-<p class='responsible'>Bernadette Hyland (3 Round Stones)</p>
-<p class="todo">Integrate from Linked Data Cookbook <a href="http://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook#Your_Social_Responsibility_as_a_Data_Publisher">content</a>.
-</section>
-
-<p>
-The following is informative in relation to publishing open government data as LOD.
-</p>
+<p class='todo'>To Review: Bernadette Hyland </p>
<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 implicite "social contract". Additional informational details are included for reference.
@@ -856,22 +615,222 @@
Giving due consideration your organization's URI strategy should be one of the first activities your team undertakes as they prepare a Linked Open Data strategy. Authoritative data requires the permanence and resolution of HTTP URIs. If publishers move or remove data that was published to the Web, third party applications or mashups may break. This is considered rude for obvious reasons and is the basis for the Linked Data "social contract." A good way to prevent causing HTTP 404's is for your organization to implement a persistence strategy.
</p>
-<p>
-It is best practice to explicitly attach a license statement to each data set. 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 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> website. Creative Commons develops, supports, and stewards legal and technical infrastructure for digital content publishing.
+</section>
+
+
+<!-- Pragmatic Provenance -->
+<!-- Note to Editors: This section is NOT part of our charter and should be folded into other section(s). -->
+
+<section>
+<h2>Pragmatic Provenance</h2>
+<p class='todo'>John Erickson (RPI)</p>
+
+<p>Provide best practice recommendations for stakeholders on documenting the provenance of their linked government data and how to interpret that data so that consumers know what they are looking at.</p>
+
+<h3>Background</h3>
+<p>In 1997 Tim Berners-Lee called for pervasive provenance on the Web:</p>
+<p class="highlight">
+<i>At the toolbar (menu, whatever) associated with a document there is a button marked "Oh, yeah?". You press it when you lose that feeling of trust. It says to the Web, 'so how do I know I can trust this information?'. The software then goes directly or indirectly back to metainformation about the document, which suggests a number of reasons.</i>
+</p>
+<p>W3C GLD therefore seeks to recommend practices that enable government providers to create the metadata necessary to answer their users' "oh yeah?" questions about the linked data they publish. Our recommendations may include processes as well as the application of specific vocabularies/ontologies.
</p>
+<h3>What do we mean by "Provenance?"</h3>
+<p>The W3C's Provenance Incubator Group (2010) <a href="http://www.w3.org/2005/Incubator/prov/XGR-prov-20101214/#What_is_provenance" target="_blank">provides</a> this simple definition of provenance:</p>
+<p class="highlight">Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance.</p>
+
+<p>More recently the W3C Provenance WG (PROV-WG) defines "provenance" for their work:</p>
+<p class="highlight"><i>The <b>provenance</b> of digital objects represents their origins. The PROV Data Model (<a href="http://www.w3.org/TR/2012/WD-prov-primer-20120110/#bib-PROV-DM" target="_blank">PROV-DM</a>) is a proposed standard to represent provenance records, which contain assertions about the entities and activities involved in producing and delivering or otherwise influencing a given object. By knowing the provenance of an object, we can make determinations about how to use it. Provenance records can be used for many purposes, such as understanding how data was collected so it can be meaningfully used, determining ownership and rights over an object, making judgments about information to determine whether to trust it, verifying that the process and steps used to obtain a result complies with given requirements, and reproducing how something it was generated...As a standard for provenance, PROV-DM accommodates all those different uses of provenance. Different people may have different perspectives on provenance, and as a result different types of information might be captured in provenance records.</i></p>
+
+
+<h3>What do we mean by "Pragmatic Provenance"</h3>
+<p>The W3C Government Linked Data WG accepts PROV WG's definition of provenance but recognizes that PROV-DM is a powerful tool. W3C GLD WG seeks to provide best practice recommendations that will be useful to government data stakeholders, that make sense for GLD use cases and are easily adopted by practitioners.</p>
+<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>
+
+</section> <!-- Pragmatic Provenance >> -->
+
+
+<!-- VERSIONING -->
+<section>
+<h2>Versioning</h2>
+<p class="todo">To Review: John Erickson (RPI), Ghislain Atemezing (INSTITUT TELECOM), Hadley Beeman (LinkedGov)</p>
+
<p>
-As an informative note, the UK and many former Commonwealth countries maintain the concept of the Crown Copyright. It is important to know who owns your data and to say so. The US Government designates information produced by civil servants as a U.S. Government Work, whereas contractors may produce works under a variety of licenses and copyright assignments. U.S. Government Works are not subject to copyright restrictions in the United States. It is critical for US government officials to know their rights and responsibilities under the Federal Acquisition Regulations (especially FAR Subpart 27.4, the Contract Clauses in 52.227-14, -17 and -20 and any agency-specific FAR Supplements) and copyright assignments if data is produced by a government contractor. It is recommended that governmental authorities publishing Linked Data review the relevant guidance for data published on the Web.
+This section specifies how to publish data which has multiple versions, including variations such as:
+<ul>
+ <li>data covering different time periods</li>
+ <li>corrected data about the same time period</li>
+ <li>the same data published using different vocabularies, formats, and presentation styles</li>
+ <li>retracting published data</li>
+</ul>
+</p>
+<p>The group will specify how to publish data which has multiple versions, including variations such as:</p>
+<ul>
+ <li>data covering different time periods</li>
+ <li>corrected data about the same time period</li>
+ <li>the same data published using different vocabularies, formats, and presentation styles</li>
+ <li>retracting published data</li>
+</ul>
+
+<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 TWC 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 -->
+<section>
+<h2>Stability</h2>
+<p class="todo">To Review: Anne Washington (GMU), Ron Reck</p>
+
+<!-- << STABILITY.overview -->
+<h3>Overview</h3>
+<p>This section will focus how to publish data so that others can rely on it being available in perpetuity, persistently archived if necessary.</p>
+
+<h3>Definition</h3>
+<p>The following definition is applicable to Linked Open Data.</p>
+<b>Stability.</b> <u>Stable</u> LOD is persistent, predictable and machine accessible from externally visible locations.
+</p>
+<ul>
+ <li>Persistent = Information accessible for an unbounded period of time.</li>
+ <li>Predictable = Names and information follow a logical format.</li>
+ <li>Stable location = Externally visible locations are consistent in name, and availability.</li>
+ <li>Other things that impact stability
+ <ul>
+ <li>legacy = earlier naming schemes, formats, data storage devices</li>
+ <li>steward = people who are committed to consistently maintain specific datasets, either individuals or roles in organizations</li>
+ <li>provenance = the sources that establish a context for the production and/or use of an artifact. See <a href="http://www.w3.org/2011/prov/wiki/Main_Page" target="_blank">W3C Provenance working group</a></li>
+ </ul>
+ </li>
+</ul>
+
+<h3>Best practice for Stability</h3>
+
+<p>The length of time information is available is inherently connected to the value placed upon it. If information is deemed valuable, it is likely to persist for a longer period of time. Value, which can change over time, is always determined based on a cost-benefit relationship; Any benefit derived from information is reduced by the cost(s) associated with using it. Increasing stability requires the adoption of a strategy to allocate limited resources for achieving a goal.
</p>
-@@ TODO: Expand for other countries by example, e.g., Brazil, others
+<h3>Organizational Success Factors</h3>
+<p>Organizational considerations without internal stability from the data stewards, any external technology stability is a challenge. The following are some organization characteristics for stable data.</p>
+<ul>
+ <li>Consistent human skills</li>
+ <li>Consistent infrastructure</li>
+ <li>Data related to organizational values or business needs</li>
+ <li>Internal champion or consistent business process</li>
+ <li>Internal politics on variation names do not impact external locations</li>
+</ul>
+
+<!-- << STABILITY.Properties -->
+
+<h3>Stability Properties</h3>
+<p><i>These are characteristics that influence the stability or longevity. Many of these properties are not unique to LOD, yet they influence data cost and therefore data value.</i></p>
+<ul>
+ <li><b><u>Consistency.</u></b>Any design of a data format should recognize that change is necessary and will happen. Recognition that change is enviable while providing a mechanism for embracing modification increases continuity and longevity.
+ The following types of changes can be anticipated. Therefore, data design should be made to accommodate them:
+ <ol type="1">
+ <li>The person who published the data changes jobs - For <u>Contact Consistency</u> - Any support contact information should be published using a data steward so that the inherent transition of responsibility does not introduce inconsistency to consumers.</li>
+ <li>Departments, Agencies and Governments are reorganized - For <u>File Naming and Data Consistency</u> - Discourage the use of the originating source as component in the name of the data file, or the URIs it contains.The information can appropriately be contained within the file as metadata.</li>
+ <li>IT infrastructure overhaul - <u>For File Naming Consistency</u> - Discourage the use of the server or system as component in the name of the data file.</li>
+ <li>Merger/acquisition - For <u>Data Consistency</u> - Discourage the use of branding as it inherently and needlessly increases cost for new owners while providing no value at all to consumers.</li>
+ <li>Primary stakeholder loses interest in the data - As above For <u>Data Consistency</u> - Discourage the use of branding as it inherently increase cost for new owners.</li>
+ </ol>
+ </li>
+
+<li><b><u>Organization.</u></b>The minimum metadata accompanying each data offering should include:
+ <ol type="1">
+ <li>Serialization type</li>
+ <li>Publisher</li>
+ <li>Creation Date</li>
+ <li>Modification Date</li>
+ <li>Version</li>
+ <li>Email address for data steward</li>
+ </ol>
+</li>
+
+<li>
+<b><u>Complexity.</u></b>All serializations are equal to a back-end system, therefore providers should serialize RDF in either
+ <ul>
+ <li>Turtle - The turtle serialization minimizes the disk space expenditure while also increasing human readability.</li>
+ <li>NTriples - The NTriples serialization increases integrity in that re-ordering will have no effect on semantics, and damaged lines only effect the assertion on those lines. NTriples also increases flexibility because files can be split into smaller files as long as the division happen at the end of the line.</li>
+ </ul>
+</li>
+
+Different serializations represent the same semantics but require varying amounts of characters (diskspace). While Turtle provides the most concise serialization and is arguably the easiest for humans to read. Turtle does not provide the integrity that NTriples does because NTriples can be reordered or split up based on size or line count without effecting the integrity of the dataset. In general NTriples will provide the greatest overall stability for LOD.
+</section>
+
+
+
+<!-- SOURCE DATA -->
+<section>
+<h2>Source Data</h2>
+<p class='todo'>To Review: Michael Hausenblas (DERI), Spyros Kotoulas(IBM/SCTC), Biplav Srivastava (IBM)</p>
+
+<p>
+This section contains advices concerning how to expose source data, data which is being maintained in pre-existing (non-linked-data) systems such as RDBs or spreadsheets.
+</p>
+
+<p class="todo">Integrate Wiki <a href="http://www.w3.org/2011/gld/wiki/Best_Practices_Discussion_Summary#Source_Data">content</a> as well as Spyros' <a href="http://www.w3.org/2011/gld/wiki/images/0/08/LegacyData.pdf">slides</a> from the F2F2</p>
+
+</section>
+
+
+
+<!-- REFERENCE: LINKED DATA COOKBOOK -->
+<section>
+<h2>References</h2>
+
+<h3>Linked Open Data Cookbook</h3>
+<p>
+See <a href="http://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook">Cookbook for Open Government Linked Data</a>.
+</p>
+</section>
<!-- ACK -->
<section class="appendix">
<h2>Acknowledgments</h2>
+<h3>Material Contributions</h3>
+
<p>
-The editors are very thankful for comments and suggestions ...
+The editors gratefully acknowledge the many contributors to this Best Practices document including:
+Michael Pendleton (US EPA), John Erickson (RPI), Ghislain Atemezing (INSTITUT TELECOM), Daniel Vila (UPM), Martin Alvarez (CTIC), David Wood (3 Round Stones), ...
+</p>
+<p>
+The editors are also very thankful for comments and suggestions ...
</p>
</section>
</body>