changes ...
authorRoger Menday <roger.menday@uk.fujitsu.com>
Mon, 05 Aug 2013 22:50:13 +0100
changeset 252 e1f7ffe2c197
parent 251 2e8c2fcfd7a7
child 253 53ce62e89aa5
changes ...
ldp-primer/attachments_s1.txt
ldp-primer/attachments_s2.txt
ldp-primer/bug_create_req.txt
ldp-primer/bug_create_res.txt
ldp-primer/bug_create_s1.txt
ldp-primer/bug_create_s2.txt
ldp-primer/bug_look_up_resp.txt
ldp-primer/bug_update_req.txt
ldp-primer/ldp-primer.html
ldp-primer/ldpc_ex.txt
ldp-primer/ldpc_ex_m.txt
ldp-primer/ldpc_ex_non_ldpr.txt
ldp-primer/product_create_req.txt
ldp-primer/product_create_res.txt
ldp-primer/product_create_s1.txt
ldp-primer/product_create_s2.txt
ldp-primer/product_create_s3.txt
ldp-primer/product_lookup.txt
ldp-primer/product_lookup_resp.txt
ldp-primer/product_options_res.txt
--- a/ldp-primer/attachments_s1.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/attachments_s1.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -2,4 +2,8 @@
     dcterms:title "A container that tracks bugs of Product A" ;
     ldp:membershipSubject <>;
     ldp:membershipPredicate bt:hasAttachment;
-    ldp:membershipObject ldp:MemberSubject .
\ No newline at end of file
+    ldp:membershipObject ldp:MemberSubject .
+
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/attachments_s2.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/attachments_s2.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -3,4 +3,8 @@
     ldp:membershipSubject <>;
     ldp:membershipPredicate bt:hasAttachment;
     ldp:membershipObject ldp:MemberSubject;
-    bt:hasAttachment <login-page.png> . 
\ No newline at end of file
+    bt:hasAttachment <login-page.png> . 
+    
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/bug_create_req.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/bug_create_req.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -4,4 +4,8 @@
  
 <> a bt:Bug;
      dcterms:title "Product A crashes when shutting down.";
-     dcterms:creator </app/users/johndoe> . 
\ No newline at end of file
+     dcterms:creator </app/users/johndoe> . 
+     
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/bug_create_res.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/bug_create_res.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -1,3 +1,7 @@
 HTTP/1.1 201 Created
 Location: /app/BugTracker/ProductA/Bug1
-Content-Length: 0 
\ No newline at end of file
+Content-Length: 0 
+
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/bug_create_s1.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/bug_create_s1.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -2,4 +2,8 @@
     dcterms:title "A container that tracks bugs of Product A" ;
     bt:hasbug </app/product1/bug3> ;
     bt:hasbug </app/product1/bug4> ;
-	bt:hasbug </app/product1/bug67> .
\ No newline at end of file
+	bt:hasbug </app/product1/bug67> .
+	
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/bug_create_s2.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/bug_create_s2.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -2,4 +2,8 @@
      dcterms:title "Product A crashes when shutting down.";
      dcterms:creator </app/users/johndoe>;
      dcterms:created "2013-05-05T10:00"^^xsd:dateTime;
-     bt:isInState "New" .
\ No newline at end of file
+     bt:isInState "New" .
+     
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/bug_look_up_resp.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/bug_look_up_resp.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -8,3 +8,7 @@
       dcterms:creator </app/users/johndoe>;
       dcterms:created "2013-05-05T10:00"^^xsd:dateTime
       bt:isInState "New" .
+
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/bug_update_req.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/bug_update_req.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -9,3 +9,7 @@
       dcterms:created "2013-05-05T10:00"^^xsd:dateTime;
       bt:isInState "InProgress";
       bt:relatedBug </app/product1/bug4> . 
+
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/ldp-primer.html	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/ldp-primer.html	Mon Aug 05 22:50:13 2013 +0100
@@ -1,1 +1,1 @@
-<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
<html 
  xmlns="http://www.w3.org/1999/xhtml"
prefix="td: http://www.w3.org/2006/03/test-description# tn: http://ldp.example.org/NewTestDefinitions# ht: http://www.w3.org/2011/http#">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Linked Data Platform 1.0 Primer</title>
    <style type="text/css">
      div.syntaxmenu {
        border: 1px dotted black;
        padding:0 0 0 0.5em;
        margin: 0em; 
      }
    </style> 
	<script type="text/javascript">
	    var displayed = [];
		displayed["turtle"] = 1;
		displayed["jsonld"] = 0;
		function primerOnLoad() {
          setTimeout(function(){
  		    display('turtle', ''); set_display_by_id('hide-ts', ''); set_display_by_id('show-ts', 'none');
 		    display('jsonld', 'none'); set_display_by_id('hide-js', 'none'); set_display_by_id('show-js', '');
          },500)
		}
		function display(syntax,status) {
		  var howmany = 0;
		  if (status=='none') {
		    displayed[syntax] = 0; 
		  } else { 
		    displayed[syntax] = 1;
		  }
		  for ( i in displayed ) {
		       howmany = howmany + displayed[i];
		  }
		  set_display_by_class('div',syntax,status);
		  if ( howmany == 1 ) {
		      set_display_by_class('b','syntax-head','none');
		  } else {
		      set_display_by_class('b','syntax-head','');
		  }
		}
		function getElementsByClassName(oElm, strTagName, oClassNames){
			var arrElements = (! (! (strTagName == "*") || ! (oElm.all)))? oElm.all : oElm.getElementsByTagName(strTagName);
			var arrReturnElements = new Array();
			var arrRegExpClassNames = new Array();
			if(typeof oClassNames == "object"){
				for(var i=0; !(i>=oClassNames.length); i++){ /*>*/
					arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames[i].replace(/\-/g, "\\-") + "(\\s|$)"));
				}
			}
			else{
				arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames.replace(/\-/g, "\\-") + "(\\s|$)"));
			}
			var oElement;
			var bMatchesAll;
			for(var j=0; !(j>=arrElements.length); j++){ /*>*/
				oElement = arrElements[j];
				bMatchesAll = true;
				for(var k=0; !(k>=arrRegExpClassNames.length); k++){ /*>*/
					if(!arrRegExpClassNames[k].test(oElement.className)){
						bMatchesAll = false;
						break;
					}
				}
				if(bMatchesAll){
					arrReturnElements.push(oElement);
				}
			}
			return (arrReturnElements)
		}
		function set_display_by_class(el, cls, newValue) {
		   var e = getElementsByClassName(document, el, cls);
		   if (e != null) {
		      for (var i=0; !(i>=e.length); i++) {
		        e[i].style.display = newValue;
		      }
		   }
		}
		function set_display_by_id(id, newValue) {
		   var e = document.getElementById(id);
		   if (e != null) {
		     e.style.display = newValue;
		   }
		}
	</script>
    <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
    <script class='remove'>
      var respecConfig = {
          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
          specStatus:           "ED",
          
          // the specification's short name, as in http://www.w3.org/TR/short-name/
          shortName:            "ldp-primer",
          // TODO: Confirm short name

          // if your specification has a subtitle that goes below the main
          // formal title, define it here
          // subtitle   :  "an excellent document",

          // if you wish the publication date to be other than today, set this
          // publishDate:  "2009-08-06",

          // if the specification's copyright date is a range of years, specify
          // the start date here:
          // copyrightStart: "2005"

          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
          // and its maturity status
          //previousPublishDate:  "2013-03-07",
          //previousMaturity:  	"FPWD",
          //previousURI: 			"http://www.w3.org/TR/2013/WD-ldp-20130307/",

          // if there a publicly available Editor's Draft, this is the link
          //edDraftURI:           "http://www.w3.org/2012/ldp/hg/ldp.html",

          // if this is a LCWD, uncomment and set the end of its review period
          // lcEnd: "2009-08-05",

          // if you want to have extra CSS, append them to this list
          // it is recommended that the respec.css stylesheet be kept
          //extraCSS:             ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],

          // editors, add as many as you like
          // only "name" is required
          editors:  [
              { name: "Nandana Mihindukulasooriya", 
              	url: "http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/universitystaff/290-nandana",
                company: "Ontology Engineering Group, Universidad Politécnica de Madrid", 
                companyURL: "http://www.oeg-upm.net/"},
              { name: "Roger Menday", 
              	url: "#",
                company: "Fujitsu Laboratories of Europe Limited, London", 
                companyURL: "#" },
          ],

          // authors, add as many as you like. 
          // This is optional, uncomment if you have authors as well as editors.
          // only "name" is required. Same format as editors.

          //authors:  [
          //    { name: "Your Name", url: "http://example.org/",
          //      company: "Your Company", companyURL: "http://example.com/" },
          //],
          
          // name of the WG
          wg:           "Linked Data Platform Working Group",
          
          // URI of the public WG page
          wgURI:        "http://www.w3.org/2012/ldp",
          
          // name (without the @w3c.org) of the public mailing to which comments are due
          wgPublicList: "public-ldp-wg",
          
          // URI of the patent status for this WG, for Rec-track documents
          // !!!! IMPORTANT !!!!
          // 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",
          doRDFa: "1.1",
      };
	// Replaces HTML characters (brackets and quotes) with legal HTML representations
	// The following example would include a code example from another file and then 
	// call this function to make the included code renderable in a browser.
	//
	// <pre class='example' data-include='include-rdf-type.ttl' data-oninclude='fixCode'></pre>
	function fixCode(r, content) {
		var result = content;
		result = result.replace(/</g, "&lt;").replace(/>/g, "&gt;");
		result = result.replace(/'/g, "&apos;").replace(/"/g, "&quot;");
		var ss = result.split('---')
		var s1 = "<div class='turtle' style='font-family: sans-serif;'>Turtle:</div><div class='turtle'><pre>"+ss[0]+"</pre></div>";
		var s2 = "<div class='jsonld' style='font-family: sans-serif;'>JSON-LD:</div><div class='jsonld'><pre>"+ss[1]+"</pre></div>";
		return s1+s2;
	}
	function highlight(r, content) {
		return '<span style="background-color:#ccffcc">' + content + '</span>';
	}
    </script>
  </head>
  <body onLoad="primerOnLoad()">
    
    <section id='abstract'>
      This primer provides an introduction to Linked Data Platform (LDP), including the basic concepts 
      of LDP including Linked Data Platform Resource (LDPR) and Linked Data Platform Container (LDPC) 
      and their affordances, and a running example showing how an LDP client can interact with a LDP server 
      in the context of read-write Linked Data application i.e. how to HTTP for accessing, updating, 
      creating and deleting resources from servers that expose their resources as Linked Data.
    </section>
    
    <section id="intro-section">
    <h1><a id="Introduction">Introduction</a></h1>
    <p>Linked Data is a universal approach for handling data which fundamentally includes the notion linking between data items. 
    	Much like the Web is giant network of interlinked documents for a human reader, the graph of Linked Data in the Web is a 
    	data layer on top of which applications are delivered, information is modified, processed, visualized and shared.
    </p>
    <p> Linked Data Platform specification discusses standard HTTP and RDF techniques and best practices that you should use, and 
    	anti-patterns you should avoid, when constructing clients and servers that read and write Linked Data resources. The LDP 
    	consists of two main building blocks: Linked Data Platform Resource (LDPR) and 
        Linked Data Platform Container (LDPC).
    </p>
    <p> Any HTTP resource whose state is represented in RDF that conforms to the simple lifecycle patterns and conventions in LDP 
    	specification is an LDPR. It is recommended that LDPRs reuse existing vocabularies instead of creating their own duplicate 
    	vocabulary terms. It is also recommended that LDPRs have at least one rdf:type set explicitly to make the representations 
    	more useful to client applications that don’t support inferencing. For example, a FOAF file of a person as shown in Example 1 
    	can be an example of an LDPR . It uses terms from Dublin Core [[DC-TERMS]], Friend of a Friend [[FOAF]] vocabularies. 
    </p>

   
    <pre title="An example LDPR" class='example' data-include='ldpr_ex.ttl' data-oninclude='fixCode'></pre>


	<p> Linked Data Platform Container (LDPC) is a specialization of an LDPR. An LDPC is a collection of same-subject, same-predicate 
		triples which is uniquely identified by a URI that responds to client requests for creation, modification, and enumeration of its members.
		For example, a set of friends of a person can be a represented as an LDPC as shown in Example 2 that contains a collection of triples
		with the pattern <code>&lt;#friends, foaf:member, ?friend&gt; </code>.
	</p>
	<div>
	  <pre title="An example LDPC" class='example' data-include='ldpc_ex.ttl'	data-oninclude='fixCode'></pre>
	</div>
	<div>	
	  <pre title="A member resource of LDPC in Example 2"	class='example' data-include='ldpc_ex_m.ttl' data-oninclude='fixCode'></pre>					
	</div>
	<p>	
		Elements of the collection of same-subject, same-predicate triples are called Membership triples or simply members of the LDPC. Several predicates 
		of the LDPC ldp:membershipSubject, ldp:membershipPredicate, ldp:membershipObject defines the different aspects of the membership relation. 
	</p>
	<p> Members of an LDPC does not have to be LDPRs. Any HTTP resource can be a member for an LDPC. For example,
	</p>
		<pre title="An example LDPC with non-LDPRs"
		class='example' data-include='ldpc_ex_non_ldpr.ttl'
					data-oninclude='fixCode'></pre>	
	<p>
		Use cases that motivated LDP specification varies from just publishing a dataset as Linked Data with advanced features as pagination, 
		providing read/write access to using Linked Data for application integration. The Linked Data Platform Use Cases and Requirements document provides 
		a more detailed information on the use cases that motivated the LDP specification. 
	</p>									
    <p>There will be several categories of systems implementing the LDP specification. Two main categories of the LDP servers include:</p>
    <dl class="glossary">
	<dt>Generic / vanilla LDP servers</dt>
	<dd>RDF storage systems that allow interacting with their resources by means of the LDP specification. These servers do not impose any restriction on LDPRs.</dd>
    <dt>Application specific LDP severs </dt>
    <dd>Systems exposing their data using the LDP specification. These systems impose restrictions on LDPRs since they have an underlying business logic and data model.</dd>
    </dl>
    </section>
    
    <section id="org-section">
	<h1 id="orgnization">Organization of this Document</h1>
    	
	<p>This document is organized as follows:</p>

    <h2 id="conventions">Conventions Used in This Document</h2>

        <pre title="An example LDPR" class='example' data-include='ldpr_ex.ttl' data-oninclude='fixCode'></pre>


	<div class="syntaxmenu">
	<p>The buttons below can be used to show or hide the available syntaxes.</p>
	<form><p>
      <input id="hide-ts" onclick="display('turtle', 'none'); set_display_by_id('hide-ts', 'none'); set_display_by_id('show-ts', ''); return false;" type="button" value="Hide Turtle Syntax" />
      <input id="show-ts" onclick="display('turtle', ''); set_display_by_id('hide-ts', ''); set_display_by_id('show-ts', 'none'); return false;" style="display:none" type="button" value="Show Turtle Syntax" />
      <input id="hide-js" onclick="display('jsonld','none'); set_display_by_id('hide-js', 'none'); set_display_by_id('show-js', ''); return false;" type="button" value="Hide JSON-LD Syntax" />
      <input id="show-js" onclick="display('jsonld',''); set_display_by_id('hide-js', ''); set_display_by_id('show-js', 'none'); return false;" style="display:none" type="button" value="Show JSON-lD Syntax" />
	</p>
    </form>
	</div>


	<p>Commonly used namespace prefixes:</p>
	<pre style="word-wrap: break-word; white-space: pre-wrap;">	@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
	@prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
	@prefix rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
	@prefix ldp:     &lt;http://www.w3.org/ns/ldp#&gt;.
	@prefix xsd:     &lt;http://www.w3.org/2001/XMLSchema#&gt;.</pre>

    </section>
    
	<section id="examples">
	<h1>Examples</h1>
	
	<p>
    This section provides a set of examples to show the Linked Data Platform interactions. Note, this is a primer and should 
    not be considered as a canonical example of ideal LDP modeling.
    The examples in this section will revolve around a very simple Bug Tracker application. Bug Tracker application records 
    the bugs of several products allowing reporting, updating and deleting bugs and products. We can re-use simple domain vocabulary, 
    e.g. has_bug or related, to express our data. LDP provides the additional interaction capability in the protocol to perform dynamic 
    evolution of knowledge representation.
	</p>
	
	
	<p>RESTful API of the example Bug Tracker system.</p>
	
	<table class="simple">
		<thead>
			<th>Path</th>
			<th>Method</th>
			<th>Description</th>
		</thead>
		<tbody>
			<!--tr>
				<td rowspan="5">/app/</td>
				<td>GET</td>
				<td>Lists all the product descriptions.</td>		
			</tr>
			<tr>
				<td>POST</td>
				<td>Create a new product description.</td>		
			</tr>
			<tr>
				<td>PUT</td>
				<td>Update the app description and/or list of product descriptions</td>		
			</tr>
			<tr>
				<td>PATCH</td>
				<td>Update the app description and/or list of product descriptions</td>		
			</tr>
			<tr>
				<td>DELETE</td>
				<td>Not allowed.</td>		
			</tr-->
			<tr>
				<td rowspan="5"><code>/app/{product-id}/</code></td>
				<td>GET</td>
				<td>Lists the bug reports associated with a product.</td>		
			</tr>
			<tr>
				<td>POST</td>
				<td>Create a new bug report associated with a product.</td>		
			</tr>
			<tr>
				<td>PUT</td>
				<td>Update the project description.</td>		
			</tr>
			<tr>
				<td>PATCH</td>
				<td>Not supported.</td>		
			</tr>
			<tr>
				<td>DELETE</td>
				<td>Delete the project description and associated bug reports.</td>		
			</tr>
			<tr>
				<td rowspan="5">/app/{product-id}/{bug-id}</td>
				<td>GET</td>
				<td>Gets the bug report.</td>		
			</tr>
			<tr>
				<td>POST</td>
				<td>Not allowed.</td>		
			</tr>
			<tr>
				<td>PUT</td>
				<td>Update the bug report.</td>		
			</tr>
			<tr>
				<td>PATCH</td>
				<td>Not supported.</td>		
			</tr>
			<tr>
				<td>DELETE</td>
				<td>Delete the bug report.</td>		
			</tr>
			<tr>
				<td rowspan="2">/*/*</td>
				<td>OPTIONS</td>
				<td>Discover the allowed operations over a resource</td>		
			</tr>
			<tr>
				<td>HEAD</td>
				<td>Only retrieve metainformation about a resource</td>		
			</tr>
		</tbody>
		
		
	</table>
	
	<section id="simple-ex">
	<h2 >Simple scenarios</h2>
		
	<h3 id="ProductLookup">Lookup a Product</h3>
	<p> One of the main use cases of the example bug tracker is to list of the bugs of a given product. Assuming 
		that a user got a URL of a product by out of band means, one can look it up to get more information including 
		the bugs associated with it.</p>
	
	<table>
		<tr>
			<td><img src="product_lookup.png" /></td>
			<td>
				<p>To get the description of the product, a client can do a GET request on the URI of the known product resource. LDPR 
					servers should provide text/turtle representations of the requested LDPRs and may provide RDF format representations
					using standard HTTP content negotiation.   </p>
<pre class="example">GET /app/product1/ HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
				<p>If the product resource is available, the server responds with the representation of the resource using the requested media type,
					<code>text/turtle</code> in this case.</p>
                    <pre title="HTTP response for product lookup" class='example' data-include='product_lookup_resp.ttl' data-oninclude='fixCode'></pre>				
			</td>
		</tr>
	</table>
	<p>
	The project description resource contains both information about the project such as the title and the information about members of the product LDPC
	i.e. the bugs associated with the product.		
		
	</p>
	<h3 id="BugLookup">Lookup a Bug</h3>
	<p>Looking up a bug is similar to looking up a product. </p>
	
	<table>
		<tr>
			<td><img src="bug_lookup.png" /></td>
			<td>
				<p>Based on links in the representation of the Product, the client uses GET to navigate to a known Bug resource.</p>
<pre class="example">GET /app/product1/bug3 HTTP/1.1
Host: example.org
Accept: text/turtle 
</pre>
				<p>The server responds with the representation of the bug.</p>
                                <pre title="The response of bug lookup"
					class='example' data-include='bug_look_up_resp.ttl'
					data-oninclude='fixCode'></pre>			
			</td>
		</tr>
	</table>
	
	<h3 id="ProductLookup">Discovering operations of a product</h3>
	<p>
		Assuming that a user got the URL of the product by out of band means, a starting point would be to discover
		which operations can be performed on the product resource.
	</p>
	
	<table>
		<tr>
			<td><img src="replace.png" /></td>
			<td>
				<p>The client does an OPTIONS with the URI of a known product description resource.</p>
<pre class="example">OPTIONS /app/product1/ HTTP/1.1
Host: example.org 
</pre>
				<p>If the product description resource is available, the server responds with the allowed HTTP operations on the product
					resource along with some other metadata.</p>
					<div class="turtle">
                      <pre title="HTTP response for OPTIONS on a product" class='example' data-include='product_options_res.tx' data-oninclude='fixCode'></pre>				
                    </div>
			</td>
		</tr>
	</table>
	
	<p> According to the response, HTTP operations {OPTIONS,GET,POST,PUT,PATCH} are allowed on the product description resource.
		In addition to the allowed operations, Accept-Post and Accept-Patch provides which media types are supported by respective operations. 
		The rel="type" Link header advertises that this is resource supports LDP protocol and the the rel="ldp:nonMemberResource" provides a link 
		to the non-member resource of this product description.
	</p>
	
	<h3 id="BugCreate">Create a new Bug</h3>
	<p>Continuing from the previous example, we can report a Bug against 'product1' by creating a Bug LDPR under the 'Product' LDPC.
The client POSTs a representation of a Bug to the Bug Tracker LDPC. </p>
	
	<table>
		<tr>
			<td><img src="bug_create.png" /></td>
			<td>
				<p>The client POSTs a representation of a Bug to the Bug Tracker LDPC.</p>
                <pre title="A resquest for creating a bug"
					class='example' data-include='bug_create_req.ttl'
					data-oninclude='fixCode'></pre>	
				<p>If the create is successful, the server responds with location of the newly created resource.</p>
                <pre title="A response of creating new a bug"
					class='example' data-include='bug_create_res.ttl'
					data-oninclude='fixCode'></pre>				
			</td>
		</tr>
		<tr>
			<td colspan="2">
				<p>If the creation fails, the server will respond with an appropriate status code depending on the error. 
					After the resource is creation, the Product A LDPC will have the following representation.</p>
				<pre title="The state of the product LDPC after the bug creation"
					class='example' data-include='bug_create_s1.ttl'
					data-oninclude='fixCode'></pre>
				<p>And the created Bug resource will have the following representation. Note that server has added a 
					server managed property, creation date (dcterms:created), and a default value for the state (bt:isInState) 
					to the Bug in addition to what was being POSTed.</p>
				<pre title="The state of the bug LDPR"
					class='example' data-include='bug_create_s2.ttl'
					data-oninclude='fixCode'></pre>						
			</td>
		</tr>
	</table>
	
	<h3 id="BugUpdate">Update a Bug</h3>
	<p> TODO - Description </p>
	
	<table>
		<tr>
			<td><img src="bug_update.png" /></td>
			<td>
				<p>TODO - Description</p>
                                <pre title="A resquest for updating a bug"
					class='example' data-include='bug_update_req.ttl'
					data-oninclude='fixCode'></pre>	
				<p>If the update is successful, the server will respond with a success status and a new etag.</p>
<pre class="example">
HTTP/1.1 204 No Content 
ETag: W/"123456790"  
</pre>				
			</td>
		</tr>
	</table>
	
	</section>
	
	<section id="basic-ex">	
	<h2>Basic scenarios</h2>
	
	<h3 id="ProductCreate">Create a Product</h3>
	<p>If the bug tracker allows creating new Products in the tracker, that can done by posting a representation of a new Product to the 
		Bug Tracker container.</p>
	<table>
		<tr>
			<td colspan="2">
				<p>The status of the bug tracker before creating the new product.</p>
				<pre title="The state of the Bug Tracker LDPC"
					class='example' data-include='product_create_s1.ttl'
					data-oninclude='fixCode'></pre>	
			</td>
		</tr>
		<tr>
			<td><img src="replace.png" /></td>
			<td>
				<p>The client POSTs a representation of a Product to the Bug Tracker LDPC.</p>
                <pre title="A resquest for creating a product"
					class='example' data-include='product_create_req.ttl'
					data-oninclude='fixCode'></pre>	
				<p>If the create is successful, the server responds with location of the newly created resource.</p>
                <pre title="A response after creating new a b"
					class='example' data-include='product_create_res.ttl'
					data-oninclude='fixCode'></pre>				
			</td>	
		</tr>
        <tr>
        	<td colspan="2">
        		<p>After creation of this new container, 'Product A', the representation of the 'Tracker' container will be</p>
        		<pre title="The state of the Bug Tracker after the product creation"
					class='example' data-include='product_create_s2.ttl'
					data-oninclude='fixCode'></pre>	
				<p>and the 'Product A' will have the following representation.</p>
				<pre title="The state of the new Product"
					class='example' data-include='product_create_s3.ttl'
					data-oninclude='fixCode'></pre>		
        	</td>	
        </tr>
	</table>
	
	<h3 id="ProductUpdate">Update a product description</h3>
	<p>If the bug tracker allows updating new product in the tracker, that can done by posting a representation of a new Product to the 
		Bug Tracker container.</p>
	
	</section>
	
	<h3 id="ProductDelete">Delete a product description</h3>
	<p>The bug tracker allows deleting products. TODO</p>
	
	</section>
	
	<section id="advanced-ex">	
	<h2>Advanced scenarios</h2>
	
	   <section id="ldp-membership">
	   <h3>Advanced use of ldp:membershipX predicates</h3>
	   </section>	
	
		<section id="paging">	
		<h3>Pagination</h3>
		</section>
	
		<section id="odering">	
		<h3>Ordering</h3>
		</section>
		
		<section id="inlining">	
		<h3>In-lining</h3>
		</section>
	
		<section id="binary-res">	
		<h3>Handling binary resources</h3>
		
		<h4>Creating a binary resource</h4>
		<table>
		<tr>
			<td colspan="2">
				<p>We have an LDPC which we can use to create binary resources</p>
				<pre title="The state of the attachments LDPC"
					class='example' data-include='attachments_s1.ttl'
					data-oninclude='fixCode'></pre>	
			</td>
		</tr>
		<tr>
			<td><img src="replace.png" /></td>
			<td>
				<p>The client POSTs POST a binary resource to the LDPC</p>
                <pre title="A resquest for creating a product"
					class='example' data-include='attachments_post_req.ttl'
					data-oninclude='fixCode'></pre>	
				<p>If the create is successful, the server it responds with a Location header and a Link header to
					the automatically created metadata LDPR.</p>
                <pre title="A response after creating new a b"
					class='example' data-include='attachments_post_res.ttl'
					data-oninclude='fixCode'></pre>				
			</td>	
		</tr>
		<tr>
			<td colspan="2">
				<p>After the creation, LDPC representation looks like</p>
				<pre title="The state of the attachments LDPC after creation"
					class='example' data-include='attachments_s2.ttl'
					data-oninclude='fixCode'></pre>	
			</td>
		</tr>
		</table>
		
		<h4>Accessing the binary resource</h4>
		
		<h4>Accessing the metadata about the binary resource</h4>
		
		<h4>Updating the metadata about the binary resource</h4>
		
		<h4>Deleting the binary resource</h4>
		
		</section>
	
	</section>
	
	
	<section>
	<h2 id="ldpc">LDP Implementations</h2>
	A list of implementations that plan to be LDP compliant is available in the LDP Implementations wiki page.
LDP Implementation report provides the coverage of the specification by each LDP implementation.
	</section>
	
	<section class='appendix informative' id="history">
	<h1>Change History</h1>
	<p>The change history is up to the editors to insert a brief summary of
	changes, ordered by most recent changes first and with heading from which
	public draft it has been changed from.
	</p>
	<ul>
		<li>2013-07-03 - Moving the content from the wiki to the note.</li>	
	</ul>
    </section>
  
  </body>
</html>
\ No newline at end of file
+<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
<html 
  xmlns="http://www.w3.org/1999/xhtml"
prefix="td: http://www.w3.org/2006/03/test-description# tn: http://ldp.example.org/NewTestDefinitions# ht: http://www.w3.org/2011/http#">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Linked Data Platform 1.0 Primer</title>
    <style type="text/css">
      div.syntaxmenu {
        border: 1px dotted black;
        padding:0 0 0 0.5em;
        margin: 0em; 
      }
      td.col1 { 
        width: 300px;
        vertical-align: top;
        padding: 30px 0 0 0;
      }
    </style> 
	<script type="text/javascript">
	    var displayed = [];
		displayed["turtle"] = 1;
		displayed["jsonld"] = 0;
		function primerOnLoad() {
          setTimeout(function(){
  		    display('turtle', ''); set_display_by_id('hide-ts', ''); set_display_by_id('show-ts', 'none');
 		    display('jsonld', 'none'); set_display_by_id('hide-js', 'none'); set_display_by_id('show-js', '');
          },500)
		}
		function display(syntax,status) {
		  var howmany = 0;
		  if (status=='none') {
		    displayed[syntax] = 0; 
		  } else { 
		    displayed[syntax] = 1;
		  }
		  for ( i in displayed ) {
		       howmany = howmany + displayed[i];
		  }
		  set_display_by_class('div',syntax,status);
		  if ( howmany == 1 ) {
		      set_display_by_class('b','syntax-head','none');
		  } else {
		      set_display_by_class('b','syntax-head','');
		  }
		}
		function getElementsByClassName(oElm, strTagName, oClassNames){
			var arrElements = (! (! (strTagName == "*") || ! (oElm.all)))? oElm.all : oElm.getElementsByTagName(strTagName);
			var arrReturnElements = new Array();
			var arrRegExpClassNames = new Array();
			if(typeof oClassNames == "object"){
				for(var i=0; !(i>=oClassNames.length); i++){ /*>*/
					arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames[i].replace(/\-/g, "\\-") + "(\\s|$)"));
				}
			}
			else{
				arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames.replace(/\-/g, "\\-") + "(\\s|$)"));
			}
			var oElement;
			var bMatchesAll;
			for(var j=0; !(j>=arrElements.length); j++){ /*>*/
				oElement = arrElements[j];
				bMatchesAll = true;
				for(var k=0; !(k>=arrRegExpClassNames.length); k++){ /*>*/
					if(!arrRegExpClassNames[k].test(oElement.className)){
						bMatchesAll = false;
						break;
					}
				}
				if(bMatchesAll){
					arrReturnElements.push(oElement);
				}
			}
			return (arrReturnElements)
		}
		function set_display_by_class(el, cls, newValue) {
		   var e = getElementsByClassName(document, el, cls);
		   if (e != null) {
		      for (var i=0; !(i>=e.length); i++) {
		        e[i].style.display = newValue;
		      }
		   }
		}
		function set_display_by_id(id, newValue) {
		   var e = document.getElementById(id);
		   if (e != null) {
		     e.style.display = newValue;
		   }
		}
	</script>
    <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
    <script class='remove'>
      var respecConfig = {
          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
          specStatus:           "ED",
          
          // the specification's short name, as in http://www.w3.org/TR/short-name/
          shortName:            "ldp-primer",
          // TODO: Confirm short name

          // if your specification has a subtitle that goes below the main
          // formal title, define it here
          // subtitle   :  "an excellent document",

          // if you wish the publication date to be other than today, set this
          // publishDate:  "2009-08-06",

          // if the specification's copyright date is a range of years, specify
          // the start date here:
          // copyrightStart: "2005"

          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
          // and its maturity status
          //previousPublishDate:  "2013-03-07",
          //previousMaturity:  	"FPWD",
          //previousURI: 			"http://www.w3.org/TR/2013/WD-ldp-20130307/",

          // if there a publicly available Editor's Draft, this is the link
          //edDraftURI:           "http://www.w3.org/2012/ldp/hg/ldp.html",

          // if this is a LCWD, uncomment and set the end of its review period
          // lcEnd: "2009-08-05",

          // if you want to have extra CSS, append them to this list
          // it is recommended that the respec.css stylesheet be kept
          //extraCSS:             ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],

          // editors, add as many as you like
          // only "name" is required
          editors:  [
              { name: "Nandana Mihindukulasooriya", 
              	url: "http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/universitystaff/290-nandana",
                company: "Ontology Engineering Group, Universidad Politécnica de Madrid", 
                companyURL: "http://www.oeg-upm.net/"},
              { name: "Roger Menday", 
              	url: "#",
                company: "Fujitsu Laboratories of Europe Limited, London", 
                companyURL: "#" },
          ],

          // authors, add as many as you like. 
          // This is optional, uncomment if you have authors as well as editors.
          // only "name" is required. Same format as editors.

          //authors:  [
          //    { name: "Your Name", url: "http://example.org/",
          //      company: "Your Company", companyURL: "http://example.com/" },
          //],
          
          // name of the WG
          wg:           "Linked Data Platform Working Group",
          
          // URI of the public WG page
          wgURI:        "http://www.w3.org/2012/ldp",
          
          // name (without the @w3c.org) of the public mailing to which comments are due
          wgPublicList: "public-ldp-wg",
          
          // URI of the patent status for this WG, for Rec-track documents
          // !!!! IMPORTANT !!!!
          // 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",
          doRDFa: "1.1",
      };
	// Replaces HTML characters (brackets and quotes) with legal HTML representations
	// The following example would include a code example from another file and then 
	// call this function to make the included code renderable in a browser.
	//
	// <pre class='example' data-include='include-rdf-type.ttl' data-oninclude='fixCode'></pre>
	function fixCode(r, content) {
		var result = content;
		result = result.replace(/</g, "&lt;").replace(/>/g, "&gt;");
		result = result.replace(/'/g, "&apos;").replace(/"/g, "&quot;");
		var ss = result.split('---')
		var s1 = "<div class='turtle' style='font-family: sans-serif;'>Turtle:</div><div class='turtle'><pre>"+ss[0]+"</pre></div>";
		var s2 = "<div class='jsonld' style='font-family: sans-serif;'>JSON-LD:</div><div class='jsonld'><pre>"+ss[1]+"</pre></div>";
		return s1+s2;
	}
	function highlight(r, content) {
		return '<span style="background-color:#ccffcc">' + content + '</span>';
	}
    </script>
  </head>
  <body onLoad="primerOnLoad()">
    
    <section id='abstract'>
      This primer provides an introduction to Linked Data Platform (LDP), including the basic concepts 
      of LDP including Linked Data Platform Resource (LDPR) and Linked Data Platform Container (LDPC) 
      and their affordances, and a running example showing how an LDP client can interact with a LDP server 
      in the context of read-write Linked Data application i.e. how to HTTP for accessing, updating, 
      creating and deleting resources from servers that expose their resources as Linked Data.
    </section>
    
    <section id="intro-section">
    <h1><a id="Introduction">Introduction</a></h1>
    <p>Linked Data is a universal approach for handling data which fundamentally includes the notion linking between data items. 
    	Much like the Web is giant network of interlinked documents for a human reader, the graph of Linked Data in the Web is a 
    	data layer on top of which applications are delivered, information is modified, processed, visualized and shared.
    </p>
    <p> Linked Data Platform specification discusses standard HTTP and RDF techniques and best practices that you should use, and 
    	anti-patterns you should avoid, when constructing clients and servers that read and write Linked Data resources. The LDP 
    	consists of two main building blocks: Linked Data Platform Resource (LDPR) and 
        Linked Data Platform Container (LDPC).
    </p>
    <p> Any HTTP resource whose state is represented in RDF that conforms to the simple lifecycle patterns and conventions in LDP 
    	specification is an LDPR. It is recommended that LDPRs reuse existing vocabularies instead of creating their own duplicate 
    	vocabulary terms. It is also recommended that LDPRs have at least one rdf:type set explicitly to make the representations 
    	more useful to client applications that don’t support inferencing. For example, a FOAF file of a person as shown in Example 1 
    	can be an example of an LDPR . It uses terms from Dublin Core [[DC-TERMS]], Friend of a Friend [[FOAF]] vocabularies. 
    </p>

   
    <pre title="An example LDPR" class='example' data-include='ldpr_ex.txt' data-oninclude='fixCode'></pre>


	<p> Linked Data Platform Container (LDPC) is a specialization of an LDPR. An LDPC is a collection of same-subject, same-predicate 
		triples which is uniquely identified by a URI that responds to client requests for creation, modification, and enumeration of its members.
		For example, a set of friends of a person can be a represented as an LDPC as shown in Example 2 that contains a collection of triples
		with the pattern <code>&lt;#friends, foaf:member, ?friend&gt; </code>.
	</p>
	<div>
	  <pre title="An example LDPC" class='example' data-include='ldpc_ex.txt'	data-oninclude='fixCode'></pre>
	</div>
	<div>	
	  <pre title="A member resource of LDPC in Example 2"	class='example' data-include='ldpc_ex_m.txt' data-oninclude='fixCode'></pre>					
	</div>
	<p>	
		Elements of the collection of same-subject, same-predicate triples are called Membership triples or simply members of the LDPC. Several predicates 
		of the LDPC ldp:membershipSubject, ldp:membershipPredicate, ldp:membershipObject defines the different aspects of the membership relation. 
	</p>
	<p> Members of an LDPC does not have to be LDPRs. Any HTTP resource can be a member for an LDPC. For example,
	</p>
    
    <pre title="An example LDPC with non-LDPRs" class='example' data-include='ldpc_ex_non_ldpr.txt' data-oninclude='fixCode'></pre>	
	
	<p>
		Use cases that motivated LDP specification varies from just publishing a dataset as Linked Data with advanced features as pagination, 
		providing read/write access to using Linked Data for application integration. The Linked Data Platform Use Cases and Requirements document provides 
		a more detailed information on the use cases that motivated the LDP specification. 
	</p>									
    <p>There will be several categories of systems implementing the LDP specification. Two main categories of the LDP servers include:</p>
    <dl class="glossary">
	<dt>Generic / vanilla LDP servers</dt>
	<dd>RDF storage systems that allow interacting with their resources by means of the LDP specification. These servers do not impose any restriction on LDPRs.</dd>
    <dt>Application specific LDP severs </dt>
    <dd>Systems exposing their data using the LDP specification. These systems impose restrictions on LDPRs since they have an underlying business logic and data model.</dd>
    </dl>
    </section>
    
    <section id="org-section">
	<h1 id="orgnization">Organization of this Document</h1>
    	
	<p>This document is organized as follows:</p>

    <h2 id="conventions">Conventions Used in This Document</h2>

        <pre title="An example LDPR" class='example' data-include='ldpr_ex.txt' data-oninclude='fixCode'></pre>


	<div class="syntaxmenu">
	<p>The buttons below can be used to show or hide the available syntaxes.</p>
	<form><p>
      <input id="hide-ts" onclick="display('turtle', 'none'); set_display_by_id('hide-ts', 'none'); set_display_by_id('show-ts', ''); return false;" type="button" value="Hide Turtle Syntax" />
      <input id="show-ts" onclick="display('turtle', ''); set_display_by_id('hide-ts', ''); set_display_by_id('show-ts', 'none'); return false;" style="display:none" type="button" value="Show Turtle Syntax" />
      <input id="hide-js" onclick="display('jsonld','none'); set_display_by_id('hide-js', 'none'); set_display_by_id('show-js', ''); return false;" type="button" value="Hide JSON-LD Syntax" />
      <input id="show-js" onclick="display('jsonld',''); set_display_by_id('hide-js', ''); set_display_by_id('show-js', 'none'); return false;" style="display:none" type="button" value="Show JSON-lD Syntax" />
	</p>
    </form>
	</div>


	<p>Commonly used namespace prefixes:</p>
	<pre style="word-wrap: break-word; white-space: pre-wrap;">	@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
	@prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
	@prefix rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
	@prefix ldp:     &lt;http://www.w3.org/ns/ldp#&gt;.
	@prefix xsd:     &lt;http://www.w3.org/2001/XMLSchema#&gt;.</pre>

    </section>
    
	<section id="examples">
	<h1>Examples</h1>
	
	<p>
    This section provides a set of examples to show the Linked Data Platform interactions. Note, this is a primer and should 
    not be considered as a canonical example of ideal LDP modeling.
    The examples in this section will revolve around a very simple Bug Tracker application. Bug Tracker application records 
    the bugs of several products allowing reporting, updating and deleting bugs and products. We can re-use simple domain vocabulary, 
    e.g. has_bug or related, to express our data. LDP provides the additional interaction capability in the protocol to perform dynamic 
    evolution of knowledge representation.
	</p>
	
	
	<p>RESTful API of the example Bug Tracker system.</p>
	
	<table class="simple">
		<thead>
			<th>Path</th>
			<th>Method</th>
			<th>Description</th>
		</thead>
		<tbody>
			<!--tr>
				<td rowspan="5">/app/</td>
				<td>GET</td>
				<td>Lists all the product descriptions.</td>		
			</tr>
			<tr>
				<td>POST</td>
				<td>Create a new product description.</td>		
			</tr>
			<tr>
				<td>PUT</td>
				<td>Update the app description and/or list of product descriptions</td>		
			</tr>
			<tr>
				<td>PATCH</td>
				<td>Update the app description and/or list of product descriptions</td>		
			</tr>
			<tr>
				<td>DELETE</td>
				<td>Not allowed.</td>		
			</tr-->
			<tr>
				<td rowspan="5"><code>/app/{product-id}/</code></td>
				<td>GET</td>
				<td>Lists the bug reports associated with a product.</td>		
			</tr>
			<tr>
				<td>POST</td>
				<td>Create a new bug report associated with a product.</td>		
			</tr>
			<tr>
				<td>PUT</td>
				<td>Update the project description.</td>		
			</tr>
			<tr>
				<td>PATCH</td>
				<td>Not supported.</td>		
			</tr>
			<tr>
				<td>DELETE</td>
				<td>Delete the project description and associated bug reports.</td>		
			</tr>
			<tr>
				<td rowspan="5">/app/{product-id}/{bug-id}</td>
				<td>GET</td>
				<td>Gets the bug report.</td>		
			</tr>
			<tr>
				<td>POST</td>
				<td>Not allowed.</td>		
			</tr>
			<tr>
				<td>PUT</td>
				<td>Update the bug report.</td>		
			</tr>
			<tr>
				<td>PATCH</td>
				<td>Not supported.</td>		
			</tr>
			<tr>
				<td>DELETE</td>
				<td>Delete the bug report.</td>		
			</tr>
			<tr>
				<td rowspan="2">/*/*</td>
				<td>OPTIONS</td>
				<td>Discover the allowed operations over a resource</td>		
			</tr>
			<tr>
				<td>HEAD</td>
				<td>Only retrieve metainformation about a resource</td>		
			</tr>
		</tbody>
		
		
	</table>
	
	<section id="simple-ex">
	<h2 >Simple scenarios</h2>
		
	<h3 id="ProductLookup">Lookup a Product</h3>
	<p> One of the main use cases of the example bug tracker is to list of the bugs of a given product. Assuming 
		that a user got a URL of a product by out of band means, one can look it up to get more information including 
		the bugs associated with it.</p>
	
	<table>
		<tr>
			<td class="col1"><img src="product_lookup.png" /></td>
			<td>
				<p>To get the description of the product, a client can do a GET request on the URI of the known product resource. LDPR 
					servers should provide text/turtle representations of the requested LDPRs and may provide RDF format representations
					using standard HTTP content negotiation.   </p>
<pre class="example">GET /app/product1/ HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
				<p>If the product resource is available, the server responds with the representation of the resource using the requested media type,
					<code>text/turtle</code> in this case.</p>
                    <pre title="HTTP response for product lookup" class='example' data-include='product_lookup_resp.txt' data-oninclude='fixCode'></pre>				
			</td>
		</tr>
	</table>
	<p>
	The project description resource contains both information about the project such as the title and the information about members of the product LDPC
	i.e. the bugs associated with the product.		
		
	</p>
	<h3 id="BugLookup">Lookup a Bug</h3>
	<p>Looking up a bug is similar to looking up a product. </p>
	
	<table>
		<tr>
			<td class="col1"><img src="bug_lookup.png" /></td>
			<td>
				<p>Based on links in the representation of the Product, the client uses GET to navigate to a known Bug resource.</p>
<pre class="example">GET /app/product1/bug3 HTTP/1.1
Host: example.org
Accept: text/turtle 
</pre>
				<p>The server responds with the representation of the bug.</p>
                                <pre title="The response of bug lookup"
					class='example' data-include='bug_look_up_resp.txt'
					data-oninclude='fixCode'></pre>			
			</td>
		</tr>
	</table>
	
	<h3 id="ProductLookup">Discovering operations of a product</h3>
	<p>
		Assuming that a user got the URL of the product by out of band means, a starting point would be to discover
		which operations can be performed on the product resource.
	</p>
	
	<table>
		<tr>
			<td class="col1"><img src="replace.png" /></td>
			<td>
				<p>The client does an OPTIONS with the URI of a known product description resource.</p>
<pre class="example">OPTIONS /app/product1/ HTTP/1.1
Host: example.org 
</pre>
				<p>If the product description resource is available, the server responds with the allowed HTTP operations on the product
					resource along with some other metadata.</p>
					<div class="turtle">
                      <pre title="HTTP response for OPTIONS on a product" class='example' data-include='product_options_res.tx' data-oninclude='fixCode'></pre>				
                    </div>
			</td>
		</tr>
	</table>
	
	<p> According to the response, HTTP operations {OPTIONS,GET,POST,PUT,PATCH} are allowed on the product description resource.
		In addition to the allowed operations, Accept-Post and Accept-Patch provides which media types are supported by respective operations. 
		The rel="type" Link header advertises that this is resource supports LDP protocol and the the rel="ldp:nonMemberResource" provides a link 
		to the non-member resource of this product description.
	</p>
	
	<h3 id="BugCreate">Create a new Bug</h3>
	<p>Continuing from the previous example, we can report a Bug against 'product1' by creating a Bug LDPR under the 'Product' LDPC.
The client POSTs a representation of a Bug to the Bug Tracker LDPC. </p>
	
	<table>
		<tr>
			<td class="col1"><img src="bug_create.png" /></td>
			<td>
				<p>The client POSTs a representation of a Bug to the Bug Tracker LDPC.</p>
                <pre title="A resquest for creating a bug"
					class='example' data-include='bug_create_req.txt'
					data-oninclude='fixCode'></pre>	
				<p>If the create is successful, the server responds with location of the newly created resource.</p>
                <pre title="A response of creating new a bug"
					class='example' data-include='bug_create_res.txt'
					data-oninclude='fixCode'></pre>				
			</td>
		</tr>
		<tr>
			<td colspan="2">
				<p>If the creation fails, the server will respond with an appropriate status code depending on the error. 
					After the resource is creation, the Product A LDPC will have the following representation.</p>
				<pre title="The state of the product LDPC after the bug creation"
					class='example' data-include='bug_create_s1.txt'
					data-oninclude='fixCode'></pre>
				<p>And the created Bug resource will have the following representation. Note that server has added a 
					server managed property, creation date (dcterms:created), and a default value for the state (bt:isInState) 
					to the Bug in addition to what was being POSTed.</p>
				<pre title="The state of the bug LDPR"
					class='example' data-include='bug_create_s2.txt'
					data-oninclude='fixCode'></pre>						
			</td>
		</tr>
	</table>
	
	<h3 id="BugUpdate">Update a Bug</h3>
	<p> TODO - Description </p>
	
	<table>
		<tr>
			<td class="col1"><img src="bug_update.png" /></td>
			<td>
				<p>TODO - Description</p>
                                <pre title="A resquest for updating a bug"
					class='example' data-include='bug_update_req.txt'
					data-oninclude='fixCode'></pre>	
				<p>If the update is successful, the server will respond with a success status and a new etag.</p>
<pre class="example">
HTTP/1.1 204 No Content 
ETag: W/"123456790"  
</pre>				
			</td>
		</tr>
	</table>
	
	</section>
	
	<section id="basic-ex">	
	<h2>Basic scenarios</h2>
	
	<h3 id="ProductCreate">Create a Product</h3>
	<p>If the bug tracker allows creating new Products in the tracker, that can done by posting a representation of a new Product to the 
		Bug Tracker container.</p>
	<table>
		<tr>
			<td colspan="2">
				<p>The status of the bug tracker before creating the new product.</p>
				<pre title="The state of the Bug Tracker LDPC"
					class='example' data-include='product_create_s1.txt'
					data-oninclude='fixCode'></pre>	
			</td>
		</tr>
		<tr>
			<td class="col1"><img src="replace.png" /></td>
			<td>
				<p>The client POSTs a representation of a Product to the Bug Tracker LDPC.</p>
                <pre title="A resquest for creating a product"
					class='example' data-include='product_create_req.txt'
					data-oninclude='fixCode'></pre>	
				<p>If the create is successful, the server responds with location of the newly created resource.</p>
                <pre title="A response after creating new a b"
					class='example' data-include='product_create_res.txt'
					data-oninclude='fixCode'></pre>				
			</td>	
		</tr>
        <tr>
        	<td colspan="2">
        		<p>After creation of this new container, 'Product A', the representation of the 'Tracker' container will be</p>
        		<pre title="The state of the Bug Tracker after the product creation"
					class='example' data-include='product_create_s2.txt'
					data-oninclude='fixCode'></pre>	
				<p>and the 'Product A' will have the following representation.</p>
				<pre title="The state of the new Product"
					class='example' data-include='product_create_s3.txt'
					data-oninclude='fixCode'></pre>		
        	</td>	
        </tr>
	</table>
	
	<h3 id="ProductUpdate">Update a product description</h3>
	<p>If the bug tracker allows updating new product in the tracker, that can done by posting a representation of a new Product to the 
		Bug Tracker container.</p>
	
	</section>
	
	<h3 id="ProductDelete">Delete a product description</h3>
	<p>The bug tracker allows deleting products. TODO</p>
	
	</section>
	
	<section id="advanced-ex">	
	<h2>Advanced scenarios</h2>
	
	   <section id="ldp-membership">
	   <h3>Advanced use of ldp:membershipX predicates</h3>
	   </section>	
	
		<section id="paging">	
		<h3>Pagination</h3>
		</section>
	
		<section id="odering">	
		<h3>Ordering</h3>
		</section>
		
		<section id="inlining">	
		<h3>In-lining</h3>
		</section>
	
		<section id="binary-res">	
		<h3>Handling binary resources</h3>
		
		<h4>Creating a binary resource</h4>
		<table>
		<tr>
			<td colspan="2">
				<p>We have an LDPC which we can use to create binary resources</p>
				<pre title="The state of the attachments LDPC"
					class='example' data-include='attachments_s1.txt'
					data-oninclude='fixCode'></pre>	
			</td>
		</tr>
		<tr>
			<td class="col1"><img src="replace.png" /></td>
			<td>
				<p>The client POSTs POST a binary resource to the LDPC</p>
                <pre title="A resquest for creating a product"
					class='example' data-include='attachments_post_req.txt'
					data-oninclude='fixCode'></pre>	
				<p>If the create is successful, the server it responds with a Location header and a Link header to
					the automatically created metadata LDPR.</p>
                <pre title="A response after creating new a b"
					class='example' data-include='attachments_post_res.txt'
					data-oninclude='fixCode'></pre>				
			</td>	
		</tr>
		<tr>
			<td colspan="2">
				<p>After the creation, LDPC representation looks like</p>
				<pre title="The state of the attachments LDPC after creation"
					class='example' data-include='attachments_s2.txt'
					data-oninclude='fixCode'></pre>	
			</td>
		</tr>
		</table>
		
		<h4>Accessing the binary resource</h4>
		
		<h4>Accessing the metadata about the binary resource</h4>
		
		<h4>Updating the metadata about the binary resource</h4>
		
		<h4>Deleting the binary resource</h4>
		
		</section>
	
	</section>
	
	
	<section>
	<h2 id="ldpc">LDP Implementations</h2>
	A list of implementations that plan to be LDP compliant is available in the LDP Implementations wiki page.
LDP Implementation report provides the coverage of the specification by each LDP implementation.
	</section>
	
	<section class='appendix informative' id="history">
	<h1>Change History</h1>
	<p>The change history is up to the editors to insert a brief summary of
	changes, ordered by most recent changes first and with heading from which
	public draft it has been changed from.
	</p>
	<ul>
		<li>2013-07-03 - Moving the content from the wiki to the note.</li>	
	</ul>
    </section>
  
  </body>
</html>
\ No newline at end of file
--- a/ldp-primer/ldpc_ex.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/ldpc_ex.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -11,4 +11,4 @@
 
 ---
 
-{ 'edwedew': 'edwde' }
\ No newline at end of file
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/ldpc_ex_m.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/ldpc_ex_m.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -4,4 +4,8 @@
 <http://id.nandana.org/friends/roger> a foaf:Person;
     owl:sameAs <http://www.linkedin.com/in/yadnem> ;
     foaf:name "Roger Menday" ;
-    foaf:workplaceHomepage <http://www.fujitsu.com/uk/> .
\ No newline at end of file
+    foaf:workplaceHomepage <http://www.fujitsu.com/uk/> .
+    
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/ldpc_ex_non_ldpr.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/ldpc_ex_non_ldpr.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -7,4 +7,8 @@
 	ldp:membershipSubject <>;
 	ldp:membershipPredicate rdf:member ;
 	ldp:membershipObject ldp:MemberSubject;	
-	rdf:member <sunset.png>, <beach.png>, <park.jpeg> .
\ No newline at end of file
+	rdf:member <sunset.png>, <beach.png>, <park.jpeg> .
+	
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/product_create_req.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/product_create_req.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -5,4 +5,8 @@
  
 <> a ldp:Container, bt:Product;
    dcterms:title "Product A" ; 
-   dcterms:description "A container that tracks bugs of Product A" .  
\ No newline at end of file
+   dcterms:description "A container that tracks bugs of Product A" .  
+   
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/product_create_res.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/product_create_res.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -1,3 +1,7 @@
 HTTP/1.1 201 Created
 Location: http://example.org/app/BugTracker/ProductA
-Content-Length: 0 
\ No newline at end of file
+Content-Length: 0 
+
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/product_create_s1.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/product_create_s1.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -1,3 +1,7 @@
 </app/> a ldp:Container, bt:BugTracker ;
     ldp:membershipPredicate bt:tracksProject .
-    bt:tracksProject </app/product1> .
\ No newline at end of file
+    bt:tracksProject </app/product1> .
+    
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/product_create_s2.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/product_create_s2.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -1,3 +1,7 @@
  </app/> a ldp:Container, bt:BugTracker;
     bt:tracksProject </app/Product1/> ;
-    bt:tracksProject </app/Product2/> .
\ No newline at end of file
+    bt:tracksProject </app/Product2/> .
+    
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/product_create_s3.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/product_create_s3.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -1,3 +1,7 @@
  </app/Product2> a ldp:Container, bt:Product;
    dcterms:title "Product A" ; 
-   dcterms:description "A container that tracks bugs of Product A" .  
\ No newline at end of file
+   dcterms:description "A container that tracks bugs of Product A" .  
+   
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/product_lookup.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/product_lookup.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -9,3 +9,7 @@
       dcterms:title "Product 1" ;
       bt:hasbug </app/product1/bug3> ;
       bt:hasbug </app/product1/bug4> .
+
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/product_lookup_resp.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/product_lookup_resp.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -10,3 +10,7 @@
     dcterms:title "Product 1";
     bt:hasbug </app/product1/bug3>;
     bt:hasbug </app/product1/bug4> .
+
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file
--- a/ldp-primer/product_options_res.txt	Mon Aug 05 22:35:11 2013 +0100
+++ b/ldp-primer/product_options_res.txt	Mon Aug 05 22:50:13 2013 +0100
@@ -4,4 +4,8 @@
 Accept-Patch: example/patch
 Link: <http://www.w3.org/ns/ldp/Resource>; rel="type"
 Link: <?nonMemberProperties>;rel="http://www.w3.org/ns/ldp#nonMemberResource"
-Content-Length: 0
\ No newline at end of file
+Content-Length: 0
+
+---
+
+{ 'needto': 'fill out' }
\ No newline at end of file