- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 28 Jan 2015 21:07:26 -0500
- To: Amy G <amy@rhiaro.co.uk>, James M Snell <jasnell@gmail.com>
- CC: "public-socialweb@w3.org" <public-socialweb@w3.org>
- Message-ID: <54C995DE.2050307@w3.org>
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).
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.
> *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.
>
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 02:07:41 UTC