Re: Foaf-browser-app -- keygen in rdf

On 10/6/11 1:12 PM, Henry Story wrote:
> On 6 Oct 2011, at 16:00, Kingsley Idehen wrote:
>
>> On 10/6/11 8:23 AM, Henry Story wrote:
>>> On 6 Oct 2011, at 14:14, Kingsley Idehen wrote:
>>>
>>>> On 10/6/11 6:11 AM, Bob Ferris wrote:
>>>>> Hi Henry,
>>>>>
>>>>> On 10/4/2011 8:04 PM, Henry Story wrote:
>>>>>> While playing with the very cool Foaf-browser Android application [1], I noticed that there are a couple of things that we need to standardise to make that type of application seamless.
>>>>>>
>>>>>> As it requires having an Android phone which not everyone may have, I put together a little video of the Foaf-browser here
>>>>>>
>>>>>>     http://vimeo.com/30014844
>>>>>>
>>>>> This is an interesting representation of this Social Web Android application.
>>>>>
>>>>> +1 re. the UX/usability remarks
>>>> This tool is a good start, but UX/usability always struggles if the fundamental UI/UX bottleneck of Linked Data isn't addressed. The problem boils down to labels for URIs across TBox and ABox. Pulling it off requires a Linked Data platform that's able to use reasoning to harmonize labels across a variety of Annotation Properties. Doing this has to scale (as we demonstrate with 29+ Billion triples at: http://lod.openlinksw.com ).
>>> Kingsley, the usability issues I describe have nothing to do with reasoning.
>> I am referring to the need for labels replacing URIs i.e., automated generation of anchors for text when presenting relations that describe a subject.
>>
>> This is the key to the matter. I've used the tool, and that's the only real UI/UX hurdle. They already figured out the value of QR Codes etc..
> Ah ok, yes. I see one can automate that. For a specialised tool such as an address book, one could quite well hard code it....
> But yes. I see what you mean.

Great.
Back in sync :-)

>>> They have to do with with focus on solving those problems. Some of those problems have to do with some missing information which we need to think about. For example the Foaf-browser is an address book that runs on a cell phone and is written in Java. It needs to be able to find the form to create a Secured WebID.
>> I think that's a separate product. Basically, a phone hosted WebID generator. We are making such a thing anyway. So stay tuned.
> That's not difficult to do. I can in no time write up some code for the telephone to create a public private key.
Henry,

Not what I am implying, re., difficulty. I said: making labels for URIs 
that automatically materialize across heterogeneous data sets across 
ABox and TBox, that scales is hard.

Making a Certificate Generator, that works consistently across Windows, 
Mac OS X, iOS, Android, Windows Phone, that takes some doing to.
> What is needed is a way to send the key to the profile so that it is published there, and so what we need is a way to do that without having to do complex setup of a each android phone, for each particular site.

Our Generator will place relations in Profiles or other data spaces. 
These data spaces range from those associated with a SPARQL endpoint 
(Digest, OAuth, WebID protected) to extreme cases like Blogs posts and 
even Tweets. In addition to all of that will remain the pkcs#12 
(password protected) and email dispatch (which may or may not be 
encrypted). Ditto use of PUT or WebDAV to drop in an (X)HTML+RDFa or 
HTML5+Microformats based profile doc into some data space.

This all happens via a simple wizard like WebID generator that is 
decoupled from any IdP. This tool makes the X.509 cert, persists it host 
OS key store  (or makes a local  pem or pkcs#12 resource) and then 
handles the relations dispatch (as outlined above re. a variety of 
options) to the IdP data space.

What I describe above, isn't a triviality.


> Ie: we need a standard authentication procedure for the time before we are authentified using WebID, so that we can create the WebID. And that has to be a one click procedure - or else we loose a lot of users.
>
> 1. Keygen end point
> -------------------
>
> One way to do this is to have the same logic as with the web services we are using now. Ie to have the equivalent of a form where a user can publish a key. This would be useful because then the rdf and the html worlds would work in parallel.
>
> Perhaps a profile would work something like this:
>
> <>  a foaf:Profile;
>     foaf:primarySubject :me .
>
> :me a foaf:Person;
>      foaf:name ....
>
> <certGen>  a xhtml:Form, cert:CreationForm;
>      xhtml:parameter [ xhtml:name "keygen"
>                        a xhtml:Keygen ];
>      xhtml:parameter [ xhtml:name "webid";
>                        xhtml:value "http://harvard.edu/profile/george#me"
>                      ] .
>
> Or perhaps something better, but the idea would be to describe a form in such a way that it can know that it has to generate a public/private key and send it to that collection. But wait! Before we can even do that, we need to be authenticated!

Yes. Note the authentication options I listed.

> 1.1 Logging in to create a cert
> -------------------------------
>
> So before one can do anything like create public/private keys to create certificates,  the user first needs to authenticate with that site in a manner that is easy to understand for said human user.
> So the current Android app does that by asking the user to upload a pem file to the phone, but clearly that is not going to work with most users - it's just too complicated. The reasonable way to do that on the phone is to do what one does on the web: log in using well understood username password auth, then create a certificate.
> So that means that the phone needs to not only know what the certificate endpoint is, but needs to also know how to login using said username password. So perhaps just the old HTTP Authentication mechanisms should be used there? But perhaps one should also develop a username/password relation also?

As per my comment above, you can use a variety subject to what the IdP 
data space is capable of handling. That's what I've already outlined 
above. That's what I mean by stay tuned :-)


[SNIP cos we deal with SPARQL via a variety of authentication methods as 
already mentioned]

>>> There are usability problems that will come up with reasoning. But since we are all getting going, and we need to work together people should try to publish data that will require a minimum or no reasoning.
>> My points is that via a Web Service the reasoning burden is alleviated. The make retrieve a data object and its representation includes:
>>
>> 1. de-referencable name
>> 2. a literal label.
>>
>> The service does the work. The client just gets the data objects.
> Well yes, the cell phone could just do html viewing. Things tend to be a bit slower that way though, and don't work that well with low connections or when roaming across countries where suddenly MBytes are extremely expensive.

Local storage and cache invalidation schemes help. Irrespective though, 
you need to be able to make labels from a data sources that host objects 
without annotation properties and/or inconsistent use of annotation 
properties. Even for a small ABox, it is a challenge.

A local store on an Android still has to deal with the challenge so that 
the data consumer is always delivered data objects that are endowed with 
an annotation property that serves as a label. Basically, this is about 
making rdfs:labels via best effort heuristics against the data "on the 
fly" so that only in extreme cases will an Object ID (URI) show up in 
the end-user realm.

The power of URIs should be experienced. Their visibility always 
compromises their power.
>>>   Then we are more likely to get other people on board, and work together as a community.
>> I am making the same point, but its kinda lost in translation .
> Ok. We're focusing in on the problems.
>
> Btw, it is writing a client such as this that I ended up feeling the need for WebID. So I think that by building these we will get to find the issues we need to solve.

Yes.

I will post a link to the HTML version of this new client. Of course, 
same thing when the iOS and Android versions are done.

Kingsley
>>
>>>> We do offer an API into our faceted browser engine that enables anyone leverage this functionality. Thus, I need to double check that we actually surface what I've described since it took some serious engineering to pull off this solution in the manner I just described.
>>> We are speaking cell phones here. If you want to market your product here is an opening for you: do you have a version of virtuoso that runs efficiently on iPhones, which java cannot reach?
>> We can make a version of Virtuoso run wherever we choose if we deem it useful.
> Ok. I don't think I need it to run on an iPhone anymore, but some people were interested last week. I'll get in contact with you if that turns up again.
>
> Henry
>
>> Kingsley
>>> Henry
>>>
>>>> Links:
>>>>
>>>> 1. http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VirtFacetBrowserInstallConfig -- Virtuoso's DBMS hosted Faceted Browsing Service .
>>>>
>>>> Kingsley
>>>>> Cheers,
>>>>>
>>>>>
>>>>> Bo
>>>>>
>>>>>
>>>>>> where I also go into detail in some of the things that need to be improved, as I show how it works.
>>>>>>
>>>>>> 1. SEAMLESS STARTUP
>>>>>> ===================
>>>>>>
>>>>>> In order to allow seamless startup, there has to be a way for a user once he has installed the browser to find his home page.
>>>>>>
>>>>>> We discussed this yesterday on the WebID-XG incubator group meeting with Tim.
>>>>>>
>>>>>> a. getting to the home page
>>>>>> ---------------------------
>>>>>>
>>>>>> Clearly getting to the home page of the user is going to be important. That will require him to either:
>>>>>>
>>>>>>   - know his profile url
>>>>>>   - the company he is with to have implemented something like web finger, so that one could just ask him for his email address
>>>>>>   - ..
>>>>>>
>>>>>> We seem to have a few protocols to help here. What clearly was missing was the keygen equivalent for an application like that.
>>>>>>
>>>>>> b. keygen form pointer
>>>>>> ----------------------
>>>>>>
>>>>>>   We need  some way to get the equivalent of a keygen form in rdf. Then a non html browser could know where it needs to send an html POST of a keygen like response. Any ideas how to do this?
>>>>>>
>>>>>> 2. EDITING
>>>>>> ----------
>>>>>>
>>>>>> I suppose the RW community group have some idea of what is needed to allow such a tool to become an editor.
>>>>>>
>>>>>>
>>>>>> Henry
>>>>>>
>>>>>>
>>>>>> [1] http://code.google.com/p/mssw/wiki/Screenshots
>>>>>>
>>>>>>
>>>>>> You can run it in a emulator - very slow btw, but if you don't want to buy a phone it saves money.  Here is what I learned looking at it: The running stable release of the Address Book is
>>>>>>
>>>>>> http://code.google.com/p/mssw/downloads/detail?name=mssw-0.9.6-stable.apk
>>>>>>
>>>>>> The emulator can be found here:
>>>>>>
>>>>>>   http://developer.android.com/guide/developing/devices/emulator.html
>>>>>>
>>>>>> Once installed the tools/android  tool allows starts a GUI which allows one to create a virtual device. Perhaps one first has to install android 2.3.3 which is more like a phone, and create a virtual device for that. Then can launch the device. One installs the app on the virtual phone using once it is running
>>>>>>
>>>>>> ../platform-tools/adb install mssw-0.9.6-stable.apk
>>>>>>
>>>>>> (there may be a GUI way of doing that)
>>>>>>
>>>>>>
>>>>>> [2] this is true for creating WebIDs, for loving in and so on....
>>>>>
>>>> -- 
>>>>
>>>> Regards,
>>>>
>>>> Kingsley Idehen	
>>>> President&    CEO
>>>> OpenLink Software
>>>> Web: http://www.openlinksw.com
>>>> Weblog: http://www.openlinksw.com/blog/~kidehen
>>>> Twitter/Identi.ca: kidehen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>>
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	
>> President&   CEO
>> OpenLink Software
>> Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen
>>
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen