Re: My slightly comments

On 10 Jan 2012, at 19:54, Kingsley Idehen wrote:

> On 1/10/12 1:39 PM, Henry Story wrote:
>> On 10 Jan 2012, at 19:20, Kingsley Idehen wrote:
>> 
>>> On 1/10/12 1:11 PM, Henry Story wrote:
>>>> On 10 Jan 2012, at 15:38, Kingsley Idehen wrote:
>>>> 
>>>>> On 1/10/12 8:59 AM, Dominik Tomaszuk wrote:
>>>>>> My comments to the lastest version in repo [1]:
>>>>>> 1.3 Namespaces - in the table there is 'bob' which isn't use in spec. It can be removed.
>>>>>> 
>>>>>> 3.1 Authentication Sequence - point 5  - "The returned representation is then transformed into an RDF graph as specified in Processing the WebID Profile". I think it would be worth to add reference to RDF spec (what does RDF graph mean) [2]
>>>>> Shouldn't transformation only happen if the de-referenced resource isn't RDF?
>>>> There is no format that has a priori more right to be the RDF format than another.
>>> But I asked the question: Shouldn't transformation only happen if the de-referenced resource isn't RDF? Why would you transform RDF to RDF?
>> I am trying to express the transformation that takes you from a representation to a graph.
>> 
>> ie from
>>  string + mime type ->  rdf graph.
> 
> Fine, so be clear about it.
>> 
>> It is true that syntaxes developed for RDF have this transformation built in automatically. But I don't see how this
>> is different from string + mime type + GRDDLwithXSPARQL ->  rdf graph.
>> indeed you could write an XSPARQL for RDF/XML for example to do the transformation.
> 
> But that isn't my point though. I am commenting on clarity with readers (profiles varied) in mind.
> 
>> 
>> Perhaps this can be more obvious if we could get Portable Contacts to join us and give us a GRDDL of their format.
>> 
>>>>  So I see no difference between RDF/XML, Turtle, RDFa or other formats that could be GRDDLed in that respect. They are all strings that have to be transformed into triples. :-)
>>> But you aren't responding to my point. What do you mean by RDF in this transformation context? Not for me, but for readers of the spec, to be crystal clear.
>> Well I hope that helps. Can you propose some text that it clearer?
> How about:
> 
> "The de-referenced data is then transformed into an RDF graph as specified in Processing the WebID Profile".
> 
> or
> 
> "The data retrieved is then transformed into an RDF graph as specified in Processing the WebID Profile".
> 
> or
> 
> "The returned data is then transformed into an RDF graph as specified in Processing the WebID Profile".

Mhh. I see. But I am trying to use vocabulary from REST ( Representation State Transfer, for those who may be new to this).
Given a  URI (Uniform Resource Identifier) a request is made on the Resource it names,  which in turn may returns a Representation. This representation is what we parse.

The resource returns a representation, not data. Data is what you get after your parse a representation, and it also has some notion of truth built in I think. 

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 


> 
> 
> Kingsley
> 
> 
>> 
>>> 
>>>>>> 3.1 Authentication Sequence - point 5  - "That graph is then queried as explained in Querying the Graph. If the query is answered positively, then that WebID is verified." - also add reference to SPARQL (what does querying the graph mean) [3]
>>>>> It should really say lookup, that's what happening. A lookup occurs against the resolved RDF graph.
>>>> "A graph is the looked up"? Sounds a bit heavy.
>>> Again, you change my comments. I said:  A lookup occurs against the resolved RDF graph.
>>> 
>>>> I don't see what is wrong with queried. You ask something of the graph.
>>> Queried is a little loaded. Not inaccurate, since you achieve a lookup via a query, but it is loaded all the same. Again, not for me, but for spec readers.
>>> 
>>> 
>>>> Since our SPARQL uses the ASK query, it fits nicely. SPARQL is a query language after all.
>>> Yes, and my fundamental point is more about loosely associating SPARQL with WebID. It's an implementation detail. Of course, if you "query" usage is in the context of the SPARQL ASK section of the spec, then fine, context is established for the spec reader.
>> I really don't think we should be ashamed of SPARQL. It may have its flaws but I am have no shame in using them. It has an active group, many implementations, and gives us something well designed to hold on to. Any flaws can be improved there.
>> 
>> 
>> 
>>> Kingsley
>>>> Anyway, thanks for the input.
>>>> 
>>>> Henry
>>>> 
>>>>> [SNIP]
>>>>>> 
>>>>>> Best regards,
>>>>>> Dominik 'domel' Tomaszuk
>>>>>> 
>>>>>> 
>>>>>> [1] http://dvcs.w3.org/hg/WebID/raw-file/6da4ac1999d6/spec/index-respec.html
>>>>>> [2] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
>>>>>> [3] http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/
>>>>>> 
>>>>>> 
>>>>> -- 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Kingsley Idehen	
>>>>> Founder&    CEO
>>>>> OpenLink Software
>>>>> Company Web: http://www.openlinksw.com
>>>>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>>>>> Twitter/Identi.ca handle: @kidehen
>>>>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>>>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>> 
>>>> 
>>> 
>>> -- 
>>> 
>>> Regards,
>>> 
>>> Kingsley Idehen	
>>> Founder&   CEO
>>> OpenLink Software
>>> Company Web: http://www.openlinksw.com
>>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>>> Twitter/Identi.ca handle: @kidehen
>>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> Founder&  CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/