Re: WebIDRealm RDFa

On 1/5/12 6:39 PM, Jürgen Jakobitsch wrote:
>
> ----- Original Message -----
> From: "Kingsley Idehen"<kidehen@openlinksw.com>
> To: public-xg-webid@w3.org
> Sent: Thursday, January 5, 2012 10:46:49 PM
> Subject: Re: WebIDRealm RDFa
>
> On 1/5/12 4:04 PM, Jürgen Jakobitsch wrote:
>> peter,
>>
>> with "visuals" do you mean the look of the WebIDTestServer [1]?
>>
>> if yes :
>>
>> WebIDRealm has absolutely no visuals packed. it has nothing to do with a whatever frontend.
>> What you see, when you browse the WebIDTestServer is a normal spring application
>> on a tomcat.
>> it uses WebIDRealm in the background for authentication and authorization.
>> for more information on realms see here [2].
>>
>> wkr j
>>
>>
>> [1] http://webid.turnguard.com/WebIDTestServer/
>> [2] http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html
> What we need is a debugger for WebID. Something like:
>
> 1. http://validator.linkeddata.org/vapour -- debugs the Name/Address
> disambiguation issue re. HTTP URIs re. Linked Data
> 2. http://linkeddata.informatik.hu-berlin.de/uridbg/ -- debugs HTTP URIs
> in general .
>
>
> ok - got ya! i'll prepare a debug section with all exceptions on my testServer and let you know to check it out.
>
> wkr j

Great!

Kingsley
>
>
> Kingsley
>>
>> ----- Original Message -----
>> From: "Peter Williams"<home_pw@msn.com>
>> To: public-xg-webid@w3.org
>> Sent: Thursday, January 5, 2012 5:07:46 PM
>> Subject: RE: WebIDRealm RDFa
>>
>>
>>
>> I find great utility in all three endpoint that act as a dumb validator (FCNS, FOAFSSL, ODS). I've not found much utility in the conformance test suite, to be honest. But, I think that is becuase "its not for me". its for the folks doing the middleware, the data service providers, etc.
>>
>> I regularly use FCNS tester site (which spits out how it decoded the cert for the required fields, which URIs it tried to match, and how it succeeded). It then outputs its intputs (as base64 cert), and its output (which matching values matches, from the graph and from the cert). If it was in EARL, I would not use it. What it does is normal and perfect. Its what I expect all my programmers to do, as a sanity mode of operations.
>>
>> Henry servers an equivalent endpoint, that again is similar to what Id expect an interceptor's logging output to be. I call it FOAFSSL, and it contrasts with FCNS in behaviour. This is what makes it interesting. If its output was in EARL, I would not use it.
>>
>> ODS has a very similar endpoint, except that it doesnt state its workings (as do the other two). It just gives pass/fail. its not as interesting, as it doesnt point out the flas in webid itself (comparing and contrasting with FOAFSSL behaviour and FCNS behaviour, for the very same inputs)
>>
>> The latest site from Jurgen is less good, since it mixes visual with debug output. Ideally, i want NO visuals (and no drama).
>>
>> The original test site from foaf.me still works, but may no longer comply with the query's of today or the more recent vocab. I used it the other day, and abandoned it.
>>
>> My own equivalent (that spits out lots of custom exceptions) is still only available in intranet form (i.e. build the zip source). Attempt to port it to 64 bit Azure failed, as its based on 32 bit libaries produced a decade ago. marshallng between 32 bit and 64 bit world is just beyond my time resources. I can hardly even read such code either (being in old microsoft win32-era coding standards).
>>
>> Most of these tools look like they were built as spinoffs of an early Henry idea (in which a webid validator turns into an IDP, and signs its validation response using a signature in a URL.). Rather than actually bother delivering such an endpoint (that allows a RP site to ping such an IDP to get a signed copy of its final decision), it allows me the browser user to see what the IDP does as it goes through its state machine. Its a functional debug output, that is, like a billion other software engineering projects.
>>
>> These made ideal system integration style endpoint, particular when their behaviour differs. If there were spitting out earl, I would not have used them (as I dont want to learn to speak EARL, not having yet learned to speak webids evolving language). Dont make the clasical error of requiring the technology you are developing, to develop the technology. It always fails. You compile windows souce on the last version, not the version you are still compiling. (GNU may be different, but then those guys are geniuses from a different planet to me)
>>
>> we should distinguish between
>>
>> (a) an interceptor-class implementations functional test output, allowing for normal protocol debugging. One gets to see how the engineer enforce the rquired behaviour through its state machine. There should be N of these, of which Im responsible for 1 (on windows). It has little nor nothing to do with semweb middleware. It has everything to do with webid-specific use cases (that build on what semweb is middleware is supposed to be able to do).
>>
>> (b) a conformance suite, of which there is 1 implementation only (delivered by a gold-standard vendor, whoc "just groks it" and somehow always expresses things "best".). Myopenid was that, in the openid land, being the "most natural" expression, which sits nicely in its intended place. Each product-grade interceptor of class (a) should go to (b), during conformance test week. Ideally, one does this together, so folks who know EARL can read it and interpret whats its telling about the functional implementaiton (and how to get over some subtle point that is impeding webid use case coverage).
>>
>> This is normal product engineering, based on standards. Oned bothers with stnadards and not proprietary tech when one wants an open market, usually becuase the tech is reaching commodity point (and its value is dropping, as reserach from a decade ago has matured). The commoditization extends the life of the core tech, giving it a new lease based on competitiion in value-adding (as folks compete). Typically, lots of fun integration happens at that point, as folks take things off the shelf, and stuff them together - for some widget advantage.
>>
>> In my work on an class (a) implementation, still on going as I attempt full coverage of the core use cases, Ive managed to offload the semweb parts to a sparql server, rather than doing an local query. this was not as easy as I thought it would be. Though Kingsley solves the query problem each and every time, any time I then alter any one element (to extend the use case to fuller coverage), it just stops working. This is a "me wall" (which may be telling, or not). So, Im going to now follow up on the OTHER integration option ODS offers, in which I simply present the cert blob to the ODS endpoint that does EVERYTHING. Rather than issuing a quer,y I present an nputs and consume the decision result. then I can get back to what I care about, which is the webid use cases for authn and authz.
>>
>> Dont force everyone into being a middleware enginer. And, dont make webid about making the middleware (that is then required for webid).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Date: Wed, 4 Jan 2012 21:43:09 -0500
>>> From: kidehen@openlinksw.com
>>> To: public-xg-webid@w3.org
>>> Subject: Re: WebIDRealm RDFa
>>>
>>> On 1/4/12 8:08 PM, Henry Story wrote:
>>>> On 5 Jan 2012, at 01:45, Kingsley Idehen wrote:
>>>>
>>>>> On 1/4/12 7:42 PM, Henry Story wrote:
>>>>>> On 5 Jan 2012, at 01:37, Henry Story wrote:
>>>>>>
>>>>>>> On 5 Jan 2012, at 01:27, Kingsley Idehen wrote:
>>>>>>>
>>>>>>>> On 1/4/12 7:16 PM, Henry Story wrote:
>>>>>>>>> On 5 Jan 2012, at 01:09, Kingsley Idehen wrote:
>>>>>>>>>
>>>>>>>>>>> But anyway, clearly you don't want to work on a common test suite to help new people join.
>>>>>>>>>> See my opening comments. It's been done before, many times over with standards much more complex than WebID, used by masses of people world wide.
>>>>>>>>> Ok. So are you against a webid test suite then? Yes/No
>>>>>>>> FWIW - No.
>>>>>> Oops, that was probably meant as "No I am not against a test suite" (the FWIW confused me)
>>>>>>
>>>>>> :-)
>>>>> Yes, my parser works :-)
>>>> Great. Now the next question is: are you prepared to help with the project of building an open source test suite?
>>>>
>>>> What would you find a reasonable thing your end point can provide so that test suites could hook onto it, and build up a report? I am speaking about an end-point such as http://id.myopenlink.net/ods/webid_demo.html but others could be ok. What can it produce that would be easy for a test suite to consume?
>>> Is there a test suite outline somewhere? Note, we've done similar with
>>> SPARQL that included EARL reports. What's the equivalent for WebID?
>>>
>>> If there isn't an outline, just look at how its being done re. SPARQL.
>>> Each vendor runs through a set of tests and products an EARL based report.
>>>
>>> If you need more information from our verification service, please
>>> specify, or point to an existing service that is providing required
>>> information.
>>>
>>> Note: http://id.myopenlink.net/ods/webid_check.vsp , the verification
>>> proxy service which supports callbacks etc. I know Peter used this
>>> successfully a while back.
>>>
>>> Kingsley
>>>> Henry
>>>>
>>>>
>>>>> Kingsley
>>>>>> Good so then, how do you think we should go around to do that simply?
>>>>>>
>>>>>> It's nearly 2am here, so I'll go to sleep.
>>>>>>
>>>>>> See you tomorrow.
>>>>>>
>>>>>> Henry
>>>>>>
>>>>>>> Why? What would be the problem with having an OpenSource set of tests to help newcomers who produce new WebID Protocol endpoints to run a bunch of tests against it to find out if they are WebID compliant?
>>>>>>>
>>>>>>> Did we not in this thread use a whole bunch of tests suites/validators? For RDFa, for RDF/XML etc....
>>>>>>>
>>>>>>> Were they not helpful?
>>>>>>>
>>>>>>> It would help if you explained your position more clearly because it could be that we have a misunderstanding between what you think I am talking about and what I think I am talking about.
>>>>>>>
>>>>>>> Henry
>>>>>>>
>>>>>>>
>>>>>>>> Kingsley
>>>>>>>>> If yes, how do you think we should proceed.
>>>>>>>>> If no, why do you think we should not have one?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Perhaps WebID would be just too simple then....
>>>>>>>>>> No comment :-)
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Social Web Architect
>>>>>>> http://bblfish.net/
>>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>


-- 

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