[foaf-protocols] WebID spec version http://bblfish.net/tmp/2010/08/02/

Henry Story henry.story at gmail.com
Wed Aug 4 19:12:42 CEST 2010

Social Web Architect

On 3 Aug 2010, at 21:01, Reto Bachmann-Gmür wrote:

> On Tue, Aug 3, 2010 at 4:02 PM, Henry Story <henry.story at gmail.com> wrote:
>> On 3 Aug 2010, at 14:58, Reto Bachmann-Gmür wrote:
>>> Hi Henry,
>>> i think the sparql query should go to a non-normative section or to the primer, but the spec should be explicit on the ontological terms (properties and datatypes) the verifying agent must understand.
>> That all depends on what that other document looks like.
> Sure, but it doesn't belong in the authoritative section of the spec.

I think that is not so clear. SPARQL is a well defined pattern language.
Expressing a pattern in SPARQL is a good way of explaining something 
quickly and concisely.

> Clearly Sparql isn't needed to implement a verifying agent,

yes, true. But we don't have to say they MUST use sparql. Just that
they have to get the same effect as a particular SPARQL query.

> also it
> doesn't seem an easy way to present a generic approach so that you
> could say "implementation must do this or something yielding to the
> same result", in fact having the sparql query for all the supported
> datatypes (which should include all xsd-types) seems quite tedious.

Not if we specify literal inferencing engine. Then we don't need to
specify all the different types.

> I must say I don't really understand section 2.2, I would avoid using
> forward references (apart from maybe in non-authoritative overviews).
> Also:
> - Used cached version: I think the cached version is an implementation
> variant, Implementations should be free to use any trusted source
> which include local cache

(that's section 2.5)
I kind of agree with you here.

> - In my earlier draft I specified that authentication shall not fail
> before the verifying agent tried to dereference the WebId: I think
> this provides a balance between leaving alternative verification paths
> open while still satisfying expectations on what happens in the
> process of verification (namely that a key added to the personal
> profile will be accepted)

that makes sense. Where would you put that? And how would you phrase it?

> - I don't understand the part about the cryptographic challenge, as
> far as I understood things WebId is about accepting a client
> certificate and that existing protocols are used for actually using
> this certificate for authenticated communication

I don't understand that either. I think there is an idea of not tying this too
much to TLS. But that seems perhaps like a bit too early a time to do such an abstraction. We should ask the person who put it there.

>> For the moment this is close enough to the core of the protocol, to be worth adding here.
>> The reason we have so many SPARQL queries there is that we are switching to literal notation. If one had to choose the simplest one to keep would be the ASK query.
>> But for that we would all have to agree that the future is literal. We can leave that open for the moment.
> I think the cert-ontology should be kept minimal, and that defining
> datatypes for expressing numbers is out of scope,

That would have been the case had xsd had reasonable types to express
certs in a flexible way (people initially want to cut and paste stuff 
into the html).

> so I think it should
> be reduced to the identity property

What we can do is remove the 
   vs:term_status "unstable";
relations on those relations we feel comfortable with.

We don't know yet what is useful in this space, and so removing
stuff early is just going to create work later. The concepts in there
have been very useful already when discussing a number of other issues.

> (I know about the cute unicode
> hearts you can add to the hex-ecoded key, so the marketing department
> might convince me we should mandate support for them, in another
> ontology maybe?) .

There are other reasons: it's much easier to specify that, and
much easier to progream it, then something that is less flexible. 
We get marketing goodness for free.

Well we could move it to another ontology. But perhaps we should avoid
doing changes like this now. 

> Cheers,
> reto
>> Henry
>>> Cheers,
>>> reto
>>> ----- Original message -----
>>>> Thanks Stephane.
>>>> I have now uploaded some new changes to the spec, incorporating a few of
>>>> your recent changes too. I also added a number of details for the SPARQL
>>>> query.
>>>> These can be viewed online here
>>>>        http://bblfish.net/tmp/2010/08/02/index-respec.html
>>>> Hope this helps,
>>>>     Henry
>>>> On 3 Aug 2010, at 13:42, Stéphane Corlosquet wrote:
>>>>> You should edit index-respec.html as it is said in the README file.
>>>>> index-respec.html uses the respec.js script to format the document
>>>>> nicely, generate the ToC etc. index.html is the static version
>>>>> generated from it every now and then.
>>>>> Steph.
>>>>> On Tue, Aug 3, 2010 at 7:05 AM, Henry Story <henry.story at gmail.com>
>>>>> wrote:
>>>>>> Oh, I noticed I edited the index.html, not the index-resp.html
>>>>>> What is index.html? How does it relate to index-resp ?
>>>>>> (I glanced at the doc,
>>>>>> http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
>>>>>> but could not find an answer to that)
>>>>>> Henry
>>>>>> On 3 Aug 2010, at 01:43, Henry Story wrote:
>>>>>>> I just put some changes up on my version of the spec
>>>>>>> http://github.com/bblfish/webid-spec/
>>>>>>> This can be viewed online here:
>>>>>>> http://bblfish.net/tmp/2010/08/02/
>>>>>>> The changes are mostly to section 2.2, which I rewrote and
>>>>>>> reorganised to
>>>>>> make it a bit clearer. This is not finished of course, and the
>>>>>> formatting is not that good. I did not want to spend too much time
>>>>>> on formatting before getting the wording right.
>>>>>>> So we should for example refer to the rdf spec which defines what a
>>>>>> graph is.   At this level we don't speak about representations at
>>>>>> all. That will be done in the referred sections.
>>>>>>> Henry
>>>>>>> Social Web Architect
>>>>>>> http://bblfish.net/

More information about the foaf-protocols mailing list