OpenSocialAugust 2012

OpenSocial Social Data Specification 2.5.0opensocial-social-data-specification-2-5-0AbstractThis document defines all the data objects used in the OpenSocial APIs. Objects defined here make use of theCore Data[CoreData]objects. The structure of the data is used by many different APIs: JavaScript within the gadget is done using osapi APIs, defined in theSocial Gadget Specification[SocialGadget] REST and RPC access is done using APIs defined in theSocial API Server Spec[SocialServer]

Table of Contents 1.Notation and Conventions 1.1Requirements 1.2Augmented BNF 1.3Basic Rules 2.Primary Social Data 2.1Activity 2.2Activity Streams Support 2.2.1ActivityEntry 2.2.1.1OpenSocial Extensions 2.3AppData 2.3.1An isolated AppData example. 2.3.2An AppData Collection Example 2.4Group 2.5Message 2.6Person 3.Additional Social Data 3.1Account 3.2ActionLink 3.3ActivityObject 3.4Address 3.5Album 3.6App Id 3.7FieldMetadata 3.8Group Id 3.9MediaItem 3.10MediaLink 3.11Name 3.12ObjectMetadata 3.13Organization 3.14File 3.15PropertyMetadata 4.References 4.1Discussion 4.2References Author's Address

1.Notation and ConventionsDomain name examples useRFC2606[RFC2606].1.1RequirementsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described inRFC2119[RFC2119].An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements.1.2Augmented BNFThe grammatical rules in this document are to be interpreted as described inRFC2234[RFC2234](Augmented Backus-Naur Form).The following constructs are introduced in this document to augment RFC2234:{rule1 rule2}Elements enclosed in braces (squiggly brackets) are treated as a single, UNORDERED element. Its contents may occur in any order. Hence:{elem foo} barwould match (elem foo bar) and (foo elem bar).NOTE: Specifying alternatives is quite different from specifying set grouping. Alternatives indicate the matching of exactly one (sub-)rule out of the total grouping. The set mechanism indicates the matching of a string which contains all of the elements within the group; however the elements may occur in any order.#ruleA construct "#" is defined, similar to "*", for defining lists of elements. The full form is "#element" indicating at least and at most elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as( *LWS element *( *LWS "," *LWS element ))can be shown as1#elementWherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.&ruleA construct "&" is defined, similar to "#", which uses an ampersand (&) instead of commas, and MUST NOT include linear white space between elements.implied *LWSThe grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens, since they would otherwise be interpreted as a single token.1.3Basic RulesThe following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by[RFC20]OCTET = CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA / LOALPHADIGIT = CTL = CR = LF = SP = HT =