The idea with the templates is that the pattern is usually:
/{datatype}/{owner-uid}/...
where the datatype means that you're dealing with, say, people or
collections of people records. So for albums I'd suggest:
/albums/{uid}/{photo-album-id}
(Note that a person record can have links off to all the things it owns if
we want to add an ownership graph. Since many things can potentially be
'owned' by multiple people, a URL path hierarchy would be inappropriate for
determining ownership I think.)
On Fri, Apr 18, 2008 at 10:04 AM, Louis Ryan <[EMAIL PROTECTED]> wrote:
> 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
> -~----------~----~----~----~------~----~------~--~---
>
>
