Re: User stories for Social API

I think there's a risk in creating User Stories by looking at API's from
existing social networks in isolation of the wider range of social
interactions.  If trying to identify existing market behavior, these are
just API's for companies that have had an interest in publishing them.
There may be a story around a first step / "foundational" approach to
standardizing the existing cow paths, but there's a risk too that with the
lack of adoption of v 1.0, there won't be an interest in V 2.0.

I think Henry makes an illuminating and important point.  A Social API
derived exclusively from analyzing the existing API's of big social players
is not the Social Web.

I think the User Story put forward by Elf Pavlik called Managing Economic
Interactions
<https://www.w3.org/wiki/Socialwg/Social_API/User_stories#Managing_economic_interactions>
is different in important ways and is not a silo.  Anywhere that there is
an inventory will be more interesting and more useful, I believe, beyond a
version of SWAT 0 version of social.  In looking at the IG's work with 18
Use Cases, I grouped them into 3 types and this one Use Case stood out.  In
that work it has the title "A Farmer In Many Food Networks".  The analysis
I did was done just ahead of our face to face and is posted in the IG wiki
here Comparison Chart grouping uses cases into types
<https://www.w3.org/wiki/Socialig/Use_Case_TF/Profile_Scenarios#Comparison_Chart_grouping_uses_cases_into_types>

I believe there is more demonstrated need for marketplaces than online
social networks as well.  I suspect that marketplaces have worked
economically for a long time though, which is why they didn't create and
publish API's for us to analyze. Social Networks are different than that
and have published API's to get more engagement in their ecosystems.  These
User Stories look like existing social networks because the documentation
for their API's is available.  That's a figment of their particular need
though.  I suspect marketplaces aren't there in part because most are not
online and easily analyzed.  For example, the way to interact with a
farmer's market is to physically show up.

There is more usefulness to the world in creating tools and processes for
exchanging goods and services than for tagging names to pictures.  I
believe that would drive adoption.

Lloyd Fassett
Azteria Inc.
Bend, OR
(541) 848-2440 (PST)

On Wed, Feb 4, 2015 at 10:26 AM, Harry Halpin <hhalpin@w3.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 02/04/2015 04:40 PM, ☮ elf Pavlik ☮ wrote:
> > On 02/04/2015 03:37 PM, henry.story@bblfish.net wrote:
> >>> Maybe for our next telecon you could sketch out an alternative
> >>> vision, without a server-to-server protocol?
> >>
> >> yes, that is not difficult. When you say client you mean browser,
> >> when you mean server you mean a machine that is usually without a
> >> display, and that is constantly bound to the internet. In my
> >> world - the world of HTTP and APIs - clients and server are just
> >> roles that computers play. A computer program can be in server
> >> role in one moment and then client the next. One multiple core
> >> machines they can be both simultaneously.  So there is no
> >> server/server api. There can only ever be client/server
> >> relations.
> > I just started wiki page for Social Web Glossary[1] I find it very
> > important to clarify terms like:
> >
> > 1 App 2 Domestic Server 3 Foreign Server 4 Web Service
>
> I in general would not use the term Web Service due to its history
> with SOAP, which is a separate stack. You could say simply "website"
> (if you mean domain, ala www.example.org running separate apps in
> different iframes) or just say "platform" if you mean something more
> cross-domain, like Twitter or Google eco-systems.
>
>  Ditto domestic and foreign server. Typically, one says "provider" for
> domestic server and "relying party" for foreign server.
>
> There's a good terminology section here:
>
> http://www.w3.org/2005/Incubator/socialweb/wiki/FinalReport#The_Terminology
>
> >
> > I see scenarios where Apps (running on your local device) use HTTP
> > API to interact with *domestic* and *foreign* servers. Also Web
> > Services (running on remote servers) in some scenarios can act as
> > client, which can use same HTTP API as mentioned front end Apps...
> >
> > [1] https://www.w3.org/wiki/Socialwg/Social_Web_Glossary
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJU0mRgAAoJEPgwUoSfMzqc5MgP/jA/nYPDZuAHBX/lGq9kfxkY
> RjLDXq/GnGTUjgZjZJEOYREqaRpWP1WKWZ1pvlr7eai16uMpA7USnNXdCq3ywZ3p
> RbNFRhkex6RA3mlDfyHWSX0+6YvjiNDbwI8v9upm+VDEW6w5scf31j4NozETK/Ff
> 7tEEnLp6UIy9mji343eC4vbYEO01aLA3rthjcxJxoPeK8p7cR5U5wsQfYIKElHLO
> JHeF0Kp0SCDRPAkvs3Mt6Eze05DwmQLLbZIeocr41l3WRMHEqdRQSSH5Qvivlzqc
> iXVS7GRk7sacgJfMkavVxba7R4kK6G8FzZXfOPi4S3btWL4PN1FhBXDiTG/WoV5P
> O9FGjaatySpqi08v9sTOXeNE1oa/ax0W9NJWuz88T2ktA4WZNeNTQlBhS/iqLeuu
> XX/y69E9ip/FBh5ivj8IH80Pts0/dmBBCcRmUT6bznS/lLdkp4h7ILojUHH3QYKT
> d9syRYYPLhAjBFyo9eH7qWnDjfEAChWN2kBfaoqFlDz3WtG8WZqh0LGkTe4SnPU8
> 8y2T6dRxxhHBEUlRcXXjUo6Zg19xzofOQnJhrOzud+ihCTBYTr0T39jfFYbOqF/3
> Qqlk7tilcLPuG8s/+dazDtryO0DkVechuV3vrYaKbJe0cTbz08rXGIM0IoOwAfUK
> S0FL3ou1xMXSTIxlwGNb
> =OW1r
> -----END PGP SIGNATURE-----
>
>