The URI format used as examples so far seems a little prone to ambiguity?
/people/{uid}/{groupid}
is also a good match for
/people/{uid}/{photo-album-id}
especialy if we intend to allow the use of natural names as identifiers, as
in..
/people/me/friends
Are we intending to namespace the id's to avoid this issue or just namespace
by extending the URL pattern
/people/{uid}/groups/{groupid}
Thanks
-Louis
On Thu, Apr 17, 2008 at 6:18 PM, Vasu Nori <[EMAIL PROTECTED]> wrote:
> anyone has a comprehensive set of testdata for "People" to correspond with
> the datamodel discussed in this thread?
> just checking..
>
> On Wed, Apr 16, 2008 at 6:24 PM, John Panzer <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Wed, Apr 16, 2008 at 6:08 PM, Vasu Nori <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, Apr 16, 2008 at 5:51 PM, John Panzer <[EMAIL PROTECTED]>
> wrote:
> > >
> > > > 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?)
> > > >
> > > >
> > > I made up the word "public".
> > > my most fundamental assumption is: A user has a set of attributes to
> > > decribe
> > > himself/herself. In this set,
> > > some attributes are set to be public
> > > and some are set to be completely private ("visible" ONLY to self)
> > > and some are set to be "visible" only to certain designated groups.
> > > does this make sense?
> > >
> > > if so, the above URL meaning is what I thought was said in the thread
> > > earlier by others.
> > >
> > > I am looking to validate my understanding really.
> >
> >
> > Ah, okay. But I think this would interact with the access control of
> the
> > requestor. There's of course a requester (which may be anonymous) in
> the
> > picture here. Requestor might be different from both {uid} and {pid}.
> >
> >
> > >
> > >
> > > >
> > > > >
> > > > > - /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)
> > > >
> > > "visible" = the attributes that are returnable in this/a query.
> > > maybe bad word..
> > >
> > > >
> > > >
> > > >
> > > > >
> > > > > - /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.)
> > > >
> > >
> > > again my assumption is that each "contact" is also a "Person" in the
> > > system
> > > - the SAME "Person" object defined at Level_1.
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > - *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.)
> > > > > >
> > > > >
> > > >
> > > >
> > > > >
> > > >
> > >
> >
> >
> > --~--~---------~--~----~------------~-------~--~----~
> > You received this message because you are subscribed to the Google
> Groups
> > "OpenSocial and Gadgets Specification Discussion" group.
> > To post to this group, send email to
> > [EMAIL PROTECTED]
> > To unsubscribe from this group, send email to
> > [EMAIL PROTECTED]
> > For more options, visit this group at
> > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> > -~----------~----~----~----~------~----~------~--~---
> >
> >
>
