- From: Harry Halpin <hhalpin@w3.org>
- Date: Thu, 29 Jan 2015 12:23:16 +0100
- 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