Re: API thoughts

I started capturing things on our wiki
https://www.w3.org/wiki/Socialwg/Online_Identity

I also hope we can put this topic on an agenda for our next face to face!

On 01/29/2015 01:27 AM, Amy G wrote:
> Hi all,
> 
> My perspective on this is to some degree a combination of what James and
> Sandro have described, with an extra layer. My main concern is that
> discussion orientates around 'real people' interacting on the web via their
> online presence. It's not usually that straightforward. I'm not sure if
> this is directly relevant to a SocialAPI, but I think it might be worth
> discussing in more detail. My instinct tells me it would be useful for
> machines to be able to understand, or at least better cope with, some more
> nuanced aspects of human identity behaviour (as people are going to
> circumvent real name policies etc regardless of what the t&c say), but I
> definitely don't have all the answers or necessarily a good description of
> the problem. It may turn out that this is just overcomplication.
> 
> People organise their online identities in different ways. James is happy
> to map "jasnell@us.ibm.com", "jasnell@gmail.com" and "
> http://www.twitter.com/jasnell" to himself, and perhaps just uses different
> services, or different accounts on the same service, to separate (eg) work
> vs personal. The consequences of context collapse may be minimal - eg.
> someone searching "James Snell IBM" and finding a personal twitter account:
> no big deal.
> 
> Imagine Bob, a software engineer by day. He too, has "bob@bobswork.com", "
> bob@gmail.com", "http://www.twitter.com/bob" and "
> http://www.twitter.com/therealbob" (the latter for more intimate personal
> tweets). Bob writes and performs original music in his spare time, under
> the stage name "Joe". "Joe" has a YouTube account, "http://youtube.com/joe",
> with a large following of fans. His fans follow him on twitter at "
> http://twitter.com/joe" and read his blog at "http://joe.tumblr.com". When
> Bob is "Joe", he exaggerates some of his attributes, omits some, and
> fabricates others.
> 
> So Bob has multiple accounts on different services, but he wouldn't want -
> or need - to map them all to Bob.
> 
> For this kind of thing, I think it's important to add an extra layer to the
> 'identity stack' and consider Personas as first-class citizens of the web.
> Thus we have:
> 
> Bob the 'real person' - an Agent.
> 
> Bob-work - a Persona.
> Bob-personal - a Persona.
> Joe - a Persona.
> 
> Accounts are held by Personas, and a Persona can hold many Accounts within
> and across services as necessary.
> 
> A Persona may or may not be traceable to an Agent. Bob may be happy to
> aggregate Bob-work and Bob-personal, but wants to keep Joe completely out
> of the mix. Bob has no need to connect Joe to his 'real world' self; Joe
> doesn't need a bank account or a passport or to get married. If Joe gets
> approached by a record label, this might change but for now, as far as
> online interactions go, Bob != Joe. Bob-personal may even follow Joe on
> twitter, as if a fan. And the last thing we want is some software to infer
> Bob is Joe, without Bob's consent.
> 
> People have many reasons for creating distinct and separate, and sometimes
> well-developed, versions of themselves online, whether to construct a
> humourous character with the help of their friends, to explore a side of
> themselves they can't express IRL, to scam people out of money/affection,
> to interact with a very specific community, due to vaguely held notions of
> privacy-protection.. and so on.
> 
> The full model is:
> 
> *Agent*: an abstract concept - I just prefer this term, but I think it's
> similar to James' Identity - for organisations, groups, bots, etc as well
> as people; specifically some entity with agency that can be tracked to the
> 'real world'.
> *Persona*: also an abstract concept - some version or subset of an Agent (
> *not* a subclass).
> *Account*: As associated with a particular service (as Sandro described).
> *Profile*: A document describing the holder of an Account and/or
> information about the Account (also as Sandro described). I agree that the
> identifier for the account is probably the URL for the profile. Which in
> the case of social networks tends to be a combination of the domain of the
> service hosting the account, and a user name (http://username.tumblr.com or
> http://twitter.com/username).
> 
> A link between an Agent and a Persona is *optional*, but could be
> one-to-one, one-to-many, many-to-one or many-to-many. And a Persona can
> hold many Accounts. Each Account has a Profile.
> 
> Explicit links between Agents and Personas could be necessary for some
> activites, eg. to collect your Google Adsense revenue, Google needs to know
> your 'real world' bank details, or when you invite someone to stay on
> Couchsurfing they need to know they can meet you face to face and have your
> address.
> 
> I guess my point is that social software can't assume the same things about
> an online Persona as about a 'real world' person (Agent). Whether this
> would need accounting for, or how, in a social API I'm not totally sure
> though.
> 
> Amy
> 
> On 28 January 2015 at 20:54, James M Snell <jasnell@gmail.com> wrote:
> 
>> On Wed, Jan 28, 2015 at 11:02 AM, Sandro Hawke <sandro@w3.org> wrote:
>>> On 01/28/2015 12:28 PM, James M Snell wrote:
>>>>
>>>> Some thoughts on the Social API...
>>>>
>>>> At the core, the majority of the social APIs reviewed reduce down to a
>>>> handful of relatively simple concepts. Let me see if I can effectively
>>>> classify them.
>>>>
>>>> 1. We have any number of Social Artifacts. These are distinct
>>>> resources that represent various kinds of Things: People, Groups,
>>>> Organizations, Various kinds of content, Responses of various types,
>>>> etc. If you look at the Activity Streams Vocabulary, you can see that
>>>> we already have many (if not most) of these Artifacts already
>>>> identified.
>>>
>>>
>>> sounds reasonable
>>
>> No one has ever accused me of being "reasonable". I'll have to try
>> harder next time ;-)
>>
>>>
>>>> 2. There are a couple of specific Social Artifact that are considered
>>>> central to social systems: that of an Identity and a Profile. The
>>>> Identity represents the authenticated individual. The Profile
>>>> represents a description of the Individual. Secondary to the Identity
>>>> is the Persona. A Persona is some scoped aspect of the Identity. For
>>>> example, "jasnell@us.ibm.com" represents one of my Persona's.
>>>> "jasnell@gmail.com" represents another, as does
>>>> "http://www.twitter.com/jasnell". These are separate Personas mapped
>>>> to the same Identity. A Profile can describe an Identity or a Persona.
>>>> Persona's are themselves a type of Identity.
>>>
>>>
>>> I agree with the basic distinctions you're making, but...
>>>
>>> I'd frame it like this: there are people and accounts.   In normal
>> usage, we
>>> often assume a 1-1 relationship between people and accounts, and that's
>> how
>>> most systems are designed to work.   In practice, however, people
>> sometimes
>>> have multiple accounts and occasionally multiple people share one
>> account.
>>> (In some systems, one or both of those is against the Terms-of-Service,
>> but
>>> I think we'd agree it still happens.)
>>>
>>> A profile is the visible-to-others data about an account.
>>
>> Agreed. I purposefully drew out the larger distinction between
>> Identity/Persona/Profile as a way of framing the discussion. I don't
>> like just calling it "people" and "accounts" because we may be dealing
>> with non-rational entities as well. There are many possible actors
>> that can play.
>>
>>>
>>> In general, computers probably should just be thinking about accounts,
>> not
>>> people.  When they start to connect up the different accounts that people
>>> use, and make inferences about the people behind those accounts, they
>> often
>>> do the wrong thing, because those accounts are often separated for
>> reasons
>>> that are too subtle to be well-modeled by the computer.   (This is the
>>> account I don't want my boss to know about, this is the account I don't
>> want
>>> my kids/parents to know about, etc....)  There may be times where for
>>> specific reasons it makes sense to connect accounts, though.
>>>
>>> If you want to model people (what you're calling "Identity"), as opposed
>> to
>>> just using accounts, I'd like some very compelling use cases.
>>>
>>
>> The key case here is that there is a solid and obvious trend towards
>> linking multiple accounts together. For instance, when I create an
>> account in one system, it may ask me to link my social service
>> accounts from Facebook, Twitter, Github, wherever. These are separate
>> Persona's that I, as a user, am being asked to associate with one
>> another. It's my choice to do so. The "Identity" is more of an
>> abstract concept in this case... a linking concept that ties the
>> various Personas together. It does not need to be explicitly modeled
>> in the software but it still exists in the conceptual model.
>>
>>>> We can formalize this
>>>> using:
>>>>
>>>>    :Identity a owl:Class .
>>>>
>>>>    :Persona a owl:Class ;
>>>>      rdfs:subClassOf :Identity .
>>>>
>>>>    :Profile a owl:Class .
>>>>
>>>>    :hasPersona a owl:ObjectProperty ;
>>>>      rdfs:domain :Identity ;
>>>>      rdfs:range :Persona .
>>>>
>>>>    :describes a owl:ObjectProperty ;
>>>>      rdfs:domain :Profile ;
>>>>      rdfs:range :Identity ;
>>>>      owl:inverseOf :describedBy .
>>>>
>>>>    :describedBy a owl:ObjectProperty ;
>>>>      rdfs:domain :Identity ;
>>>>      rdfs:range :Profile ;
>>>>      owl:inverseOf :describes .
>>>
>>>
>>> I kind of like the trick of having the identifier for the account (aka
>>> persona) also be the URL for the profile.  I'd also make that the root
>> URL
>>> for the user's webspace.   EG http://tantek.com/  or
>>> http://sandhawke.livejournal.com/
>>>
>>> I know some people don't like that, though, so maybe we can't collapse
>> the
>>> three.    Still, it's painful to have the identifier for the
>> account/persona
>>> not be either of those two URLs.    If it's not one of those, what is it,
>>> and how can we make sure people understand it and use it correctly?
>>>
>>
>> I agree that it would be ideal to collapse these but I don't believe
>> we can get away with it entirely. For instance, within IBM we have a
>> corporate "Intranet ID" which is essentially our work email addresses.
>> We use these ID's to log in to various services internally, including
>> our internal deployment of our Connections product. We have a couple
>> of different systems that provide a Profile that describes an
>> individual. The Connections Profile is distinct from our Corporate
>> Employee Directory profile although there is a trend towards combining
>> the two. In this case, the two profiles have distinct URL identifiers
>> separate from our "Intranet ID" identifier.
>>
>> Using the rough sketch model I describe above, an instance of this
>> would look like:
>>
>> <mailto:jasnell@us.ibm.com> a :Identity, :Persona ;
>>   describedBy <http://directory.example.org/?id=jasnell@us.ibm.com>,
>>           <http://connections.example.org/profiles?id=abc123> .
>>
>>  <http://directory.example.org/?id=jasnell@us.ibm.com> a :Profile ;
>>   describes <mailto:jasnell@us.ibm.com> .
>>
>> <http://connections.example.org/profiles?id=abc123> a :Profile ;
>>   describes <mailto:jasnell@us.ibm.com> .
>>
>> Now again, this is just a rough sketch model to help frame the
>> conversation. I'm not arguing that this is how we have to model the
>> API... only that these are the conceptual elements we need to be
>> thinking about.
>>
>>> Maybe this is out-of-scope, but it's hard to think about a social API
>>> without some of these notions.
>>>
>>>>
>>>> 3. The various kinds of Actor's we have defined as part of the
>>>> Activity Streams Vocabulary are all types of Identities.
>>>
>>>
>>> Link?    None of the occurrences of the word "actor" at
>>> http://www.w3.org/TR/2014/WD-activitystreams-vocabulary-20141023/ seem
>>> relevant.
>>>
>>
>> That draft is out of date. Hopefully the updated draft will post
>> tomorrow. Until then, look here:
>>
>> http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html
>> .
>>
>> Note also, in the rough sketch model I outlined, :Persona is a
>> subclass of :Identity. When I say "Identity" I mean to cover what you
>> are calling accounts as well.
>>
>>>> 4. All of the other Social Artifacts are owned by an Identity.
>>>
>>>
>>> -1    Everything needs to be associated with accounts ("personas"), not
>>> people ("Identity").  Otherwise you quickly end up with things associated
>>> with the wrong account, and then my personal work ends up owned by my
>>> employer, etc.
>>>
>>
>> See previous comment :-)
>>
>>>>
>>>> 5. All Social Artifacts can be organized into Collections.
>>>>
>>>> 6. Collections are themselves a type of Social Artifact.
>>>
>>>
>>> Not sure what that means.   Too vague.    But sure....
>>
>> Consider a photo album. The album is a collection composed of
>> individual artifacts but can itself be viewed as an Artifact. It can
>> be shared, liked, commented on, etc.
>>
>>>
>>>> 7. Identity, Persona and Profile are all types of Social Artifacts
>>>> that can be owned by an Identity (an Identity can either own itself or
>>>> be owned by another Identity).
>>>>
>>>> Given these presumptions, the Social API needs to provide a means of
>>>> discovering basic information about an Identity, including:
>>>>
>>>> A. Discovery of any Persona's associated with the Identity
>>>> B. Discovery of any Profile's describing the Identity
>>>> C. Discovery of any Social Artifacts owned by the Identity
>>>
>>>
>>> (again, let's stay away from Identity)
>>>
>>>> Further, the Social API ought to allow the owner of a social artifact
>> to:
>>>>
>>>> D. Create, Modify or Delete the Artifact
>>>> E. Permit other Identities to View the Artifact
>>>
>>>
>>> accounts.    as your boss, I'm likely to grant access to certain files to
>>> your employee account, not your personal account which I know you
>> sometimes
>>> like your kids use.
>>>
>>> etc....     (I'll ignore this issue for the rest of this email)
>>>
>>>> F. Permit other Identities to Create, Modify or Delete the Artifact
>>>
>>>
>>> It's a bit radical, but I love the POSSE idea that you only create or
>> modify
>>> things in your own space.   It simplifies some of this quite a bit
>> (although
>>> it brings up other complications).
>>>
>>
>> I agree that POSSE is good but it does not reflect the reality of many
>> existing social systems. Take Facebook, for example: when you post,
>> are you posting to your own space or to a shared space? Likewise with
>> Twitter, Github, Connections, etc. I have no problem with supporting
>> POSSE in general but it cannot be the only point of view we take.
>>
>>>> G. Permit any Identity to Perform Actions relative to the Artifact
>>>> (Like, Unlike, Share, Comment, Annotate, etc)
>>>
>>>
>>> Are those "actions" any different from creating new Artifacts?
>>>
>>
>> Not likely.
>>
>>>> H. Provide a means of recording which Actions have been performed
>>>> relative to an Artifact.
>>>>
>>>> There are at least two key flows to consider:
>>>>
>>>> 1. I have an Identity, I need to discover information about this
>>>> Identity, potentially including what Artifacts are owned by this
>>>> Identity and what Actions I can take on those Artifacts. (e.g. is
>>>> "acct:joe@example.org" the same as "http://example.org/joe" ? Does
>>>> "joe" have a blog? Can I comment on those blog entries? etc)
>>>>
>>>> 2. I have an Artifact, I need to discover what Identity owns this
>>>> artifact and what Actions I can take on the Artifact. (e.g. can I
>>>> "Like" it? can I "Share" it? can I "Comment" on it? etc)
>>>
>>>
>>> Thinking of these as just data queries and data create/update works
>> pretty
>>> well for me.
>>>
>>
>> +1
>>
>> - James
>>
>>>> >From here it should be straight forward to construct an API. I'll post
>>>> a few thoughts on that a bit later on.
>>>
>>>
>>> I love how the mail system still inserts the ">" before your line
>> starting
>>> "From", because of the how poorly the mbox format was defined ~35 years
>> ago
>>> (as I recall -- not going to get distracted by looking it up).
>>>
>>>         -- Sandro
>>>
>>>> - James
>>>>
>>>>
>>>
>>>
>>
>>
>