Merge branch 'master' into patch-1

Author: TallTed

README.md

@@ -26,7 +26,6 @@
     * [HTTPS REST API](#https-rest-api)
     * [WebSockets API](#websockets-api)
 8. [Social Web App Protocols](#social-web-app-protocols)
-    * [Feed Discovery](#feed-discovery)
     * [Notifications](#notifications)
     * [Friends Lists, Followers and
         Following](#friends-lists-followers-and-following)
@@ -35,7 +34,7 @@
 10. [Recommendations for Client App
       Implementation](#recommendations-for-client-app-implementations)
 11. [Examples](#examples)
-12. [Current Implementations](#implementations)
+12. [Current Implementations](#current-implementations)
 
 ## Overview
 
@@ -153,7 +152,7 @@ protocols, adapted for WebID based decentralized use cases.
 **See component spec:
   [WebID-OIDC Specification](https://github.com/solid/webid-oidc-spec)**
 
-#### Other Authentication Mechanisms
+#### Alternative Authentication Mechanisms
 
 There are several other authentication mechanisms that are
 currently being investigated, such as combinations of traditional

UserStories/BrowsingTheFriendshipGraph.md

@@ -12,7 +12,7 @@
 
 The Linked Data People graph extends to several million organic user profiles over hundreds of multiple domains.  If facebook is included (they are producers of linked data via turtle) it extends to over 1.4 billion profiles.  
 
-Facebook profiles generally require an OAuth token to use the API, this enables access control and viewing priveledges.  Solid in general uses WebAccessControl and ACL's to achieve the same thing, but implementors may choose which approach they wish to take.
+Facebook profiles generally require an OAuth token to use the API, this enables access control and viewing privileges.  Solid in general uses WebAccessControl and ACL's to achieve the same thing, but implementors may choose which approach they wish to take.
 
 In Solid people are denoted by an HTTP URI.  Normally, as a best practice the URI contains a fragment identifier (#).  This is to help software disambiguate between an HTTP document and the person it talks about, in much the same way that a passport contains information about a person but a passport ID is the ID of that document, not the person.
 

UserStories/UserProfileManagement.md

@@ -152,7 +152,7 @@ She can do this either with a PUT which requires re-sending the full document as
 
 #### update using PUT
 
-PUT is the easiest for the client, as it does not have to calculate a diff between the original version it has and the version it wishes to have. We use If-Match, to make sure we don't override someone elses content.
+PUT is the easiest for the client, as it does not have to calculate a diff between the original version it has and the version it wishes to have. We use If-Match, to make sure we don't override someone else's content.
 
 ```http
 PUT /card HTTP/1.1

acl-inheritance.md

@@ -51,7 +51,7 @@ In `defaultForNew`, ACL permissions are inherited from the whole path as in 'mom
 - Fast
 
 #### Cons
-- Generates a storage reuirement for all the ACL files, which is a pain, especialy in a fiel space shared with other systems.
+- Generates a storage requirement for all the ACL files, which is a pain, especially in a file space shared with other systems.
 - Users may lose access to their resource by creating an ACL file that does not contain themselves.
 - Changing permissions recursively to a folder will require changing permission on each subfolder's ACL
 

api-rest.md

@@ -60,9 +60,16 @@ HTTP/1.1 200 OK
 
 #### Globbing (inlining on `GET`)
 
+**Note: this feature is _at risk_ of being
+[changed](https://github.com/solid/solid-spec/pull/148)
+or [removed](https://github.com/solid/solid-spec/pull/151).
+Please join the discussion.
+Code depending on this will still work for now.**
+
 In some cases, we have found that using the existing LDP features was not
 enough. For instance, to optimize certain applications, we needed to aggregate
 all RDF resources from a container and retrieve them with a single `GET`
+
 operation. We implemented this feature on the servers and decided to call it
 "globbing". Similar to [UNIX shell
 glob](https://en.wikipedia.org/wiki/Glob_(programming)), doing a `GET` on any URI

examples/user-posts-note.md

@@ -1,7 +1,7 @@
 # Example: User Posts a Note
 
 **Note:** This example is a component of the parent
-[Solid specification](README.md); the parent spec and all its components are
+[Solid specification](../README.md); the parent spec and all its components are
 versioned as a whole.
 
 This example is taken from [W3C Social Web

recommendations-client.md

@@ -87,7 +87,7 @@ profile document.
 
 **Attention!** Because creating client certificates requires the [keygen HTML5
 element](http://www.w3schools.com/tags/tag_keygen.asp),
-which does not work with AJAX reques ts, the client must submit a form to the
+which does not work with AJAX requests, the client must submit a form to the
 **account host URI** -- i.e. `https://user.example.org/`. This restriction means
 that a predefined set of form element names must be respected on the server.
 Here is the minimum list of form element names (case sensitive!) that **MUST**

recommendations-server.md

@@ -55,18 +55,15 @@ space#preferencesFile](http://www.w3.org/ns/pim/space#preferencesFile) property.
 ##### `/inbox/` (Inbox)
 
 A container to serve as a default primary channel for
-notifications. Note that this is complementary (and not necessarily replacing)
-app-specific notification inboxes such as the one used by
-[Dokieli](https://github.com/linkeddata/dokieli).
+notifications.
+
 **Default ACL:** append-only by public, read by owner.
 
-Discoverable from profile via
-[solid-terms](https://github.com/solid/vocab/blob/master/solid-terms.ttl)#Inbox
-property.
+Discoverable from profile using the [ldp:inbox](http://www.w3.org/ns/ldp#inbox) property as specified in [W3C Linked Data Notifications](https://www.w3.org/TR/ldn/).
 
 ```ttl
 <#me>
-    <http://www.w3.org/ns/solid/terms#inbox> <../inbox/> ;
+    <http://www.w3.org/ns/ldp#inbox> <../inbox/> ;
 ```
 
 ## CORS - Cross Origin Resource Sharing

solid-webid-profiles.md

@@ -89,12 +89,18 @@ for the purposes of building distributed read-write-web applications.
 In addition, Solid recommends that WebID profiles include the following
 statements:
 
-1. A profile SHOULD include a `foaf:name` (see the discussion
+1. A profile MUST include a `foaf:name` (see the discussion
   on [user names](#recommendation-for-user-names-in-profiles) below).
-2. A profile SHOULD include `cert:key` public key certificate information, for
+  This does not have to be a real name, it can by any pseudonym, but
+  a string provided for apps to use for representing the user, in chats, sharing etc etc.
+2. A profile SHOULD include a public `foaf:img` of either a mugshot of the person or a chosen avatar
+  to make the display of the user's contributions identifiable.
+3. A profile MAY provide a `foaf:nick` nickname as a short string for use by user interfaces where
+  space is limited.
+3. A profile SHOULD include `cert:key` public key certificate information, for
   use with WebID+TLS (which is currently the primary Solid authentication
   mechanism).
-3. A profile SHOULD point to the root storage location using `pim:storage`
+4. A profile SHOULD point to the root storage location using `pim:storage`
   (so that applications will know where to read and write their data).
 
 ```ttl
@@ -125,7 +131,7 @@ what to name the user, is to perform the following steps:
 1. An app SHOULD look in the user's WebID Profile for the `foaf:name` predicate,
   and use that as the name, if it's available.
 2. If an app does not find a name in the user profile, it MAY fall back to using
-  the WebID URL as the username.
+  the WebID URL, or a part of it, as the username.
 
 ## Public and Private Profiles
 
@@ -148,13 +154,42 @@ across several RDF documents:
 The combination of the main WebID Profile document, and all of the *related*
 profile documents is referred to as the **Extended Profile**.
 
-Solid apps that interact with the WebID profile MUST also load and parse *all*
-of the related RDF resources that are linked to from the main profile using
-the following predicates:
+Solid apps that interact anonymously with the WebID profile MUST also load and parse *all*
+of the related public RDF resources that are linked to from the main profile using any
+the following triples in the main profile document:
+
+1. $webid   `http://www.w3.org/2002/07/owl#sameAs`  ?public
+2. $webid   `http://www.w3.org/2000/01/rdf-schema#seeAlso`  ?public
+
+Solid apps that interact as the user in question, logged in with their credentials,
+with their own WebID profile MUST also load and parse all
+of the related public resources above and also will normally
+load the user's preferences file.
+
+### Private preferences file
+
+The private preferences file is part of the extended profile. It is found
+by following a triple in the main profile (the result of looking up the webid)
+
+3. $webid   `http://www.w3.org/ns/pim/space#preferencesFile` ?preferences
+
+Where the subject is the user's original webid.
+
+It is the first private file that the app discovers in this process, and
+it is the place which either stores, or leads to, all of the
+data which is private to the user, including settings 
+and preferences, language and display preferences, and so on 
+and all the user's personal data, be it contacts, pictures or health data.
+
+The `solid:preferencesFile` link is unusual then in that it is a link
+from public data to private data.  Otherwise, discovery happens in two 
+parallel but otherwise congruent ways, in a tree of public information starting from
+the extended profile, and a tree of private information starting from the 
+private preferences file. Developers are urged to use common software for
+these cases, and also to make it extensible in future for when 
+the congruent trees may be rooted in files corresponding to groups and organizations
+of which the user is a member.
 
-1. `http://www.w3.org/2002/07/owl#sameAs`
-2. `http://www.w3.org/2000/01/rdf-schema#seeAlso`
-3. `http://www.w3.org/ns/pim/space#preferencesFile`
 
 ## Public Key Certificates
 
@@ -228,7 +263,7 @@ Example:
 # ...
 <#me>
     a foaf:Person ;
-    <http://www.w3.org/ns/solid/terms#inbox> </inbox/> .
+    <http://www.w3.org/ns/ldp#inbox> </inbox/> .
 ```
 
 ### Type Registry Index Discovery