W3C home > Mailing lists > Public > public-socialweb@w3.org > May 2012

Re: Re-org of chart

From: Jeff Jaffe <jeff@w3.org>
Date: Wed, 02 May 2012 11:35:03 -0400
Message-ID: <4FA15427.1080204@w3.org>
To: Blaine Cook <romeda@gmail.com>
CC: public-socialweb@w3.org
On 5/2/2012 10:48 AM, Blaine Cook 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.

By #1 I meant a local (non-social) activity.  By #2, I meant share with 
others.  They might result in the same underlying instantiation of the 
infrastructure - but they feel different to the user.

>   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?

I don't know how many scenarios we need.  For each scenario we need to 
show the traversal of the basis set - and once we show that the 
traversal is identical - we certainly can collapse 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.

This is probably just ignorance on my part.  To the extent that we can 
describe a smaller basis set; and then demonstrate how other functions 
are compositions of the smaller basis set - I agree we have a cleaner 
model.  I understand (below) that your refinement will address that.

>> 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.

No problem.  We progress both on the calls, and on the threads, and in 
our thinking time.

> Best,
> b.
Received on Wednesday, 2 May 2012 15:35:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 December 2016 15:48:17 UTC