Re: Matter of DN and what's possible

On 1/9/12 5:43 PM, Mo McRoberts wrote:
> On 9 Jan 2012, at 22:28, Kingsley Idehen wrote:
>
>> On 1/9/12 5:22 PM, Mo McRoberts wrote:
>>> On 9 Jan 2012, at 22: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?
>>> Because the behaviour is extremely well-defined with a #-style URI? That's (partly) why they exist…
>> You are wrong!
> I beg your pardon?
>
> To spell it out:—
>
> If I have a URI of http://example.com/foo#f
>
> A request goes to example.com:80 for /foo, it returns a document containing descriptions of:
>
> #a
> #b
> #c
> #d
> #e
> #f
> #g
> #h
>
> The consumer picks out #f. Straightforward. So how, exactly, am I wrong, given the question that you asked?

The question is about URIs. I asked why would that not apply to # style 
of URIs? You respond with # URIs being clearly defined. So I ask you 
again: what do we do with HTTP URIs that aren't so well defined? Can we 
use them in SAN or not? If so, your end game is all about mandating a 
particular style of URI.

I state you are wrong on the basis that WebID cannot and should not 
enter the realm of mandating a style of de-referencable URI. That's broken.

My original question (which Jurgen clearly understands) boils down to: 
how do we handle the following in SAN:

1. multiple HTTP URIs - when the function/role varies e.g., one is a 
Name and the other a Descriptor Document Address
2. multiple URIs - when the function/roles var
3. multiple URIs - where function is intuitive e.g., clear sense of Name 
and clear sense of Descriptor Document Address (of information Resource).

An when that's ironed out to conclusion. What happens when the above 
proves problematic to implementors since they bear the burden of Name / 
Address disambiguation.

And as for Henry's SPARQL pushback, the query is irrelevant is the 
target of the query is a description documents (or information 
resources) bearing relations with the correct semantics. Basically, my 
comments ultimately have no bearing on the SPARQL.


>
>>>> 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.
>>> WebID itself doesn't care.
>
>> If it didn't care why do you make the statement about # URIs. Talk about URIs, even HTTP URIs, but not a style of HTTP URI. That's totally broken beyond repair.
> Which statement, exactly?
>
>>> A verifier looks for the subject in the resource it gets back by dereferencing that URI. It matters _not one bit_ to the relying party whether it’s a #-URI or not.
>> Please make up your mind. You just stated that: ".. Because the behaviour is extremely well-defined with a #-style URI? That's (partly) why they exist…" .
> Good lord. I’m almost completely certain that you know how this stuff works, why are you asking these basic questions?
>
> I stated that picking out a single subject from a resource containing descriptions of many resources was well-defined with #-style URIs. WebID, on the other hand, only cares if that actually needs to happen.

Again, digest my point above re. multiple URIs in SAN. Or simply wait, 
Jurgen will get Henry there. And by there I mean, proving that the 
SPARQL ASK pushback was utterly irrelevant. The query will still work if 
the semantics in the description graph are correct.

>
> You can make YOUR WebID http://example.org/cgi-bin/webidapp.pl?userid=328145 if you like, provided that<http://example.org/cgi-bin/webidapp.pl?userid=328145>  is described as a subject with a key matching that in your certificate. Will it cause problems with other applications beyond the verifier itself? Quite possibly. Will the WebID verifier itself need to care? No.
>
>> So how do we handle other de-referencable URIs that are not so well-defined, to use your characterization?
> If you'd actually read what I was replying to, I’m not sure you'd be asking that question.
>
>>> The fact is, however, that the vast majority of people don’t NEED to care if they're following recipes and patterns (and it's been emphasised at length that people will be…)
> Both Peter and you have both talked about “copy&  paste” users, no? They don’t need to understand the finer points of HTTP in order to copy and paste a snippet — just to be able to follow a clearly laid-out pattern.

Trouble is this: a # HTTP URI is one style of URI. Like all things, it 
has its strengths and weaknesses. Thus, you cannot mandate it for use 
with WebID (overtly or covertly). WebID should stick to being about 
de-referencable URIs, but it has to understand that withing the URI 
abstraction there are two critical roles: Name and Address.


> 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