Re: WebID equivalence

On 1/2/12 5:36 AM, Henry Story wrote:
>> On 1/1/12 11:38 AM, Mo McRoberts wrote:
>>> On 31 Dec 2011, at 17:52, Kingsley Idehen wrote:
>>>
>>>>> Now, because URI-A's document can't be parsed, there's no way to verify that it does contain the triples which confirm the relationship between it as a WebID URI and the WebID certificate, *however* a consumer can look for triples describing URI-A in the document referring to it retrieved from URI-B: in this case, it finds some, and can process them as being equivalent to as if they were asserted about URI-B, but what it cannot do is state that URI-A is an identifier for the certificate-holder.
>>>> Identifier equivalence has been asserted in a signed claim via the use of multiple URIs in a Certs. SAN. The effect here is that we have synonyms so the public key associated with URI-B is now also a relation with URI-A. The fact that we can't make a union of all the data the one could de-reference via URI-A and URI-B doesn't matter re. this kind of equivalence and the resulting assurance.
>>> The problem here isn't the data. Getting the union set of triples is fine.
>> You don't need to get a union of triples. You just need triples that describe any URI in the owl:sameAs relation.
>>
>>>   The problem here is what you consider the URI to be for the certificate holder. As you can't retrieve and process the data for URI-A, you can't treat that URI as belonging to the holder.
>> The Certificate Identifies a Subject. The SAN is a slot for alternative Names of said subject. A composite of alternative names is a signed equivalence claim that may or may not be mirrored in idp space.
>>> It's a subtle point, but it's an important one when you're dealing with synonyms.
>> <URIA>  owl:sameAs<URIB>  means that both URIs share a co-referent. Thus, what goes for one (e.g., public key association) goes for the other, if if the evidence emerges from triples that describe either<URIA>  or<URIB>.  This is all about equivalence by name. You can also have equivalence by values, and you require an IFP predicate in the relation for that. All of this is quite easy to demonstrate.
> Yes, you are right a = b means that a refers to the same thing as b.
> But that is not the problem that needs to be addressed. The problem is whether the claim is true, or likely to be true. Do you believe what URIA-Profile-Doc says about URIA? Well you can believe what it says about terms it defines in that document, since it is master of the terms it defines there. That is why WebID works.
>
> But is the assertion of identity it makes in that document true, when those assertion cross namespaces? That is something that can be doubted and over which there can be disagreement, and so to the degree that it can be doubted so you have a problem of trust. It is the problem of trust that we are dealing with here, which is a layer above the linked data cake.

Of course I understand the layer above the hyperlink driven  linked data 
structure (aka Linked Data). I am referring to assurance that comes from 
the verification of the claim itself. What is WebID if it simply about 
the verification of a single claim?

Why do we have compound and composite keys in the DBMS realm?

Why do we forget that URIs are superclasses of URLs. Thus, you can 
really put compound and composite keys to use inside an X.509 cert. and 
up the ante re. assurances that can be derived from the WebID protocol?

These matters (IMHO) have less to do with the WebID spec. They are field 
usage matters. You don't need to look far as they pop up in the 
Authorization realm.

Look at this:
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
                 OU=FreeSoft, 
CN=www.freesoft.org/emailAddress=baccala@freesoft.org

Where's the rule that states: we couldn't have a resource URL where you 
have: www.freesoft.org and a mailto: URI that resolves as per hammer 
stack. In both cases they resolve to description oriented directed 
graphs. BTW -- the DN is just a compound key.


Where's the rule that states that in the SAN we can have a composite key 
comprised of multiple URIs. Where the URIs in question are the Subjects 
of the description graphs exposed by Addresses in the DN?

I am not necessarily pushing for this to increase complexity of the 
simple WebID spec. But in reality, esp. re., matters that are of 
interest to Peter (and many of similar profile across enterprises), this 
is where the action is going to be and its all doable via SPARQL and 
Linked Data oriented resources.

WebID is for all intents and purposes a simple exploitation of what's 
possible. That's all fine. But in reality (industry level) its quite a 
distance away for the nirvana.

The nirvana is about revisiting and understanding DBMS technology and 
what its always provided once you can front said technology with a 
declarative query language. Especially, one where data access protocol 
and data representation formats are distinct, as delivered by SPARQL.

We are basically exploiting deductive DBMS technology which failed last 
time around re. Datalog due to the non existence of today ubiquitous 
InterWeb and distributed data objects.

We just need to be able to sign claims and then combine that with the 
what's already delivered to use re. X.500 names re. the ability to 
exploit compound and composite keys.

URI abstraction plays extremely well here, but this will play out on the 
commercial product implementation front (e.g., via RWW apps) and less so 
re. the WebID spec goals etc..


Kingsley

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


-- 

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