Re: Re-org of chart

Blaine,

re:   "Identity and Data are definitely towards the base of the stack, but
one needs a way
to negotiate identity. I see "identity" in this world as comparable to DNS
in the OSI model.

>> Perhaps Identity and relationships should be a core part of how to
operate across implementations where the data can be different.  i.e. where
else does this DNS connect? Is that connection reciprocated?  Is the
connection with an 'authority' i.e. government or celebrity.  Are
activities happening over that DNS?  If yes then I can trust this DNS
better than if I don't know anything about it.  The value add is that it's
an activity and feedback element that goes with a profile in a
non-centralized way. The feedback and network of relationships might be a
part of a foundation for distributed networked relationships at the core.

However, that might conflict with something else you wrote,which was

"a lot of the early "open" social network technologies were based on social
graph traversal, when the focus desperately needs to be on creating social
experiences."

>> I'm not sure what you mean by that.  I'm wondering if mining a network
of relationships might be useful with what permissions, like posting
privileges, might be granted to known good players based on activities
elsewhere.  At the 'core' I'm not thinking of cross posting information, or
a following friend-of-a-friend graph, but just carrying some weight to a
'DNS'.

Lloyd

On Wed, May 2, 2012 at 7:48 AM, Blaine Cook <romeda@gmail.com> wrote:

> Hi all,
>
> On Apr 30, 2012 5:16 PM, "Jeff Jaffe" <jeff@w3.org> wrote:
> > We need a similar paradigm for social networking.  Blaine's description
> of 25 April is a step in the right direction.  But it is probably not the
> final word.  There are pieces of "social networking" that don't seem to
> show up in the graph (sharing, notification).  And the notion of "layer" so
> prevalent in communications might not be the right metaphor for the social
> block diagram.
>
> +1 - my intent was bout at all to suggest that my work was anything
> but a thought piece, intended to help us move towards an understanding
> of how the various bits connect.
>
> > Scenarios.  These are social networking activities that people perform.
> >
> > 1. Update personal information
> > 2. Share information
> > 3. Form a group
> > 4. Use a group to collaborate on a problem
> > 5. React to an event
> > 6. Launch an app
> > 7. Explore a social graph
> > 8. Update a location
> > 9. Provide a reaction
>
> This is great.
>
> Probably #1 and #2 are the same thing. I'm not sure what #y means? #7
> is tricky, if only because a lot of the early "open" social network
> technologies were based on social graph traversal, when the focus
> desperately needs to be on creating social experiences.
>
> #8 is similar to #1 & #2 - is it worth breaking these things out into
> lots of different scenarios?
>
> > Proposed basis set.  This is the minimal comprehensive description that
> allows the scenarios to be performed.
> >
> > 1. Identity and addressing (includes profile)
> > 2. Data (text, documents, etc.)
> > 3. Sharing infrastructute (events, location, status)
> > 4. Linking to more information (posting, hyperlinks, search)
> > 5. Group dynamics (create groups, membership lists, social graph)
> > 6. Transport / messaging
> > 7. "Feeds" management
> > 8. Reactions
>
> This formulation doesn't match my mental model at all – Identity and
> Data are definitely towards the base of the stack, but one needs a way
> to negotiate identity. I see "identity" in this world as comparable to
> DNS in the OSI model. Other issues are that group dynamics can be
> composed from messaging (point-to-point or multicast) (i.e., #5 is
> dependent on #6), and I think "sharing infrastructure", #3 is the
> meta-category of all of this, isn't it? Reactions can't happen without
> some construction of feeds, but neither can #3, #4, or #5. Likewise, I
> think reactions are just a kind of data.
>
> > The test
> >
> > The test is the following.  For each scenario (currently 9), is it the
> case that the underlying technology that allows us to describe the scenario
> sits in the basis set (currently 8 technology categories).  And are these
> categories used roughly the same way each time.
>
> I like this conception; I'll try to expand and refine the stack I
> proposed and try to run some scenarios through it. :-)
>
> Sorry I haven't been able to make the calls recently – two hours is
> tough for me to set aside unless it's really focused time.
>
> Best,
>
> b.
>
>


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