You can probably use and extend MediaItems[1] and Album[2] data model from OpenSocial specs to associate PhotArk image to a person/user.
As for implementation, you can use Apache Shindig[3] as the base for your REST endpoints. It also has support for JSON-RPC for easy access from JavaScript. [1] http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-Data.xml#MediaItem [2] http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-Data.xml#Album [3] http://shindig.apache.org/ - Henry On Tue, May 17, 2011 at 8:12 PM, Umashanthi Pavalanathan <[email protected]> wrote: > Hi, > > On Tue, May 17, 2011 at 11:42 PM, Avdhesh Yadav <[email protected]>wrote: > >> On Tue, May 17, 2011 at 11:45 AM, Umashanthi Pavalanathan < >> [email protected]> wrote: >> >> > Hi devs, >> > >> > As part of the GSoC project on 'Adding Social Features to PhotArk' [0], >> > currently I am working on building a social API for PhotArk. >> > The purpose of this is to enable support for social features in the >> PhotArk >> > back-end and to enable persisting social data. As discussed in an earlier >> > thread [1], I am planning to build the API based on the Open Social data >> > specification 1.0 [2]. It has two parts: Primary Social Data[3] and >> > Additional Social Data[4]. Supporting the primary data is essential. I >> > would >> > like to know the thoughts of you about supporting the additional social >> > data, considering its usage in PhortArk. >> > >> Can you please explain a bit more what are additional social data >> > > Additional Social Data objects are data objects that are contained within > other Social Data object. These do not stand alone.[0] > For eg: > The Person object has fields like name, address etc of type Name, Address. > The Name data object contains String type fields like firstname, lastname > etc and similarly the Address data object contains String fileds like > region, country etc.[1],[2] > > > >> >> > In my opinion, it will be fine to use String data type for fields like >> > Address, Organization, Name (firstname & lastname) etc. Your valuable >> > thoughts are much appreciated. >> > >> Yes I think String data type for the above fields are fine. >> > > +1. I also think the same since string type fields are enough to represent > social data in the context of PhotArk. > > Anyone having different thoughts? > > > [0] > http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#rfc.section.3 > [1] > http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#Name > [2] > http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#Address > > > > Thanks, > ~Umashanthi > > >> > >> > >> > [0] >> > >> > >> https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/Adding+Social+Features+to+PhotArk >> > [1] >> > >> > >> http://www.mail-archive.com/[email protected]/index.html#01141 >> > [2] >> > http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml >> > [3] >> > >> > >> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#primary-social-data >> > [4] >> > >> > >> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#rfc.section.3 >> > >> > Thanks, >> > ~Umashanthi >> > >> >> >> >> -- >> Avdhesh Yadav >> http://www.avdheshyadav.com >> http://twitter.com/yadavavdhesh >> >
