Re: new Social Architecture effort

> Thanks a lot, Melvin, for all this effort! 
> 
> It's late here, at TPAC in Sapporo, and I'm whupped, so, truthfully, I just don't have the energy to read and absorb what you've written. 
> 
> As you know, I'm officially 'on hiatus' until the new year. So -- hold that thought!  Or, I will. (Of course you and other folks are welcome to continue working, and I'll catch up later.)
> 
> Thanks again!
> 
>   -- Ann
> 
> PS. I think we may have picked up a couple new participants from our social session today. 



> On Oct 28, 2015, at 18:13, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> 
> 
>> On 2 October 2015 at 01:42, Ann Bassetti <ann.bassetti@yahoo.com> wrote:
>> You're the bees knees, Melvin!  I really appreciate the new energy you're bringing to this work.  And, Ed, we've missed you!
>>  
>> Before this goes very far, I wanted to voice my perception that what you describe as "architectural best practices for modeling people" ... sound very SoLiD-centric. I'm not saying I agree nor disagree. 
>> 
>> It does seem to me that the foundations of "social" rest on the social graph. I'm not sure if that is universally agreed-to, or not. If not, then what do others suggest?
>> 
>> In any case, before we call something a "best practice", I'd like to be sure we have some consensus from the various technical points-of-view.  
>> 
>> (I hope the gods don't send lightning down because I'm inserting a comment .... I'm only 1 day into my "dark" phase, but couldn't resist. :-)
> 
> Hi Ann
> 
> I've been thinking more about this, and I think you're absolutely right.
> 
> We have design issues, and awww, and we have solid and the social web, but we dont much anything in between that gives how we got from one to the other.
> 
> My thoughts on an "architecture of the social web" type document would be to have it similar to awww [1].
> 
> In "weaving the web", tim writes "The web is more a social invention than a technical one", see tantek's commentary on this, back from 2003! [2]
> 
> To my mind the first two chapters of this work should clear up and describe how the social web is :
> 
> 1. People Oriented
> 2. Relationship Driven
> 
> I think that logically it makes sense to start with (1) before tackling (2).
> 
> Having followed identity on the web since the start of openid (yadis) [3] it's very confused and very confusing.  I think it would help to have a document that dispels some of the confusion.
> 
> Because identity is an emotive topic, I suggest developing this in the IG, and leaving the WG to continue it's work.  Anyone interested from the WG or identity community can join the IG.
> 
> Off the top of my head:
> 
> Identity on the web is an exercise in naming.  We mimic the typical process in the real world of parents naming a child with a string of characters in their local alphabet.
> 
> Points to consider:
> 
> 1. Global vs Local Identifiers.  On the web it is advantageous to use URIs to name things.  There are a number of advantages, covered in awww, such as long lived identifiers, uniqueness, scalability and network effect.  This contrasts to the real world where name clashes occur frequently.  On the web both strategies are employed, local nicks (common) or global identifiers.  In creating a scalable software solution, global identifiers discourage fragmentation and balkanization.
> 
> 2. Choosing a scheme.  Global URIs always have a scheme ( the string of characters before the ":" ).  Introspecting on the URI enables you to find a specification that tells you how to interpret that scheme.  Typical identifiers for identity on the web are http:, mailto:, xmpp: (and others) with each type having its own following.  One of the problems typically faced on the web is that systems using one scheme are unable to communicate with those using another.  So email bases systems dont often talk to http profile based systems, again creating fragmentation and balkanization.  A scalable solution to this issue is not to mandate any one scheme, but to build systems that are tolerant of multiple schems.
> 
> 3. Indirect Identifiers and Overloading.  Once a scheme is chosen, a string of characters that can denote a user (or account see later) can be formed as part of a system, typically used as primary and foreign keys used to make connected systems.  It is common to overload identifiers for multiple uses.  For example, an email address may be used as A) a memorable identifier for login forms B) a message delivery service C) A global identifier.  Another example is using an http home page or profile as A) a document containing information about an entity B) A global identifier.  Care must be taken to follow the guidelines in each individual spec, and it must be recognized that using identifiers for multiple purposes can cause unexpected behavior in software.  
> 
> 4. Users vs Accounts.  Conceptually there is often confusion as to what an identifier denotes.  Is it the user themselves (typical example facebook), or is it an account on a service (typical example google plus).  Both systems have their advocates and uses.  At a minimum, if a social web is to be people oriented, there should be a mechanism for denoting people.  It is desirable for both account oriented systems and people oriented systems to interoperate.  More work is needed in this area.
> 
> 5. Single vs Composite Identity.  The assumption that an identifier and what is being identified is a one to one relationship can often break down when operating at scale.  In practice relationships can be one to many, many to one, and even many to many.  There is no single perfect mechanisms to handle all of these cases, at present time.  And the temptation is to not try and just say "identity is complicate", however this leads to a social web that is very hard to build systems.  A starting point should be to model one to one relationships in a way that allows extension to many to many.
> 
> 6. Other.  I'm sure I've missed a few things, feel free to add or make suggestions.
> 
> Just writing that list out I found to be a good exercise.  I think it illustrates potential value in documenting much of what we've learnt in the last 10 years in trying (and sometimes failing) to build a social web.  I appreciate that many will think this is either too hard a problem, or a problem not worth trying to tackle, and that's a reasonable viewpoint.  However, I would welcome any constructive comments on this thread.
> 
> [1] http://www.w3.org/TR/webarch/
> [2] http://tantek.com/log/2003/0813t1158.html
> [3] http://lj-dev.livejournal.com/683939.html
>  
>> 
>>  
>>   -- Ann
>> 
>> PS. I updated the subject line.
>>  
>>  
>> From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] 
>> Sent: Thursday, October 01, 2015 4:15 PM
>> To: Krebs, Edward (E.C.)
>> Cc: Bassetti, Ann; Larry Hawes; Social Web Working Group; public-social-interest@w3.org
>> Subject: Re: Boeing resignations (hopefully temporary for me)
>>  
>>  
>>  
>> On 1 October 2015 at 18:46, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>  
>>  
>> On 1 October 2015 at 17:39, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>  
>>  
>> On 1 October 2015 at 15:02, Krebs, Edward (E.C.) <ekrebs@ford.com> wrote:
>> There are some good architecture starting points. The social Headlights task Force started on this path. I suggested one view based on that initial work in the Workshop on Social Standards in August 2013. http://www.w3.org/2013/socialweb/papers/An%20Enterprise%20Social%20Network%20Reference%20Architecture.pdf
>>  
>> IBM presented one in 2014: http://www.slideshare.net/heathwulf/social-architecture-1-h2014
>>  
>> Thanks Edward, these are great slides.
>> What really struck me was the call for a:
>> - People Centric
>> - Relationship Driven
>> architecture.  I think the work we've started out on has a gap here.  While there's a lot of work done to cater for micro blogging enthusiasts the enterprise has been less well served, imho. 
>> I think these presentations could be a great basis to create an architecture document, which is missing, not just in this group, but in the social web in general.  In creating a people centric, relationship driven architecture we can talk about people and relationships.  How this can be achieved technically, as part of a social graph.  The declarative nature using the law of least power.  Having open ended extensibility to cater for enterprise use cases as well as common social networking features.
>> Essentially creating the awww [1] of the social web.  An essential document for anyone creating a system in the social web, either in an enterprise or public setting, that will cover all the base work needed to get started with real world use cases.  It's something that's been missing for 10 years, and imho, one reason that has lead to balkanization.  
>> 
>> This is an IG deliverable.  Would anyone in the IG wish to help with this?  
>> 
>> Where could we get started -- perhaps a wiki page, then migrate to a github repo?
>>  
>> elf has suggested building on :
>> 
>> http://w3c-social.github.io/social-arch/
>> Which I think is a great idea.  I've chatted to Amy too, who hopefully may have some cycles free to collaborate.
>> Input here or on in the github issues very welcome! :)
>>  
>> Im going to start working on this document, but my initial thoughts are:
>> "Data Model" is too broad a section, I'd like to see it broken down as follows:
>> "People" -- this is a loose term that can mean nodes in general, referring to people, agents, accounts, profiles, groups etc. but try to capture that the social people is people oriented.
>> Have architectural best practices for modeling people:
>> 1. Give a person a URL
>> 2. Give that url a type (as exemplified by open graph protocol, schema.org and foaf)
>> 3. Distinguish between the (HTTP) document and the person, as this could cause processor problems
>> 4. Allow people to have relationships
>> Then cover "Relationships" as a basis of relationship driven design
>> 1. Show the nature of relationships as one way and two way
>> 2. Show typical relationship styles such as, follow, friend, co-worker etc.
>> 3. Show an open ended architecture for extensibility and reuse
>> Once these two core pieces are described, show how they are combined to form a social graph.  Talk about the read, write and search functionality etc.
>> I would suggest moving as much of the technical decisions as possible out into another doc, and keeping the architecture document clean and minimal yet, covering all the basics an implementor would need to get started and to tackle the user stories.
>>  
>>  
>> 
>> [1] http://www.w3.org/TR/webarch/
>>  
>>  
>> Regards,
>> Edward C. Krebs 
>> Enterprise Architect 
>> Enterprise Technology Research
>> Ford Motor Company Information Technology
>> Quote of the day:
>> "The best way to predict the future is to invent it." -- Alan Kay
>