Re: new Social Architecture effort

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