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

Re: API thoughts

From: Sandro Hawke <sandro@w3.org>
Date: Wed, 28 Jan 2015 14:02:41 -0500
Message-ID: <54C93251.8050904@w3.org>
To: public-socialweb@w3.org
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

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

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.

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

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.

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

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

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

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

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

> >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 Wednesday, 28 January 2015 19:02:54 UTC

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