Re: Slash URIs and WebID Experiment

On 1/11/12 4:32 PM, Henry Story wrote:
> On 11 Jan 2012, at 21:36, Jürgen Jakobitsch wrote:
>
>> hi,
>>
>> this image [1] actually illustrates the situation quite well...
>> the verifi-cat-ion is the moment of truth for the webID.
>> in case the webID is a non-# uri it is either a name or an address, 
>> it can't be both by definition.
> I like the picture.
>

Henry,

> The other way to say it is, the meaning of the URI is given by 
> dereferencing it, in either case.
> (The Web is a mapping from URIs to meanings 
> http://blogs.oracle.com/bblfish/entry/possible_worlds_and_the_web )

Hmm.

You have an Object that Represents something. Said thing (an Entity) has 
a Name (an Identifier).

A URI is an Identifier. So we are just dealing with a new kind of Object 
ID. One that is network aware and protocol agnostic.

An Object is endowed with Identity distinct from its values 
(Representation).

You de-reference an Object Identifier to access the Object's 
Representation. They are not the same thing. You know that anyway. At 
least, I've since evidence of your possessing said knowledge. I remember 
your: 1 + 1 = 2 (or something like that) example in a thread with Peter.

>
> If the URI returned is not 303 then by http it names an information 
> resource (i.e. a foaf:Document )
> otherwise it can name anything else.
>
> If it is in the SAN then it is a foaf:Agent.
>
> So we then have these questions:
>   - are  a foaf:Document and a foaf:Agent non overlapping classes

They are disjoint, you know that.

>      - if they are overlapping, is this a case of where they are?

See comment above.

>      - if they are not overlapping, or this is not a case where they 
> are overlapping
>          + is this something the verifier should care about.

Warmer ...

>            how deeply should it care?

Warmer ...
>            what are the security risks it takes by not caring
>            what non security risks does it take by not caring

Irrelevant at this stage, we are trying to make sense of:

1. WebID spec
2. Cool URIs
3. Linked Data.

>
> The other option is that SAN's are just a bit fuzzy, sometimes they 
> name documents,sometimes they name agents.

Warmer....
> But then the protocol soon gets more complicated, and the question is: 
> is it really worth it.

And we are home!! And home means this: WebID is a system that has either 
High or Low Linked Data fidelity. It just cannot be both. That's not 
possible.

"Check!"

>
>> in case the server did not respond with 303 seeOther, it seems to be 
>> a common agreement,
>> that the uri is an information resource [2], in other words it's an 
>> address.
>>
>> =>  now accepting said uri, from which we now know that it's an 
>> address, means accepting
>>    login from a document about a foaf:Agent which is in sharp 
>> contrast to the spec :
>>
>>    "WebID : A URI that refers to an Agent - Person, Robot, Group or 
>> other thing that can have Intentions."
>>
>>    "WebID Profile or Profile Page
>>     A structured document asserting the relationship between the =>  
>> Subject (identified by his WebID)<= "
>>
>>   and therefor WRONG.
>>
>> the tricky part is to understand that although you have all triples 
>> for authentication at hand, you must not
>> even start to look for modulus match and stuff, because you would 
>> authenticate the document.
> IF you were being very precise yes. Otherwise you could continue with 
> the proviso that there was an error in the
> HTTP headers, or somewhere else.
>
> What are the well known practical issues with confusing objects with 
> documents?

Come on now!

> Well things like the following come to mind: If you do that you can  
> no longer name the document without also naming the thing. If you want 
> to say the document was created on a certain day you also end up 
> saying the thing was created on that day, etc... And soon you have to 
> introduce ambiguity along the whole chain.
>
> But is that relevant to the authenticator?

Come on now!

>
> I don't think that for security reasons it is directly relevant, 
> though it will lead to confusions.

Oh yes it would!

So once again, we arrive at the effects of the http-Range-14 imbroglio. 
The Linked Data luxury tax.

>   So I would say that if one were to go down this line, one would not 
> say MUST not, but rather MAY not, or something weaker. Unless you can 
> develop a scenario where things are problematic.

Ambiguity == Insecurity !!!

Links:

1. http://en.wikipedia.org/wiki/Object_theory -- Object Theory
2. 
http://www.cs.cmu.edu/~clamen/OODBMS/Manifesto/htManifesto/node4.html#SECTION00022000000000000000 
-- Object Identity .


-- 

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