Re: My slightly comments

On 1/10/12 2:37 PM, Henry Story wrote:
>
> 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.

You say:

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.

But there is some conflation that ultimately leads to confusion:

You are talking about a URI that resolves to a Resource. The naming, in 
this context, relates to a Location (Address). Basically, the sense here 
is URL. Of course, if you want to stick with the Name sense, then you 
have to introduce the fact that indirection occurs. You also have 
introduce the fact that whats retrieved is a description for which the 
URI is the subject.


You retrieve data from an Address, and transform it to RDF en route to 
performing a lookup oriented query.

To illustrate:
Name.Address.Data (or Resource) -- greater than 1 level of indirection 
since Name is the focal point of data access.
Address.Data (or Resource) -- 1 level of indirection since Address is 
focal point of data access.

We understand these matters, but we just can't assume they are clear to 
readers.


>
> 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.

You have data in a negotiated representation. Or a negotiated 
representation of data. That's what's streamed across the wire.

>
> 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?
>
>  1. The WebID Verifier must get access to an up to date version of the
>     WebID Profile Graph.
>      1. If the WebID Verifier has an up to date version of the graph
>         in its graph cache then it can return it
>      2. 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
>         <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#bib-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
>         <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#bib-RDF-MT>]
>         as specified in Processing the WebID Profile
>         <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#processing-the-webid-profile> .
>         This graph may be cached.
>  2. That graph returned in the previous step is then queried as
>     explained in Verifying the WebIDs
>     <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#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.

Kingsley
>
>
>>
>>
>> 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 
>>>>>> <http://www.openlinksw.com/blog/%7Ekidehen>
>>>>>> 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 
>>>> <http://www.openlinksw.com/blog/%7Ekidehen>
>>>> 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 
>> <http://www.openlinksw.com/blog/%7Ekidehen>
>> 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