Things are clearer to me now.
I noticed that there was a case where @all was used, and another where all
was used without the @ sign. Should those both use the @?
Also, AFAIK, the opensocial spec doesn't talk much about public and private
data for a user. That is to say, other than the limited discussion about
appdata read and write access, the spec seems pretty quiet about this issue.
Someone correct that if I am wrong.
On the issue of {pid} and {uid} both being a member of {alluids}. All
implementations I have seen so far respect that. The spec seems quiet on
this notion.
As to groups, thanks for the clarification. It seems like the only place in
the spec that talks about groups is around user_spec for DataRequests, but
it also explicitly says that the only supported groups are VIEWER_FRIENDS
and OWNER_FRIENDS. So, not sure if the spec should include discussion of
managing groups in order to facilitate this RESTful api feature.
Bob
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
> -~----------~----~----~----~------~----~------~--~---
>
>
