Re: neither FCNS nor FOAFSSL can read a new foaf card (hosted in Azure). RDFa validators at W3C and RDFachecker say its fine...

On 12/27/11 9:35 PM, Kingsley Idehen wrote:
> On 12/27/11 5:14 PM, Peter Williams wrote:
>> Ive reached screaming point, despite it sort of working: See 
>> http://tinyurl.com/7zjf77v
>>
>>
>>
>> It only works in what I assume are "advanced validators" - those able 
>> to deal with proxying. Which is not to say that the advanced 
>> validators can use my own data source (and validated against it). 
>> But, assuming Kingsleys system SOMEHOW cleans up my data source (and 
>> turns it into a linked data set), putting the proxy URI in the SAN 
>> alongside the URI does make something work, in some places, sometimes.
>
> Some things to treat as key rules:
>
> 1. only put URIs in SAN that are Object/Entity Names (> 1 level of 
> indirection re. data access i.e., name.address.data) rather than 
> Object/Entity descriptor resource  Addresses ( 1 level of indirection 
> re. data access i.e., address.data)
>
> 2. the resource to which the Name resolves must be comprised of an 
> eav/spo directed graph (serialization formats may vary) in which 
> attribute=value or predicate=object pairs coalesce around the URI 
> based Object/Entity Name re., Public Key relations.
>
> What URIBurner (a Virtuoso instance with its Linked Data Deployment 
> middlware module enabled) does is generate a proxy/wrapper Linked Data 
> URI because of ambiguity its detects when dealing the the URIs used in 
> your Certs. SAN.
>
> In my earlier response I forgot to tell you to also place the #me URI 
> in your Certs. SAN. Thus you would have had the following:
>
> 1. 
> http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Home/About 
> -- descriptor resource address
> 2. 
> http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Home/About#me -- 
> object/entity name that resolves to its descriptor via de-reference 
> (an act of >1 level of indirection) .
>
> If you want to have >1 URIs in SAN, ensure you have two Object/Entity 
> Names rather than an Object/Entity Name and a Descriptor Address.
>
> Your exercise is demonstrating why Name/Address disambiguation is 
> important when HTTP URIs are used as Object/Entity Names. You aren't 
> the first to scream, but you might be one of the last as this exercise 
> may ultimately reveal a new way of explaining what's dogged many for 
> years in this realm.
>
>>
>>
>>
>> I think I learned something, about where webid will get too. ANd, 
>> now, I can at least SEE/CONTEMPLATE the full power of the linke data 
>> model (as it relates to just webid, never mind the rest). Its rather 
>> BETTER than the X.500 subobject/instancing model, particularly if 
>> such as Henrys validator can cast its query to suit the linked data 
>> view (of my data source).
>>
>>
>>
>> What this means for security I dont know; as the traditional notions 
>> of authority have gone out of the window.
>
> Out of the old Window into a new one where logic prevails :-)
>
>

Here is another form of descriptor document for looking at the 
description (relations graph) of the referents of the URIs in your 
certs. san:

http://uriburner.com/describe/?url=http%3A%2F%2Furiburner.com%2Fabout%2Fid%2Fentity%2Fhttp%2Fb3d0c8f68475422784748b65f76b1642.cloudapp.net%3A8080%2FAbout.aspx%23me 
.

-- 

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