Re: Matter of DN and what's possible

On 1/9/12 6:58 PM, Henry Story wrote:
> Please Kingsley try to read through my response first before you respond.
>
> On 10 Jan 2012, at 00:25, Kingsley Idehen wrote:
>
>> 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 .
> yes, you did last December in a Skype conversation. But anyway.

Yes, but that particular URI is potentially problematic due to issues 
with cert:key relations sometimes being lost from the graph. Thus, I 
don't need it in the mix until I know that issue associated with that 
particular URI has been resolved. That's why I used: 
http://id.myopenlink.net/dataspace/person/kidehen#this for the verifier 
experiments over the weekend. I wanted to ensure the test specimen was 
devoid of an potential distractions.

>
>>> 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.
> No I am just saying that you have resources on your servers that contain definitions for more than one entity.

Yes, but that really isn't what matters re. the debate hand. Put 
differently, going down the path of that particular URI isn't the 
shortest path to resolving the topic of debate.

The utility of a # URI based Name comes boils down to the fact that the 
Subject Name / Descriptor (Information) Resource Address disambiguation 
is implicit -- no content negotiation required since you don't need to 
leverage/enlist 303 redirection.

> So the question then is if a SAN URI refers to document, and if we don't use the SPARLQ ASK query currently defined, which of the entities are we speaking about.

Neither Jurgen nor I are speaking about a sole URI in the SAN of a 
certificate that serves the role of descriptor (information resource) 
address. We are talking about the scenario where you have > 1 HTTP based 
URI in SAN and both URIs serve different functions. Basically, you hit 
this issue if you have > 1 HTTP URIs in SAN and they aren't # based:

1. <SlashURI-A> -- Locator/Address
2. <SlashURI-B> -- Description Subject.

Who bears the burden of disambiguation? Is it the publisher, verifier, 
or both?

Now, if the position is that WebID covertly mandates # based HTTP URIs 
for SAN, then fine, I don't agree with that position at all, but let's 
establish that reality and associated implications.

>
> But if we do use the SPARLQ ASK query defined in the spec
>
>     https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#verifying-the-webid-claim
>
> then it is of course not a problem what other relations the document claims about the URI defined in the X509 spec. The profile could after all say that you are superman, and that you are just fighting a superheroin from another planet.

The issue is Location of the graph. With a # Based HTTP URI based Name 
you have > 1 level of indirection i.e., the Name resolves to the 
descriptor (information) resource that bears the graph processed by the 
SPARQL Query. If you use any other form of URI the scope of the graph 
isn't implicit by way of de-reference, thus, you need indirection 
delivered some other way, that's where the 303 comes into play re. HTTP, 
but one could negate that by allowing the SAN support multiple HTTP URI 
based Names, and when the style is slash based a verifier has to look to 
more than one of the URIs as the graph locator (address). Likewise, when 
a publisher is making their idp space claims, using slash based HTTP URI 
names, they follow the same doctrine re. multipe HTTP URIs in SAN 
knowing the roles vary.

At the start of this whole affair I assumed there was clear 
understanding of this matters, clearly this isn't the case. Most of my 
thoughts on this matter go beyond what I've outlined since I see it 
confusing and burdensome (potentially) to all parties involved. This is 
why I started gravitating to a new location for the Locator (Address) 
for the description graph. First point of call was via CN and the 
current point of call is the Subject Information Access slot.

The endgame here is that publishers and verifiers don't get tangled up 
with Name/Address disambiguation.

>
> So since you think the SPARLQ query defined in the spec is not a problem, we can agree that the # uri or not discussion is not a problem for the spec.

It depends on the guidelines for multiple URIs in the SAN. Dealing with 
slash HTTP URIs and URIs for other schemes.

> So there is in fact nothing we are disagreeing on that has any practical consequences, it seems.

Incorrect.

>
>>> 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!
> Does this have a practical consequence we should be aware of that we you can describe and that we can reproduce?

Jurgen will get you there.

> Because otherwise it is like counting how many angels fit on the head of a pin.

Maybe to you. That isn't how I see things at all.

>
>>> 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!
> Good remember this response of yours "of course not" . Ie you are ok with that query
> Ie we don't have a problem with # or no uris.

The query works when it is scoped to a graph. The problem is setting the 
scope of the graph via a resource locator.

The horrible problem here is conflation all over the place.

Resource is conflated term as per information resource (descriptor) and 
non information resource (description subject).

HTTP URI is conflated because a de-referencable URI can serve as a 
Locator (Address) or a Name.

You have a double whammy and it will eventually torpedo this effort, if 
you don't take a close look at what I am trying explain to you.

If you don't believe me, just ignore me, the problem is inescapable!

>
>> 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.
> yes, with the SPARQL query above the spec does not ask the verifier to decide the coherence of the rest of the document. At least it is not up to us to make that decision.

See my comments above.

You are simply inheriting as problematic narrative re. Linked Data. Why 
do you think people struggle with Linked Data deployment? Why do you 
think people even struggle with its basic definition? It's nuance laced.

>
>> If a verifier can disambiguate Name/Address roles of URIs in SAN the query will work unchanged.
> I don't see why the verifier has to make that distinction.

Good, and that's where we differ.

You are really saying: the verifier should just de-reference what's in 
the SAN. Thus, what happens when there are many URIs in the SAN?

>
>
>> If any modification is need at all, and that's a  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.
> The from clause is explained in the text of the SPARQL query. the graph is the one fetched by dereferencing the URI.

As I outlined above, that is the position you are taking, so please 
explain how it works with multiple HTTP URIs in SAN where these aren't 
necessarily # based. Even better how would it work with a mix of URI 
schemes?

Now, let's say you somehow navigate the above from the verifiers 
perspective, what about the publisher? Ultimately, the publisher is the 
biggest problem point of all.

>
> The verifier:
>    1. fetches the remote document
>    2. transforms it to rdf
>    3. queries that graph with the above SPARQL query after having replaced the variables

The verifier actually does the following:

   1. fetches the remote document by act of *URI de-reference*
   2. queries that graph with the above SPARQL query after having replaced the variables .

What happens when there is>  1 URI to de-reference?


>
>>> 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.
> why? Can you develop that?

I don't understand your question.

Do you support > 1 URIs in SAN or not?

Implementing that fidelity is a non issue, for us. But that's besides 
the point.

>
>> 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.
> There are two queries above. In fact there is one query template which produces two queries.
>
>> Of course, once we do the owl:sameAs semantics dance, we loop back to the imbroglio about signed claims etc..
> Ah perhaps changing topic?

No, again, what happens if there a multiple URIs in the SAN? How does 
the query get to work properly without being altered ?


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