OpenLike protocol and system high-level design (crowdsourcing semantic web/ontologies)

[NickMikhailovsky]

I believe that the goal of the project are the following:

1. Build a network of relationships between humans and items
1a. Provide an open way to express a relationship between two
arbitrary items (I like this "The art of the start" book; I like Ann,
the book hates scissors, etc.)
1b. Provide an open way to create a type of relationship between
arbitrary items (My users can have the following relationships to the
books I sell through my website: read, have written, like, hate)
(RDF?)
1c. Provide a way to identify a human (OpenSocial?)
1d. Provide a way to identify an item (URI?)

2. Allow an open way to request the relationship data (SPARQL?)
2a. Provide a set of easy tool to retrieve the typical data

3. Create a data silo for all this info (organizational issue,
sponsorship needed)

4. Create sample implementation with major services (should be easy on
OpenSocial side, need support of major retailers/content websites
etc.)

Thus, a set of pretty simple client-side scripts + things already done
on semantic web front should do a large part of the job.

Any thoughts?


--
Subscription settings: http://groups.google.com/group/openlike/subscribe?hl=en

[Nathan]

Couldn't agree more,

FOAF+SSL caters for the identification, every link you could possibly
ever want between "things" is just a simple triple, linked data provides
everything that is needed, a user could simply delegate control of these
"likes" through to a 3rd party service by adding in a triple

{ <my-webid> , rdfs:seeAlso, <http://someservice.com/my-username> }

The main thing is to nail down a protocol for sending this info across
the wire, but that can fall down to sparql update or some form of
atompub style POST to container GET container style protocol (which
needs addressed generally for RDF/linked data).

Laurent Eschenauer <laurent.e...@gmail.com> seems to be thinking
along the same lines, and I know many over at foaf-protocols would hook
up on this rather swiftly, myself included.

Best,

Nathan

[NickMikhailovsky]

Nathan,

Nice job! +1

I believe it is important to keep OpenSocial in the loop (even that
internally we can make it FOAF-based), because it can provide seamless
integration of OpenLike/RelationshipButtons with second-tier social
services like MySpace, LinkedIn and Blogger. This is where the key
interface part is - making OpenLike/RelationshipButtons work as smooth
as FaceBook's Like button, without the need to log in when any of
these apps are running in a different browser window. I will look into
that later today/tomorrow.

The thing I did not quite get in your post was about delegating Likes
to the third party. Can you detail a bit more - what specifically do
you propose to delegate?

Protocol for sending the triple from the end-client should most likely
be a GET request, for simplicity and brevity. Internally looks like it
should use sparql update, as you have suggested.

Nick.

> Laurent Eschenauer <laurent.eschena...@gmail.com> seems to be thinking

[Nathan]

Nick Mikhailovsky wrote:
> Nathan,
>
> Nice job! +1
>
> I believe it is important to keep OpenSocial in the loop (even that
> internally we can make it FOAF-based), because it can provide seamless
> integration of OpenLike/RelationshipButtons with second-tier social services
> like MySpace, LinkedIn and Blogger. This is where the key interface part is
> - making OpenLike/RelationshipButtons work as smooth as FaceBook's Like
> button, without the need to log in when any of these apps are running in a
> different browser window. I will look into that later today/tomorrow.

My main concern with the current openlike, is that really it isn't
anything (no offence at all), it's nothing more than the knowledge that
one service uses ?url= and another uses ?addLike= (examples)

imho what's really needed is a single protocol that all services can
implement, and that anybody can implement, this protocol has two sides,
one is to publish likes in a single format which can be consumed by anybody

<person> likes <thing>

the "likes" verb could of course be changed, and ideally would be a
property from an rdfs or owl ontology, this could just as easily be
"knows" <person>, "follows" <user-account>, or any other link you could
imagine.

The above is very much handled by structured linked data already and
could be implemented in a snap. (+ widgets made etc).

The bit which isn't really handled is the common protocol for sending
those relations (together with any additional information such as a
title, a comment, dates&times etc).

Again though the common data format is covered by linked data, as is
0-click authorisation + person identification (via foaf+ssl).

I wholeheartedly feel this is an opportunity for multiple parties to
come together and forge out the missing link, which is that protocol for
sending this structured information to endpoints in a restful manner.

> The thing I did not quite get in your post was about delegating Likes to the
> third party. Can you detail a bit more - what specifically do you propose to
> delegate?

we can delegate two things:

1: the listing of this additional data (let's say all services provided
an url for a users likes, then in my own foaf document I could simply
assert:

#me rdfs:seeAlso <http://facebook.com/nathan/likes>,
<http://digg.com/nathan/links>,
<http://reddit.com/nathan> .

Then any client that so wished could lookup those likes and display
them, or pubsubhubbub subscribe to each of the end points, or countless
methods of handling it - the point is that by having a uniform data
structure that is understood by all, every service and machine can
understand the data from any other service, it moves HTTP in to the API
role and no documentation or further info is needed, you simply GET one
of the urls and parse the structured linked data returned, who or
whatever you are.

> Protocol for sending the triple from the end-client should most likely be a
> GET request, for simplicity and brevity. Internally looks like it should
> use sparql update, as you have suggested.

yup it's one way to handle it, as long as GET remains "safe", the actual
save action would have to be POST after a user confirm, however if a
browser extension simply posted it to an https endpoint then it could be
a single action, just click one button and foaf+ssl does all the
identification + handling, the process at the endpoint collects the data
and saves it, then publishes it and notifies subscribers, all safe
secure, instant, delegated and distributed - simples.

> Nick.
>
> 2010/4/26 Nathan <nat...@webr3.org>

[Jeff Eddings]

Before we invent lots of new stuff, it's worth looking at things like:

• ActivityStrea.ms for allowing an open and standards-based way for people to express themselves and syndicating it
• WebFinger for an open and standards-based form of identity.  This way, identifying a person and identifying an item are both URI-based.

By using these (and others), OpenLike can focus on what makes it unique and the problem it solves.  It's possible that OpenLike is merely a agreed-upon set of rules for how these other open standards are used together to build something that looks like a universal "like" on web pages.

Jeff

[Nathan]

Jeff Eddings wrote:
> Before we invent lots of new stuff, it's worth looking at things like:
>

> - ActivityStrea.ms for allowing an open and standards-based way for

> people to express themselves and syndicating it

> - WebFinger for an open and standards-based form of identity. This way,

> identifying a person and identifying an item are both URI-based.
>
> By using these (and others), OpenLike can focus on what makes it unique and
> the problem it solves. It's possible that OpenLike is merely a agreed-upon
> set of rules for how these other open standards are used together to build
> something that looks like a universal "like" on web pages.

I agree, investing the time and effort of multiple parties to create
something that looks like a universal "like" on a web page is a
positively stunning idea and the best use of everybodies time - then we
can do the same for "dislike", and "read", and then for people knowing
each other, and so on for every relationship between things known to man.

Brilliant! :)

[NickMikhailovsky]

Nathan,

I think that Jeff's suggestion of making use of ActivityStrea.ms as
the missing protocol element makes a lot of sense. It allows for
triples and is quite widespread.

I think we are close to having a full set of almost-ready things, and
will just need to mash up.

> >>>> Laurent Eschenauer <laurent.eschena...@gmail.com> seems to be thinking

[Alex Iskold]

I like the idea of leveraging existing work, it makes a lot of sense.

Activity streams are great for data out and we can re-use the schema.
We'd need to define REST API for publishing to it.

On Apr 26, 3:00 pm, NickMikhailovsky <nick.mikhailov...@gmail.com>
wrote:

[Rabbit]

OpenLike imho:

* A well-defined set of best practices.
* Describes an arrangement of XAuth, WebFinger, XRD, OpenGraph, and
OExchange for the purpose of tethering an identity to a resource for
some purpose (sharing, rating, etc.)
* A drop-in-place JavaScript library which:
** Understands the user (XAuth+WebFinger+XRD)
** Understands the resource (XRD+OpenGraph)
** Provides a sensible list of exchange options based on the data
discovered (User+Resource+OExchange)

I don't think anything needs to be invented.

The components are there. What isn't there is a solid recommendation,
an available library, and cohesion among sharing services around a
single approach.

I also don't feel that OpenLike should dictate the privacy level of
the information (ie: sharing analytics being made public without user
consent). That sounds like jealousy over Facebooks data advantage and
doesn't necessarily have the best interest of the user in mind.

=Rabbit

[Nathan]

Well, sadly I'm bailing, will be indeed be fun to review this mail in a
year or two :)

good luck,

nathan

[Nathan]

Rabbit wrote:
> OpenLike imho:
>
> * A well-defined set of best practices.
> * Describes an arrangement of XAuth, WebFinger, XRD, OpenGraph, and
> OExchange for the purpose of tethering an identity to a resource for
> some purpose (sharing, rating, etc.)

reason for bailing ^

{ <uri> <link> <uri> }

job done

> * A drop-in-place JavaScript library which:
> ** Understands the user (XAuth+WebFinger+XRD)
> ** Understands the resource (XRD+OpenGraph)
> ** Provides a sensible list of exchange options based on the data
> discovered (User+Resource+OExchange)

[NickMikhailovsky]

I really like the idea of defining the purpose of protocol/system
first.

Let's try and (ery informally) define the use cases. I think there are
four:

UC0. Service defines relationships to be supported.
UC1. User expresses the relationship to an object presented by a
service.
UC2. Service provides added value to the user.
UC3. Service uses graph data to create extra added value to the user.

Above, by service I mean the website/application that hosts OpenLike
button.

UC0 is not a part of a UI (Javascript) library.
UC1 is when user clicks the OpenLike button. I agree with Nathan that
the key here is 0-click person identification, not user authentication
or understanding. To that end, we will be better off identifying the
user with some existing social profile/FOAF+SSL rather than Xauth+XRD,
in my opinion. The data can be sent using ActivityStreams.
UC2 is most likely not a part of Javascript Library as well, but it
definitely includes understanding the user etc. This is most likely
accomplished using OpenGraph or URI and SPARQL, also, most likely,
FOAF.
UC3 is about the service querying the data silo.

Thus, my choice of technology stack would be:

Person identification: FOAF+SSL
Resource Identification: URI and/or OpenGraph
Data retrieval: SPARQL

[Nathan]

NickMikhailovsky wrote:
> I really like the idea of defining the purpose of protocol/system
> first.
>
> Let's try and (ery informally) define the use cases. I think there are
> four:
>
> UC0. Service defines relationships to be supported.
> UC1. User expresses the relationship to an object presented by a
> service.
> UC2. Service provides added value to the user.
> UC3. Service uses graph data to create extra added value to the user.
>
> Above, by service I mean the website/application that hosts OpenLike
> button.
>
> UC0 is not a part of a UI (Javascript) library.

sounds like an ontology to me

> UC1 is when user clicks the OpenLike button. I agree with Nathan that
> the key here is 0-click person identification, not user authentication
> or understanding. To that end, we will be better off identifying the
> user with some existing social profile/FOAF+SSL rather than Xauth+XRD,
> in my opinion. The data can be sent using ActivityStreams.

concur of course, would like off-list convo about activitystrea.ms if
that's okay with you :) [fill me in more esp re: triples]

> UC2 is most likely not a part of Javascript Library as well, but it
> definitely includes understanding the user etc. This is most likely
> accomplished using OpenGraph or URI and SPARQL, also, most likely,
> FOAF.

agree, however will add that sioc and the sioc type extensions are
probably key here, regardless taking a ontology approach allows this to
be tailed to everybodies needs and every scenario possible

> UC3 is about the service querying the data silo.
>
> Thus, my choice of technology stack would be:
>
> Person identification: FOAF+SSL
> Resource Identification: URI and/or OpenGraph

dereferenceable uri aka linked data is key here (which includes open graph)

> Data retrieval: SPARQL

+1 to the above and faith in the sanity of the web restored :)

[NickMikhailovsky]

Here is how I think the user interface may look like (needs designer
hand, of course):

1. Services should give user a meaningful choice of relationships to
items
2. User can define a custom relationship

http://picasaweb.google.ru/Nick.Mikhailovsky/OpenLike#5464568703340612050

[Rabbit]

Considering the OExchange spec tackles a similar work flow I would recommend using this vocabulary just so we understand each other.

http://www.oexchange.org/spec/#definitions

(Source, Target, User)

I did not completely understand some of your use cases (sorry!) and I don't want to presume I knew what you meant. Could you elaborate?

UC1 is when user clicks the OpenLike button. I agree with Nathan that
the key here is 0-click person identification, not user authentication
or understanding. To that end,  we will be better off identifying the
user with some existing social profile/FOAF+SSL rather than Xauth+XRD,
in my opinion. The data can be sent using ActivityStreams.

How would the existence of "social profile/FOAF+SSL" be made known?

I don't see any reason to eliminate other forms of identity. A URI should suffice.

I am concerned that the introduction of ontologies adds unnecessary complexity. Is it possible to come up with a flow that works without showing the users "relationship" to the source and then allow for extensions to provide that functionality optionally?

=Rabbit

[Nathan]

Rabbit wrote:
> Considering the OExchange spec tackles a similar work flow I would
> recommend using this vocabulary just so we understand each other.
>
> http://www.oexchange.org/spec/#definitions
>
> (Source, Target, User)
>
> I did not completely understand some of your use cases (sorry!) and I
> don't want to presume I knew what you meant. Could you elaborate?
>
>> UC1 is when user clicks the OpenLike button. I agree with Nathan that
>> the key here is 0-click person identification, not user authentication
>> or understanding. To that end, we will be better off identifying the
>> user with some existing social profile/FOAF+SSL rather than Xauth+XRD,
>> in my opinion. The data can be sent using ActivityStreams.
>
> How would the existence of "social profile/FOAF+SSL" be made known?

That's the whole point of FOAF+SSL, each person has a webid (personal
uri), that personal uri when looked up provides their foaf (social)
profile, in the persons client (browser) they have a client side
certificate where their personal uri is stored inside the subjectAltName
field, the public key of which is stored in their foaf.

All somebody needs to do to login, be authorised, identified and provide
access to their full profile is visit an https url which requests a
client side certificate, it's 0 click for all the aforementioned.

> I don't see any reason to eliminate other forms of identity. A URI
> should suffice.

indeed :) everybody is identified by a URI (which can be dereferenced /
looked up to get more information), this is taking uri identification to
the next level.

> I am concerned that the introduction of ontologies adds unnecessary
> complexity. Is it possible to come up with a flow that works without
> showing the users "relationship" to the source and then allow for
> extensions to provide that functionality optionally?

actually, it adds simplicity and unlimited flexibility to the design,
and it is really rather simple once the inhibitions go.

if you think about what you're saying above, at the very least you are
going to be left with:

<user> linkedto <uri> .

why add anything else to the mix, when that "linkedto" could be swapped
out with any meaning, unambiguously and without the need for lookups?

[Rabbit]

I appreciate your passion for FOAF I've just never been a fan. At the
same time I can see how someone might appreciate its value. It's been
almost a decade and I still don't "get it".

I think we agree on everything except the specifics.
Would love to chat more, unfortunately, I have a day job.

Good luck.

=Rabbit

[Kingsley Idehen]

Rabbit wrote:
> I appreciate your passion for FOAF I've just never been a fan. At the
> same time I can see how someone might appreciate its value. It's been
> almost a decade and I still don't "get it".

Why not try a different route, put FOAF and RDF aside for a second.

How about the fact that you can use a 3-tuple record format to create a
network oriented record? Thus, you like something, so you can write this
record in your data space for Favorite Things:

<#me> <#favoritething> <#A-Thing-With-A-Name> .

The statement above is a 1000 ft view, of course you can be more
granular e.g. adding temporal, location, and other dimensional aspects.

>
> I think we agree on everything except the specifics.
> Would love to chat more, unfortunately, I have a day job.

What's most important here is to understand that we are creating
records, so putting up yet another API doesn't negate the ultimate data
persistence reality. Basically, not only will this data be persisted
somewhere, if will be reused (over a network), so its structure is vital.

FOAF, SIOC, and other schemas simply deliver "relation terms" for these
3-tuple network records. If you don't like these schemas, you don't have
to use them. What is/should be immutable though is the fact that your
data should be structured meaning: entity, entity attributes, and
attribute values, being clearly discernible courtesy of an underlying
data model.

To conclude, its just about structured linkable data, the
vocabularies/schemas/ontologies only require structure, and can be used
by others in their specific data contexts etc..

Kingsley

--

Regards,

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