--- a/AccessControl.html Tue Aug 26 09:12:16 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,220 +0,0 @@
-<!DOCTYPE html>
-<html>
- <head>
- <title>LDP Access Control</title>
- <!-- Changed by: , 13-Aug-2014 -->
- <meta charset='utf-8'>
- <script src='https://www.w3.org/Tools/respec/respec-w3c-common'
- async class='remove'></script>
- <script class='remove'>
- var respecConfig = {
- // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
- specStatus: "WG-NOTE",
-
- // the specification's short name, as in http://www.w3.org/TR/short-name/
- shortName: "LDP-AC",
-
- // if your specification has a subtitle that goes below the main
- // formal title, define it here
- subtitle : "Usecases and Requirements for Access Control for the Linked Data Platform",
-
- // if you wish the publication date to be other than the last modification, 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: "1977-03-15",
- // previousMaturity: "WD",
-
- // if there a publicly available Editor's Draft, this is the link
- // edDraftURI: "http://berjon.com/",
-
- // if this is a LCWD, uncomment and set the end of its review period
- // lcEnd: "2009-08-05",
-
- // editors, add as many as you like
- // only "name" is required
- editors: [
- {
- name: "Ashok Malhotra"
- , mailto: "ashok.malhotra@oracle.com"
- , company: "Oracle America, Inc."
- , companyURL: "http://www.oracle.com/"
- },
- ],
-
- // name of the WG
- wg: "Linked Data Platform WG",
-
- // URI of the public WG page
- wgURI: "https://www.w3.org/2012/ldp/wiki/Main_Page",
-
- // name (without the @w3c.org) of the public mailing to which comments are due
- wgPublicList: "public-ldp-comments@w3.org",
-
- // 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: "",
- // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
- };
- </script>
- </head>
- <body>
- <section id='abstract'>
- <p>
- This note discusses usecases and requirements for Access Control for the
- <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a>
- It also outlines a charter for developing a standard for HTTP-based access control.
- The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG.
- </p>
- </section>
-
- <section id='sotd'>
- <p>
- While the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> did not
- address Access Control directly, a number of usescases and requirements were identified as part of its
- deliberations. These usecases and requirements are captured in this document to serve as a basis for
- future work.
- </p>
- </section>
-
- <section>
- <h2>Access Control</h2>
- <p>
- Access Control is a mechanism through which an agent ( an HTTP server in this case ) permits other agents --
- individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as
- specified by policies for the resources and for the agents. Within this document, the resources are LDP resources, but the access
- control may operate at different granularities: RDF or other documents, named graphs or individual triples.
- The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
- this design.
- </p>
- <p>
- When an agent requests a collection of resources it gets to see only those resources or parts of resources
- it is authorized for.</p>
- <p>
- Depending on the granularity, the access control mechanisms may affect performance, but should not affect
- semantics.</p>
- <p>
- For access control to come into play, the server must restrict some operations on some resources.
- </p>
- </section>
- <section>
- <h2>Terminology</h2>
- <ul>
- <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
- <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies
- upon to make access control decisions.</li>
- </ul>
- </section>
- <section>
- <h2>Usecases</h2>
- <section>
- <h3>Access Control on manipulation of resources via HTTP</h3>
- Adam's user agent attempts:
- <ol>
- <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL. The server may immediately
- allow or deny the request, or it may request that he authenticate to confirm his privileges,
- as specified by the ACG for the Resource.</li>
- <li>If he is denied access, an explanation of why all or part of his request was denied should be provided
- so that it becomes possible to detect errors, and so that he may modify the request --
- potentially to include making a request for such privileges.
- </li>
- <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource
- before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
- </li>
- <ol>
- </section>
- <section>
- <h3>Editability of Access Control Rules using HTTP</h3>
- <ol>
- <li>
- Bart's user agent logs on to a server and requests
- the capability to read a group of related resources such as all the papers presented at a conference.</li>
- </li>
- <li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
- <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the
- people who attended the conference.</li>
- <ol>
- </section>
- <section>
- <h3>User Interface Scenarios</h3>
- Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to
- <ol>
- <li>Know if he can edit or delete a resource.</li>
- <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have
- paid a fee )</li>
- <li>Allow Eddie to edit the access control rules for a resource such as:
- <ol>
- <li>Allow friends of his to access a document.</li>
- <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container,
- those posted by that agent for example.</li>
- <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a
- specific URL pattern.</li>
- <li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments
- to a container related to some content, and edit their own comments.</li>
- <li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network,
- to work together on set of ontologies. It should be possible to drag and drop URLs for these groups,
- found on the web, onto the User Interface as a way of creating the union of the members of the group.</li>
- </ol>
- </ol>
- </section>
- <section>
- <h2>Requirements</h2>
- <ul>
- <li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token.
- ( All use cases )</li>
- <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description.
- (Usecase 3.2.2, 3.2.3)</li>
- <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
- with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
- <li>Ability to connect a collection of agents with a collection of resources with given access privileges.
- ( All use cases )</li>
- </ul>
-
- <p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs.
-
- <ul>
- <li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
- <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
- <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
- (Usecase 3.1.3)
- </li>
- <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
- <li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
- </ul>
- </section>
- <section>
- <h2>Outline of a Charter for a Access Control WG</h2>
- <p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of
- resources. It then connects a collection of agents with a collection of resources with the connection identifying
- the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
- <p>ACGs are resources in their own right and can have access control priviledges specified for them just like
- any other resource. This permits the creation and modification of ACGs to be delegated.
- </p>
- <p>
- The members of the collection of agents contain tokens that the agents obtain from some authentication service.
- The members of the collection of resources are URIs or URI templates.</p>
- <p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
-<section>
-<h2>Deliverables</h2>
-<ul>
-<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a
-connection of resources.</li>
-<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
-<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed
-efficiently with the ACG structure defined above.</li>
-</ul>
-</section>
- </section>
- </section>
-
-
- </body>
-</html>
--- a/AccessControlRespec.html Tue Aug 26 09:12:16 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,219 +0,0 @@
-<!DOCTYPE html>
-<html>
- <head>
- <title>LDP Access Control</title>
- <meta charset='utf-8'>
- <script src='https://www.w3.org/Tools/respec/respec-w3c-common'
- async class='remove'></script>
- <script class='remove'>
- var respecConfig = {
- // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
- specStatus: "WG-NOTE",
-
- // the specification's short name, as in http://www.w3.org/TR/short-name/
- shortName: "LDP-ACR",
-
- // if your specification has a subtitle that goes below the main
- // formal title, define it here
- subtitle : "Usecases and Requirements for Access Control for the Linked Data Platform",
-
- // if you wish the publication date to be other than the last modification, set this
- publishDate: "2014-08-22",
-
- // 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: "1977-03-15",
- // previousMaturity: "WD",
-
- // if there a publicly available Editor's Draft, this is the link
- // edDraftURI: "http://berjon.com/",
-
- // if this is a LCWD, uncomment and set the end of its review period
- // lcEnd: "2009-08-05",
-
- // editors, add as many as you like
- // only "name" is required
- editors: [
- {
- name: "Ashok Malhotra"
- , mailto: "ashok.malhotra@oracle.com"
- , company: "Oracle America, Inc."
- , companyURL: "http://www.oracle.com/"
- },
- ],
-
- // name of the WG
- wg: "Linked Data Platform WG",
-
- // URI of the public WG page
- wgURI: "https://www.w3.org/2012/ldp/wiki/Main_Page",
-
- // name (without the @w3c.org) of the public mailing to which comments are due
- wgPublicList: "public-ldp-comments@w3.org",
-
- // 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: "",
- // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
- };
- </script>
- </head>
- <body>
- <section id='abstract'>
- <p>
- This note discusses usecases and requirements for Access Control for the
- <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a>
- It also outlines a charter for developing a standard for HTTP-based access control.
- The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG.
- </p>
- </section>
-
- <section id='sotd'>
- <p>
- While the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> did not
- address Access Control directly, a number of usescases and requirements were identified as part of its
- deliberations. These usecases and requirements are captured in this document to serve as a basis for
- future work. This is a First Public Working Draft.
- </p>
- </section>
-
- <section>
- <h2>Access Control</h2>
- <p>
- Access Control is a mechanism through which an agent ( an HTTP server in this case ) permits other agents --
- individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as
- specified by policies for the resources and for the agents. Within this document, the resources are LDP resources, but the access
- control may operate at different granularities: RDF or other documents, named graphs or individual triples.
- The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
- this design.
- </p>
- <p>
- When an agent requests a collection of resources it gets to see only those resources or parts of resources
- it is authorized for.</p>
- <p>
- Depending on the granularity, the access control mechanisms may affect performance, but should not affect
- semantics.</p>
- <p>
- For access control to come into play, the server must restrict some operations on some resources.
- </p>
- </section>
- <section>
- <h2>Terminology</h2>
- <ul>
- <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
- <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies
- upon to make access control decisions.</li>
- </ul>
- </section>
- <section>
- <h2>Usecases</h2>
- <section>
- <h3>Access Control on manipulation of resources via HTTP</h3>
- Adam's user agent attempts:
- <ol>
- <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL. The server may immediately
- allow or deny the request, or it may request that he authenticate to confirm his privileges,
- as specified by the ACG for the Resource.</li>
- <li>If he is denied access, an explanation of why all or part of his request was denied should be provided
- so that it becomes possible to detect errors, and so that he may modify the request --
- potentially to include making a request for such privileges.
- </li>
- <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource
- before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
- </li>
- <ol>
- </section>
- <section>
- <h3>Editability of Access Control Rules using HTTP</h3>
- <ol>
- <li>
- Bart's user agent logs on to a server and requests
- the capability to read a group of related resources such as all the papers presented at a conference.</li>
- </li>
- <li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
- <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the
- people who attended the conference.</li>
- <ol>
- </section>
- <section>
- <h3>User Interface Scenarios</h3>
- Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to
- <ol>
- <li>Know if he can edit or delete a resource.</li>
- <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have
- paid a fee )</li>
- <li>Allow Eddie to edit the access control rules for a resource such as:
- <ol>
- <li>Allow friends of his to access a document.</li>
- <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container,
- those posted by that agent for example.</li>
- <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a
- specific URL pattern.</li>
- <li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments
- to a container related to some content, and edit their own comments.</li>
- <li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network,
- to work together on set of ontologies. It should be possible to drag and drop URLs for these groups,
- found on the web, onto the User Interface as a way of creating the union of the members of the group.</li>
- </ol>
- </ol>
- </section>
- <section>
- <h2>Requirements</h2>
- <ul>
- <li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token.
- ( All use cases )</li>
- <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description.
- (Usecase 3.2.2, 3.2.3)</li>
- <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
- with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
- <li>Ability to connect a collection of agents with a collection of resources with given access privileges.
- ( All use cases )</li>
- </ul>
-
- <p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs.
-
- <ul>
- <li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
- <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
- <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
- (Usecase 3.1.3)
- </li>
- <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
- <li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
- </ul>
- </section>
- <section>
- <h2>Outline of a Charter for a Access Control WG</h2>
- <p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of
- resources. It then connects a collection of agents with a collection of resources with the connection identifying
- the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
- <p>ACGs are resources in their own right and can have access control priviledges specified for them just like
- any other resource. This permits the creation and modification of ACGs to be delegated.
- </p>
- <p>
- The members of the collection of agents contain tokens that the agents obtain from some authentication service.
- The members of the collection of resources are URIs or URI templates.</p>
- <p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
-<section>
-<h2>Deliverables</h2>
-<ul>
-<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a
-connection of resources.</li>
-<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
-<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed
-efficiently with the ACG structure defined above.</li>
-</ul>
-</section>
- </section>
- </section>
-
-
- </body>
-</html>
--- a/LDP Access ControlNoRespec.htm Tue Aug 26 09:12:16 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,406 +0,0 @@
-<!DOCTYPE html>
-<html dir="ltr" typeof="bibo:Document " about="" property="dcterms:language" content="en" lang="en"><head>
-<meta http-equiv="content-type" content="text/html; charset=UTF-8">
- <title>LDP Access Control</title>
- <meta charset="utf-8">
-
-
- <style>/*****************************************************************
- * ReSpec 3 CSS
- * Robin Berjon - http://berjon.com/
- *****************************************************************/
-
-/* --- INLINES --- */
-em.rfc2119 {
- text-transform: lowercase;
- font-variant: small-caps;
- font-style: normal;
- color: #900;
-}
-
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
- border: none;
-}
-
-dfn {
- font-weight: bold;
-}
-
-a.internalDFN {
- color: inherit;
- border-bottom: 1px solid #99c;
- text-decoration: none;
-}
-
-a.externalDFN {
- color: inherit;
- border-bottom: 1px dotted #ccc;
- text-decoration: none;
-}
-
-a.bibref {
- text-decoration: none;
-}
-
-cite .bibref {
- font-style: normal;
-}
-
-code {
- color: #C83500;
-}
-
-/* --- TOC --- */
-.toc a, .tof a {
- text-decoration: none;
-}
-
-a .secno, a .figno {
- color: #000;
-}
-
-ul.tof, ol.tof {
- list-style: none outside none;
-}
-
-.caption {
- margin-top: 0.5em;
- font-style: italic;
-}
-
-/* --- TABLE --- */
-table.simple {
- border-spacing: 0;
- border-collapse: collapse;
- border-bottom: 3px solid #005a9c;
-}
-
-.simple th {
- background: #005a9c;
- color: #fff;
- padding: 3px 5px;
- text-align: left;
-}
-
-.simple th[scope="row"] {
- background: inherit;
- color: inherit;
- border-top: 1px solid #ddd;
-}
-
-.simple td {
- padding: 3px 10px;
- border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
- background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
- margin-top: 0;
-}
-
-.section dd > p:last-child {
- margin-bottom: 0;
-}
-
-.section dd {
- margin-bottom: 1em;
-}
-
-.section dl.attrs dd, .section dl.eldef dd {
- margin-bottom: 0;
-}
-
-@media print {
- .removeOnSave {
- display: none;
- }
-}
-</style><link href="LDP%20Access%20ControlNoRespec_files/W3C-WG-NOTE.css" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
- <body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
- <p>
-
- <a href="http://www.w3.org/"><img src="LDP%20Access%20ControlNoRespec_files/w3c_home.png" alt="W3C" height="48" width="72"></a>
-
- </p>
- <h1 class="title p-name" id="title" property="dcterms:title">LDP Access Control</h1>
-
- <h2 property="bibo:subtitle" id="subtitle">Usecases and Requirements for Access Control for the Linked Data Platform</h2>
-
- <h2 id="w3c-working-group-note-22-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-22T04:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-22">22 August 2014</time></h2>
- <dl>
-
- <dt>This version:</dt>
- <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-LDP-ACR-20140822/">http://www.w3.org/TR/2014/NOTE-LDP-ACR-20140822/</a></dd>
- <dt>Latest published version:</dt>
- <dd><a href="http://www.w3.org/TR/LDP-ACR/">http://www.w3.org/TR/LDP-ACR/</a></dd>
-
-
-
-
-
-
-
-
- <dt>Editor:</dt>
- <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><span property="foaf:name" class="p-name fn">Ashok Malhotra</span>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com/">Oracle America, Inc.</a>, <span class="ed_mailto"><a class="u-email email" rel="foaf:mbox" href="mailto:ashok.malhotra@oracle.com">ashok.malhotra@oracle.com</a></span></span>
-</dd>
-
-
-
- </dl>
-
-
-
-
-
- <p class="copyright">
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
- 2014
-
- <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
- (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
- <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
- <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
-
- All Rights Reserved.
-
- <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
-
- <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
-
- rules apply.
- </p>
-
-
- <hr>
-</div>
- <section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2>
- <p>
- This note discusses usecases and requirements for Access Control for the
- <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a>
- It also outlines a charter for developing a standard for HTTP-based access control.
- The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG.
- </p>
- </section><section rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
-
-
-
- <p>
- <em>This section describes the status of this document at the time of its publication.
- Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
- latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
- http://www.w3.org/TR/.</em>
- </p>
-
- <p>
- While the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> did not
- address Access Control directly, a number of usescases and requirements were identified as part of its
- deliberations. These usecases and requirements are captured in this document to serve as a basis for
- future work. This is a First Public Working Draft.
- </p>
-
- <p>
- This document was published by the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG</a> as a Working Group Note.
-
-
- If you wish to make comments regarding this document, please send them to
- <a href="mailto:public-ldp-comments@w3.org@w3.org">public-ldp-comments@w3.org@w3.org</a>
- (<a href="mailto:public-ldp-comments@w3.org-request@w3.org?subject=subscribe">subscribe</a>,
- <a href="http://lists.w3.org/Archives/Public/public-ldp-comments@w3.org/">archives</a>).
-
-
-
-
- All comments are welcome.
-
- </p>
-
-
- <p>
- Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
- Membership. This is a draft document and may be updated, replaced or obsoleted by other
- documents at any time. It is inappropriate to cite this document as other than work in
- progress.
- </p>
-
-
-
- <p>
-
- This document was produced by a group operating under the
- <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
- Policy</a>.
-
-
-
-
- <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="" rel="disclosure">public list of any patent
- disclosures</a>
-
- made in connection with the deliverables of the group; that page also includes
- instructions for disclosing a patent. An individual who has actual knowledge of a patent
- which the individual believes contains
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
- Claim(s)</a> must disclose the information in accordance with
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
- 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-
-
- </p>
-
- <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
- </p>
-
-
-
-
-
-</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#access-control"><span class="secno">1. </span>Access Control</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">2. </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#usecases"><span class="secno">3. </span>Usecases</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#access-control-on-manipulation-of-resources-via-http"><span class="secno">3.1 </span>Access Control on manipulation of resources via HTTP</a></li><li class="tocline"><a class="tocxref" href="#editability-of-access-control-rules-using-http"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</a></li><li class="tocline"><a class="tocxref" href="#user-interface-scenarios"><span class="secno">3.3 </span>User Interface Scenarios</a></li><li class="tocline"><a class="tocxref" href="#requirements"><span class="secno">3.4 </span>Requirements</a></li><li class="tocline"><a class="tocxref" href="#outline-of-a-charter-for-a-access-control-wg"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#deliverables"><span class="secno">3.5.1 </span>Deliverables</a></li></ul></li></ul></li></ul></section>
-
-
-
- <section id="access-control">
- <!--OddPage--><h2 id="h2_access-control" role="heading" aria-level="1"><span class="secno">1. </span>Access Control</h2>
- <p>
- Access Control is a mechanism through which an agent ( an HTTP
-server in this case ) permits other agents --
- individuals, organizations, and/or groups made up of these -- to
-perform certain operations on resources as
- specified by policies for the resources and for the agents. Within
-this document, the resources are LDP resources, but the access
- control may operate at different granularities: RDF or other
-documents, named graphs or individual triples.
- The operations are typically create, read, update, and delete (CRUD)
-but other operations can easily be accomodated by
- this design.
- </p>
- <p>
- When an agent requests a collection of resources it gets to see only those resources or parts of resources
- it is authorized for.</p>
- <p>
- Depending on the granularity, the access control mechanisms may affect performance, but should not affect
- semantics.</p>
- <p>
- For access control to come into play, the server must restrict some operations on some resources.
- </p>
- </section>
- <section id="terminology">
- <!--OddPage--><h2 id="h2_terminology" role="heading" aria-level="1"><span class="secno">2. </span>Terminology</h2>
- <ul>
- <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
- <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies
- upon to make access control decisions.</li>
- </ul>
- </section>
- <section id="usecases">
- <!--OddPage--><h2 id="h2_usecases" role="heading" aria-level="1"><span class="secno">3. </span>Usecases</h2>
- <section id="access-control-on-manipulation-of-resources-via-http">
- <h3 id="h3_access-control-on-manipulation-of-resources-via-http" role="heading" aria-level="2"><span class="secno">3.1 </span>Access Control on manipulation of resources via HTTP</h3>
- Adam's user agent attempts:
- <ol>
- <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL. The server may immediately
- allow or deny the request, or it may request that he authenticate to confirm his privileges,
- as specified by the ACG for the Resource.</li>
- <li>If he is denied access, an explanation of why all or part of his request was denied should be provided
- so that it becomes possible to detect errors, and so that he may modify the request --
- potentially to include making a request for such privileges.
- </li>
- <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource
- before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
- </li>
- <ol>
- </ol></ol></section>
- <section id="editability-of-access-control-rules-using-http">
- <h3 id="h3_editability-of-access-control-rules-using-http" role="heading" aria-level="2"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</h3>
- <ol>
- <li>
- Bart's user agent logs on to a server and requests
- the capability to read a group of related resources such as all the papers presented at a conference.</li>
-
- <li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
- <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the
- people who attended the conference.</li>
- <ol>
- </ol></ol></section>
- <section id="user-interface-scenarios">
- <h3 id="h3_user-interface-scenarios" role="heading" aria-level="2"><span class="secno">3.3 </span>User Interface Scenarios</h3>
- Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to
- <ol>
- <li>Know if he can edit or delete a resource.</li>
- <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have
- paid a fee )</li>
- <li>Allow Eddie to edit the access control rules for a resource such as:
- <ol>
- <li>Allow friends of his to access a document.</li>
- <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container,
- those posted by that agent for example.</li>
- <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a
- specific URL pattern.</li>
- <li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments
- to a container related to some content, and edit their own comments.</li>
- <li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network,
- to work together on set of ontologies. It should be possible to drag and drop URLs for these groups,
- found on the web, onto the User Interface as a way of creating the union of the members of the group.</li>
- </ol>
- </li></ol>
- </section>
- <section id="requirements">
- <h3 id="h3_requirements" role="heading" aria-level="2"><span class="secno">3.4 </span>Requirements</h3>
- <ul>
- <li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token.
- ( All use cases )</li>
- <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description.
- (Usecase 3.2.2, 3.2.3)</li>
- <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
- with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
- <li>Ability to connect a collection of agents with a collection of resources with given access privileges.
- ( All use cases )</li>
- </ul>
-
- <p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs.
-
- </p><ul>
- <li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
- <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
- <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
- (Usecase 3.1.3)
- </li>
- <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
- <li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
- </ul>
- </section>
- <section id="outline-of-a-charter-for-a-access-control-wg">
- <h3 id="h3_outline-of-a-charter-for-a-access-control-wg" role="heading" aria-level="2"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</h3>
- <p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of
- resources. It then connects a collection of agents with a collection of resources with the connection identifying
- the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
- <p>ACGs are resources in their own right and can have access control priviledges specified for them just like
- any other resource. This permits the creation and modification of ACGs to be delegated.
- </p>
- <p>
- The members of the collection of agents contain tokens that the agents obtain from some authentication service.
- The members of the collection of resources are URIs or URI templates.</p>
- <p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
-<section id="deliverables">
-<h4 id="h4_deliverables" role="heading" aria-level="3"><span class="secno">3.5.1 </span>Deliverables</h4>
-<ul>
-<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a
-connection of resources.</li>
-<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
-<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed
-efficiently with the ACG structure defined above.</li>
-</ul>
-</section>
- </section>
- </section>
-
-
-
-
-</body></html>
\ No newline at end of file
--- a/LDP Access ControlNoRespec_files/W3C-WG-NOTE.css Tue Aug 26 09:12:16 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,89 +0,0 @@
-
-/* Style for a "Working Group Note" */
-
-/*
- Copyright 1997-2003 W3C (MIT, ERCIM, Keio). All Rights Reserved.
- The following software licensing rules apply:
- http://www.w3.org/Consortium/Legal/copyright-software */
-
-/* $Id: base.css,v 1.28 2014-04-22 03:27:49 ijacobs Exp $ */
-
-body {
- padding: 2em 1em 2em 70px;
- margin: 0;
- font-family: sans-serif;
- color: black;
- background: white;
- background-position: top left;
- background-attachment: fixed;
- background-repeat: no-repeat;
-}
-:link { color: #00C; background: transparent }
-:visited { color: #609; background: transparent }
-a:active { color: #C00; background: transparent }
-
-a:link img, a:visited img { border-style: none } /* no border on img links */
-
-a img { color: white; } /* trick to hide the border in Netscape 4 */
-@media all { /* hide the next rule from Netscape 4 */
- a img { color: inherit; } /* undo the color change above */
-}
-
-th, td { /* ns 4 */
- font-family: sans-serif;
-}
-
-h1, h2, h3, h4, h5, h6 { text-align: left }
-/* background should be transparent, but WebTV has a bug */
-h1, h2, h3 { color: #005A9C; background: white }
-h1 { font: 170% sans-serif }
-h2 { font: 140% sans-serif }
-h3 { font: 120% sans-serif }
-h4 { font: bold 100% sans-serif }
-h5 { font: italic 100% sans-serif }
-h6 { font: small-caps 100% sans-serif }
-
-.hide { display: none }
-
-div.head { margin-bottom: 1em }
-div.head h1 { margin-top: 2em; clear: both }
-div.head table { margin-left: 2em; margin-top: 2em }
-
-p.copyright { font-size: small }
-p.copyright small { font-size: small }
-
-@media screen { /* hide from IE3 */
-a[href]:hover { background: #ffa }
-}
-
-pre { margin-left: 2em }
-/*
-p {
- margin-top: 0.6em;
- margin-bottom: 0.6em;
-}
-*/
-dt, dd { margin-top: 0; margin-bottom: 0 } /* opera 3.50 */
-dt { font-weight: bold }
-
-ul.toc, ol.toc {
- list-style: disc; /* Mac NS has problem with 'none' */
- list-style: none;
-}
-
-@media speech {
- h1, h2, h3 { voice-stress: moderate; }
- .hide { speak: none; }
- p.copyright { voice-volume: x-soft; voice-rate: x-fast; }
- dt { pause-before: 63ms; }
-}
-
-
-/* Copyright 1997-2003 W3C (MIT, ERCIM, Keio). All Rights Reserved.
- The following software licensing rules apply:
- http://www.w3.org/Consortium/Legal/copyright-software */
-
-body {
- background-image: url(//www.w3.org/StyleSheets/TR/logo-WG-Note);
-}
-
Binary file LDP Access ControlNoRespec_files/w3c_home.png has changed
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/NOTE-ldp-acr-20140825/Overview.html Tue Aug 26 09:12:41 2014 -0400
@@ -0,0 +1,402 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document " about="" property="dcterms:language" content="en">
+<head>
+ <title>LDP Access Control</title>
+ <!-- Changed by: , 25-Aug-2014 -->
+ <meta charset="utf-8">
+
+
+ <style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+ border: none;
+}
+
+dfn {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: 1px dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+cite .bibref {
+ font-style: normal;
+}
+
+code {
+ color: #C83500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+ text-decoration: none;
+}
+
+a .secno, a .figno {
+ color: #000;
+}
+
+ul.tof, ol.tof {
+ list-style: none outside none;
+}
+
+.caption {
+ margin-top: 0.5em;
+ font-style: italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+ border-spacing: 0;
+ border-collapse: collapse;
+ border-bottom: 3px solid #005a9c;
+}
+
+.simple th {
+ background: #005a9c;
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+}
+
+.simple th[scope="row"] {
+ background: inherit;
+ color: inherit;
+ border-top: 1px solid #ddd;
+}
+
+.simple td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+ background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+ margin-top: 0;
+}
+
+.section dd > p:last-child {
+ margin-bottom: 0;
+}
+
+.section dd {
+ margin-bottom: 1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+
+@media print {
+ .removeOnSave {
+ display: none;
+ }
+}
+</style><link href="https://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+ <body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
+ <p>
+
+ <a href="http://www.w3.org/"><img src="https://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a>
+
+ </p>
+ <h1 class="title p-name" id="title" property="dcterms:title">LDP Access Control</h1>
+
+ <h2 property="bibo:subtitle" id="subtitle">Usecases and Requirements for Access Control for the Linked Data Platform</h2>
+
+ <h2 id="w3c-working-group-note-25-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-25T19:14:30.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-25">25 August 2014</time></h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-acr-20140825/">http://www.w3.org/TR/2014/NOTE-ldp-acr-20140825/</a></dd>
+ <dt>Latest published version:</dt>
+ <dd><a href="http://www.w3.org/TR/ldp-acr/">http://www.w3.org/TR/ldp-acr/</a></dd>
+
+ <dt>Latest editor's draft:</dt>
+ <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-acr.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-acr.html</a></dd>
+
+
+
+
+
+
+
+ <dt>Editor:</dt>
+ <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><span property="foaf:name" class="p-name fn">Ashok Malhotra</span>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com/">Oracle America, Inc.</a>, <span class="ed_mailto"><a class="u-email email" rel="foaf:mbox" href="mailto:ashok.malhotra@oracle.com">ashok.malhotra@oracle.com</a></span></span>
+</dd>
+
+
+
+ </dl>
+
+
+
+
+
+ <p class="copyright">
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+ 2014
+
+ <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+ (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+ <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+ <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
+
+ All Rights Reserved.
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+
+ <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+
+ rules apply.
+ </p>
+
+
+ <hr>
+</div>
+ <section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2>
+ <p>
+ This note discusses usecases and requirements for Access Control for the
+ <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a>
+ It also outlines a charter for developing a standard for HTTP-based access control.
+ The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG.
+ </p>
+ </section><section rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
+
+
+
+ <p>
+ <em>This section describes the status of this document at the time of its publication.
+ Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
+ latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
+ http://www.w3.org/TR/.</em>
+ </p>
+
+ <p>
+ While the <a href="http://www.w3.org/2012/ldp">Linked Data Platform WG.</a> did not
+ address Access Control directly, a number of usescases and requirements were identified as part of its
+ deliberations. These usecases and requirements are captured in this document to serve as a basis for
+ future work.
+ </p>
+
+ <p>
+ This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform WG</a> as a Working Group Note.
+
+
+ If you wish to make comments regarding this document, please send them to
+ <a href="mailto:public-ldp-comments@w3.org@w3.org">public-ldp-comments@w3.org@w3.org</a>
+ (<a href="mailto:public-ldp-comments@w3.org-request@w3.org?subject=subscribe">subscribe</a>,
+ <a href="http://lists.w3.org/Archives/Public/public-ldp-comments@w3.org/">archives</a>).
+
+
+
+
+ All comments are welcome.
+
+ </p>
+
+
+ <p>
+ Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
+ Membership. This is a draft document and may be updated, replaced or obsoleted by other
+ documents at any time. It is inappropriate to cite this document as other than work in
+ progress.
+ </p>
+
+
+
+ <p>
+
+ This document was produced by a group operating under the
+ <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
+ Policy</a>.
+
+
+
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
+ disclosures</a>
+
+ made in connection with the deliverables of the group; that page also includes
+ instructions for disclosing a patent. An individual who has actual knowledge of a patent
+ which the individual believes contains
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
+ Claim(s)</a> must disclose the information in accordance with
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+ 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+
+
+ </p>
+
+ <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
+ </p>
+
+
+
+
+
+</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#access-control"><span class="secno">1. </span>Access Control</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">2. </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#usecases"><span class="secno">3. </span>Usecases</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#access-control-on-manipulation-of-resources-via-http"><span class="secno">3.1 </span>Access Control on manipulation of resources via HTTP</a></li><li class="tocline"><a class="tocxref" href="#editability-of-access-control-rules-using-http"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</a></li><li class="tocline"><a class="tocxref" href="#user-interface-scenarios"><span class="secno">3.3 </span>User Interface Scenarios</a></li><li class="tocline"><a class="tocxref" href="#requirements"><span class="secno">3.4 </span>Requirements</a></li><li class="tocline"><a class="tocxref" href="#outline-of-a-charter-for-a-access-control-wg"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#deliverables"><span class="secno">3.5.1 </span>Deliverables</a></li></ul></li></ul></li></ul></section>
+
+
+
+ <section id="access-control">
+ <!--OddPage--><h2 id="h2_access-control" role="heading" aria-level="1"><span class="secno">1. </span>Access Control</h2>
+ <p>
+ Access Control is a mechanism through which an agent ( an HTTP server in this case ) permits other agents --
+ individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as
+ specified by policies for the resources and for the agents. Within this document, the resources are LDP resources, but the access
+ control may operate at different granularities: RDF or other documents, named graphs or individual triples.
+ The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
+ this design.
+ </p>
+ <p>
+ When an agent requests a collection of resources it gets to see only those resources or parts of resources
+ it is authorized for.</p>
+ <p>
+ Depending on the granularity, the access control mechanisms may affect performance, but should not affect
+ semantics.</p>
+ <p>
+ For access control to come into play, the server must restrict some operations on some resources.
+ </p>
+ </section>
+ <section id="terminology">
+ <!--OddPage--><h2 id="h2_terminology" role="heading" aria-level="1"><span class="secno">2. </span>Terminology</h2>
+ <ul>
+ <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
+ <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies
+ upon to make access control decisions.</li>
+ </ul>
+ </section>
+ <section id="usecases">
+ <!--OddPage--><h2 id="h2_usecases" role="heading" aria-level="1"><span class="secno">3. </span>Usecases</h2>
+ <section id="access-control-on-manipulation-of-resources-via-http">
+ <h3 id="h3_access-control-on-manipulation-of-resources-via-http" role="heading" aria-level="2"><span class="secno">3.1 </span>Access Control on manipulation of resources via HTTP</h3>
+ Adam's user agent attempts:
+ <ol>
+ <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL. The server may immediately
+ allow or deny the request, or it may request that he authenticate to confirm his privileges,
+ as specified by the ACG for the Resource.</li>
+ <li>If he is denied access, an explanation of why all or part of his request was denied should be provided
+ so that it becomes possible to detect errors, and so that he may modify the request --
+ potentially to include making a request for such privileges.
+ </li>
+ <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource
+ before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
+ </li>
+ </ol></section>
+ <section id="editability-of-access-control-rules-using-http">
+ <h3 id="h3_editability-of-access-control-rules-using-http" role="heading" aria-level="2"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</h3>
+ <ol>
+ <li>
+ Bart's user agent logs on to a server and requests
+ the capability to read a group of related resources such as all the papers presented at a conference.</li>
+
+ <li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
+ <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the
+ people who attended the conference.</li>
+ </ol></section>
+ <section id="user-interface-scenarios">
+ <h3 id="h3_user-interface-scenarios" role="heading" aria-level="2"><span class="secno">3.3 </span>User Interface Scenarios</h3>
+ Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to
+ <ol>
+ <li>Know if he can edit or delete a resource.</li>
+ <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have
+ paid a fee )</li>
+ <li>Allow Eddie to edit the access control rules for a resource such as:
+ <ol>
+ <li>Allow friends of his to access a document.</li>
+ <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container,
+ those posted by that agent for example.</li>
+ <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a
+ specific URL pattern.</li>
+ <li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments
+ to a container related to some content, and edit their own comments.</li>
+ <li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network,
+ to work together on set of ontologies. It should be possible to drag and drop URLs for these groups,
+ found on the web, onto the User Interface as a way of creating the union of the members of the group.</li>
+ </ol>
+ </li></ol>
+ </section>
+ <section id="requirements">
+ <h3 id="h3_requirements" role="heading" aria-level="2"><span class="secno">3.4 </span>Requirements</h3>
+ <ul>
+ <li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token.
+ ( All use cases )</li>
+ <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description.
+ (Usecase 3.2.2, 3.2.3)</li>
+ <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
+ with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
+ <li>Ability to connect a collection of agents with a collection of resources with given access privileges.
+ ( All use cases )</li>
+ </ul>
+
+ <p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs.
+
+ </p><ul>
+ <li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
+ <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
+ <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
+ (Usecase 3.1.3)
+ </li>
+ <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
+ <li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
+ </ul>
+ </section>
+ <section id="outline-of-a-charter-for-a-access-control-wg">
+ <h3 id="h3_outline-of-a-charter-for-a-access-control-wg" role="heading" aria-level="2"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</h3>
+ <p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of
+ resources. It then connects a collection of agents with a collection of resources with the connection identifying
+ the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
+ <p>ACGs are resources in their own right and can have access control priviledges specified for them just like
+ any other resource. This permits the creation and modification of ACGs to be delegated.
+ </p>
+ <p>
+ The members of the collection of agents contain tokens that the agents obtain from some authentication service.
+ The members of the collection of resources are URIs or URI templates.</p>
+ <p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
+<section id="deliverables">
+<h4 id="h4_deliverables" role="heading" aria-level="3"><span class="secno">3.5.1 </span>Deliverables</h4>
+<ul>
+<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a
+connection of resources.</li>
+<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
+<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed
+efficiently with the ACG structure defined above.</li>
+</ul>
+</section>
+ </section>
+ </section>
+
+
+
+
+</body></html>
\ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/NOTE-ldp-bp-20140829/Overview.html Tue Aug 26 09:12:41 2014 -0400
@@ -0,0 +1,1215 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document w3p:NOTE" about="" property="dcterms:language" content="en">
+<head>
+<title>Linked Data Platform Best Practices and Guidelines</title>
+<!-- Changed by: , 25-Aug-2014 -->
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+<!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+<!-- script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script -->
+
+
+
+
+
+<style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+ border: none;
+}
+
+dfn {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: 1px dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+cite .bibref {
+ font-style: normal;
+}
+
+code {
+ color: #C83500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+ text-decoration: none;
+}
+
+a .secno, a .figno {
+ color: #000;
+}
+
+ul.tof, ol.tof {
+ list-style: none outside none;
+}
+
+.caption {
+ margin-top: 0.5em;
+ font-style: italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+ border-spacing: 0;
+ border-collapse: collapse;
+ border-bottom: 3px solid #005a9c;
+}
+
+.simple th {
+ background: #005a9c;
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+}
+
+.simple th[scope="row"] {
+ background: inherit;
+ color: inherit;
+ border-top: 1px solid #ddd;
+}
+
+.simple td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+ background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+ margin-top: 0;
+}
+
+.section dd > p:last-child {
+ margin-bottom: 0;
+}
+
+.section dd {
+ margin-bottom: 1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+
+@media print {
+ .removeOnSave {
+ display: none;
+ }
+}
+</style><style>/* --- EXAMPLES --- */
+div.example-title {
+ min-width: 7.5em;
+ color: #b9ab2d;
+}
+div.example-title span {
+ text-transform: uppercase;
+}
+aside.example, div.example, div.illegal-example {
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+}
+div.illegal-example { color: red }
+div.illegal-example p { color: black }
+aside.example, div.example {
+ padding: .5em;
+ border-left-width: .5em;
+ border-left-style: solid;
+ border-color: #e0cb52;
+ background: #fcfaee;
+}
+
+aside.example div.example {
+ border-left-width: .1em;
+ border-color: #999;
+ background: #fff;
+}
+aside.example div.example div.example-title {
+ color: #999;
+}
+</style><link href="https://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+
+
+
+<body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
+ <p>
+
+ <a href="http://www.w3.org/"><img src="https://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a>
+
+ </p>
+ <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Best Practices and Guidelines</h1>
+
+ <h2 id="w3c-working-group-note-29-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-29T07:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-29">29 August 2014</time></h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/">http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/</a></dd>
+ <dt>Latest published version:</dt>
+ <dd><a href="http://www.w3.org/TR/ldp-bp/">http://www.w3.org/TR/ldp-bp/</a></dd>
+
+
+ <dt>Latest editor's draft:</dt>
+ <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html</a></dd>
+
+
+
+
+
+
+
+ <dt>Editors:</dt>
+ <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Cody Burleson" href="http://codyburleson.com/">Cody Burleson</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://base22.com/">Base22</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Miguel Esteban Gutiérrez" href="http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/phdstudents/27-mesteban">Miguel Esteban Gutiérrez</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Nandana Mihindukulasooriya" href="http://www.nandana.org/">Nandana Mihindukulasooriya</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
+</dd>
+
+
+
+ </dl>
+
+
+
+
+
+ <p class="copyright">
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+ 2014
+
+ <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+ (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+ <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+ <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
+
+ All Rights Reserved.
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+
+ <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+
+ rules apply.
+ </p>
+
+
+ <hr>
+</div>
+
+ <section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2><p>This document provides best practices
+ and guidelines for implementing Linked Data Platform [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] servers
+ and clients.</p></section><section rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
+
+
+
+ <p>
+ <em>This section describes the status of this document at the time of its publication.
+ Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
+ latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
+ http://www.w3.org/TR/.</em>
+ </p>
+
+
+
+ <p>
+ This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Working Group Note.
+
+
+ If you wish to make comments regarding this document, please send them to
+ <a href="mailto:public-ldp@w3.org">public-ldp@w3.org</a>
+ (<a href="mailto:public-ldp-request@w3.org?subject=subscribe">subscribe</a>,
+ <a href="http://lists.w3.org/Archives/Public/public-ldp/">archives</a>).
+
+
+
+
+ All comments are welcome.
+
+ </p>
+
+
+ <p>
+ Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
+ Membership. This is a draft document and may be updated, replaced or obsoleted by other
+ documents at any time. It is inappropriate to cite this document as other than work in
+ progress.
+ </p>
+
+
+
+ <p>
+
+ This document was produced by a group operating under the
+ <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
+ Policy</a>.
+
+
+
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
+ disclosures</a>
+
+ made in connection with the deliverables of the group; that page also includes
+ instructions for disclosing a patent. An individual who has actual knowledge of a patent
+ which the individual believes contains
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
+ Claim(s)</a> must disclose the information in accordance with
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+ 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+
+
+ </p>
+
+ <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
+ </p>
+
+
+
+
+
+</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#intro"><span class="secno">1. </span>About this Document</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#impetus"><span class="secno">1.1 </span>Impetus</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">1.2 </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#prerequisites-and-assumptions"><span class="secno">1.3 </span>Prerequisites and Assumptions</a></li></ul></li><li class="tocline"><a class="tocxref" href="#best-practices"><span class="secno">2. </span>Best Practices</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#predicate-uris-should-be-http-urls"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</a></li><li class="tocline"><a class="tocxref" href="#use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
+ concept of type in LDPRs</a></li><li class="tocline"><a class="tocxref" href="#use-relative-uris"><span class="secno">2.3 </span>Use relative URIs</a></li><li class="tocline"><a class="tocxref" href="#avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</a></li><li class="tocline"><a class="tocxref" href="#represent-container-membership-with-hierarchical-uris"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</a></li><li class="tocline"><a class="tocxref" href="#include-a-trailing-slash-in-container-uris"><span class="secno">2.6 </span>Include a trailing slash in container URIs</a></li><li class="tocline"><a class="tocxref" href="#use-fragments-as-relative-identifiers"><span class="secno">2.7 </span>Use fragments as relative identifiers</a></li><li class="tocline"><a class="tocxref" href="#prefer-standard-datatypes"><span class="secno">2.8 </span>Prefer standard datatypes</a></li><li class="tocline"><a class="tocxref" href="#re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
+ (re-)inventing duplicates</a></li><li class="tocline"><a class="tocxref" href="#use-qvalues-properly"><span class="secno">2.10 </span>Use qvalues properly</a></li><li class="tocline"><a class="tocxref" href="#respond-with-primary-urls-and-use-them-for-identity-comparison"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</a></li><li class="tocline"><a class="tocxref" href="#representing-relationships-between-resources"><span class="secno">2.12 </span>Representing relationships between resources</a></li><li class="tocline"><a class="tocxref" href="#minimize-server-specific-constraints"><span class="secno">2.13 </span>Minimize server-specific constraints</a></li></ul></li><li class="tocline"><a class="tocxref" href="#guidelines"><span class="secno">3. </span>Guidelines</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#containers-are-not-limited-to-membership-and-containment-triples"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</a></li><li class="tocline"><a class="tocxref" href="#finding-established-vocabularies"><span class="secno">3.2 </span>Finding established vocabularies</a></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">B.1 </span>Informative references</a></li></ul></li></ul></section>
+
+
+
+
+ <section rel="bibo:Chapter" resource="#intro" typeof="bibo:Chapter" id="intro">
+
+ <!--OddPage--><h2 id="h2_intro" role="heading" aria-level="1"><span class="secno">1. </span>About this Document</h2>
+
+ <section id="impetus">
+
+ <h3 id="h3_impetus" role="heading" aria-level="2"><span class="secno">1.1 </span>Impetus</h3>
+
+ <p>While writing the Linked Data Platform Specification, the
+ authors and contributors felt compelled to share common conventions
+ and valuable lessons-learned. Yet, at the same time, they did not
+ wish to impose or imply unnecessary restrictions, or to make the
+ formal specification unnecessarily verbose. This document, along
+ with the LDP Primer [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>], was therefore developed to
+ provide additional context. Drawing upon the professional
+ experiences of its authors and contributors, research into the rich
+ history of related technologies, and continuous feedback from the
+ community at large, it aims to help system implementers avoid common
+ pitfalls, improve quality, and achieve greater interoperability with
+ other Linked Data systems.</p>
+
+ </section>
+
+ <section id="terminology">
+
+ <h3 id="h3_terminology" role="heading" aria-level="2"><span class="secno">1.2 </span>Terminology</h3>
+
+ <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'. We define and differentiate
+ the terms as follows:</p>
+
+ <dl>
+ <dt>best practice</dt>
+ <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 LDP servers and
+ clients are implemented as well as how certain resources 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 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 in Linked Data Platform 1.0
+ [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] as well as the Linked Data Glossary [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] for
+ definitions to a variety of terms used in this document and related
+ to the Linked Data sphere of knowledge.</p>
+
+ </section>
+
+ <section id="prerequisites-and-assumptions">
+
+ <h3 id="h3_prerequisites-and-assumptions" role="heading" aria-level="2"><span class="secno">1.3 </span>Prerequisites and Assumptions</h3>
+
+ <p>
+ Implementers should have at least a general familiarity with the <a href="#informative-references">informative references</a> cited in
+ this document - especially the following:
+ </p>
+
+ <ul>
+ <li><strong>RDF Vocabulary Description Language 1.0: RDF Schema</strong>
+ [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] - The Resource Description Framework
+ (RDF) is a general-purpose language for representing information in
+ the Web and it is the defacto language for expressing Linked Data.
+ This specification describes how to use RDF to describe RDF
+ vocabularies.</li>
+ <li><strong>RDF Primer 1.1</strong> [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] - This Primer is designed to
+ provide the reader with the basic knowledge required to effectively
+ use RDF. It introduces the basic concepts of RDF and describes its
+ XML syntax. It describes how to define RDF vocabularies using the
+ RDF Vocabulary Description Language, and gives an overview of some
+ deployed RDF applications. It also describes the content and
+ purpose of other RDF specification documents.</li>
+ <li><strong>Turtle - Terse RDF Triple Language</strong>
+ [<cite><a href="#bib-TURTLE" class="bibref">TURTLE</a></cite>] - defines a textual syntax for RDF called Turtle that
+ allows RDF graphs to be completely written in a compact and natural
+ text form, with abbreviations for common usage patterns and
+ datatypes. RDF examples used in this document are expressed in
+ Turtle.</li>
+ <li><strong>Linked Data Glossary</strong> [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] - a
+ useful glossary containing terms defined and used to describe
+ Linked Data, and its associated vocabularies and best practices for
+ publishing structured data on the Web.</li>
+ <li><strong>Linked Data Platform 1.0</strong> [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] - the
+ formal specification for the LDP read-write Linked Data
+ architecture, based on HTTP access to web resources that describe
+ their state using the RDF data model.
+ </li><li><strong>Linked Data Platform 1.0 Test Cases</strong>
+ [<cite><a href="#bib-LDP-TESTS" class="bibref">LDP-TESTS</a></cite>] - a standard set of tests provided by the <abbr title="World Wide Web Consortium">W3C</abbr>, which
+ can be use to verify an implementation's conformance to the LDP
+ specification.</li>
+ <li><strong>Linked Data Platform Primer</strong> [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>]
+ - an introduction to LDP, which describes the basic concepts of LDP
+ such as Linked Data Platform Resources (LDPRs), Linked Data
+ Platform Containers (LDPCs), and their affordances. The Primer
+ provides a running example illustrating how an LDP client can
+ interact with an LDP server in the context of a read-write Linked
+ Data application (i.e. how to use HTTP for accessing, updating,
+ creating and deleting resources from servers that expose their
+ resources as Linked Data).</li>
+ <li><strong>Linked Data Platform Use Cases and
+ Requirements</strong> [<cite><a href="#bib-LDP-UCR" class="bibref">LDP-UCR</a></cite>] - a set of user stories, use cases,
+ scenarios and requirements that motivate a simple read-write Linked
+ Data architecture, based on HTTP access to web resources that
+ describe their state using RDF.</li>
+ </ul>
+
+ </section>
+
+ </section>
+
+ <section id="best-practices">
+
+ <!--OddPage--><h2 id="h2_best-practices" role="heading" aria-level="1"><span class="secno">2. </span>Best Practices</h2>
+
+ <section id="predicate-uris-should-be-http-urls">
+
+ <h3 id="h3_predicate-uris-should-be-http-urls" role="heading" aria-level="2"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</h3>
+
+ <p>URIs are used to uniquely identify resources and URLs are used
+ to locate resources on the Web. That is to say that a URL is
+ expected to resolve to an actual resource, which can be retrieved
+ from the host. A URI, on the other hand, may also be a URL, but it
+ does not have to be; it may refer to something that has no
+ retrievable representation.</p>
+
+ <p>One of the fundamental ideas behind Linked Data is that the
+ things referred to by HTTP URIs can actually be looked up
+ ("dereferenced"). This important principle was originally
+ outlined by Tim Berners-Lee as rule #2 of "the four rules"
+ for linking data [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>]. It is therefore ideal that predicate
+ URIs identify resources with representations that are retrievable. LDP
+ servers should at least provide [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] representations of
+ these predicates where possible.</p>
+
+ <p>Of course, it is also a common practice to reuse properties
+ 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
+ practice as a benchmark for which to judge the efficacy of a
+ vocabulary's use for linking data.</p>
+
+ </section>
+
+ <section id="use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs">
+
+ <h3 id="h3_use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs" role="heading" aria-level="2"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
+ concept of type in LDPRs</h3>
+
+ <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 data more useful in the broadest context,
+ type should be explicitly defined using the <code>rdf:type</code>
+ predicate defined by [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>].
+ </p>
+
+ <p>This provides a way for clients to easily determine the type(s)
+ of a resource without having to perform additional processing or
+ make additional HTTP requests. For example, clients that cannot
+ infer the type because they do not support inferencing can benefit
+ from this explicit declaration.</p>
+
+ <div class="example"><div class="example-title"><span>Example 1</span>: Representation of an LDPR with explicit declaration of rdf:type</div><pre class="example">@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+@prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#>.
+
+<http://www.w3.org/People/EM/contact#me>
+ a contact:Person;
+ contact:fullName "Eric Miller";
+ contact:mailbox <mailto:em@w3.org>;
+ contact:personalTitle "Dr.".</pre></div>
+
+ <p>The token 'a' in the predicate position of a Turtle triple represents the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#type.
+ In the example above, therefore, <code>a contact:Person</code> is the same as <code>rdf:type contact:Person</code> or the fully-qualified form, <code><http://www.w3.org/1999/02/22-rdf-syntax-ns#type> contact:Person</code>.</p>
+
+ </section>
+
+ <section id="use-relative-uris">
+
+ <h3 id="h3_use-relative-uris" role="heading" aria-level="2"><span class="secno">2.3 </span>Use relative URIs</h3>
+
+ <!-- http://www.w3.org/2012/ldp/track/issues/29 -->
+
+ <p>Relative URIs are useful to the Linked Data Platform in much
+ the same ways that relative URLs [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>] have been useful to
+ traditional web systems. Since the things referred to by Linked Data
+ URIs should provide a retrievable representation [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>], 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 LDP Container model promotes
+ hierarchical representations.</p>
+
+ <p>Implementers should therefore align the function of relative
+ URIs in LDP with those of traditional relative URLs where possible
+ and appropriate. Aside from giving developers the comfort and
+ convenience of familiarity, they provide many of the same
+ advantages.</p>
+
+ <dl>
+ <dt>Relative URIs are shorter than absolute URIs.</dt>
+ <dd>
+ <p>In many cases, this can aid development by making code and
+ RDF easier for humans to read. It can also reduce the size of
+ payloads, which in turn, can reduce network traffic and stress on
+ servers, while improving response times for end-users.</p>
+
+ <div class="example"><div class="example-title"><span>Example 2</span>: Representation of http://example.org/container1/ with absolute URIs</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1/>
+ a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains
+ <http://example.org/container1/member1>,
+ <http://example.org/container1/member2>,
+ <http://example.org/container1/member3>.</pre></div>
+
+
+ <div class="example"><div class="example-title"><span>Example 3</span>: Representation of http://example.org/container1/ with relative URIs</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<> a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains <member1>, <member2>, <member3> .</pre></div>
+
+ </dd>
+
+ <dt>Relative URIs can make resources more portable.</dt>
+ <dd>When information which is already known from the context of
+ the base resource's retrieval is omitted, there can be less
+ information to modify when its location changes. This can make
+ copying resources to new servers or to a new position in a
+ containment hierarchy easier; in the preceding example,
+ a process that clones just the container need not adjust any of
+ its member URIs.
+ </dd>
+
+ <dt>Relative URIs are convenient during development.</dt>
+ <dd>During development the scheme and network location
+ information in a URI may either be unknown or likely to change. The
+ commonly used 'localhost' for example, is better expressed by the
+ server name or a domain name. Developers often experience less
+ hassle by omitting this information. Additionally, the hierarchy
+ implied by a relative URI may be mimicked in a server file system,
+ which can help developers find and work with information, even when
+ the server isn't running.</dd>
+
+ <dt>Relative URIs support arbitrary, machine-generated URIs.</dt>
+ <dd>
+ RESTful URLs are often defined by a pattern of hierarchical
+ 'collections', which clients interact with in very logical ways.
+ For example, when creating a new resource the client does not
+ typically know the name of the resource until after a successful
+ POST to a collection's URL. A POST to
+ <code>/people/</code>
+ for example, may create the resource
+ <code>/people/1</code>
+ . LDP Containers are such collections whose URIs can benefit from
+ the same model, which in some implementations, may actually be
+ crucial.
+ </dd>
+ </dl>
+ </section>
+
+ <section id="avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution">
+ <h3 id="h3_avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution" role="heading" aria-level="2"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</h3>
+
+ <p>The semantics of dot-segments (eg. <code>../</code>) within relative URIs may be implied by other
+ specifications and by common historical use, but in the case of LDP, additional consideration is required.</p>
+
+ <p>The LDP specification states that... </p><blockquote>LDP servers <em title="MUST" class="rfc2119">MUST</em> assign the default base-URI for [<cite><a href="#bib-RFC3987" class="bibref">RFC3987</a></cite>] relative-URI resolution
+ to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation
+ of a new resource.</blockquote> It follows from this definition that use of <code>../</code> and other non-null relative URI constructs during
+ POST can cause the posted content to be referring to resources in a manner the client might not be able to predict.
+ Dot-segments should therefore be avoided unless the client knows specifically what can be expected of the given implementation
+ and/or deployment.<p></p>
+ </section>
+
+
+ <section id="represent-container-membership-with-hierarchical-uris">
+
+ <h3 id="h3_represent-container-membership-with-hierarchical-uris" role="heading" aria-level="2"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</h3>
+
+ <p>Hierarchical URIs are good for containers because they enable
+ the use of relative URIs. They also promote easy interaction with
+ resources that are modeled to represent parent-child relationships
+ where the child logically belongs to the parent.</p>
+
+ <p>
+ One example of such a model can be found in the case of the
+ <code>oslc_cm:attachment</code>
+ 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 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>
+ container. The URI for such a container might be represented as
+ follows:
+ </p>
+
+ <p>
+ <code>http://example.org/bugs/2314/attachments/</code>
+ </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>In addition to making the use of relative URIs possible,
+ hierarchical URIs make interacting with resources easier for users because
+ they represent the actual structure of the underlying graph.
+ Software agents (code acting on behalf of users [<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>]) must be careful
+ before exploiting the structure of URIs, considering historical problems
+ when doing so ([<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>], [<cite><a href="#bib-metaDataInURI" class="bibref">metaDataInURI</a></cite>]).
+ </p>
+
+ </section>
+
+
+ <section id="include-a-trailing-slash-in-container-uris">
+
+ <!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
+
+ <h3 id="h3_include-a-trailing-slash-in-container-uris" role="heading" aria-level="2"><span class="secno">2.6 </span>Include a trailing slash in container URIs</h3>
+
+ <p>When representing container membership with hierarchical URLs,
+ including the trailing slash in a container's URI makes it
+ easier to use relative URIs.
+ Take the following container URI for example:</p>
+
+ <p>
+ <code>http://example.org/container1</code>
+ </p>
+
+ <p>It is more advantageous to use the following instead:</p>
+
+ <p>
+ <code>http://example.org/container1/</code>
+ </p>
+
+ <p>To illustrate the advantage, let's start with the following
+ container using absolute URIs:</p>
+
+ <div class="example"><div class="example-title"><span>Example 4</span>: A simple container</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1>
+ a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains
+ <http://example.org/container1/member1>,
+ <http://example.org/container1/member2>,
+ <http://example.org/container1/member3>.</pre></div>
+
+ <p>Suppose now that we wish to reflect the same resource using
+ relative URIs. If the URI of the container includes the trailing
+ slash, we end up with a very elegant representation, as shown below.</p>
+
+ <div class="example"><div class="example-title"><span>Example 5</span>: Container URI is http://example.org/container1/</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<> a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains <member1>, <member2>, <member3> .</pre></div>
+
+ <p>But suppose that we omit the trailing slash, issued an HTTP
+ GET, and the container returned the representation shown above. This
+ could produce a graph that is equivalent to the following:</p>
+
+ <div class="example"><div class="example-title"><span>Example 6</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1>
+ a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains
+ <http://example.org/member1>,
+ <http://example.org/member2>,
+ <http://example.org/member3>.</pre></div>
+
+ <p>That is not what was intended; the member URLs lack the
+ <code>container</code> path segment.
+ The returned document would
+ have to be more verbose in order to be correct:</p>
+
+ <div class="example"><div class="example-title"><span>Example 7</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<> a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains <container1/member1>, <container1/member2>, <container1/member3> .</pre></div>
+
+ <p>So, clearly, the better solution is to ensure that container
+ URIs end with a trailing slash.</p>
+
+ </section>
+
+
+ <section id="use-fragments-as-relative-identifiers">
+
+ <h3 id="h3_use-fragments-as-relative-identifiers" role="heading" aria-level="2"><span class="secno">2.7 </span>Use fragments as relative identifiers</h3>
+
+ <p>
+ Resource URIs are permitted to end with a fragment; the fragment
+ component is delimited from the rest of the URI because it is
+ introduced by a hash mark (<b><code>#</code></b>).
+ For this reason, URIs with non-empty fragments are often called hash URIs;
+ a hash URI identifies a subordinate or related resource [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>].
+ </p>
+
+ <p>
+ Take the URI,
+ <code>http://www.example.org/products#item10245</code>
+ , for example. The non-fragment portion of the URI is the part preceding the hash mark,
+ <code>http://www.example.org/products</code>
+ , and the fragment identifier is the part that follows,
+ <code>item10245</code>
+ .
+ </p>
+
+ <p>When expressing Linked Data Platform Resources in RDF,
+ fragments are useful because they can be expressed as relative URIs
+ on the document describing them. This is particularly handy for
+ describing multiple LDPRs whose representations are contained within
+ a single document.</p>
+
+ <p>
+ First, it provides the convenience and efficiency of brevity.
+ Suppose, for example, the resources foo, bar, and baz 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>
+ and
+ <code><#baz></code>
+ ). [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] ensures that the default base URI is the document
+ URI (
+ <code>http://www.example.org/products</code>
+ ), so the absolute URI for each is
+ the base URI, plus the hash mark,
+ plus the fragment identifier.
+ </p>
+
+
+ <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 multiple
+ documents would have to be published, perhaps also including the
+ setup of 303 redirects.</p>
+
+ <p>
+ <strong>See also:</strong>
+ </p>
+
+ <p>
+ <a href="http://www.w3.org/TR/cooluris">Cool URIs for the
+ Semantic Web</a>
+ </p><ul>
+ <li><a href="http://www.w3.org/TR/cooluris/#hashuri">http://www.w3.org/TR/cooluris/#hashuri</a></li>
+ <li><a href="http://www.w3.org/TR/cooluris/#choosing">http://www.w3.org/TR/cooluris/#choosing</a></li>
+ </ul>
+ <p></p>
+
+ <p>
+ <a href="http://www.w3.org/DesignIssues/Fragment.html">Axioms of
+ Web Architecture, URI References: Fragment Identifiers on URIs</a><br>
+ http://www.w3.org/DesignIssues/Fragment.html
+ </p>
+
+ <p>
+ <a href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">Dereferencing
+ HTTP URIs</a><br>
+ http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
+ </p>
+
+ </section>
+
+
+ <section id="prefer-standard-datatypes">
+ <h3 id="h3_prefer-standard-datatypes" role="heading" aria-level="2"><span class="secno">2.8 </span>Prefer standard datatypes</h3>
+
+ <p>LDPR representations should use only the following standard
+ datatypes. RDF does not by itself define datatypes to be used for
+ literal property values, therefore a set of standard datatypes based
+ on [<cite><a href="#bib-XMLSCHEMA11-2" class="bibref">XMLSCHEMA11-2</a></cite>] and [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] should be used:</p>
+
+ <table class="simple">
+ <thead>
+ <tr>
+ <th>URI</th>
+ <th>Description</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#boolean">http://www.w3.org/2001/XMLSchema#boolean</a></td>
+ <td>Boolean type as specified by XSD Boolean</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#date">http://www.w3.org/2001/XMLSchema#date</a></td>
+ <td>Date type as specified by XSD date</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#dateTime">http://www.w3.org/2001/XMLSchema#dateTime</a></td>
+ <td>Date and Time type as specified by XSD dateTime</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#decimal">http://www.w3.org/2001/XMLSchema#decimal</a></td>
+ <td>Decimal number type as specified by XSD Decimal</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#double">http://www.w3.org/2001/XMLSchema#double</a></td>
+ <td>Double floating-point number type as specified by XSD
+ Double</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#float">http://www.w3.org/2001/XMLSchema#float</a></td>
+ <td>Floating-point number type as specified by XSD Float</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#hexBinary">http://www.w3.org/2001/XMLSchema#hexBinary</a></td>
+ <td>Arbitrary hex-encoded binary data as specified by XSD hexBinary</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#integer">http://www.w3.org/2001/XMLSchema#integer</a></td>
+ <td>Integer number type as specified by XSD Integer</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#string">http://www.w3.org/2001/XMLSchema#string</a></td>
+ <td>String type as specified by XSD String</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#base64Binary">http://www.w3.org/2001/XMLSchema#base64Binary</a></td>
+ <td>Binary type as specified by XSD Base64Binary</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral</a></td>
+ <td>Literal XML value as specified by RDF</td>
+ </tr>
+ </tbody>
+ </table>
+
+ </section>
+
+
+ <section id="re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates">
+
+ <h3 id="h3_re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates" role="heading" aria-level="2"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
+ (re-)inventing duplicates</h3>
+
+ <p>
+ This section summarizes some well-known RDF vocabularies that should
+ be used in Linked Data Platform Resources wherever a resource needs
+ to use a predicate whose meaning matches one of these. For example,
+ if a resource has a description, and the application semantics of
+ that description is compatible with
+ <code>dcterms:description</code>
+ , then
+ <code>dcterms:description</code>
+ should be used. If needed, additional application-specific
+ predicates may be used. A specification for a domain may require one
+ or more of these properties for a particular resource type. The
+ Range column in the tables below identifies the defined
+ <code>rdfs:range</code>
+ for the properties.
+ </p>
+
+ <h3 id="common-properties">Common Properties</h3>
+
+ <p>
+ <strong>From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong>
+ </p>
+
+ <table class="simple">
+ <thead>
+ <tr>
+ <th>Property</th>
+ <th>Range/DataType</th>
+ <th>Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>dcterms:contributor</td>
+ <td>dcterms:Agent</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:creator</td>
+ <td>dcterms:Agent</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:created</td>
+ <td>xsd:dateTime</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:description</td>
+ <td>rdf:XMLLiteral</td>
+ <td>Descriptive text about the resource represented as rich
+ text in XHTML format. should include only content that is valid
+ and suitable inside an XHTML element.</td>
+ </tr>
+ <tr>
+ <td>dcterms:identifier</td>
+ <td>rdfs:Literal</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:modified</td>
+ <td>xsd:dateTime</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:relation</td>
+ <td>rdfs:Resource</td>
+ <td>The HTTP URI of a related resource. This is the predicate
+ to use when you don't know what else to use. If you know more
+ specifically what sort of relationship it is, use a more specific
+ predicate.</td>
+ </tr>
+ <tr>
+ <td>dcterms:subject</td>
+ <td>rdfs:Resource</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:title</td>
+ <td>rdf:XMLLiteral</td>
+ <td>A name given to the resource. Represented as rich text in
+ XHTML format. should include only content that is valid inside an
+ XHTML element.</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <p>
+ The predicate
+ <code>dcterms:type</code>
+ should not be used, instead use
+ <code>rdf:type</code>
+ . [<cite><a href="#bib-DC-RDF" class="bibref">DC-RDF</a></cite>].
+ </p>
+
+ <p>
+ <strong>From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong>
+ </p>
+
+ <table class="simple">
+ <thead>
+ <tr>
+ <th>Property</th>
+ <th>Range/DataType</th>
+ <th>Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>rdf:type</td>
+ <td>rdfs:Class</td>
+ <td>The type or types of the resource</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <p>
+ <strong>From RDF Schema URI: <a href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong>
+ </p>
+
+ <table class="simple">
+ <thead>
+ <tr>
+ <th>Property</th>
+ <th>Range/DataType</th>
+ <th>Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>rdfs:member</td>
+ <td>rdfs:Resource</td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>rdfs:label</td>
+ <td>rdfs:Literal</td>
+ <td>Only use this in vocabulary documents, to define the name
+ of the vocabulary term.</td>
+ </tr>
+ </tbody>
+ </table>
+
+
+
+ </section>
+
+
+ <section id="use-qvalues-properly">
+ <h3 id="h3_use-qvalues-properly" role="heading" aria-level="2"><span class="secno">2.10 </span>Use qvalues properly</h3>
+
+ <p>Quality factors allow the user or user agent to indicate the
+ relative degree of preference for a media-range, using the qvalue
+ scale from 0 to 1. The default value is q=1. Take the following for
+ example:</p>
+
+ <p>
+ <code>Accept: text/turtle; q=0.5, application/json</code>
+ </p>
+
+ <p>This should be interpreted as "I prefer application/json, but
+ send me text/turtle if it is the best available after a 50%
+ mark-down in quality."</p>
+
+ <p>Improper handling of qvalues is a common problem in
+ implementations of content negotiation.
+ </p><p>Refer to Section 14, Header Field Definitions, in the
+ [<cite><a href="#bib-HTTP11" class="bibref">HTTP11</a></cite>] specification to understand the proper use and evaluation
+ of qvalues for both client and server implementations.</p>
+
+ </section>
+
+ <section id="respond-with-primary-urls-and-use-them-for-identity-comparison">
+ <h3 id="h3_respond-with-primary-urls-and-use-them-for-identity-comparison" role="heading" aria-level="2"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</h3>
+
+ <p>Clients can access an LDPR using multiple URLs. An LDP server
+ should respond to each of those requests using a single consistent
+ URL, a primary URL, for the LDPR. This primary URL may be found
+ in the response's Location and/or Content-Location headers, and
+ potentially also in the representation of the LDPR. A common case is
+ URLs that vary by protocol, one HTTP and one HTTPS, but are
+ otherwise identical. In most cases those two URLs refer to the same
+ resource, and the server should respond to requests on either URL
+ with a single (primary) URL.</p>
+
+ <p>Clients should use the primary URL as an LDPR's identity;
+ for example, when determining if two URLs refer to the same resource
+ clients should compare the primary URLs, not the URLs used to
+ access the resources. Note that this usage <em>does</em> imply that the
+ client has sufficient reason to trust the headers and/or content
+ by which the primary URL is communicated to the client, which is
+ beyond what HTTP alone can guarantee [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>].
+ </p>
+
+ </section>
+
+ <section id="representing-relationships-between-resources">
+ <h3 id="h3_representing-relationships-between-resources" role="heading" aria-level="2"><span class="secno">2.12 </span>Representing relationships between resources</h3>
+ <p>LDPRs can use one RDF triple to represent a link
+ (relationship) to another resource. Having the source resource’s URI
+ as the subject and the target resource’s URI as the object of the
+ triple is enough. Contrary to a misconception that readers with
+ certain backgrounds may assume, the creation of an
+ "intermediate link" resource is not required to express
+ the relationship.</p>
+ </section>
+
+ <section id="minimize-server-specific-constraints">
+ <h3 id="h3_minimize-server-specific-constraints" role="heading" aria-level="2"><span class="secno">2.13 </span>Minimize server-specific constraints</h3>
+ <p>LDP servers should enable simple creation and modification of
+ LDPRs.</p>
+
+ <p>It may be common for LDP servers to put restrictions on
+ representations – for example, the range of rdf:type predicates,
+ datatypes of the objects of predicates, and the number of
+ occurrences of predicates in an LDPR, but servers should minimize
+ such restrictions.</p>
+
+ <p>For some server applications, excessive constraints on
+ modification of resources may be required. However, enforcement of
+ more complex constraints will greatly restrict the set of clients
+ that can modify resources. For interoperability with a wider range
+ of clients, implementers are therefore encouraged to minimize
+ server-specific constraints.</p>
+ </section>
+
+ </section>
+ <!-- End Best Practices Section -->
+
+ <section id="guidelines">
+
+ <!--OddPage--><h2 id="h2_guidelines" role="heading" aria-level="1"><span class="secno">3. </span>Guidelines</h2>
+
+ <section id="containers-are-not-limited-to-membership-and-containment-triples">
+
+ <h3 id="h3_containers-are-not-limited-to-membership-and-containment-triples" role="heading" aria-level="2"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</h3>
+
+ <p>It is important to remember that a Linked Data Platform
+ Container (LDPC) is also a Linked Data Platform RDF Source (LDP-RS) and
+ though it might exist as a membership controller, it may also represent
+ additional data that is valuable to the agents that access
+ it.</p>
+
+ </section>
+
+ <section id="finding-established-vocabularies">
+ <h3 id="h3_finding-established-vocabularies" role="heading" aria-level="2"><span class="secno">3.2 </span>Finding established vocabularies</h3>
+
+ <p>Following are some useful resources for finding and leveraging
+ pre-existing, common, and well-established vocabularies.</p>
+
+
+ <ul>
+ <li><strong>Linked Open Vocabularies (LOV)</strong>
+ [<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>] - an entry point to the growing
+ ecosystem of linked open vocabularies (RDFS or OWL ontologies) used
+ 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
+ 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. Users can also suggest a new vocabulary to add to
+ LOV. [<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>]</li>
+ <li><strong>Common Vocabularies / Ontologies / Micromodels</strong> [<cite><a href="#bib-LOD-COMMON-VOCABS" class="bibref">LOD-COMMON-VOCABS</a></cite>] - a wiki list maintained by the Linked Data LOD community project.</li>
+ </ul>
+
+ <div style="clear: both"></div>
+
+ </section>
+
+ </section>
+ <!-- End Guidelines Section -->
+
+ <section id="acknowledgements" class="appendix">
+ <!--OddPage--><h2 id="h2_acknowledgements" role="heading" aria-level="1"><span class="secno">A. </span>Acknowledgements</h2>
+ <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:
+ </p><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>, <abbr title="World Wide Web Consortium">W3C</abbr></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>, <abbr title="World Wide Web Consortium">W3C</abbr></li>
+ <li><a href="http://stevebattle.me">Steve Battle</a></li>
+ <li><a href="http://stevespeicher.blogspot.com/">Steve Speicher</a>, IBM</li>
+ <li>Ted Thibodeau</li>
+ </ul>
+ </section>
+
+
+
+
+
+<section rel="bibo:Chapter" resource="#references" typeof="bibo:Chapter" id="references" class="appendix"><!--OddPage--><h2 id="h2_references" role="heading" aria-level="1"><span class="secno">B. </span>References</h2><section rel="bibo:Chapter" resource="#informative-references" typeof="bibo:Chapter" id="informative-references"><h3 id="h3_informative-references" role="heading" aria-level="2"><span class="secno">B.1 </span>Informative references</h3><dl about="" class="bibliography"><dt id="bib-DC-RDF">[DC-RDF]</dt><dd rel="dcterms:references">M. Nilsson et al. <a href="http://dublincore.org/documents/dc-rdf/"><cite>Expressing Dublin Core metadata using the Resource Description Framework (RDF)</cite></a>. 14 January 2008. DCMI Recommendation. URL: <a href="http://dublincore.org/documents/dc-rdf/">http://dublincore.org/documents/dc-rdf/</a>
+</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7230.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7230.txt">http://www.ietf.org/rfc/rfc7230.txt</a>
+</dd><dt id="bib-LD-DI">[LD-DI]</dt><dd rel="dcterms:references">Tim Berners-Lee. <a href="http://www.w3.org/DesignIssues/LinkedData.html"><cite>Linked Data - Design Issues</cite></a>. URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
+</dd><dt id="bib-LD-GLOSSARY">[LD-GLOSSARY]</dt><dd rel="dcterms:references">B Hyland; G Atemezing; M Pendleton; B Srivastava. <a href="http://www.w3.org/TR/ld-glossary/"><cite>Linked Data Glossary</cite></a>. URL: <a href="http://www.w3.org/TR/ld-glossary/">http://www.w3.org/TR/ld-glossary/</a>
+</dd><dt id="bib-LDP">[LDP]</dt><dd rel="dcterms:references">Steve Speicher; John Arwe; Ashok Malhotra. <a href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 19 June 2014. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
+</dd><dt id="bib-LDP-PRIMER">[LDP-PRIMER]</dt><dd rel="dcterms:references">Nandana Mihindukulasooriya; Roger Menday. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html"><cite>Linked Data Platforn Primer</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html</a>
+</dd><dt id="bib-LDP-TESTS">[LDP-TESTS]</dt><dd rel="dcterms:references">Raúl García-Castro. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html"><cite>Linked Data Platform 1.0 Test Cases</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html</a>
+</dd><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/ldp-ucr/"><cite>Linked Data Platform Use Cases and Requirements</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a>
+</dd><dt id="bib-LOD-COMMON-VOCABS">[LOD-COMMON-VOCABS]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies"><cite>Common Vocabularies / Ontologies / Micromodels </cite></a>. URL: <a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies">http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies</a>
+</dd><dt id="bib-LOV">[LOV]</dt><dd rel="dcterms:references"><a href="http://lov.okfn.org/dataset/lov/"><cite>Linked Open Vocabularies (LOV)</cite></a>. URL: <a href="http://lov.okfn.org/dataset/lov/">http://lov.okfn.org/dataset/lov/</a>
+</dd><dt id="bib-RDF-PRIMER11">[RDF-PRIMER11]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/"><cite>RDF 1.1 Primer</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/">http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/</a>
+</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd rel="dcterms:references">Dan Brickley; Ramanathan Guha. <a href="http://www.w3.org/TR/rdf-schema/"><cite>RDF Schema 1.1</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-schema/">http://www.w3.org/TR/rdf-schema/</a>
+</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd rel="dcterms:references">T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax</cite></a>. January 2005. Internet Standard. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
+</dd><dt id="bib-RFC3987">[RFC3987]</dt><dd rel="dcterms:references">M. Duerst; M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRIs)</cite></a>. January 2005. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
+</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7231.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7231.txt">http://www.ietf.org/rfc/rfc7231.txt</a>
+</dd><dt id="bib-TURTLE">[TURTLE]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Gavin Carothers. <a href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a>
+</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
+</dd><dt id="bib-XMLSCHEMA11-2">[XMLSCHEMA11-2]</dt><dd rel="dcterms:references">David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. <a href="http://www.w3.org/TR/xmlschema11-2/"><cite>W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes</cite></a>. 5 April 2012. W3C Recommendation. URL: <a href="http://www.w3.org/TR/xmlschema11-2/">http://www.w3.org/TR/xmlschema11-2/</a>
+</dd><dt id="bib-metaDataInURI">[metaDataInURI]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31"><cite>The use of Metadata in URIs</cite></a>. finding. URL: <a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31">http://www.w3.org/2001/tag/doc/metaDataInURI-31</a>
+</dd></dl></section></section></body></html>
\ No newline at end of file
--- a/TR/NOTE-ldp-bp-20140829/ldp-bp.html Tue Aug 26 09:12:16 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1209 +0,0 @@
-<!DOCTYPE html>
-<html prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#" content="en" property="dcterms:language" about="" typeof="bibo:Document w3p:NOTE" dir="ltr" lang="en"><head>
-<title>Linked Data Platform Best Practices and Guidelines</title>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<!--
- === NOTA BENE ===
- For the three scripts below, if your spec resides on dev.w3 you can check them
- out in the same tree and use relative links so that they'll work offline,
- -->
-<!-- script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script -->
-
-
-<style>/*****************************************************************
- * ReSpec 3 CSS
- * Robin Berjon - http://berjon.com/
- *****************************************************************/
-
-/* --- INLINES --- */
-em.rfc2119 {
- text-transform: lowercase;
- font-variant: small-caps;
- font-style: normal;
- color: #900;
-}
-
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
- border: none;
-}
-
-dfn {
- font-weight: bold;
-}
-
-a.internalDFN {
- color: inherit;
- border-bottom: 1px solid #99c;
- text-decoration: none;
-}
-
-a.externalDFN {
- color: inherit;
- border-bottom: 1px dotted #ccc;
- text-decoration: none;
-}
-
-a.bibref {
- text-decoration: none;
-}
-
-cite .bibref {
- font-style: normal;
-}
-
-code {
- color: #C83500;
-}
-
-/* --- TOC --- */
-.toc a, .tof a {
- text-decoration: none;
-}
-
-a .secno, a .figno {
- color: #000;
-}
-
-ul.tof, ol.tof {
- list-style: none outside none;
-}
-
-.caption {
- margin-top: 0.5em;
- font-style: italic;
-}
-
-/* --- TABLE --- */
-table.simple {
- border-spacing: 0;
- border-collapse: collapse;
- border-bottom: 3px solid #005a9c;
-}
-
-.simple th {
- background: #005a9c;
- color: #fff;
- padding: 3px 5px;
- text-align: left;
-}
-
-.simple th[scope="row"] {
- background: inherit;
- color: inherit;
- border-top: 1px solid #ddd;
-}
-
-.simple td {
- padding: 3px 10px;
- border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
- background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
- margin-top: 0;
-}
-
-.section dd > p:last-child {
- margin-bottom: 0;
-}
-
-.section dd {
- margin-bottom: 1em;
-}
-
-.section dl.attrs dd, .section dl.eldef dd {
- margin-bottom: 0;
-}
-
-@media print {
- .removeOnSave {
- display: none;
- }
-}
-</style><style>/* --- EXAMPLES --- */
-div.example-title {
- min-width: 7.5em;
- color: #b9ab2d;
-}
-div.example-title span {
- text-transform: uppercase;
-}
-aside.example, div.example, div.illegal-example {
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
-}
-div.illegal-example { color: red }
-div.illegal-example p { color: black }
-aside.example, div.example {
- padding: .5em;
- border-left-width: .5em;
- border-left-style: solid;
- border-color: #e0cb52;
- background: #fcfaee;
-}
-
-aside.example div.example {
- border-left-width: .1em;
- border-color: #999;
- background: #fff;
-}
-aside.example div.example div.example-title {
- color: #999;
-}
-
-</style>
-
-<link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-NOTE" />
-
-<!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
-
-
-
-<body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
-
- <p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p>
-
- <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Best Practices and Guidelines</h1>
-
- <h2 id="w3c-working-group-note-29-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-29T05:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-29">29 August 2014</time></h2>
- <dl>
-
- <dt>This version:</dt>
- <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/">http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/</a></dd>
- <dt>Latest published version:</dt>
- <dd><a href="http://www.w3.org/TR/ldp-bp/">http://www.w3.org/TR/ldp-bp/</a></dd>
-
-
- <dt>Latest editor's draft:</dt>
- <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html</a></dd>
-
- <dt>Editors:</dt>
- <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Cody Burleson" href="http://codyburleson.com/">Cody Burleson</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://base22.com/">Base22</a></span>
-</dd>
-<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Miguel Esteban Gutiérrez" href="http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/phdstudents/27-mesteban">Miguel Esteban Gutiérrez</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
-</dd>
-<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Nandana Mihindukulasooriya" href="http://www.nandana.org/">Nandana Mihindukulasooriya</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
-</dd>
-
- </dl>
-
- <p class="copyright">
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
- 2014
-
- <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
- (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
- <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
- <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
-
- All Rights Reserved.
-
- <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
-
- <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
-
- rules apply.
- </p>
-
-
- <hr>
-</div>
-
- <section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2><p>This document provides best practices
- and guidelines for implementing Linked Data Platform [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] servers
- and clients.</p></section><section rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
-
-
-
- <p>
- <em>This section describes the status of this document at the time of its publication.
- Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
- latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
- http://www.w3.org/TR/.</em>
- </p>
-
-
-
- <p>
- This document was published by the <a href="http://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform Working Group</a> as a Working Group Note.
-
-
- If you wish to make comments regarding this document, please send them to
- <a href="mailto:public-ldp@w3.org">public-ldp@w3.org</a>
- (<a href="mailto:public-ldp-request@w3.org?subject=subscribe">subscribe</a>,
- <a href="http://lists.w3.org/Archives/Public/public-ldp/">archives</a>).
-
-
-
-
- All comments are welcome.
-
- </p>
-
-
- <p>
- Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
- Membership. This is a draft document and may be updated, replaced or obsoleted by other
- documents at any time. It is inappropriate to cite this document as other than work in
- progress.
- </p>
-
-
-
- <p>
-
- This document was produced by a group operating under the
- <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
- Policy</a>.
-
-
-
-
- <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
- disclosures</a>
-
- made in connection with the deliverables of the group; that page also includes
- instructions for disclosing a patent. An individual who has actual knowledge of a patent
- which the individual believes contains
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
- Claim(s)</a> must disclose the information in accordance with
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
- 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-
-
- </p>
-
- <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
- </p>
-
-
-
-
-
-</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#intro"><span class="secno">1. </span>About this Document</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#impetus"><span class="secno">1.1 </span>Impetus</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">1.2 </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#prerequisites-and-assumptions"><span class="secno">1.3 </span>Prerequisites and Assumptions</a></li></ul></li><li class="tocline"><a class="tocxref" href="#best-practices"><span class="secno">2. </span>Best Practices</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#predicate-uris-should-be-http-urls"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</a></li><li class="tocline"><a class="tocxref" href="#use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
- concept of type in LDPRs</a></li><li class="tocline"><a class="tocxref" href="#use-relative-uris"><span class="secno">2.3 </span>Use relative URIs</a></li><li class="tocline"><a class="tocxref" href="#avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</a></li><li class="tocline"><a class="tocxref" href="#represent-container-membership-with-hierarchical-uris"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</a></li><li class="tocline"><a class="tocxref" href="#include-a-trailing-slash-in-container-uris"><span class="secno">2.6 </span>Include a trailing slash in container URIs</a></li><li class="tocline"><a class="tocxref" href="#use-fragments-as-relative-identifiers"><span class="secno">2.7 </span>Use fragments as relative identifiers</a></li><li class="tocline"><a class="tocxref" href="#prefer-standard-datatypes"><span class="secno">2.8 </span>Prefer standard datatypes</a></li><li class="tocline"><a class="tocxref" href="#re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
- (re-)inventing duplicates</a></li><li class="tocline"><a class="tocxref" href="#use-qvalues-properly"><span class="secno">2.10 </span>Use qvalues properly</a></li><li class="tocline"><a class="tocxref" href="#respond-with-primary-urls-and-use-them-for-identity-comparison"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</a></li><li class="tocline"><a class="tocxref" href="#representing-relationships-between-resources"><span class="secno">2.12 </span>Representing relationships between resources</a></li><li class="tocline"><a class="tocxref" href="#minimize-server-specific-constraints"><span class="secno">2.13 </span>Minimize server-specific constraints</a></li></ul></li><li class="tocline"><a class="tocxref" href="#guidelines"><span class="secno">3. </span>Guidelines</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#containers-are-not-limited-to-membership-and-containment-triples"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</a></li><li class="tocline"><a class="tocxref" href="#finding-established-vocabularies"><span class="secno">3.2 </span>Finding established vocabularies</a></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">B.1 </span>Informative references</a></li></ul></li></ul></section>
-
-
-
-
- <section rel="bibo:Chapter" resource="#intro" typeof="bibo:Chapter" id="intro">
-
- <!--OddPage--><h2 id="h2_intro" role="heading" aria-level="1"><span class="secno">1. </span>About this Document</h2>
-
- <section id="impetus">
-
- <h3 id="h3_impetus" role="heading" aria-level="2"><span class="secno">1.1 </span>Impetus</h3>
-
- <p>While writing the Linked Data Platform Specification, the
- authors and contributors felt compelled to share common conventions
- and valuable lessons-learned. Yet, at the same time, they did not
- wish to impose or imply unnecessary restrictions, or to make the
- formal specification unnecessarily verbose. This document, along
- with the LDP Primer [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>], was therefore developed to
- provide additional context. Drawing upon the professional
- experiences of its authors and contributors, research into the rich
- history of related technologies, and continuous feedback from the
- community at large, it aims to help system implementers avoid common
- pitfalls, improve quality, and achieve greater interoperability with
- other Linked Data systems.</p>
-
- </section>
-
- <section id="terminology">
-
- <h3 id="h3_terminology" role="heading" aria-level="2"><span class="secno">1.2 </span>Terminology</h3>
-
- <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'. We define and differentiate
- the terms as follows:</p>
-
- <dl>
- <dt>best practice</dt>
- <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 LDP servers and
- clients are implemented as well as how certain resources 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 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 in Linked Data Platform 1.0
- [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] as well as the Linked Data Glossary [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] for
- definitions to a variety of terms used in this document and related
- to the Linked Data sphere of knowledge.</p>
-
- </section>
-
- <section id="prerequisites-and-assumptions">
-
- <h3 id="h3_prerequisites-and-assumptions" role="heading" aria-level="2"><span class="secno">1.3 </span>Prerequisites and Assumptions</h3>
-
- <p>
- Implementers should have at least a general familiarity with the <a href="#informative-references">informative references</a> cited in
- this document - especially the following:
- </p>
-
- <ul>
- <li><strong>RDF Vocabulary Description Language 1.0: RDF Schema</strong>
- [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] - The Resource Description Framework
- (RDF) is a general-purpose language for representing information in
- the Web and it is the defacto language for expressing Linked Data.
- This specification describes how to use RDF to describe RDF
- vocabularies.</li>
- <li><strong>RDF Primer 1.1</strong> [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] - This Primer is designed to
- provide the reader with the basic knowledge required to effectively
- use RDF. It introduces the basic concepts of RDF and describes its
- XML syntax. It describes how to define RDF vocabularies using the
- RDF Vocabulary Description Language, and gives an overview of some
- deployed RDF applications. It also describes the content and
- purpose of other RDF specification documents.</li>
- <li><strong>Turtle - Terse RDF Triple Language</strong>
- [<cite><a href="#bib-TURTLE" class="bibref">TURTLE</a></cite>] - defines a textual syntax for RDF called Turtle that
- allows RDF graphs to be completely written in a compact and natural
- text form, with abbreviations for common usage patterns and
- datatypes. RDF examples used in this document are expressed in
- Turtle.</li>
- <li><strong>Linked Data Glossary</strong> [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] - a
- useful glossary containing terms defined and used to describe
- Linked Data, and its associated vocabularies and best practices for
- publishing structured data on the Web.</li>
- <li><strong>Linked Data Platform 1.0</strong> [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] - the
- formal specification for the LDP read-write Linked Data
- architecture, based on HTTP access to web resources that describe
- their state using the RDF data model.
- </li><li><strong>Linked Data Platform 1.0 Test Cases</strong>
- [<cite><a href="#bib-LDP-TESTS" class="bibref">LDP-TESTS</a></cite>] - a standard set of tests provided by the <abbr title="World Wide Web Consortium">W3C</abbr>, which
- can be use to verify an implementation's conformance to the LDP
- specification.</li>
- <li><strong>Linked Data Platform Primer</strong> [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>]
- - an introduction to LDP, which describes the basic concepts of LDP
- such as Linked Data Platform Resources (LDPRs), Linked Data
- Platform Containers (LDPCs), and their affordances. The Primer
- provides a running example illustrating how an LDP client can
- interact with an LDP server in the context of a read-write Linked
- Data application (i.e. how to use HTTP for accessing, updating,
- creating and deleting resources from servers that expose their
- resources as Linked Data).</li>
- <li><strong>Linked Data Platform Use Cases and
- Requirements</strong> [<cite><a href="#bib-LDP-UCR" class="bibref">LDP-UCR</a></cite>] - a set of user stories, use cases,
- scenarios and requirements that motivate a simple read-write Linked
- Data architecture, based on HTTP access to web resources that
- describe their state using RDF.</li>
- </ul>
-
- </section>
-
- </section>
-
- <section id="best-practices">
-
- <!--OddPage--><h2 id="h2_best-practices" role="heading" aria-level="1"><span class="secno">2. </span>Best Practices</h2>
-
- <section id="predicate-uris-should-be-http-urls">
-
- <h3 id="h3_predicate-uris-should-be-http-urls" role="heading" aria-level="2"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</h3>
-
- <p>URIs are used to uniquely identify resources and URLs are used
- to locate resources on the Web. That is to say that a URL is
- expected to resolve to an actual resource, which can be retrieved
- from the host. A URI, on the other hand, may also be a URL, but it
- does not have to be; it may refer to something that has no
- retrievable representation.</p>
-
- <p>One of the fundamental ideas behind Linked Data is that the
- things referred to by HTTP URIs can actually be looked up
- ("dereferenced"). This important principle was originally
- outlined by Tim Berners-Lee as rule #2 of "the four rules"
- for linking data [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>]. It is therefore ideal that predicate
- URIs identify resources with representations that are retrievable. LDP
- servers should at least provide [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] representations of
- these predicates where possible.</p>
-
- <p>Of course, it is also a common practice to reuse properties
- 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
- practice as a benchmark for which to judge the efficacy of a
- vocabulary's use for linking data.</p>
-
- </section>
-
- <section id="use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs">
-
- <h3 id="h3_use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs" role="heading" aria-level="2"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
- concept of type in LDPRs</h3>
-
- <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 data more useful in the broadest context,
- type should be explicitly defined using the <code>rdf:type</code>
- predicate defined by [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>].
- </p>
-
- <p>This provides a way for clients to easily determine the type(s)
- of a resource without having to perform additional processing or
- make additional HTTP requests. For example, clients that cannot
- infer the type because they do not support inferencing can benefit
- from this explicit declaration.</p>
-
- <div class="example"><div class="example-title"><span>Example 1</span>: Representation of an LDPR with explicit declaration of rdf:type</div><pre class="example">@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
-@prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#>.
-
-<http://www.w3.org/People/EM/contact#me>
- a contact:Person;
- contact:fullName "Eric Miller";
- contact:mailbox <mailto:em@w3.org>;
- contact:personalTitle "Dr.".</pre></div>
-
- <p>The token 'a' in the predicate position of a Turtle triple represents the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#type.
- In the example above, therefore, <code>a contact:Person</code> is the same as <code>rdf:type contact:Person</code> or the fully-qualified form, <code><http://www.w3.org/1999/02/22-rdf-syntax-ns#type> contact:Person</code>.</p>
-
- </section>
-
- <section id="use-relative-uris">
-
- <h3 id="h3_use-relative-uris" role="heading" aria-level="2"><span class="secno">2.3 </span>Use relative URIs</h3>
-
- <!-- http://www.w3.org/2012/ldp/track/issues/29 -->
-
- <p>Relative URIs are useful to the Linked Data Platform in much
- the same ways that relative URLs [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>] have been useful to
- traditional web systems. Since the things referred to by Linked Data
- URIs should provide a retrievable representation [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>], 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 LDP Container model promotes
- hierarchical representations.</p>
-
- <p>Implementers should therefore align the function of relative
- URIs in LDP with those of traditional relative URLs where possible
- and appropriate. Aside from giving developers the comfort and
- convenience of familiarity, they provide many of the same
- advantages.</p>
-
- <dl>
- <dt>Relative URIs are shorter than absolute URIs.</dt>
- <dd>
- <p>In many cases, this can aid development by making code and
- RDF easier for humans to read. It can also reduce the size of
- payloads, which in turn, can reduce network traffic and stress on
- servers, while improving response times for end-users.</p>
-
- <div class="example"><div class="example-title"><span>Example 2</span>: Representation of http://example.org/container1/ with absolute URIs</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-
-<http://example.org/container1/>
- a a ldp:Container, ldp:BasicContainer;
- dcterms:title "A very simple container";
- ldp:contains
- <http://example.org/container1/member1>,
- <http://example.org/container1/member2>,
- <http://example.org/container1/member3>.</pre></div>
-
-
- <div class="example"><div class="example-title"><span>Example 3</span>: Representation of http://example.org/container1/ with relative URIs</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-
-<> a a ldp:Container, ldp:BasicContainer;
- dcterms:title "A very simple container";
- ldp:contains <member1>, <member2>, <member3> .</pre></div>
-
- </dd>
-
- <dt>Relative URIs can make resources more portable.</dt>
- <dd>When information which is already known from the context of
- the base resource's retrieval is omitted, there can be less
- information to modify when its location changes. This can make
- copying resources to new servers or to a new position in a
- containment hierarchy easier; in the preceding example,
- a process that clones just the container need not adjust any of
- its member URIs.
- </dd>
-
- <dt>Relative URIs are convenient during development.</dt>
- <dd>During development the scheme and network location
- information in a URI may either be unknown or likely to change. The
- commonly used 'localhost' for example, is better expressed by the
- server name or a domain name. Developers often experience less
- hassle by omitting this information. Additionally, the hierarchy
- implied by a relative URI may be mimicked in a server file system,
- which can help developers find and work with information, even when
- the server isn't running.</dd>
-
- <dt>Relative URIs support arbitrary, machine-generated URIs.</dt>
- <dd>
- RESTful URLs are often defined by a pattern of hierarchical
- 'collections', which clients interact with in very logical ways.
- For example, when creating a new resource the client does not
- typically know the name of the resource until after a successful
- POST to a collection's URL. A POST to
- <code>/people/</code>
- for example, may create the resource
- <code>/people/1</code>
- . LDP Containers are such collections whose URIs can benefit from
- the same model, which in some implementations, may actually be
- crucial.
- </dd>
- </dl>
- </section>
-
- <section id="avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution">
- <h3 id="h3_avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution" role="heading" aria-level="2"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</h3>
-
- <p>The semantics of dot-segments (eg. <code>../</code>) within relative URIs may be implied by other
- specifications and by common historical use, but in the case of LDP, additional consideration is required.</p>
-
- <p>The LDP specification states that... </p><blockquote>LDP servers <em title="MUST" class="rfc2119">MUST</em> assign the default base-URI for [<cite><a href="#bib-RFC3987" class="bibref">RFC3987</a></cite>]
- relative-URI resolution
- to be the HTTP Request-URI when the resource already exists, and to
-the URI of the created resource when the request results in the creation
-
- of a new resource.</blockquote> It follows from this definition that use of <code>../</code>
- and other non-null relative URI constructs during
- POST can cause the posted content to be referring to resources in a
-manner the client might not be able to predict.
- Dot-segments should therefore be avoided unless the client knows
-specifically what can be expected of the given implementation
- and/or deployment.<p></p>
- </section>
-
-
- <section id="represent-container-membership-with-hierarchical-uris">
-
- <h3 id="h3_represent-container-membership-with-hierarchical-uris" role="heading" aria-level="2"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</h3>
-
- <p>Hierarchical URIs are good for containers because they enable
- the use of relative URIs. They also promote easy interaction with
- resources that are modeled to represent parent-child relationships
- where the child logically belongs to the parent.</p>
-
- <p>
- One example of such a model can be found in the case of the
- <code>oslc_cm:attachment</code>
- 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 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>
- container. The URI for such a container might be represented as
- follows:
- </p>
-
- <p>
- <code>http://example.org/bugs/2314/attachments/</code>
- </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>In addition to making the use of relative URIs possible,
- hierarchical URIs make interacting with resources easier for users because
- they represent the actual structure of the underlying graph.
- Software agents (code acting on behalf of users [<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>]) must be careful
- before exploiting the structure of URIs, considering historical problems
- when doing so ([<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>], [<cite><a href="#bib-metaDataInURI" class="bibref">metaDataInURI</a></cite>]).
- </p>
-
- </section>
-
-
- <section id="include-a-trailing-slash-in-container-uris">
-
- <!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
-
- <h3 id="h3_include-a-trailing-slash-in-container-uris" role="heading" aria-level="2"><span class="secno">2.6 </span>Include a trailing slash in container URIs</h3>
-
- <p>When representing container membership with hierarchical URLs,
- including the trailing slash in a container's URI makes it
- easier to use relative URIs.
- Take the following container URI for example:</p>
-
- <p>
- <code>http://example.org/container1</code>
- </p>
-
- <p>It is more advantageous to use the following instead:</p>
-
- <p>
- <code>http://example.org/container1/</code>
- </p>
-
- <p>To illustrate the advantage, let's start with the following
- container using absolute URIs:</p>
-
- <div class="example"><div class="example-title"><span>Example 4</span>: A simple container</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-
-<http://example.org/container1>
- a a ldp:Container, ldp:BasicContainer;
- dcterms:title "A very simple container";
- ldp:contains
- <http://example.org/container1/member1>,
- <http://example.org/container1/member2>,
- <http://example.org/container1/member3>.</pre></div>
-
- <p>Suppose now that we wish to reflect the same resource using
- relative URIs. If the URI of the container includes the trailing
- slash, we end up with a very elegant representation, as shown below.</p>
-
- <div class="example"><div class="example-title"><span>Example 5</span>: Container URI is http://example.org/container1/</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-
-<> a a ldp:Container, ldp:BasicContainer;
- dcterms:title "A very simple container";
- ldp:contains <member1>, <member2>, <member3> .</pre></div>
-
- <p>But suppose that we omit the trailing slash, issued an HTTP
- GET, and the container returned the representation shown above. This
- could produce a graph that is equivalent to the following:</p>
-
- <div class="example"><div class="example-title"><span>Example 6</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-
-<http://example.org/container1>
- a a ldp:Container, ldp:BasicContainer;
- dcterms:title "A very simple container";
- ldp:contains
- <http://example.org/member1>,
- <http://example.org/member2>,
- <http://example.org/member3>.</pre></div>
-
- <p>That is not what was intended; the member URLs lack the
- <code>container</code> path segment.
- The returned document would
- have to be more verbose in order to be correct:</p>
-
- <div class="example"><div class="example-title"><span>Example 7</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-
-<> a a ldp:Container, ldp:BasicContainer;
- dcterms:title "A very simple container";
- ldp:contains <container1/member1>, <container1/member2>, <container1/member3> .</pre></div>
-
- <p>So, clearly, the better solution is to ensure that container
- URIs end with a trailing slash.</p>
-
- </section>
-
-
- <section id="use-fragments-as-relative-identifiers">
-
- <h3 id="h3_use-fragments-as-relative-identifiers" role="heading" aria-level="2"><span class="secno">2.7 </span>Use fragments as relative identifiers</h3>
-
- <p>
- Resource URIs are permitted to end with a fragment; the fragment
- component is delimited from the rest of the URI because it is
- introduced by a hash mark (<b><code>#</code></b>).
- For this reason, URIs with non-empty fragments are often called hash URIs;
- a hash URI identifies a subordinate or related resource [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>].
- </p>
-
- <p>
- Take the URI,
- <code>http://www.example.org/products#item10245</code>
- , for example. The non-fragment portion of the URI is the part preceding the hash mark,
- <code>http://www.example.org/products</code>
- , and the fragment identifier is the part that follows,
- <code>item10245</code>
- .
- </p>
-
- <p>When expressing Linked Data Platform Resources in RDF,
- fragments are useful because they can be expressed as relative URIs
- on the document describing them. This is particularly handy for
- describing multiple LDPRs whose representations are contained within
- a single document.</p>
-
- <p>
- First, it provides the convenience and efficiency of brevity.
- Suppose, for example, the resources foo, bar, and baz 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>
- and
- <code><#baz></code>
- ). [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] ensures that the default base URI is the document
- URI (
- <code>http://www.example.org/products</code>
- ), so the absolute URI for each is
- the base URI, plus the hash mark,
- plus the fragment identifier.
- </p>
-
-
- <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 multiple
- documents would have to be published, perhaps also including the
- setup of 303 redirects.</p>
-
- <p>
- <strong>See also:</strong>
- </p>
-
- <p>
- <a href="http://www.w3.org/TR/cooluris">Cool URIs for the
- Semantic Web</a>
- </p><ul>
- <li><a href="http://www.w3.org/TR/cooluris/#hashuri">http://www.w3.org/TR/cooluris/#hashuri</a></li>
- <li><a href="http://www.w3.org/TR/cooluris/#choosing">http://www.w3.org/TR/cooluris/#choosing</a></li>
- </ul>
- <p></p>
-
- <p>
- <a href="http://www.w3.org/DesignIssues/Fragment.html">Axioms of
- Web Architecture, URI References: Fragment Identifiers on URIs</a><br>
- http://www.w3.org/DesignIssues/Fragment.html
- </p>
-
- <p>
- <a href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">Dereferencing
- HTTP URIs</a><br>
- http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
- </p>
-
- </section>
-
-
- <section id="prefer-standard-datatypes">
- <h3 id="h3_prefer-standard-datatypes" role="heading" aria-level="2"><span class="secno">2.8 </span>Prefer standard datatypes</h3>
-
- <p>LDPR representations should use only the following standard
- datatypes. RDF does not by itself define datatypes to be used for
- literal property values, therefore a set of standard datatypes based
- on [<cite><a href="#bib-XMLSCHEMA11-2" class="bibref">XMLSCHEMA11-2</a></cite>] and [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] should be used:</p>
-
- <table class="simple">
- <thead>
- <tr>
- <th>URI</th>
- <th>Description</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#boolean">http://www.w3.org/2001/XMLSchema#boolean</a></td>
- <td>Boolean type as specified by XSD Boolean</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#date">http://www.w3.org/2001/XMLSchema#date</a></td>
- <td>Date type as specified by XSD date</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#dateTime">http://www.w3.org/2001/XMLSchema#dateTime</a></td>
- <td>Date and Time type as specified by XSD dateTime</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#decimal">http://www.w3.org/2001/XMLSchema#decimal</a></td>
- <td>Decimal number type as specified by XSD Decimal</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#double">http://www.w3.org/2001/XMLSchema#double</a></td>
- <td>Double floating-point number type as specified by XSD
- Double</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#float">http://www.w3.org/2001/XMLSchema#float</a></td>
- <td>Floating-point number type as specified by XSD Float</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#hexBinary">http://www.w3.org/2001/XMLSchema#hexBinary</a></td>
- <td>Arbitrary hex-encoded binary data as specified by XSD hexBinary</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#integer">http://www.w3.org/2001/XMLSchema#integer</a></td>
- <td>Integer number type as specified by XSD Integer</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#string">http://www.w3.org/2001/XMLSchema#string</a></td>
- <td>String type as specified by XSD String</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#base64Binary">http://www.w3.org/2001/XMLSchema#base64Binary</a></td>
- <td>Binary type as specified by XSD Base64Binary</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral</a></td>
- <td>Literal XML value as specified by RDF</td>
- </tr>
- </tbody>
- </table>
-
- </section>
-
-
- <section id="re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates">
-
- <h3 id="h3_re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates" role="heading" aria-level="2"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
- (re-)inventing duplicates</h3>
-
- <p>
- This section summarizes some well-known RDF vocabularies that should
- be used in Linked Data Platform Resources wherever a resource needs
- to use a predicate whose meaning matches one of these. For example,
- if a resource has a description, and the application semantics of
- that description is compatible with
- <code>dcterms:description</code>
- , then
- <code>dcterms:description</code>
- should be used. If needed, additional application-specific
- predicates may be used. A specification for a domain may require one
- or more of these properties for a particular resource type. The
- Range column in the tables below identifies the defined
- <code>rdfs:range</code>
- for the properties.
- </p>
-
- <h3 id="common-properties">Common Properties</h3>
-
- <p>
- <strong>From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong>
- </p>
-
- <table class="simple">
- <thead>
- <tr>
- <th>Property</th>
- <th>Range/DataType</th>
- <th>Comment</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>dcterms:contributor</td>
- <td>dcterms:Agent</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:creator</td>
- <td>dcterms:Agent</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:created</td>
- <td>xsd:dateTime</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:description</td>
- <td>rdf:XMLLiteral</td>
- <td>Descriptive text about the resource represented as rich
- text in XHTML format. should include only content that is valid
- and suitable inside an XHTML element.</td>
- </tr>
- <tr>
- <td>dcterms:identifier</td>
- <td>rdfs:Literal</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:modified</td>
- <td>xsd:dateTime</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:relation</td>
- <td>rdfs:Resource</td>
- <td>The HTTP URI of a related resource. This is the predicate
- to use when you don't know what else to use. If you know more
- specifically what sort of relationship it is, use a more specific
- predicate.</td>
- </tr>
- <tr>
- <td>dcterms:subject</td>
- <td>rdfs:Resource</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:title</td>
- <td>rdf:XMLLiteral</td>
- <td>A name given to the resource. Represented as rich text in
- XHTML format. should include only content that is valid inside an
- XHTML element.</td>
- </tr>
- </tbody>
- </table>
-
- <p>
- The predicate
- <code>dcterms:type</code>
- should not be used, instead use
- <code>rdf:type</code>
- . [<cite><a href="#bib-DC-RDF" class="bibref">DC-RDF</a></cite>].
- </p>
-
- <p>
- <strong>From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong>
- </p>
-
- <table class="simple">
- <thead>
- <tr>
- <th>Property</th>
- <th>Range/DataType</th>
- <th>Comment</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>rdf:type</td>
- <td>rdfs:Class</td>
- <td>The type or types of the resource</td>
- </tr>
- </tbody>
- </table>
-
- <p>
- <strong>From RDF Schema URI: <a href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong>
- </p>
-
- <table class="simple">
- <thead>
- <tr>
- <th>Property</th>
- <th>Range/DataType</th>
- <th>Comment</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>rdfs:member</td>
- <td>rdfs:Resource</td>
- <td> </td>
- </tr>
- <tr>
- <td>rdfs:label</td>
- <td>rdfs:Literal</td>
- <td>Only use this in vocabulary documents, to define the name
- of the vocabulary term.</td>
- </tr>
- </tbody>
- </table>
-
-
-
- </section>
-
-
- <section id="use-qvalues-properly">
- <h3 id="h3_use-qvalues-properly" role="heading" aria-level="2"><span class="secno">2.10 </span>Use qvalues properly</h3>
-
- <p>Quality factors allow the user or user agent to indicate the
- relative degree of preference for a media-range, using the qvalue
- scale from 0 to 1. The default value is q=1. Take the following for
- example:</p>
-
- <p>
- <code>Accept: text/turtle; q=0.5, application/json</code>
- </p>
-
- <p>This should be interpreted as "I prefer application/json, but
- send me text/turtle if it is the best available after a 50%
- mark-down in quality."</p>
-
- <p>Improper handling of qvalues is a common problem in
- implementations of content negotiation.
- </p><p>Refer to Section 14, Header Field Definitions, in the
- [<cite><a href="#bib-HTTP11" class="bibref">HTTP11</a></cite>] specification to understand the proper use and evaluation
- of qvalues for both client and server implementations.</p>
-
- </section>
-
- <section id="respond-with-primary-urls-and-use-them-for-identity-comparison">
- <h3 id="h3_respond-with-primary-urls-and-use-them-for-identity-comparison" role="heading" aria-level="2"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</h3>
-
- <p>Clients can access an LDPR using multiple URLs. An LDP server
- should respond to each of those requests using a single consistent
- URL, a primary URL, for the LDPR. This primary URL may be found
- in the response's Location and/or Content-Location headers, and
- potentially also in the representation of the LDPR. A common case is
- URLs that vary by protocol, one HTTP and one HTTPS, but are
- otherwise identical. In most cases those two URLs refer to the same
- resource, and the server should respond to requests on either URL
- with a single (primary) URL.</p>
-
- <p>Clients should use the primary URL as an LDPR's identity;
- for example, when determining if two URLs refer to the same resource
- clients should compare the primary URLs, not the URLs used to
- access the resources. Note that this usage <em>does</em> imply that the
- client has sufficient reason to trust the headers and/or content
- by which the primary URL is communicated to the client, which is
- beyond what HTTP alone can guarantee [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>].
- </p>
-
- </section>
-
- <section id="representing-relationships-between-resources">
- <h3 id="h3_representing-relationships-between-resources" role="heading" aria-level="2"><span class="secno">2.12 </span>Representing relationships between resources</h3>
- <p>LDPRs can use one RDF triple to represent a link
- (relationship) to another resource. Having the source resource’s URI
- as the subject and the target resource’s URI as the object of the
- triple is enough. Contrary to a misconception that readers with
- certain backgrounds may assume, the creation of an
- "intermediate link" resource is not required to express
- the relationship.</p>
- </section>
-
- <section id="minimize-server-specific-constraints">
- <h3 id="h3_minimize-server-specific-constraints" role="heading" aria-level="2"><span class="secno">2.13 </span>Minimize server-specific constraints</h3>
- <p>LDP servers should enable simple creation and modification of
- LDPRs.</p>
-
- <p>It may be common for LDP servers to put restrictions on
- representations – for example, the range of rdf:type predicates,
- datatypes of the objects of predicates, and the number of
- occurrences of predicates in an LDPR, but servers should minimize
- such restrictions.</p>
-
- <p>For some server applications, excessive constraints on
- modification of resources may be required. However, enforcement of
- more complex constraints will greatly restrict the set of clients
- that can modify resources. For interoperability with a wider range
- of clients, implementers are therefore encouraged to minimize
- server-specific constraints.</p>
- </section>
-
- </section>
- <!-- End Best Practices Section -->
-
- <section id="guidelines">
-
- <!--OddPage--><h2 id="h2_guidelines" role="heading" aria-level="1"><span class="secno">3. </span>Guidelines</h2>
-
- <section id="containers-are-not-limited-to-membership-and-containment-triples">
-
- <h3 id="h3_containers-are-not-limited-to-membership-and-containment-triples" role="heading" aria-level="2"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</h3>
-
- <p>It is important to remember that a Linked Data Platform
- Container (LDPC) is also a Linked Data Platform RDF Source (LDP-RS) and
- though it might exist as a membership controller, it may also represent
- additional data that is valuable to the agents that access
- it.</p>
-
- </section>
-
- <section id="finding-established-vocabularies">
- <h3 id="h3_finding-established-vocabularies" role="heading" aria-level="2"><span class="secno">3.2 </span>Finding established vocabularies</h3>
-
- <p>Following are some useful resources for finding and leveraging
- pre-existing, common, and well-established vocabularies.</p>
-
-
- <ul>
- <li><strong>Linked Open Vocabularies (LOV)</strong>
- [<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>] - an entry point to the growing
- ecosystem of linked open vocabularies (RDFS or OWL ontologies) used
- 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
- 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. Users can also suggest a new vocabulary to add to
- LOV. [<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>]</li>
- <li><strong>Common Vocabularies / Ontologies / Micromodels</strong> [<cite><a href="#bib-LOD-COMMON-VOCABS" class="bibref">LOD-COMMON-VOCABS</a></cite>] - a wiki list maintained by the Linked Data LOD community project.</li>
- </ul>
-
- <div style="clear: both"></div>
-
- </section>
-
- </section>
- <!-- End Guidelines Section -->
-
- <section id="acknowledgements" class="appendix">
- <!--OddPage--><h2 id="h2_acknowledgements" role="heading" aria-level="1"><span class="secno">A. </span>Acknowledgements</h2>
- <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:
- </p><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>, <abbr title="World Wide Web Consortium">W3C</abbr></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>, <abbr title="World Wide Web Consortium">W3C</abbr></li>
- <li><a href="http://stevebattle.me/">Steve Battle</a></li>
- <li><a href="http://stevespeicher.blogspot.com/">Steve Speicher</a>, IBM</li>
- <li>Ted Thibodeau</li>
- </ul>
- </section>
-
-
-
-
-
-<div style="position: fixed; top: 20px; right: 20px; width: 202px; text-align: right;" id="respec-ui" class="removeOnSave"><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); font-weight: bold; border: 1px solid rgb(204, 204, 204); border-radius: 5px;">ReSpec</button><div style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border: 1px solid rgb(0, 0, 0); width: 200px; display: none; text-align: left; margin-top: 5px; margin-right: 5px;"><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border-width: medium medium 1px; border-style: none none solid; border-color: -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border-bottom-colors: none; -moz-border-left-colors: none; border-image: none; width: 100%; text-align: left; font-size: inherit;">Save Snapshot</button><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border-width: medium medium 1px; border-style: none none solid; border-color: -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border-bottom-colors: none; -moz-border-left-colors: none; border-image: none; width: 100%; text-align: left; font-size: inherit;">About ReSpec</button><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border-width: medium medium 1px; border-style: none none solid; border-color: -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border-bottom-colors: none; -moz-border-left-colors: none; border-image: none; width: 100%; text-align: left; font-size: inherit;">Search Specref DB</button></div></div><section rel="bibo:Chapter" resource="#references" typeof="bibo:Chapter" id="references" class="appendix"><!--OddPage--><h2 id="h2_references" role="heading" aria-level="1"><span class="secno">B. </span>References</h2><section rel="bibo:Chapter" resource="#informative-references" typeof="bibo:Chapter" id="informative-references"><h3 id="h3_informative-references" role="heading" aria-level="2"><span class="secno">B.1 </span>Informative references</h3><dl about="" class="bibliography"><dt id="bib-DC-RDF">[DC-RDF]</dt><dd rel="dcterms:references">M. Nilsson et al. <a href="http://dublincore.org/documents/dc-rdf/"><cite>Expressing Dublin Core metadata using the Resource Description Framework (RDF)</cite></a>. 14 January 2008. DCMI Recommendation. URL: <a href="http://dublincore.org/documents/dc-rdf/">http://dublincore.org/documents/dc-rdf/</a>
-</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7230.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7230.txt">http://www.ietf.org/rfc/rfc7230.txt</a>
-</dd><dt id="bib-LD-DI">[LD-DI]</dt><dd rel="dcterms:references">Tim Berners-Lee. <a href="http://www.w3.org/DesignIssues/LinkedData.html"><cite>Linked Data - Design Issues</cite></a>. URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
-</dd><dt id="bib-LD-GLOSSARY">[LD-GLOSSARY]</dt><dd rel="dcterms:references">B Hyland; G Atemezing; M Pendleton; B Srivastava. <a href="http://www.w3.org/TR/ld-glossary/"><cite>Linked Data Glossary</cite></a>. URL: <a href="http://www.w3.org/TR/ld-glossary/">http://www.w3.org/TR/ld-glossary/</a>
-</dd><dt id="bib-LDP">[LDP]</dt><dd rel="dcterms:references">Steve Speicher; John Arwe; Ashok Malhotra. <a href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 19 June 2014. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
-</dd><dt id="bib-LDP-PRIMER">[LDP-PRIMER]</dt><dd rel="dcterms:references">Nandana Mihindukulasooriya; Roger Menday. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html"><cite>Linked Data Platforn Primer</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html</a>
-</dd><dt id="bib-LDP-TESTS">[LDP-TESTS]</dt><dd rel="dcterms:references">Raúl García-Castro. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html"><cite>Linked Data Platform 1.0 Test Cases</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html</a>
-</dd><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/ldp-ucr/"><cite>Linked Data Platform Use Cases and Requirements</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a>
-</dd><dt id="bib-LOD-COMMON-VOCABS">[LOD-COMMON-VOCABS]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies"><cite>Common Vocabularies / Ontologies / Micromodels </cite></a>. URL: <a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies">http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies</a>
-</dd><dt id="bib-LOV">[LOV]</dt><dd rel="dcterms:references"><a href="http://lov.okfn.org/dataset/lov/"><cite>Linked Open Vocabularies (LOV)</cite></a>. URL: <a href="http://lov.okfn.org/dataset/lov/">http://lov.okfn.org/dataset/lov/</a>
-</dd><dt id="bib-RDF-PRIMER11">[RDF-PRIMER11]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/"><cite>RDF 1.1 Primer</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/">http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/</a>
-</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd rel="dcterms:references">Dan Brickley; Ramanathan Guha. <a href="http://www.w3.org/TR/rdf-schema/"><cite>RDF Schema 1.1</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-schema/">http://www.w3.org/TR/rdf-schema/</a>
-</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd rel="dcterms:references">T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax</cite></a>. January 2005. Internet Standard. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
-</dd><dt id="bib-RFC3987">[RFC3987]</dt><dd rel="dcterms:references">M. Duerst; M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRIs)</cite></a>. January 2005. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
-</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7231.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7231.txt">http://www.ietf.org/rfc/rfc7231.txt</a>
-</dd><dt id="bib-TURTLE">[TURTLE]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Gavin Carothers. <a href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a>
-</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
-</dd><dt id="bib-XMLSCHEMA11-2">[XMLSCHEMA11-2]</dt><dd rel="dcterms:references">David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. <a href="http://www.w3.org/TR/xmlschema11-2/"><cite>W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes</cite></a>. 5 April 2012. W3C Recommendation. URL: <a href="http://www.w3.org/TR/xmlschema11-2/">http://www.w3.org/TR/xmlschema11-2/</a>
-</dd><dt id="bib-metaDataInURI">[metaDataInURI]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31"><cite>The use of Metadata in URIs</cite></a>. finding. URL: <a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31">http://www.w3.org/2001/tag/doc/metaDataInURI-31</a>
-</dd></dl></section></section></body></html>
\ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-acr.html Tue Aug 26 09:12:41 2014 -0400
@@ -0,0 +1,220 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>LDP Access Control</title>
+ <!-- Changed by: , 25-Aug-2014 -->
+ <meta charset='utf-8'>
+ <script src='https://www.w3.org/Tools/respec/respec-w3c-common'
+ async class='remove'></script>
+ <script class='remove'>
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
+ specStatus: "WG-NOTE",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "ldp-acr",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ subtitle : "Usecases and Requirements for Access Control for the Linked Data Platform",
+
+ // if you wish the publication date to be other than the last modification, 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: "1977-03-15",
+ // previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-acr.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ {
+ name: "Ashok Malhotra"
+ , mailto: "ashok.malhotra@oracle.com"
+ , company: "Oracle America, Inc."
+ , companyURL: "http://www.oracle.com/"
+ },
+ ],
+
+ // name of the WG
+ wg: "Linked Data Platform WG",
+
+ // 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-comments@w3.org",
+
+ // 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",
+ // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
+ };
+ </script>
+ </head>
+ <body>
+ <section id='abstract'>
+ <p>
+ This note discusses usecases and requirements for Access Control for the
+ <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a>
+ It also outlines a charter for developing a standard for HTTP-based access control.
+ The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG.
+ </p>
+ </section>
+
+ <section id='sotd'>
+ <p>
+ While the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> did not
+ address Access Control directly, a number of usescases and requirements were identified as part of its
+ deliberations. These usecases and requirements are captured in this document to serve as a basis for
+ future work.
+ </p>
+ </section>
+
+ <section>
+ <h2>Access Control</h2>
+ <p>
+ Access Control is a mechanism through which an agent ( an HTTP server in this case ) permits other agents --
+ individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as
+ specified by policies for the resources and for the agents. Within this document, the resources are LDP resources, but the access
+ control may operate at different granularities: RDF or other documents, named graphs or individual triples.
+ The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
+ this design.
+ </p>
+ <p>
+ When an agent requests a collection of resources it gets to see only those resources or parts of resources
+ it is authorized for.</p>
+ <p>
+ Depending on the granularity, the access control mechanisms may affect performance, but should not affect
+ semantics.</p>
+ <p>
+ For access control to come into play, the server must restrict some operations on some resources.
+ </p>
+ </section>
+ <section>
+ <h2>Terminology</h2>
+ <ul>
+ <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
+ <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies
+ upon to make access control decisions.</li>
+ </ul>
+ </section>
+ <section>
+ <h2>Usecases</h2>
+ <section>
+ <h3>Access Control on manipulation of resources via HTTP</h3>
+ Adam's user agent attempts:
+ <ol>
+ <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL. The server may immediately
+ allow or deny the request, or it may request that he authenticate to confirm his privileges,
+ as specified by the ACG for the Resource.</li>
+ <li>If he is denied access, an explanation of why all or part of his request was denied should be provided
+ so that it becomes possible to detect errors, and so that he may modify the request --
+ potentially to include making a request for such privileges.
+ </li>
+ <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource
+ before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
+ </li>
+ </ol>
+ </section>
+ <section>
+ <h3>Editability of Access Control Rules using HTTP</h3>
+ <ol>
+ <li>
+ Bart's user agent logs on to a server and requests
+ the capability to read a group of related resources such as all the papers presented at a conference.</li>
+ </li>
+ <li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
+ <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the
+ people who attended the conference.</li>
+ </ol>
+ </section>
+ <section>
+ <h3>User Interface Scenarios</h3>
+ Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to
+ <ol>
+ <li>Know if he can edit or delete a resource.</li>
+ <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have
+ paid a fee )</li>
+ <li>Allow Eddie to edit the access control rules for a resource such as:
+ <ol>
+ <li>Allow friends of his to access a document.</li>
+ <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container,
+ those posted by that agent for example.</li>
+ <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a
+ specific URL pattern.</li>
+ <li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments
+ to a container related to some content, and edit their own comments.</li>
+ <li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network,
+ to work together on set of ontologies. It should be possible to drag and drop URLs for these groups,
+ found on the web, onto the User Interface as a way of creating the union of the members of the group.</li>
+ </ol>
+ </ol>
+ </section>
+ <section>
+ <h2>Requirements</h2>
+ <ul>
+ <li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token.
+ ( All use cases )</li>
+ <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description.
+ (Usecase 3.2.2, 3.2.3)</li>
+ <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
+ with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
+ <li>Ability to connect a collection of agents with a collection of resources with given access privileges.
+ ( All use cases )</li>
+ </ul>
+
+ <p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs.
+
+ <ul>
+ <li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
+ <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
+ <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
+ (Usecase 3.1.3)
+ </li>
+ <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
+ <li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
+ </ul>
+ </section>
+ <section>
+ <h2>Outline of a Charter for a Access Control WG</h2>
+ <p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of
+ resources. It then connects a collection of agents with a collection of resources with the connection identifying
+ the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
+ <p>ACGs are resources in their own right and can have access control priviledges specified for them just like
+ any other resource. This permits the creation and modification of ACGs to be delegated.
+ </p>
+ <p>
+ The members of the collection of agents contain tokens that the agents obtain from some authentication service.
+ The members of the collection of resources are URIs or URI templates.</p>
+ <p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
+<section>
+<h2>Deliverables</h2>
+<ul>
+<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a
+connection of resources.</li>
+<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
+<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed
+efficiently with the ACG structure defined above.</li>
+</ul>
+</section>
+ </section>
+ </section>
+
+
+ </body>
+</html>
--- a/ldp-paging.html Tue Aug 26 09:12:16 2014 -0400
+++ b/ldp-paging.html Tue Aug 26 09:12:41 2014 -0400
@@ -1164,7 +1164,8 @@
<div class="atrisk" id="atrisk-units"><p class="atrisktext">Feature At Risk</p>
<p>The LDP Working Group proposes incorporation of the preference parameters
<code>max-member-count</code> and <code>max-kbyte-count</code>, along with
- corresponding requirements on servers to support them.
+ corresponding requirements on servers of <a href="#ldpr-units-triple-count">LDPRs</a>
+ and <a href="#atrisk-paging-record-count">LDPCs</a> to support them.
</p>
</div>
@@ -1584,7 +1585,7 @@
<p>The LDP Working Group proposes incorporation of the following clause:</p>
-->
<section id="ldpr-units-triple-count"><h2 class="normal">
- <a title="LDP Paging server">LDP Paging servers</a> MUST
+ <a title="LDP Paging server">LDP Paging servers</a> SHOULD
support the <code>max-triple-count</code> <a href="#ldpp-hints">client preference parameter</a>,
which expresses a page size limiting the number of RDF triples represented on a page.
For example, <code>max-triple-count="500"</code> expresses a limit of 500 RDF triples per page.
@@ -1597,7 +1598,7 @@
<div class="atrisk" id="atrisk-paging-kbyte-count"><p class="atrisktext">Feature At Risk</p>
<p>The LDP Working Group proposes incorporation of the following clause:</p>
<section id="ldpr-units-kbyte-count"><h2 class="normal">
- <a title="LDP Paging server">LDP Paging servers</a> MUST
+ <a title="LDP Paging server">LDP Paging servers</a> SHOULD
support the <code>max-kbyte-count</code> <a href="#ldpp-hints">client preference parameter</a>,
which expresses a page size limit as kilobytes of representation size.
For example, <code>max-kbyte-count="1"</code> expresses a limit of 1024 bytes per page.
@@ -1613,7 +1614,7 @@
honor all hints that it recognizes. This has the net effect that the most restrictive
hint for any given response governs the resulting page size.
For example, <code>max-kbyte-count="1"</code> and <code>max-triple-count="500"</code>
- usually would result in pages with fewer than 500 triples, since each triple very likely
+ usually would result in pages whose size hits the 1 kilobyte limit first, since each triple very likely
requires more than two bytes (500 triples/1024 bytes).
</h2>
</section>
@@ -1670,7 +1671,7 @@
<div class="atrisk" id="atrisk-paging-record-count"><p class="atrisktext">Feature At Risk</p>
<p>The LDP Working Group proposes incorporation of the following clause:</p>
<section id="ldpr-units-record-count"><h2 class="normal">
- <a title="LDP Paging server">LDP Paging servers</a> MUST
+ <a title="LDP Paging server">LDP Paging servers</a> SHOULD
support the <code>max-member-count</code> <a href="#ldpp-hints">client preference parameter</a>,
which expresses a page size limiting the number of members returned on each page of a <a title="paged resource">paged LDPC</a>.
For example, <code>max-member-count="10"</code> expresses a limit of 10 members per page.
@@ -2203,7 +2204,7 @@
reviews, content, criticism and input in the creation of this specification:</p>
<p style="margin-left: 3em;">
- Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, Ashok Malhota, Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Erik Wilde, Gregory McFall, Henry Story, John Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon
+ Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, Ashok Malhotra, Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Erik Wilde, Gregory McFall, Henry Story, John Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon
</p>
</section>
@@ -2218,6 +2219,8 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140730/">Last Call Draft</a></em></blockquote> -->
<ul>
+ <li>2014-08-25 - max-triple-count, max-member-count, max-kbyte-count support must > should per Aug 25 mtg (JA) </li>
+ <li>2014-08-25 - Clarify example (JA) </li>
<li>2014-08-22 - AT RISK the three limits, first reached per Aug 18 mtg (JA) </li>
<li>2014-08-21 - max-triple-count, max-member-count, max-kbyte-count with parms being integers per Aug 18 mtg (JA) </li>
<li>2014-08-05 - Re-cast sort criteria as rdf:List compatible with syntactic sugar for those (JA) </li>
