[foaf-dev] DataPortability, SPARQL and the "Connect!" button

Peter Williams pwilliams at rapattoni.com
Fri May 2 18:06:59 BST 2008


Interesting to see the assumption limits placed around the Oh Yeah? notion =
- something that calls for a Theory of Reliance perhaps, to ensure one goes=
 beyond such limiting notions. In the description, the construct of trust a=
nd validation is expressed almost exclusively in terms of keys, the signing=
 of real-time proof assertions by keys, and the notion that 'key distributi=
on' is the key web-centric technology for "addressing an individuals loss o=
f trust in a document, such that s/he suddenly wants 'metadata' to be gathe=
red in a form that can be relied upon". he assumptions omit the whole space=
 of obligation passing, which is a practical way of negotiating the paramet=
ers for mutual reliance.

The funny thing is that the OASIS XRI trusted resolution process based on t=
ree walking metadata sources addresses this quite nicely, and facilitates o=
bligation signaling. But, W3C decided against XRI on the religious grounds =
that classical URIs and client-based crawling algorithms can do better.  Th=
is was a few years ago....

Seems we know what we don't want, but cannot say what we do want. Trusted X=
.500 was wrong. LDAP is wrong. XRI is wrong. secure DNS is wrong. Trusted h=
ttp proxying was wrong. PKI and SSL are wrong, as is signed P3P. The web is=
 however "right"...in at least as much that its process ensure that given t=
he web is an evolutionary process, the right solution will find the right p=
roblem when the time is right.

I followed a few of the links, and used their openid sign-ins. None worked.

_________________________
Peter Williams




From: Kingsley Idehen
Sent: Fri 5/2/2008 9:31 AM
Cc: foaf-dev
Subject: Re: [foaf-dev] DataPortability, SPARQL and the "Connect!" button


Danny Ayers wrote:
> In one of timbl's Design Issues pieces he describes the "Oh yeah?" =

> button [1] - something you press to get a chain of proof about some =

> statements. This really neat "showing" came to mind when I was putting =

> together my cheesy DataPortability video [2] - I reckon DP done right =

> on the Web could be summarised as a "Connect!" button. So I included a =

> mockup of a possible UI for DataPortability across social networking =

> sites - slides I used are at [3], ASCII version below. While my =

> mock-up is no doubt suboptimal, it's not hard to imagine how one might =

> use it (click the button!), or for that matter how it might work =

> behind the scenes. Because everyone here knows DataPortability is a =

> Simple Matter of Programming given RDF. But it'd be nice to have =

> something implemented before we see something emerge and gain mass =

> adoption that solves the immediate part of the problem in an ugly =

> one-off fashion, leaving a mess to clear up afterwards once the next =

> special case comes along...rant.abort()
>
> Anyhow, how I imagine this particular thing working is that OpenID is =

> used for authentication, and SPARQL CONSTRUCT is used to build a graph =

> based on the selections the user's made. That graph gets posted from =

> system A to system B. Job done.
>
> I believe SPARQLPress/the ARC plugin for WordPress has most of the =

> necessary with the OpenID stuff around WordPress already, the =

> RDF-in-Drupal work seems to have made great strides recently, and then =

> there are all the SIOC plugins.
>
> What I'm really not sure about is what would be the quickest way to =

> get (at least part of) this up & running. Some tech points I've not =

> really figured out are the best approach to the sequence - would extra =

> auth be needed on the service-service wire? Then there's the =

> integration at the receiver side - how could this be set up so it'd =

> behave reasonably consistently across different CMSs/social network =

> thingies?
>
> I'd be delighted to get together something that, say, passed across x =

> foaf:knows y with enough to build a blogroll. Once the basic setup was =

> in place, extending it should be straightforward. Making suitable =

> plugins for the various thingies might be hard work - perhaps needing =

> intermediary services to do the proprietary API/RDF+HTTP mapping, but =

> maybe OpenSocial might help (along with the existing SIOC stuff).
>
> Ok, I'm not 100% sure the approach I have in mind is the best one, and =

> the kind of UI interaction I've sketched is mighty crude - but I think =

> it might be near enough to work, both technically and in terms of =

> getting folks used to Facebook or whatever to follow what's going on. =

> What I am sure of is the big red "Connect!" button. It must have one =

> of those :-)
>
> Thoughts?
>
> Cheers,
> Danny.
>
> *** Page 1 ***
>
> To join Yet Another Social Network
>
> [Sign Up]   [Connect!]
>
> *** Page 2 ***
>
> Connect your...
>
> [x] Personal Profile
> [x] Social Contacts
> [ ] Business Contacts
> [ ] Content
>
>      [Connect!]
>
> *** Page 3 ***
>
> From...
>
> [x] Your Homepage
> [ ] MySpace
> [ ] Flickr
> [x] Twitter
> [ ] Etc .etc.
>
>      [Connect!]
>
> *** Page 4 ***
>
> Your URI:
>
> [ <openid>    ]
>
> Password:
>
> [ ******  ]
>
>      [Connect!]
>
> *** Page 5 ***
>
> Connected!
>
> ---------------
>
>
>
> [1] http://www.w3.org/DesignIssues/UI.html#OhYeah
> [2] http://www.youtube.com/watch?v=3D6eGcsGPgUTw
> [3] http://hyperdata.org/dataportability/docs/
>
> -- =

> http://dannyayers.com
> ~
> http://blogs.talis.com/nodalities/this_weeks_semantic_web/
> ------------------------------------------------------------------------
>
> _______________________________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Danny,

Sure!

But what about the additional benefit of a URI e.g a .Name based URI =

provides a canonical entry point into resulting data graph?

Your post + my comments above =3D OpenLink Data Spaces  :-) This is part =

of what OpenLink Data Spaces has always been about, plus some more such as:
1. Automatic association of Tags with formal meaning via MOAT
2. Tag stats via SCOT
3.  Formal typing of Tags as Concepts via SKOS

This is congruent with my LODW presentation =

<http://community.linkeddata.org/%7Ekidehen2/Public/DataPortability_and_Dat=
aSpaces.ppt> =

(I do apologize in advance or the PPT presentation format when it should =

have a  Slidy style variant).


Demos:

1. http://community.linkeddata.org/dataspace/person/kidehen2
2. http://myopenlink.net/dataspace/person/kidehen

Notes ( I am deliberately not using URI universally for intended clarity):

My Person Entity URIs:
1. http://community.linkeddata.org/dataspace/person/kidehen2#this
2. http://myopenlink.net/dataspace/person/kidehen#this

My OpenID & FOAF Profile Page URLs:
1. http://community.linkeddata.org/dataspace/person/kidehen2
2. http://myopenlink.net/dataspace/person/kidehen

My resulting Data Space Page URL (the conjunction of all the data I've =

choosen to share with good use of foaf:made):
1. http://community.linkeddata.org/dataspace/kidehen2
2. http://myopenlink.net/dataspace/kidehen

My Data Space URIs:

1. http://community.linkeddata.org/dataspace/kidehen2#this
2. http://myopenlink.net/dataspace/kidehen#this


Also note:
My various URIs are connected across Data Spaces via owl:sameAs.
I can arbitrarily enrich my FOAF via a URI associated with the Profile =

Page UI.


Anyway, I like the layout you are suggesting, it is quite concise and =

easier to comprehend :-)  We will make a tweak or two to ODS.

BTW - there is a live instance at: http://community.linkeddata.org/ods  =

(OpenID is accepted etc..).

-- =



Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO =

OpenLink Software     Web: http://www.openlinksw.com




_______________________________________________
foaf-dev mailing list
foaf-dev at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20080502/57d=
ce07a/attachment-0001.htm


More information about the foaf-dev mailing list