As OpenSocial has become adopted across a broad set of domains, we've realized that the definition that we have for a "person" doesn't really match our use cases. For example, in many enterprise systems, like Jive's Social Business Platform, IBM Connections, SAP, etc, we end up discarding much of the "social" parts of PoCo and replacing them with more "enterprizy" stuff, e.g. @manager, @reports, @colleagues (think org chart). We also have people using this in a scientific domain and want to add "aspects" / "facets" (please forgive me!) to the profile of a person. Also, when we hit integration scenarios, we find that the structure of the REST APIs, where you always have to specify a "group", e.g. @self, is pretty awkward.
As a result, we'v started a thread to understand if PoCo compatibility is important going forward<https://groups.google.com/forum/?fromgroups#!topic/opensocial-and-gad...>. At one point, I suggested a PoCo/OpenSocial/Schema.org "love fest" where we can come together and figure out the right way to create a flexible model. It would be pretty sweet if we could all agree and get something that really works. Across the install base of PoCo, Schema.org, vcard, & opensocial, this would be something wicked impressive.
From an opensocial perspective, we're trying to align our annual "State of the Union" event with OSCON in Portland. What if we carved out some time around this to have a meetup where we get all the issues on the table and try to figure something out? I'd like to figure out a way to stay in alignment and all work happily together. If we could figure something out, then we could put a reference implementation in place for OpenSocial 3.0, which is tentatively slated for March 2013.
> As OpenSocial has become adopted across a broad set of domains, we've > realized that the definition that we have for a "person" doesn't really > match our use cases. For example, in many enterprise systems, like Jive's > Social Business Platform, IBM Connections, SAP, etc, we end up discarding > much of the "social" parts of PoCo and replacing them with more > "enterprizy" stuff, e.g. @manager, @reports, @colleagues (think org chart). > We also have people using this in a scientific domain and want to add > "aspects" / "facets" (please forgive me!) to the profile of a person. > Also, when we hit integration scenarios, we find that the structure of the > REST APIs, where you always have to specify a "group", e.g. @self, is > pretty awkward.
> As a result, we'v started a thread to understand if PoCo compatibility is > important going forward<https://groups.google.com/forum/?fromgroups#!topic/opensocial-and-gad...>. > At one point, I suggested a PoCo/OpenSocial/Schema.org "love fest" where we > can come together and figure out the right way to create a flexible model. > It would be pretty sweet if we could all agree and get something that > really works. Across the install base of PoCo, Schema.org, vcard, & > opensocial, this would be something wicked impressive.
> From an opensocial perspective, we're trying to align our annual "State of > the Union" event with OSCON in Portland. What if we carved out some time > around this to have a meetup where we get all the issues on the table and > try to figure something out? I'd like to figure out a way to stay in > alignment and all work happily together. If we could figure something out, > then we could put a reference implementation in place for OpenSocial 3.0, > which is tentatively slated for March 2013.
> What do you think???
> -Mark Weitzel > President, OpenSocial Foundation
As OpenSocial has become adopted across a broad set of domains, we've realized that the definition that we have for a "person" doesn't really match our use cases. For example, in many enterprise systems, like Jive's Social Business Platform, IBM Connections, SAP, etc, we end up discarding much of the "social" parts of PoCo and replacing them with more "enterprizy" stuff, e.g. @manager, @reports, @colleagues (think org chart). We also have people using this in a scientific domain and want to add "aspects" / "facets" (please forgive me!) to the profile of a person. Also, when we hit integration scenarios, we find that the structure of the REST APIs, where you always have to specify a "group", e.g. @self, is pretty awkward.
As a result, we'v started a thread to understand if PoCo compatibility is important going forward<https://groups.google.com/forum/?fromgroups#!topic/opensocial-and-gad...>. At one point, I suggested a PoCo/OpenSocial/Schema.org "love fest" where we can come together and figure out the right way to create a flexible model. It would be pretty sweet if we could all agree and get something that really works. Across the install base of PoCo, Schema.org<http://Schema.org>, vcard, & opensocial, this would be something wicked impressive.
From an opensocial perspective, we're trying to align our annual "State of the Union" event with OSCON in Portland. What if we carved out some time around this to have a meetup where we get all the issues on the table and try to figure something out? I'd like to figure out a way to stay in alignment and all work happily together. If we could figure something out, then we could put a reference implementation in place for OpenSocial 3.0, which is tentatively slated for March 2013.
What do you think???
-Mark Weitzel
President, OpenSocial Foundation
--
You received this message because you are subscribed to the Google Groups "PortableContacts" group.
To view this discussion on the web visit https://groups.google.com/d/msg/portablecontacts/-/A02Wv8yuPx4J.
To post to this group, send email to portablecontacts@googlegroups.com<mailto:portablecontacts@googlegroups.com> .
To unsubscribe from this group, send email to portablecontacts+unsubscribe@googlegroups.com<mailto:portablecontacts+unsub scribe@googlegroups.com>.
For more options, visit this group at http://groups.google.com/group/portablecontacts?hl=en.
