Re: My slightly comments

On 10 Jan 2012, at 21:35, Kingsley Idehen wrote:

> On 1/10/12 2:37 PM, Henry Story wrote: 
>> 
>> Now it is true that point 5.1 does not speak of the returned representation, which is perhaps confusing. It speaks of the Profile. Also it does not speak to the fact that the verifier could have access to a graph cache, rather than just a representation cache (http cache). And in your case you would have access to a graph cache so then you would end up already with a graph, and therefore there is no need to parse the graph again.
>> 
>> Perhaps then we should split this up a little. Is this better?
>> The WebID Verifier must get access to an up to date version of the WebID Profile Graph.
>> If the WebID Verifier has an up to date version of the graph in its graph cache then it can return it
>> Otherwise the WebID verifier MUST fetch an up to date version of the WebID Profile representation by dereferencing the URI, using the canonical method for dereferencing a URL of that scheme. For an https://... WebID this would be done using the [HTTP-TLS] protocol. The dereferencing of the URI MAY use any representation caching mechanism it can to speed up the process. The returned representation is then transformed into an RDF graph [RDF-MT] as specified in Processing the WebID Profile . This graph may be cached.
>> That graph returned in the previous step is then queried as explained in Verifying the WebIDs. If the query is answered positively, then that WebID is verified. If the query fails and the graph was not up to date, then the Verifier MAY start again at point 1.2 
> 
> Yes, that works! You've established clear context for Name and Address roles re. URIs and URLs. 

Ok, those changes are now in.

diff
  https://dvcs.w3.org/hg/WebID/rev/ad18b0266757

editor's draft 

 https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html

Ok. For the RESTfulness of the spec I have asked people on REST discuss to see if they can give us feedback.

Henry

> 
> Kingsley