RE: Another Translator for RDF

Lets take this rather more slowly (or perhaps, have a phone call with folks at your level). This is way over my head. I'm down at compiling against crypt32.dll, marshalling bytes across DLL calls so dot net can call windows binary crypto and cert libs (from 1995 era). Thats all Im good for, these days. To me, I saw a translator of formats, from RDFa serialization to TTL serialization. This was a layer 6 function, from one presentation data value to another, in different syntax/format. It made an output that visually looked just like an old LDIF file. It was very natural. There were facts about the object, and facts about the container. The object has an X.500-like object class (with some schematically-correct attributes, with types and syntaxes), and the container has an implied object class (container). Furthermore, the schema of object classes is also in the directory (I mean web). ONe could even determine that cert:certificate is an improper attribute for the object class of the whose distinguished RDN is "me" This is how I think. It has nothing to do with how Im supposed to think (which is just too hard for me).  But, me and a million others can think like this, now TTL is making it all look like an LDIF fie.  Then there is X500 information model, which gets us into names vs address, and dualities. The X500 world was easy: white pages with real objects on the heap, and yellow pages pointers on the stack making references to the heap. Thats it. The web is more complex in its identity model, facilitating theorem proving. This is beyond me, these days, however. When I considered putting the translator URI in the SAN cert pointing to a TTL stream  - rather than the pointer to an RDFa stream - it was to engender clarity. I was not Infact intending to be making a identity statement, about 2 SAN URIs, or what such double referencing SHOULD/MUST/OUGHT to mean (in a object theory sense). I think this is what you did, though. I think I have just learned (and im leaping here) that there is just like in C++ a magic #fragment name called "this". I dont have a literal in my stream named #this, though - any more than I have such a literal in C++ structure. OK. Wonderful. That makes sense (by analogy with C++). I now have a way to always name what is otherwise an address (causing endless fuss). So, now I have a collection of SAN URIs in a signed cert blob. The original idea was: mr validtor, pick one, any one, and do your de-ferencing trick. Oh, and then do a sparql query to run a matching rule. In my mind, this was no different to getting the X.500 object at a DN from a DSA (that might chain off elsewhere), and running the X.500 matching rules for the attribute once the entry was provided, where the value of said attribute (cert:key) is a compound ASN.1 type of definition SEQ { int mod, int exp }. The matching rule is able to match values of compound types. You have on this list in David Chadwick a world expert in doing just such definitions. To my mind, what Henry now has is directly equivalent. But you went further. You invite me in my yorkporc entry to assert an owl:sameAs relation (hope thats the right term, and not "property") to what I though of as an onthe fly transacltion of bit formats. But, you are saying, in web identity theory, no : go futher. Its not just a codec translation. What OPTIONALLY some validator (with the optional OWL reasoner) can do is be more calculating. I can be making equivalency assertions between identity names, and not just locatiing service endpoints which transform bit formats, much like a UNIX pipeline. Ok I can buy that. And, I see how Im getting what our OASIS friends were offering with the XDI graph model, when talking about XRI synonyms in a non RDF basis. Here, we OPTIONALLY stay within (I think) the RDF theory of EAV, but for security/key management purposes, we get to apply some of the synonym theory (to help address practical life issues, and some of the needs of security doctrine). Perhaps, it will sort out the apparent mess I described in my blog post recently, concerning 7 layers of identity following, in the openid world. it becomes something that one CAN reason with. So, if I add that owl:sameAs as relation to the yorkporc2 entity pointing at (referring to?) the translation service's URI (agumented by the magical #this), to a validation agent that is RUNNING OWL, it gets to offer a higher assurance validation logic. This goes beyond (1) the matching rule of the spec, and goes beyond (2) Bergi's walking a triple collection. Ok. Do we have 3 levels of identity assurance, executed at different validation agents with different levels of sophistication for reasoning. (Hmm. I lost a million dollars in the ValiCert startup for certs, becuase evidently it was 7 years too early in its business plan!) If ODS says its valid, there is more assured than if Bergi say its valid. Providing we agument the spec so the requestor of validation can KNOW which class of assurance during validation was used, Im sold.                    .                  > Date: Thu, 29 Dec 2011 22:28:54 -0500
> From: kidehen@openlinksw.com
> To: public-xg-webid@w3.org
> CC: imitko@openlinksw.com
> Subject: Re: Another Translator for RDF
> 
> On 12/29/11 9:12 PM, Kingsley Idehen wrote:
> > On 12/29/11 12:32 PM, Kingsley Idehen wrote:
> >> On 12/29/11 12:26 PM, Kingsley Idehen wrote:
> >>> I meant:
> >>>
> >>> <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3#this> 
> >>>
> >>> wdrs:describedby
> >>> <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3> 
> >>> .
> >>>
> >>>
> >>> Put this in your browser for implicit indirection effect:
> >>> http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3#this 
> >>> .
> >> Peter,
> >>
> >> seeAlso:
> >>
> >> 1.  
> >> http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http%3A%2F%2Frdf-translator.appspot.com%2Fparse%3Furl%3Dhttp%253A%252F%252Fyorkporc2.blogspot.com%252F%26of%3Dn3%23this&useragentheader=&acceptheader= 
> >> -- URI Debugger output
> >>
> >> 2. 
> >> http://validator.linkeddata.org/vapour?vocabUri=http%3A%2F%2Frdf-translator.appspot.com%2Fparse%3Furl%3Dhttp%253A%252F%252Fyorkporc2.blogspot.com%252F%26of%3Dn3%23this&classUri=http%3A%2F%2F&propertyUri=http%3A%2F%2F&instanceUri=http%3A%2F%2F&defaultResponse=dontmind&userAgent=vapour.sourceforge.net 
> >> -- another Debugger (but it suffers from RDF/XML specificity so jump 
> >> to its conclusion re. Object/Entity Name / Descriptor Resource 
> >> Address disambiguation) .
> >>
> > Peter,
> >
> > A correction to the above.
> >
> > URI in SAN: 
> > http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1 
> > <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1>#this 
> >
> >
> > Means that in your (X)HTML you need to add the relation:
> >
> > <http://yorkporc2.blogspot.com/#me> owl:sameAs 
> > <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1 
> > <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1>#this>  
> > .
> 
> First off, cut and past fix for the relation. It should be:
> 
> <http://yorkporc2.blogspot.com/#me> owl:sameAs 
> <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1#this> 
> 
> 
> >
> > Please add that to your posts and repeat your tests with our 
> > validator. The relation above is crucial, I completely forget to 
> > mention that :-(
> >
> 
> In addition to the above, if you have two HTTP URIs in SAN:
> 
> 1. http://yorkporc2.blogspot.com/#me
> 2. 
> http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1#this 
> .
> 
> A WebID verifier should really assume that you are claiming that:
> <http://yorkporc2.blogspot.com/#me> and 
> <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3&html=1#this> 
> are co-references for the certificate's subject .
> 
> Basically, that claim is signed and verifiable. One could go the extra 
> mile on the IdP side and also sign the claim. But that's for another 
> time, once we are beyond the basics :-)
> 
> 
> Hopefully, no cut and paste craziness this time around .
> 
> 
> Kingsley
> 
> 
> -- 
> 
> 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
> 
> 
> 
> 
> 
>