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:48 PM, Kingsley Idehen wrote:
> 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 
> .
>

Also remember, you can also SPARQL ASK in the form:

PREFIX : <http://www.w3.org/ns/auth/cert#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

#Pragma for forcing retrieval from source that overrides default cache 
invalidation scheme, so remove comment from line below if required.

# DEFINE get:soft "replace"


ASK FROM 
<http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Home/About> 
WHERE {
<http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Home/About#me>  
:key [
:modulus ?mod ;
:exponent ?exp ;
] .
}

-- 

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