Re: Matter of DN and what's possible

On 1/9/12 5:44 PM, Henry Story wrote:
> On 9 Jan 2012, at 23:15, Kingsley Idehen wrote:
>
>> 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?
> Why would it not? You remember how you asked me to download

Henry,
>
>   http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen

We've done some experimentation over the weekend, in public, at no point 
in time did I refer to the URI above. I referred to: 
http://kingsley.idehen.net/dataspace/person/kidehen#this .

>
> which contained 1 MB of information with the webids of thousand of people? It's no longer functioning.

Irrelevant. You are supposed to be looking up a relation. Instead you 
are responding with yet another example of what can go wrong with # URIs.
>
> You say, that Jürgen is saying that when he puts a document URL in the SAN he is saying that, and I quote
> " a document at an address holds my description"
Note, I said: HTTP URIs with varied roles:

1. name
2. address.

I am not doing the conflation thing with URIs. That's part of the 
problem with Linked Data!

>
> Good so he is not saying which description, then right?

He is saying: this the referent of URI-A is described by the Document at 
accessible from the Address/Location: URL-B (or technically, if we play 
the conflation game: URI-B).

>   So it could be any identity in there. If the meaning of the SAN is:
> a document that contains the description of the Subject then the following query won't do.
>
>>> 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!

Well, imagine you had FROM: URL-B or the backend didn't care, it would 
still find the relation as part of its WebID verification protocol 
implementation. It just needs to find a relation between a URI in the 
SAN of a Cert. and the Certs. Public Key.

If a verifier can disambiguate Name/Address roles of URIs in SAN the 
query will work unchanged. If any modification is need at all, and 
that's a i big IF, it would be the addition of a FROM CLAUSE which 
ultimately takes us dead center into yet another problem re. conflicting 
interpretations of Named Graphs across SPARQL and RDF realms.

> Well you are saying that. Anyway. That is why putting things down clearly in logical language
> helps to make progress.
>
>
>>> 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.
> They are very useful, as they have clear semantics. So that we can communicate better.
> They allow us to focus on something precisely.

And the acid test is that multiples SAN should require the queries to 
break. A verifier would end up de-referencing the correct data. An if 
owl:sameAs semantics are applied to the multiple URIs in SAN, the net 
effects is a graph that will work with the query above.

Of course, once we do the owl:sameAs semantics dance, we loop back to 
the imbroglio about signed claims etc..

>
>
>> 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
> I was considering that above, but you seem intent on switching subjects towards an http-range-14 discussion. Why not consider the SPARQL query above. It leads to a lot of interesting cases.

I am not moving towards httpRange-14. The issue at hand is part of the 
deal re. HTTP URI based Names.

>
>> 2. an subject Name URI identifies the subject of the description in #1 .
> Ok, that we have covered already in the spec.
>
>
>> All of the above is swept under the covers via the convenience of # style of HTTP URI based Names.
> Well except 2. 1 I want to speak about. That was the second query above.
>
>
>> 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!
> You saw it took about 1 minute to fix these bugs. It's not a big deal. In fact most libraries do it right.

How are you sure of the library count, then the count of those that have 
done it right, and what actually already out in the wild?

>   It is just that some had not patched theirs yet. The Apache http client did do the right thing. We had an issue mostly because the RDFa verifier had a bug. that was fixed the same day.

The issue has popped up via Peter on Windows and then again via PHP, and 
who knows where next? Who is going to coordinate the masses of deployed 
solutions built on broken libraries and frameworks? There are serious 
issues here. This is why DBpedia opted for slash URIs. The goal was to 
just work, no compromise!

>
>>
>> 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.
> yes. as it happens Jurgens graph would pass my verifier, even if he confuses himself with a document.
He isn't confusing himself with a document at all.

The reality here is that right now the URIs in SAN have to deliver > 1 
level of indirection to work. Said indirection may be implicit as 
demonstrated by # based HTTP URI Names, or explicit. Trouble is that the 
explicit option is what is being overlooked or not being understood.

>   It's not my verifier's current interest to know if Jurgen is confused or not.

That isn't the point and Jurgen isn't confused. If he is confused so am 
I, and you know that doesn't compute re. the subject matter of: Linked Data!

>
>> 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.
> The luxury tax!!! no less than that!
>
>
>> At this juncture I leave it to Jurgen. I am confident he'll get you there :-)
> That is pretty pretentious you know. You assume you are right from the beginning.

Please prove me wrong. I beg you!

>   It's not surprising that a conversation with you is like spewing to a wall.

Mirror mirror on the wall..... we'll see who is the semantically fairest 
of them all :-)


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