W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

Re: Matter of DN and what's possible

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 09 Jan 2012 17:15:33 -0500
Message-ID: <4F0B6705.8000601@openlinksw.com>
To: public-xg-webid@w3.org
On 1/9/12 4:58 PM, Henry Story wrote:
> On 9 Jan 2012, at 22:49, Kingsley Idehen wrote:
>
>> On 1/9/12 4:44 PM, Henry Story wrote:
>>> yes I see. So, you are saying you are a document. Why do you want to do that?
>> He is saying, a document at an address holds my description!
> Ah and what if that document contains the description of 10 people?

But why would it? How does that question not apply to a # style of HTTP 
URI?

>
> Are you saying that the query we should ask should not be
>
> PREFIX :<http://www.w3.org/ns/auth/cert#>
> PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>
> ASK {
>     ?webid :key [
>        :modulus ?mod;
>        :exponent ?exp;
>     ] .
> }

of course not!

>
> as described here https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#verifying-the-webid-claim
> that is after the ?webid ?mod and ?exp have been replaced with the values from the certificate but rather
> should be
>
> SELECT ?webid
> WHERE {
>     ?webid :key [
>        :modulus ?mod;
>        :exponent ?exp;
>     ] .
> }
>
> where only the ?mod and ?exp get replaced?

I don't see the queries being relevant to the critical issue at hand.

A # URI carries implicit de-reference and Name/Address disambiguation. 
Most miss it completely. WebID cannot be about a style of URI. It should 
just be about URIs.

If you have a SAN with multiple HTTP scheme URIs where one functions as 
a Name and another functions as an Address, you put the burden of 
disambiguation on the WebID verifier implementor. Today, most won't be 
able to determine that a SAN has > 1 URIs in it where:

1. a document URL (a kind of URI) holds the description of a subject
2. an subject Name URI identifies the subject of the description in #1 .

All of the above is swept under the covers via the convenience of # 
style of HTTP URI based Names.

So what's wrong with mandating # based URI re. WebID you might be 
wondering? We'll for starters, look at the mess that lies in wait re. 
libraries and frameworks that don't implement HTTP properly i.e., they 
send the # over the wire. Just as experiments here have demonstrated 
repeatedly, and this is right here, the home of the WebID grokers!


Jurgen isn't confused about being a document. He understands that he has 
an identifier that's described by a directed graph borne/carried by a 
descriptor (information) resource (a document type) accessible at an 
address.

There is not escaping the luxury tax that comes with HTTP URI based 
Names re. Linked Data. This is what I continue to try to shed light on.

At this juncture I leave it to Jurgen. I am confident he'll get you 
there :-)

Kingsley
>
>
> Henry
>
>> -- 
>>
>> 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








Received on Monday, 9 January 2012 22:16:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 January 2012 22:16:06 GMT