[Fwd: Re: OpenLike protocol and system high-level design (crowdsourcing semantic web/ontologies)]

fyi - re openlike

source / discussion ongoing at:
http://groups.google.com/group/openlike/browse_thread/thread/aa613068bbd95f4c

"Openlike... 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.)"

-------- Original Message --------
Subject: Re: OpenLike protocol and system high-level design

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

On 26 апр, 23:56, Rabbit <rab...@cyberpunkrock.com> 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.)
> * 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
>
> On Apr 26, 2010, at 3:25 PM, Alex Iskold wrote:> 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:
> >> 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.
>
> >> On 26 апр, 21:52, Nathan <nat...@webr3.org> wrote:
>
> >>> 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! :)
>
> >>>> Jeff
>
> >>>> On Mon, Apr 26, 2010 at 10:21 AM, Nathan <nat...@webr3.org> wrote:
>
> >>>>> 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>
>
> >>>>>>> NickMikhailovsky wrote:
> >>>>>>>> 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?
>
> >>>>>>> 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.eschena...@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
>
> >>>>> --
> >>>>> Subscription settings:
> >>>>>http://groups.google.com/group/openlike/subscribe?hl=en

Received on Monday, 26 April 2010 21:06:14 UTC