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

RE: Re-org of chart

From: Bassetti, Ann <ann.bassetti@boeing.com>
Date: Mon, 30 Apr 2012 11:34:08 -0700
To: Jeff Jaffe <jeff@w3.org>, Blaine Cook <romeda@gmail.com>
CC: "public-socialweb@w3.org" <public-socialweb@w3.org>
Message-ID: <2F6E39BD3FF63148929B0CFD2ED0CC1B1D33D7AFE7@XCH-NW-16V.nw.nos.boeing.com>
Very helpful ideas, Jeff.  Thanks!

From: Jeff Jaffe [mailto:jeff@w3.org]
Sent: Monday, April 30, 2012 9:16 AM
To: Blaine Cook
Cc: public-socialweb@w3.org
Subject: Re: Re-org of chart


We spent a great deal of time discussing this on the call today.  Here are my thoughts for comment by you and the rest of the list.

Background:  The block diagram has pluses and minuses.  What is very positive about the diagram is that it is getting all of components of social networking into one picture.  What still needs work is that we have not yet succeeded in coming up with an approach to relate the components to each other.

On our wiki we have several documents that begin to relate the components to each other.  We have a "narrative" which describes the block diagram in more details.  And we have "scenarios" which describe how someone using social networking technology traverses the block diagram.

These begin to show the relationships, but don't have sufficient consistency to characterize the block diagram as an architectural framework.

Blaine's refactoring of the block diagram.  Blaine reminds us that successful block diagrams have often come from communications.  In these block diagrams there are "layers" of activity.  Every time "the function" is exercised, it goes through each layer.  Thus for data communications, "the function" is "sending a message".  Every time a message is sent, it goes through each layer: application, presentation, transport, session, route, link, etc.

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.

Scenarios and basis sets.  What can we learn from the OSI datacomm experience that we can apply here?  it is useful to introduce the vocabulary of "scenarios" and "basis sets".

Scenarios means the activity that drives the block diagram.  For datacomm, the scenarios were pretty simple.  They all involved sending messages.  Some scenarios for datacomm were: Dumb terminal, client/server, file transfer, email, Web access, etc.

Basis set means the irreducible list of 5-10 components that is the top level description of the block diagram.  For datacomm, the basis set was the 7 layers.

Here is the test that you have the right basis set.  If every time you describe a scenario, it maps into an exercising of the basis set of the block diagram - then you've correctly described the underlying technology.  For datacomm, the 7 layer model was (mostly) the right basis set because every time you sent a message it went through the 7 layers in pretty much the same way.

So the questions are (a) what are the relevant canonical scenarios of social networking, and (b) what basis set is the best way to describe the block diagram.  And can we apply the test that for each relevant scenario we are traversing the block diagram in the same way.

It's likely to be tricky because the diversity of activity under the banner of "social networking" is broad.  But that is what we are trying to do.

As a team, then, we need to work together to develop the list of scenarios and propose a basis set for the block diagram.  Building on the shoulders of giants that have already posted to the wiki, here is a proposal.  Please add, modify, or delete.

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

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

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.



On 4/25/2012 1:44 PM, Blaine Cook wrote:
Hi all,

I took a stab at re-factoring the chart that Harry, Evan, and Ann have been working on into something that parallels the OSI 7-layer model. I've attached the incomplete HTML version that I've come up with to this message. If it seems to others to be a useful direction, I'm happy to keep fleshing it out or collaborating with others. I want to get some feedback before I go to far, though! :-)



Received on Monday, 30 April 2012 18:39:24 UTC

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