--- a/ldp-bp/ldp-bp.html Mon Dec 30 08:28:37 2013 -0600
+++ b/ldp-bp/ldp-bp.html Mon Dec 30 20:48:15 2013 -0600
@@ -16,6 +16,8 @@
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus : "ED",
+ edDraftURI : "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html",
+
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName : "ldp-bp",
@@ -90,7 +92,7 @@
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
- wgPatentURI : "http://www.w3.org/2004/01/pp-impl/55082/status",
+ //wgPatentURI : "http://www.w3.org/2004/01/pp-impl/55082/status",
localBiblio : {
"LD-DI" : {
title : "Linked Data - Design Issues",
@@ -190,7 +192,8 @@
and general guidelines for implementing Linked Data Platform servers
and clients.</section>
- <section>
+
+ <section id="intro">
<h2>About this Document</h2>
@@ -217,7 +220,7 @@
<h3>Terminology</h3>
- <p>For the purposes of this document, we have found it useful to
+ <p>For the purposes of this document, it is useful to
make a minor, yet important distinction between the term 'best
practice' and the term 'guideline'. For the purposes of this
document, we define and differentiate the terms as follows:</p>
@@ -227,24 +230,25 @@
<dd>An implementation practice (method or technique) that has
consistently shown results superior to those achieved with other
means and that is used as a benchmark. Best practices within this
- document apply specifically to the ways that one should implement
- LDP servers and clients. In this document, the best practices might
- be used as a kind of check-list against which an implementer can
- directly evaluate a system's design and code. Lack of adherence to
- any given best practice, however, does not necessarily imply a lack
- of quality; they are recommendations that are said to be 'best' in
- most cases and in most contexts, but not all. A best practice is
- always subject to improvement as we learn and evolve the Web
- together.</dd>
+ document apply specifically to the ways that LDP servers and
+ clients are implemented as well as how certain resources should are
+ prepared and used with them. In this document, the best practices
+ might be used as a kind of check-list against which an implementer
+ can directly evaluate a system's design and code. Lack of adherence
+ to any given best practice, however, does not necessarily imply a
+ lack of quality; they are recommendations that are said to be
+ 'best' in most cases and in most contexts, but not all. A best
+ practice is always subject to improvement as we learn and evolve
+ the Web together.</dd>
<dt>guideline</dt>
<dd>A tip, a trick, a note, a suggestion, or answer to a
frequently asked question. Guidelines within this document provide
- useful information that can advance your knowledge and
- understanding, but that may not be directly applicable to your
+ useful information that can advance an implementer's knowledge and
+ understanding, but that may not be directly applicable to an
implementation or recognized by consensus as a 'best practice'.</dd>
</dl>
- <p>Please see the Terminology section of the LDP specification
+ <p>Please see the Terminology section in Linked Data Platform 1.0
[[LDP1]] as well as the Linked Data Glossary [[LD-GLOSSARY]] for
definitions to a variety of terms used in this document and related
to the Linked Data sphere of knowledge.</p>
@@ -339,14 +343,14 @@
these predicates where possible.</p>
<p>Of course, it is also a common practice to reuse properties
- from vocabularies that you don't own. In this case, you typically
- have no control over the result when attempting to dereference the
- URI. For this reason, publishers who wish to make their vocabularies
- useful for linking data should strive to provide a retrievable
- representation of the properties their vocabularies define.
- Consequently, implementers are also expected to use this standard as
- a benchmark for which to judge the efficacy of a vocabulary's use
- for linking data.</p>
+ from open vocabularies that are publicly available. In this case,
+ implementers have no control over the result when attempting to
+ dereference the URI. For this reason, publishers who wish to make
+ their vocabularies useful for linking data should strive to provide
+ a retrievable representation of the properties their vocabularies
+ define. Consequently, implementers are also expected to use this
+ standard as a benchmark for which to judge the efficacy of a
+ vocabulary's use for linking data.</p>
</section>
@@ -358,11 +362,10 @@
<p>
It is often very useful to know the type (class) of an LDPR, though
it is not essential to work with the interaction capabilities that
- LDP offers. Still, to make your data more useful in the broadest
- context, you should explicitly define the type when possible and
- appropriate and you should use the
+ LDP offers. Still, to make data more useful in the broadest context,
+ type should be explicitly defined using the
<code>rdf:type</code>
- predicate defined by [[RDF-SCHEMA]] when doing so.
+ predicate defined by [[RDF-SCHEMA]].
</p>
<p>This provides a way for clients to easily determine the type
@@ -390,7 +393,7 @@
URIs should ideally provide a retrievable representation, Linked
Data URIs are usually also URLs; they locate rather than just
identify. As such, the utilitarian value of relative URLs still
- applies; especially since the Container model of the LDP promotes
+ applies; especially since the LDP Container model promotes
hierarchical representations.</p>
<p>Implementers should therefore align the function of relative
@@ -469,7 +472,7 @@
container from the vocabularies defined by the <a
href="http://open-services.net/">Open Service for Lifecycle
Management (OSLC)</a> community. The OSLC defines specifications and
- vocabularies that are well-aligned to the LDP. A resource in an OSLC
+ vocabularies that are well-aligned to LDP. A resource in an OSLC
compliant change management system such as an issue or bug tracker
may have attachments represented by the
<code>oslc_cm:attachment</code>
@@ -481,19 +484,19 @@
<code>http://example.org/bugs/2314/attachments/</code>
</p>
- <p>From this URI, you can easily discern the URI of the parent
- resource, which holds the attachments. You can also discern the base
- container for other sibling resources by moving up the hierarchy,
- which is implied by the URI. You might also go down the hierarchy to
- fetch meta-data or binary content using a URI such as the following:</p>
+ <p>From this URI, the URI of the parent resource which holds the
+ attachments is easily discerned. The base container for other
+ sibling resources can be discerned by moving up the hierarchy, which
+ is implied by the URI. Meta-data or binary content might be fetched
+ further down the hierarchy by using a URI such as the following:</p>
<p>
<code>http://example.org/bugs/2314/attachments/1</code>
</p>
- <p>As you can see, in addition to making the use of relative URIs
- possible, hierarchical URIs make interacting with resources easier
- because they represent the actual structure of the underlying graph.</p>
+ <p>In addition to making the use of relative URIs possible,
+ hierarchical URIs make interacting with resources easier because
+ they represent the actual structure of the underlying graph.</p>
</section>
@@ -581,11 +584,10 @@
<p>
First, it provides the convenience and efficiency of brevity.
- Suppose, for example that you want to describe the resources foo,
- bar and baz, which are contained in the same document. Since serving
- all of the descriptions in a single document is acceptable, we can
- mint relative URIs within the document using the fragment identifier
- (
+ Suppose, for example, the resources foo, bar and baz, which are
+ contained in the same document. Since serving all of the
+ descriptions in a single document is acceptable, we can mint
+ relative URIs within the document using the fragment identifier (
<code><#foo></code>
,
<code><#bar></code>
@@ -598,9 +600,9 @@
<p>Second, it can help avoid certain complexities inherent with
other approaches. Achieving the same result using three independent
- dereferenceable URIs could be more involved because you'd need to
- create and publish multiple documents, perhaps also having to setup
- 303 redirects.</p>
+ dereferenceable URIs could be more involved because multiple
+ documents would have to be published, perhaps also including the
+ setup of 303 redirects.</p>
<p>
<strong>See also:</strong>
@@ -962,8 +964,8 @@
<section>
<h3>Finding established vocabularies</h3>
- <p>Following are some sources which may be useful for finding and
- leveraging pre-existing, common, and well-established vocabularies.</p>
+ <p>Following are some useful resources for finding and leveraging
+ pre-existing, common, and well-established vocabularies.</p>
<p style="clear: both">
<img src="lov-thumb.jpg" width="150"
@@ -971,13 +973,13 @@
href="http://lov.okfn.org" target="_blank">Linked Open
Vocabularies (LOV)</a><br /> LOV is an entry point to the growing
ecosystem of linked open vocabularies (RDFS or OWL ontologies) used
- in the Linked Data Cloud. There you can find vocabularies listed and
+ in the Linked Data Cloud. Users can find vocabularies listed and
individually described by metadata, classified by vocabulary spaces,
and interlinked using the dedicated vocabulary VOAF. The site allows
- you to query the LOV dataset either at vocabulary level or at
+ users to query the LOV dataset either at vocabulary level or at
element level, exploring the vocabulary content using full-text
faceted search, and finding metrics about the use of vocabularies in
- the Semantic Web. You can also suggest a new vocabulary to add to
+ the Semantic Web. Users can also suggest a new vocabulary to add to
LOV. [[LOV]]
</p>
@@ -992,8 +994,6 @@
<div style="clear: both"></div>
-
-
</section>
</section>
@@ -1001,11 +1001,27 @@
<section class='appendix'>
<h2>Acknowledgements</h2>
- <p>Many thanks to Robin Berjon for making our lives so much easier
- with his cool tool.</p>
- <p>To Ashok Malhotra, Melvin Carvalho, Richard Cyganiak, Steve
- Speicher, and Miguel Esteban Gutiérrez for providing recommendations
- for improvement to the editors.</p>
+ <p>Many thanks to Robin Berjon and all contributors to the <a href="http://www.w3.org/respec/">ReSpec</a> tool, which makes writing these kinds of documents much easier.
+ </p>
+ <p>To the following individuals who, in addition to the editors, have contributed either directly or indirectly to the ongoing improvement of this document:
+ <ul>
+ <li><a href="http://lehors.wordpress.com/">Arnaud Le Hors</a>, IBM</li>
+ <li><a href="http://www.linkedin.com/pub/ashok-malhotra/4/675/6a2">Ashok Malhotra</a>, Oracle</li>
+ <li>Bart van Leeuwen</li>
+ <li>David Wood</li>
+ <li><a href="http://www.w3.org/People/Eric/">Eric Prud'hommeaux</a>, W3C</li>
+ <li>Henry Story</li>
+ <li>John Arwe, IBM</li>
+ <li>Kevin Page</li>
+ <li>Miel Vander Sande</li>
+ <li><a href="http://melvincarvalho.com/">Melvin Carvalho</a></li>
+ <li>Raúl García Castro</li>
+ <li><a href="http://richard.cyganiak.de/">Richard Cyganiak</a></li>
+ <li><a href="http://www.linkedin.com/in/yadnem">Roger Menday</a>, Fujitsu Laboratories of Europe</li>
+ <li><a href="http://www.w3.org/People/Sandro/">Sandro Hawke</a>, W3C</li>
+ <li><a href="http://stevespeicher.blogspot.com/">Steve Speicher</a>, IBM</li>
+ <li>Ted Thibodeau</li>
+ </ul>
</section>