W3C home > Mailing lists > Public > public-socialweb@w3.org > January 2015

Re: API thoughts

From: Harry Halpin <hhalpin@w3.org>
Date: Thu, 29 Jan 2015 12:23:16 +0100
Message-ID: <54CA1824.4070508@w3.org>
To: public-socialweb@w3.org


On 01/29/2015 03:07 AM, Sandro Hawke wrote:
> summary: +1, nicely said
> 
> a few ideas and two concerns, below...
> 
> On 01/28/2015 07:27 PM, 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 <mailto:jasnell@us.ibm.com>",
>> "jasnell@gmail.com <mailto: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
>> <mailto:bob@bobswork.com>", "bob@gmail.com <mailto: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.
>>
> 
> I agree this model is quite accurate, and elegant.   My only concern is
> that it may be still be too complicated for end-users.  I don't really
> think most folks will understand the idea of "Persona", and if they
> misunderstand it even a little, they could easily have some nasty
> surprises.   I don't think I've seen it in a mass-market UI.
> 
> One approach that might make more sense is to have the notion of
> "linked" accounts.   When you "link" accounts, you're saying they have
> the same persona behind them, and it's okay if people think it means
> they have the same person behind them.   It's certainly my intuition,
> that people out there googling for my accounts will mentally connect
> some of them as belonging to the same person, and others they might not
> link, or might link with less confidence.       If I had a stage
> persona, I'd probably try to keep any of its accounts from being linked
> with any of my other accounts.  I think I'd understand once any Bob
> account was linked with any Joe account, all Bob accounts would
> effectively be linked with all Joe accounts.
> 
>> 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).

Again, I'm not sure what this buys you other than saying, "hey,there are
agents that can be subclasses of other agents".

Whenever we get out of purely technically defined spaces, I think it's
best to make minimalistic assumptions about the world.

> 
> One small issue with the term "Agent" is that it's broad enough that
> people, in my discussions with them, seem to think Persona *is* a
> subclass of Agent.  (I agree it shouldn't be for this modeling.) People
> in the WebID CG seemed to argue that WebIDs identify agents and so can
> be used to identify Personas and Accounts.    So, that's a problem.
> 
> But now I'm thinking maybe we can avoid naming this "Agent" class, since
> the modeling doesn't need to reach through Persona much, and when it
> does (as with your banking example), then it's very specifically to a
> certain kind of entity.  In my jurisdiction, as I understand it, the
> class of things allowed to individually possess a bank account is the
> union of Natural Person (a retronym formed once it became clear that
> Corporations are legally people) and Corporation.  Actually, I'm sure
> only certain kinds of Natural Person (over age 16, etc) and Corporation
> (domiciled in one of the 50 states) are allowed.  My point is *we*
> shouldn't try to model what happens above/behind Persona, since it's
> very domain-specific, so maybe we don't even need a name for it.

Yes. So you can just have personae/agents/identity/whatever be
subclasses of each other and link to each other.

I think if anyone is arguing for any more complexity here, they deserve
to give the WG a real use-case that can't be solved without this
two-step distinction.


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

This seems to be a sensible distinction. Note that the IETF has the
accnt URI scheme, and we can scope profiles to be documents that can be
retrieved that describe an account.


>>
>> 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.
>>
> 
> Arguably, to give you money like this, Google does NOT need to know
> anything about Persona or Person -- it just needs your bank account,
> which is (of course), just another Account.    So we have a Google
> Account linked to a Bank Account.   From that link, you can infer the
> same Persona behind them both, and might even infer the same Person, but
> those are both unnecessary inferences.  In many, many cases, it's really
> just the Accounts that matter.
> 
> 
>> 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.
>>
> 
> There are a ton of parameters (eg To, Tag) and structures (eg Contact
> List, Group) in these APIs which identify "people" in some sense.   My
> argument is that in nearly every case, we should be using account
> identifiers (eg Profile URLs) to do this, not Person/Agent identifiers
> or Persona identifiers.
> 
>      -- Sandro
> 
> 
>> Amy
>>
>> On 28 January 2015 at 20:54, James M Snell <jasnell@gmail.com
>> <mailto:jasnell@gmail.com>> wrote:
>>
>>     On Wed, Jan 28, 2015 at 11:02 AM, Sandro Hawke <sandro@w3.org
>>     <mailto: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 <mailto:jasnell@us.ibm.com>"
>>     represents one of my Persona's.
>>     >> "jasnell@gmail.com <mailto: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 <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 <mailto:jasnell@us.ibm.com>> .
>>
>>     <http://connections.example.org/profiles?id=abc123> a :Profile ;
>>       describes <mailto:jasnell@us.ibm.com <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 <mailto:acct%3Ajoe@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
>>     >>
>>     >>
>>     >
>>     >
>>
>>
> 
> 
Received on Thursday, 29 January 2015 11:23:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:14 UTC