Looks good, some comments below:
(Also, + spec list as this is really overlapping with the spec)
On Wed, Apr 16, 2008 at 2:05 PM, Vasu Nori <[EMAIL PROTECTED]> wrote:
> Let me summarize People Restful API and the IMPLIED data model behind it.
>
> API calls
>
> - /people/{uid}/all - Collection of all Public profiles for all users
> connected with uid {uid}
>
I'm not sure what Public profile means here -- specifically, I think it's
possible for a social network to implement an interface where the records
here are private to the user, or created by the user to describe people he
knows. They could also be direct representations of a public or
semi-private profile of the target user of course, but I don't think
OpenSocial requires this semantic (right?)
>
>
> - /people/{uid}/friends -- Collection of all Public profiles
> for all users connected with user {uid} and group = "friends"
> - /people/{uid}/{groupid} -- Collection of all people connected
> to user {uid} in group {groupid}
> - /people/{uid}/@all/{pid} -- Public profile, returning ALL
> attributes of the user {pid} which are visible to ANY of the groups of
> user
> {uid}
Not quite sure what the above means (the "visible to ANY..." part)
>
> - /people/{uid}/@self -- Return the COMPLETE Profile for
> user {uid}
> - /groups/{uid}/@self - Return ALL groups for user {uid}
>
>
> Data Model (in the following, Level N+1 is inside Level N object)
>
> - *Level_1 * Person Object
> - *Level_2 * uid String type
> - *Level_2 * set of all groups for this user
> - *Level_3 *groupid (Reserved words: family, friends)
> - *Level_3 * for each group, contacts
> - *Level_4 * set of all contacts of in this group
> (set of Person objects identified by their uid)
Do we want to make each pid also be required to be a uid? This implies that
pids cannot be relative in any implementation. (If this is just talking
about the Shindig implementation then ignore this.)
>
>
>
> - *Level_2 * User profile attributes
> - *Level_3 * for each attribute, flag = public/private
> - *Level_3 * for each attribute, indicate which of the
> user's groups can view this attribute
> - *Level_4 *set of groups this attribute belongs to
>
> what do you say?
>
> On Wed, Apr 16, 2008 at 12:07 PM, John Panzer <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Apr 15, 2008 at 4:43 PM, Robert Evans <[EMAIL PROTECTED]>
> wrote:
> >
> > > I am trying to think of the URIs as mapping to resources on the web,
> and
> > > trying to read it out loud. Consequently, please see the reading of
> URIs
> > > and
> > > some questions/suggestions interspersed below.
> > >
> > > Thanks,
> > > Bob
> > >
> > > On Mon, Apr 14, 2008 at 10:02 PM, David Primmer <
> [EMAIL PROTECTED]
> > >
> > > wrote:
> > >
> > > > We're struggling with these implementation details right now. I'd
> love
> > > > to see what others have decided on.
> > > >
> > > > quick summary of the proposed url system (just for the people api)
> > > >
> > > > /people/{uid}/all -- Collection of all people connected
> to
> > > user
> > > > {uid}
> > >
> > >
> > > Sounds like: "Get people for user, {uid}; all of them."
> >
> >
> > Yes (of course, it really just names the group of all people connected
> to
> > user {uid}, you can do GET/PUT/POST/DELETE on this collection depending
> on
> > what you want to do).
> >
> >
> > >
> > >
> > > >
> > > > /people/{uid}/friends -- Collection of all friends of user
> > {uid};
> > > > subset of all
> > >
> > >
> > > Sounds like: "Get people for user, {uid}; only those who are
> friends."
> >
> >
> > Yep.
> >
> >
> > >
> > >
> > > >
> > > > /people/{uid}/{groupid} -- Collection of all people connected
> to
> > > user
> > > > {uid} in group {groupid}
> > >
> > >
> > > Sounds like: "Get people for user, {uid}; who are also in group_id."
> > >
> > > That one is confusing. Won't this be the same as all people in {group
> > id}?
> > > I
> > > have only a vague concept of "group" here, so please correct that for
> > me.
> >
> >
> > The concept here is that groups are user-relative too (see below for
> > groups
> > discussion). My group "family" is much different from your group
> > "family".
> > friends is really exactly this type of group.
> >
> >
> > >
> > >
> > >
> > > >
> > > > /people/{uid}/all/{pid} -- Individual person record.
> > >
> > >
> > > Sounds like: "Get people for user, {uid}; All of them. Only with
> person
> > > id,
> > > {pid}."
> > >
> > > Why not drop the 'all'? /people/{uid}/{pid}
> >
> >
> > I only put the "all" in there to make the URLs less confusing --
> anything
> > at
> > level 3 is always a person-id, anything at level 2 is always a group id.
> > Conceptually you're saying "give me the person record as accessed
> through
> > group 'X'". Today people records are the same no matter what group
> you're
> > in, but I could imagine wanting to change this (e.g., having a
> > date-added-to-group field) which might vary depending on the context.
> >
> >
> >
> > >
> > >
> > > Then it could sound like, "Get people for user, {uid}; with person id,
> > > {pid}."
> > > Sounds like: "Get people for user, {uid}, with person id {pid}."
> > >
> > >
> > > > /people/{uid}/sel -- Self Profile record for user {uid}
> > >
> > >
> > > Sounds like, "Get people for user, {uid}; sel."
> > >
> > > Why not drop the 'sel' here, and /people/{uid}/ just refers to that
> user
> > > resource specified by {uid}.
> >
> >
> > We could probably drop @self (we added @ signs to make meta-names not
> > conflict with regular names). Thoughts?
> >
> >
> > >
> > >
> > >
> > > > /groups/{uid}/self -- Collection of groups owned by the
> > > > user, which always contains 'all' and 'friends' and may contain
> more.
> > > > (Details TBD)
> > > >
> > > >
> > > Sounds like: "Get groups for user, {uid}; self."
> > > Perhaps, predicated on the group definition, it could just be
> > > /groups/{uid}
> > > which gets all groups that user, {uid} belongs (owns?) to.
> >
> >
> > The intended semantics are groups the user owns. If we drop @self then
> it
> > would just be /groups/{uid}
> >
> >
> > >
> > >
> > > What is group ownership? Is the group any subset of people that a user
> > > knows?
> > >
> >
> > A user can in principle set up any number of groups to classify the
> people
> > they know. They get one special group by default, "friends". Not
> > everybody
> > they know is necessarily a friend.
> >
> > This is different from groups-you-belong-to in principle, in that you
> can
> > set up a group and stuff me in it without me being aware of it or
> caring.
> > (Again, "friends" is special and has additional semantics -- it's double
> > opt
> > in. Other groups may have special semantics too, but the API doesn't
> > specify those semantics.)
> >
>
