“In most books, the I, or first person, is omitted; in this it will be retained; that, in respect to egotism, is the main difference. We commonly do not remember that it is, after all, always the first person that is speaking.
I should not talk so much about myself if there were anybody else whom I knew as well. Unfortunately, I am confined to this theme by the narrowness of my experience. Moreover, I, on my side, require of every writer, first or last, a simple and sincere account of his own life, and not merely what he has heard of other men's lives; some such account as he would send to his kindred from a distant land; for if he has lived sincerely, it must have been in a distant land to me.
Perhaps these pages are more particularly addressed to poor students. As for the rest of my readers, they will accept such portions as apply to them. I trust that none will stretch the seams in putting on the coat, for it may do good service to him whom it fits.”
― Henry David Thoreau, Walden
It’s not just a game that includes a ball,
this is a game with a rise and a fall.
The players work hard and hardly ever rest,
their names printed proudly across their vest.
The ball bounces many of times,
and goes through the net as the buzzer chimes.
A slam dunk or alley-oop the skills are all there,
as the ball flies high up into the air.
Basketball is not just a game, it’s an art,
where the game is decided right from the start.
Basketball is all about the team,
as each individual has their own dream.
It’s not just about those points on the board,
but the hard work winning shot as the point is scored.
I love the gym; I love basketball. I'm really passionate about it.
---Kyrie Irving


| Network Working Group | |
| Internet-Draft | April 2012 |
| Expires: October 01, 2012 |
OpenSocial Core API Specification 3.0
TBD
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 01, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
TBD
The 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 in RFC2119 [RFC2119].
Some sections of this specification are illustrated with fragments of a Augmented Backus-Naur Form [RFC5234] (ABNF) grammar. The rules specified are normative.
This specification allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also an IRI, so a URI may be used wherever an IRI is named. There are two special considerations: (1) when an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in Section 3.1 of RFC 3987. and (2) when an IRI is serving as an identifier, it MUST NOT be so mapped.
OpenSocial REST Services consist of collections of Web-accessible resources that can be accessed and modified using the basic set of HTTP request methods as defined by [I-D.ietf-httpbis-p2-semantics]. Such services are intended to be used either by OpenSocial Applications as defined by [core-gadget] or other third parties to access social data hosted and managed by an OpenSocial-enabled server.
In general, for all REST Services:
Implementations are free to support additional HTTP methods but their use is considered to be outside the scope of this specification.
Resources made available via a REST Service can represent individual objects (e.g. a person, a document, an activity) or collections of objects (e.g. a friends list, a folder containing multiple files, a listing of events). Every resource is identified by a distinct URI to which the various HTTP methods are to be sent.
For example, to retrieve a user's current profile using the OpenSocial Person Service, a client application would issue a GET request:
GET /api/people/@me/@self HTTP/1.1 Host: api.example.org
When a client application is required to communicate with an OpenSocial server via an intermediary that restricts the use of certain standard and extension HTTP Methods (e.g. PUT, DELETE, PATCH), the client SHOULD utilize the X-HTTP-Method-Override HTTP Request Header mechanism in a POST request.
For example, the HTTP PATCH request method is still relatively new and is not yet fully supported by deployed HTTP infrastructure. It is therefore possible that PATCH requests might be blocked by certain intermediaries. To address such cases, the PATCH request may be modified by sending a POST request that includes the X-HTTP-Method-Override HTTP header:
POST /api/people/@me/@self HTTP/1.1 Host: api.example.org Content-Type: application/json X-HTTP-Method-Override: PATCH {...}
OpenSocial Servers MUST respond to such requests as if the method specified by the X-HTTP-Method-Override was the actual operation used by the request, as opposed to POST.
The X-HTTP-Method-Override header MUST NOT be used to send HTTP GET requests.
Responses to all requests will specify an appropriate HTTP Status Code indicating the status of the response.
All REST Services share a common, basic URI Structure that MAY be extended on a case-by-case basis. This common structure helps to ensure that all interactions remain as consistent as possible across multiple REST Services while allowing individual service-specific and implementation specific behaviors to be supported.
By convention, the Common URI Structure is described using a URL Template [RFC6570]:
{protocol}://{+host}{/rootpath*,service-identifier,local-identifier,aspect-identifier,filters*}{?parameters*}
| Expression | Description |
|---|---|
| protocol | Indicates either "http" or "https" depending on whether or not SSL or TLS is to be used with the request. |
| host | Specifies the DNS Host Name and, if necessary, the TCP/IP port at which the REST service is available. For instance, "api.example.org" or "api.example.org:8080". |
| rootpath | Specifies the root path of the REST Service. The value is specified as an Array of isegment-nz path segments as defined by [RFC3987]. For example, ["services","api"], which when expanded by the URL Template produces "/services/api". |
| service-identifier | The service identifier as defined by Section 2.2. |
| local-identifier | The local-identifier of a data object, as defined by Section 2.3 that is the target of an HTTP request. |
| aspect-identifier | An aspect-identifier, as defined by Section 2.4, that identifies the specific aspect of the identified Data Object to which the HTTP request is being directed. For instance, if the intent of the request is to retrieve the list of other people connected to a particular user's profile, the local-identifier specifies the target user's local-identifier and the aspect-identifier would specify "@friends". |
| filters | A set of zero or more service, resource and aspect specific path segments that specify additional filters for the request (see Section 2.5). The value is specified as an Array, each member of which can either be an isegment-nz path segment or an Array of isegment-nz path segments. For instance, the value ["a","b","c"] would expand within the URL Template to "/a/b/c"; whereas the value ["a",["b","c"]] would expand to "/a/b,c". |
| parameters | Specifies a collection of query parameters associated with the request, specified as a collection of name and value pairs. All REST Services are required to support a common core collection of query parameters as defined in Section 2.6 and MAY introduce additional service, resource and aspect specific parameters. |
To illustrate how the common URI structure operates, consider the following example. For each of the URI Template variables, assume the following values:
| Variable | Value |
|---|---|
| protocol | https |
| host | api.example.org |
| rootpath | ["service","api"] |
| service-identifier | people |
| local-identifier | @me |
| aspect-identifier | @friends |
| filters | ["@recent"] |
| parameters | {"count":"10", "updatedAfter":"2012-04-16T00:00:00Z"} |
When applied to the common URI Template, the Request URI Generated becomes: "https://api.example.org/service/api/people/@me/@friends/@recent?count=10&updatedAfter=2012-04-16T00:00:00Z".
Service Identifiers are simple text labels, conforming to the isegment-nz construction defined in [RFC3987], used to identify an individual OpenSocial REST service.
service-identifier = isegment-nz
For instance, the OpenSocial Person Service is identified using the label "people" while the Activity Stream Service is identified using the label "activity".
An example request to retrieve a person's profile using the Person Service:
GET /service/api/people/@me/@self HTTP/1.1 Host: example.org
An example request to retrieve an Activity Stream associated with a person using the Activity Stream Service:
GET /service/api/activity/@me/@all HTTP/1.1 Host: example.org
Please refer to the [social-app] specification for complete details on the core set of social data services defined by this version of the OpenSocial specification. Implementations are free to implement additional services.
If a particular implementation does not support a given specified service, it SHOULD simply return a 404 Not Found response.
Every individual data object managed and made available via a REST service is uniquely identified within that service's context by a local-identifier.
The local identifier is an opaque String conforming to the isegment-nz construction of [RFC3987]. This string unique identifies the object within the context of the service with which the object is associated.
local-identifier = isegment-nz
The literal string value "@me" MAY be used as an alias for the local-identifier of the currently authenticated entity.
For instance, if a person uses the OpenSocial Person Service to request information about their own social data profile, the request URI can specify the "@me" alias as opposed to the requester's local-identifier. The server fullfilling the request would use the requests authentication context to determine the appropriate local-identifier.
The literal string value "@anonymous" MAY be used as an alias for the local-identifier of any anonymous, non-authenticated entity.
Previous versions of this specification used the numeric integer value -1 (negative one) to identify anonymous, non-authenticated users. The use of the numeric integer is considered to be deprecated and SHOULD NOT be used; however implementations MAY continue to support the use of -1 in order to maintain backwards compatibility with older applications.
The literal string value "@public" is provided as a local-identifier identifying the total collection of "public" resources provided by a REST service. For instance, if a requesting application wishes to use the OpenSocial Activity Service to retrieve a listing of all recent public Activities that have occurred independent of the specific person or resource with which those activities are associated, the request URI can specify "@public" as the local-identifier.
The "@public" alias might not be supported by all REST services or implementations.
Previous versions of this specification utilized an older form of "global identifier" that has since been deprecated. Server implementations MAY continue to support the older format for backwards-compatibility purposes with existing applications but new applications SHOULD NOT make use of the deprecated syntax.
The legacy syntax consisted of a combination of a DNS domain name and an object's local identifier separated by a colon (":") character.
domain-name = *( ALPHA / DIGIT / "_" / "." / "-" ) legacy-global-identifier = domain-name ":" local-identifier
Every type of Data Object provided by a REST service can have zero or more distinct aspects to which requests can be directed. These aspects are always specific to the individual type of resource and service. Aspects are identified within the URL structure using an aspect-identifier.
aspect-identifier = "@" isegment-nz
For example, Person Data Objects as defined by the [social-app] expose a number of Aspects that are specific to the social data that makes up a person's profile data. For instance:
To retrieve information about specific aspects, the appropriate aspect-identifier would be included in the request URI.
GET /service/api/people/@me/@self HTTP/1.1 Host: example.org GET /service/api/people/@me/@friends HTTP/1.1 Host: example.org GET /service/api/people/@me/@network HTTP/1.1 Host: example.org
Please refer to [social-app] for complete details on the specific aspects associated with each of the core OpenSocial Social Data Objects and services. Implementations are free to define additional aspects for any of the core Social Data Objects and Services.
To prevent against the likelihood of compatibility issues arising through the use and extension of aspects by implementations as well to promote the reuse and socialization of new aspect-identifiers, this document establishes a registry of common aspect identifiers. [aspect-identifier-registry] It is RECOMMENDED that all aspect-identifiers used within OpenSocial implementations be added to the registry per the requirements detailed in Section 8.
If a particular implementation does not support a given specified aspect, it SHOULD simply return a 404 Not Found response.
The Common URI Structure also supports the use of service, data object and aspect specific filters that can be used to further define the scope of a particular REST request. When expressed within the request URI, such filters take the form of an arbitrary set of additional isegment-nz path segments.
Implementations MAY choose to allow multiple filter identifiers separated by a comma (,) character within a single path segment. When multiple, comma-separated filter identifiers are specified, they are to be interpreted as distinct alternatives (e.g. the filter segment "a,b" is to be interpreted as "a or b" as opposed to "a and b").
filter = isegment-nz
For example, an application that is requesting a listing of Activity Objects provided by the OpenSocial Activity Stream service may wish to limited the returned set of activities to only those generated by particular applications. To do so, the application would identify the applications using filter segments:
GET /service/api/activity/@me/@all/app-1,app-2 Host: example.org
Alternatively, an implementation can choose to allow applications to limit the results returned by the request to only those that have been "tagged" with a particular label. This is strictly an non-normative example illustrating the basic function of filters as "tagging" of Data Objects is not defined by this specification:
GET /service/api/activity/@me/@all/@tags/foo,bar
When an implementation supports and applies filters, they MUST be interpreted as a hierarchy, with each subsequent path segment being interpreted relative to the previous segment. The exact application of the filters is left to the implementation, however.
For example, given the hypothetical request:
GET /service/api/activity/@me/@all/app-1,app-2/@tags/foo,bar
The appropriate way to interpret this request is: Return the list of all activities for the authenticated user generated by either app-1 or app-2 that have been tagged with either "foo" or "bar".
Please refer to [social-app] for complete detail on specific filters associated with each of the core OpenSocial Social Data Objects and services. Implementations are free to define additional filters for any of the core Social Data Objects and Services.
If a particular implementation does not support a given specified filter, it SHOULD simply return a 404 Not Found response.
All REST services MUST support a common set of URI Query String parameters that can be used to modify the processing of the request and the information returned to the client.
| Name | Description |
|---|---|
| count | When the resource to which a request is directed represents a collection of items and the intention of the request is to retrieve a listing of a subset of those items, the count value specifies the maximum number of items to return. The value is specified as a non-negative integer. If unspecified, the server is free to determine a reasonable default value. No default value is assumed. If a value of zero (0) is specified then it is to be interpreted as a request for an empty collection. If any value other than a non-negative integer value is specified, the parameter SHOULD be ignored as if the parameter were not present at all. |
| fields | The fields parameter allows a client application retrieving information about a resource to specify individual pieces of information it is interested in receiving as a simple, comma separated list. For instance, "fields=name,email". The server MAY choose to return a representation of the requested information containing only the requested fields along with any additional information the server determines is required. If the resource identified by the URI represents a collection of individual objects, the fields parameter identifies the requested properties of those individual objects, rather than the properties of the collection. |
| filterBy | When the resource to which a request is directed represents a collection of items and the intention of the request is to retrieve a subset of those items, the filterBy parameter specifies the name of a field to be used as a selection filter to determine the subset of items to return. The value of the parameter is the name of a field contained by each of the objects in the collection. This property is intended to be used in conjunction with the filterOp and filterValue parameters. |
| filterOp | When the filterBy parameter is used to specify the name of a field to use as a selection filter, the filterOp parameter is used to specify the specific type of selection filter operation to apply. See Section 2.6.1 for details on the possible values for the filterOp parameter. |
| filterValue | When using the filterBy and filterOp parameters, and filterOp equals "contains", "equals" or "startsWith", the filterValue parameter specifies the value against which the value of the filterBy field is tested. |
| sort | When the resource to which a request is directed represents a collection of items and the intention of the request is to retrieve a listing of those items, the sort parameter specifies one or more fields to be used as a sorting index and the order in which items SHOULD be returned. The value is a comma separated list of sort-key definitions as specified in Section 2.6.2. |
| startIndex | When the resource to which a request is directed represents a collection of items and the intention of the request is to retrieve a subset of those items, the startIndex parameter specifies the relative position of the first item to return out of the total set of items that can be returned as determined by the server after any requested filtering and sorting of the set as been applied. The index is 0-based such that to return the first item of the set, the startIndex parameter value would be 0. |
| updatedSince | When the resource to which a request is directed represents a collection of items and the intention of the request is to retrieve a subset of those items, the updatedSince parameter specifies that the server SHOULD only return items that have been updated after a given date and time. The value is expressed as an RFC 3339 date-time as described in Section 3. |
| updatedBefore | When the resource to which a request is directed represents a collection of items and the intention of the request is to retrieve a subset of those items, the updatedBefore parameter specifies that the server SHOULD only return items updated before the given date and time. The value is expressed as an RFC 3339 date-time as described in Section 3. |
The value of the filterOp parameter is one of:
The value of the sort parameter is a comma-separated list of sort-keys as defined below.
sort-default-order = field sort-default-field = "+" / "-" sort-order-field = ("+" / "-") field sort-key = sort-default-order / sort-default-field / sort-order-field
Each sort-key consists of an optional ASCII plus (+) or minus (-) character that indicates the requested sorting order -- where plus indicates ascending and minus indicates descending -- and the name of a field to sort by.
For instance, to request that the items of the collection be returned in reverse chronological order by the date and time they were last updated, assuming each item in the collection has an "updated" field, the value of the sort parameter would be: sort=-updated.
Multiple sort-keys MAY be specified. For instance, to request that the items of the collection be returned in reverse chronological order by the date and time they were last updated, but in alphabetical order by the title field, the value of the sort parameter would be: sort=-updated,+title.
If the optional plus or minus indicator is omitted, the server shall determine an appropriate default sorting order.
If the sort parameter specifies a field that is unsupported for the type of objects within the collection, the unsupported field MUST be ignored.
All REST services MUST support the use of Conditional Request mechanisms as defined in [I-D.ietf-httpbis-p4-conditional].
When returning the current representation of any resource, whether that representation is for a single object or a collection of objects, the HTTP Response MUST include either a strong Entity Tag as defined in Section 2.3 of [I-D.ietf-httpbis-p4-conditional], a Last-Modified Timestamp as specified in Section 2.2, or both.
For example, the response to a request retrieving the current representation of a person's profile might include both an Entity Tag and a Last-Modified timestamp:
HTTP/1.1 200 OK Content-Type: application/json ETag: "ab12cd34ef56" Last-Modified: Tue, 15 Nov 2012 12:45:26 GMT
Once a client has the Entity Tag or Last-Modified timestamp for a given resource representation, subsequent requests SHOULD utilize one or the other within a conditional request to optimize communication and to ensure that multiple clients do not inadvertently overwrite each other's data.
For instance, given the Last-Modified Timestamp included in a response to a request to receive a user's profile, a client can request that the server return an updated view of the profile if, and only if the state of the profile has changed since the specified time:
GET /api/people/@me/@self HTTP/1.1 If-Modified-Since: Tue, 15 Nov 1994 12:45:26 GMT
If the profile has not been modified since the date specified, the server would respond with a "304 Not Modified" status.
Given the Entity Tag of a resource representation, a client wishing to modify the resource can request that changes only be applied if the resource has not been subsequently modified since the original representation and Entity Tag were created:
PUT /api/people/@me/@self HTTP/1.1 If-Match: "ab12cd34ef56" Content-Type: application/json {...}
If the server is unable to determine that the specified Entity Tag applies to the current state of the resource, it will abort the change request and respond to the request using a "412 Precondition Failed" status.
Note that the Entity Tag specified in the response is generally specific to the actual payload included in the response. If a REST service supports multiple representation formats for a single resource, such as offering multiple data format options or modified views of the resource tailored to the authentication credentials included in the request, the Entity Tag can vary for each specific response, regardless of whether the actual state of the resource on the server has changed. Therefore, for any single resource, multiple Entity Tags can potentially represent the current state of the resource.
At a minimum, all OpenSocial REST Services MUST support the If-Match, If-None-Match, If-Modified-Since and If-Unmodified-Since HTTP request headers for conditional requests. All requests that result in the potential modification of the current state of a resource MUST include at least one of these request headers.
The current state of a resource may be modified in part or in full using either the PATCH [RFC5789] or PUT HTTP methods, respectively.
Given a URI that represents an resource, the current state of that resource can be modified in full by sending an HTTP PUT request to the URI. The payload of the PUT request is considered to be a replacement for the identified resource, although the server is free to determine exactly how the resource is to be modified.
For example, suppose an application wishes to modify an existing profile that contains nothing more than a name and en email address. First, the application needs to GET the existing state of the profile so it can know what it is working with and can get the Entity Tag necessary for the PUT operation:
GET /api/people/@me/@self HTTP/1.1
The server responds with the profile:
HTTP/1.1 200 OK Content-Type: application/json ETag: "ab12cd34ef56" {"name":{"displayName":"J. Doe"}<EMAIL_ADDRESS>The application wishes to modify this profile such that the name is expanded from "J. Doe" to "John Doe" and the email address is dropped completely. The application can do so by sending the following PUT request:
PUT /api/people/@me/@self HTTP/1.1 If-Match: "ab12cd34ef56" Content-Type: application/json {"name":{"displayName":"John Doe"}}
Assuming the change is successful, the server would respond with an appropriate 2xx status, and MAY include the updated representation of the resource:
HTTP/1.1 200 OK Content-Type: application/json ETag: "ab12cd34ef57" {"name":{"displayName":"John Doe"}}
Alternatively, the application can use a PATCH request to perform a partial modification of the resource. For instance, suppose the application needs to add an email address to the previously modified profile:
PATCH /api/people/@me/@self HTTP/1.1 If-Match: "ab12cd34ef57" Content-Type: application/json-patch<EMAIL_ADDRESS>Assuming the change is successful, the server would respond with an appropriate 2xx status, and MAY include the updated representation of the resource:
HTTP/1.1 200 OK Content-Type: application/json ETag: "ab12cd34ef57" {"name":{"displayName":"John Doe"}<EMAIL_ADDRESS>}
Support for the PATCH method to perform partial modifications of resource is optional.
OpenSocial REST Services that implement support for the PATCH operation MUST, at a minimum, support the use of the JSON Patch document format [I-D.ietf-appsawg-json-patch] for describing partial modifications and MAY support the use of the JSON Merge Patch mechanism as defined by section 3 of [I-D.snell-merge-patch].
With JSON Patch, the payload of the HTTP PATCH request uses a simple JSON data structure to explicitly describe the changes being requested to the data.
For example, when working with an OpenSocial Person object, to change the value of a person's given name and add a new phone number, the request would be:
PATCH /people/@me/@self HTTP/1.1 Content-Type: application/json-patch [{"replace":"/name/givenName","value":"John"}, {"add":"/phoneNumbers","value":{"label":"home","value":"123-123-1234"}]
The advantage of using the JSON Patch format is that the requested changes are unamgibuous and clear, regardless of specific details of the implementation.
If the JSON Patch document specifies any change that cannot be made, i.e. it references a field that does not exist, or attempts to make a change that would cause the resulting data to be invalid in any way, the server MUST reject the PATCH request without making any changes to the target resource.
As an alternative, the Merge Patch [I-D.snell-merge-patch] mechanism allows a client to requests partial modifications to be made by example.
For example, given the following data object:
{ "displayName": "John Doe", "name" : { "givenName" : "John", "familyName" : "Doe" }, "tags":["example","sample"] }
If the intent is to change the value of the "displayName" property from "John Doe" to the value "J. Doe", add a new "phoneNumber" property, remove the "familyName" property from the "name" object, and remove the word sample from the "tags" Array, I would send the following request:
PATCH /my/resource HTTP/1.1 Host: example.org Content-Type: application/json+merge-patch; charset="UTF-8" { "displayName": "J. Doe", "phoneNumber": "+01-123-456-7890", "name": { "familyName": null } "tags": ["example"] }
Servers that support the Merge Patch mechanism MUST adhere to the rules specified in Section 3 of [I-D.snell-merge-patch] to determine the specific set of changes that is being requested.
As with JSON Patch, if the Merge Patch request specifies any change that cannot be made for any reason, the server MUST reject the PATCH request without making any changes to the target resource.
REST Services that support PATCH MUST advertise that support using the Accept-Patch HTTP Response header as defined by [RFC5789], Section 3.1
For example,
HTTP/1.1 200 OK Allow: GET, PUT, POST, DELETE, HEAD, PATCH, OPTIONS Accept-Patch: application/json-patch, application/json+merge-patch
When errors occur during the processing of a request sent to a REST service, the HTTP response will specify an appropriate error status identifying the general nature of the failure that occurred as well as any relevant specific detail.
Errors in processing generally fall in to one of the following three categories:
When a Functional Error occurs during the processing of a request, server implementations MUST take cautions against inappropriately disclosing too much detail about the underlying implementation of the service. Unless the user-agent submitting the request is considered to be a trusted entity by the server, error responses that represent Functional Errors SHOULD contain only a minimal amount of information about the error.
Function Errors are typically reported using 5xx Server Error response codes as defined in Section 7.5 of [I-D.ietf-httpbis-p2-semantics].
The example response below communicates that the service is unavailable to process any requests and that the user agent can retry the request in two minutes:
HTTP/1.1 503 Service Unavailable Retry-After: 120
When a Request Validation Error occurs, the server MUST provide adequate detail in the response to indicate the nature of the validation failure. Such errors can occur for a variety of reasons and are generally reported using 4xx Client Error response codes as defined in Section 7.4 of [I-D.ietf-httpbis-p2-semantics]. If a payload is included in the HTTP Response, then it SHOULD be a JSON document containing a single Error Object [error-object] that describes the specific validation error that occurred. A payload will not be required for all Request Validation Errors. The choice of whether to include a payload describing the error for any particular request is left up to the server.
The example response below indicates that the request was not properly authenticated and indicates that the user-agent must use OAuth 2.0 Bearer tokens to authenticate future requests.
HTTP/1.1 403 Forbidden WWW-Authentication: Bearer realm="example"
When Business Rule Violations occur, the server MUST provide adequate detail in the response to indicate the nature of the violation. Such errors can occur for a variety of reasons are are generally reported using specific HTTP response codes such as 409 Conflict, 403 Forbidden, or 400 Bad Request. Such responses MUST contain a payload consisting of a single Section 2.9.1 that describes the specific violation.
Business Rule Violations differ from other types of errors in that, typically, the request is properly formed and understood by the service, but was rejected for some other reason. An example of such an error is when a particular user agent surpasses a preallocated number of requests within a given period of time.
For example:
HTTP/1.1 403 Forbidden Content-Type: application/json { "code": -12345, "message": "Exceeded request quota" }
The Error object is a simple JSON data structure intended to communicate basic information about an error condition that has occurred.
Error objects conform to all the same rules as all other OpenSocial Data Objects [data-objects], including extensibility characteristics. At a minimum, Error objects have the following properties:
| Name | Type | Description |
|---|---|---|
| code | Integer | A numeric code indicating the specific nature of the error that occurred. When an error object is included as the payload of an HTTP response, this code MUST NOT be interpreted as a replacement for the HTTP response status code, which takes precedence and specifies the general status of the HTTP request. No standard error code values are defined by this specification. |
| data | Object | A JSON object containing arbitrary additional data about the error. The specific properties of the object are undefined. |
| message | String | A human readable and localized description of the error that occurred. The value SHOULD NOT contain markup of any kind and SHOULD be interpreted as plain text. |
When an error object is included as the payload of an HTTP message, the Content-Type header field, if specified, MUST specify a value of "application/json".
For the GET, HEAD and OPTIONS HTTP methods, a REST service MAY support the ability for a user-agent to specify multiple local-identifiers and aspect-identifiers within a single request URI. There are, however, a number of important caveats and considerations that need to be taken into consideration when working with multiple resources and multiple aspects within a single operation.
To illustrate how the support for multiple resources works, consider a profile service that provides access to information about different users. A user-agent can access the profiles of individual users by issuing a GET request to their respective URIs:
GET /api/people/user-1/@self HTTP/1.1 GET /api/people/user-2/@self HTTP/1.1 GET /api/people/user-3/@self HTTP/1.1
Each of these requests would return a single profile representations:
HTTP/1.1 200 OK Content-Type: application/json ETag: "abcdef123456" { "id"<EMAIL_ADDRESS>"name": {"displayName": "John Doe"} }
Using the multiple-resource capability, these three distinct HTTP requests can be combined into a single request:
GET /api/people/user-1,user-2,user-3/@self HTTP/1.1
This combined request would return each of the requested profiles within a single response consisting of a single top-level JSON object containing one property for each requested object, where the property key is the local-identifier of the resource:
HTTP/1.1 200 Ok Content-Type: application/json ETag: "abcdefg123456" { "user-1": { "id"<EMAIL_ADDRESS>"name": {"displayName": "John Doe"} }, "user-2": { "id"<EMAIL_ADDRESS>"name": {"displayName": "Jane Doe"} }, "user-3": { "id"<EMAIL_ADDRESS>"name": {"displayName": "Sally Jones"} } }
If one of the requested resources does not exist, the server MAY choose to either reject the entire request with a 404 Not Found response or simply omit the missing item from the response or optionally include an explicit indicator that the specific item could not be found.
For instance, if "user-3" does not exist, the following:
HTTP/1.1 200 Ok Content-Type: application/json ETag: "abcdefg123456" { "user-1": { "id"<EMAIL_ADDRESS>"name": {"displayName": "John Doe"} }, "user-2": { "id"<EMAIL_ADDRESS>"name": {"displayName": "Jane Doe"} }, "user-3": null }
Is equivalent to omitting the "user-3" property altogether:
HTTP/1.1 200 Ok Content-Type: application/json ETag: "abcdefg123456" { "user-1": { "id"<EMAIL_ADDRESS>"name": {"displayName": "John Doe"} }, "user-2": { "id"<EMAIL_ADDRESS>"name": {"displayName": "Jane Doe"} } }
When the request specifies multiple aspect identifiers, the JSON object contained within the response will contain an additional layer of property values representing each individual aspect.
For instance, if the user-agent wishes to retrieve both the profile and friends list for the current authenticated user, it could send a GET request to:
GET /api/people/@me/@self,@friends
The response to this request would include a single top-level JSON object with properties for each of the requested aspects, whose values will be equivalent to what would have been returned had each aspect been requested by individual requests:
HTTP/1.1 200 OK Content-Type: application/json ETag: "abcdefg1234567" { "@self": { "id"<EMAIL_ADDRESS>"name": {"displayName": "John Doe"} }, "@friends": { "items": [ { "id"<EMAIL_ADDRESS>"name": {"displayName": "Jane Doe"} }, { "id"<EMAIL_ADDRESS>"name": {"displayName": "Sally Jones"} } ] } }
When multiple local-identifiers and aspect-identifiers are specified, the construction of the returned JSON object is similarly nested:
GET /api/people/user-1,user-2/@self,@friends
HTTP/1.1 200 OK Content-Type: application/json ETag: "abcdefg1234567" { "user-1": { "@self": { "id"<EMAIL_ADDRESS>"name": {"displayName": "John Doe"} }, "@friends": { "items": [ { "id"<EMAIL_ADDRESS>"name": {"displayName": "Jane Doe"} }, { "id"<EMAIL_ADDRESS>"name": {"displayName": "Sally Jones"} } ] } }, "user-2": { "@self": { "id"<EMAIL_ADDRESS>"name": {"displayName": "Jane Doe"} }, "@friends": { "items": [ { "id"<EMAIL_ADDRESS>"name": {"displayName": "John Doe"} } ] } } }
If the data that would normally be returned when requesting a particular local-identifier and aspect-identifier cannot be represented as JSON -- for instance, when requesting a hypothetical @avatar aspect for a particular profile that could return a binary image resource-- the value for the given item within the JSON response MUST specify the IRI of the specific individual item within a field named "$self".
For instance:
GET /people/api/@me/@self,@avatar HTTP/1.1 Host: example.org
HTTP/1.1 200 OK Content-Type: application/json ETag: "abcdefg1234567" { "@self": { "id"<EMAIL_ADDRESS>"name": {"displayName": "John Doe"} }, "@avatar": { "$self": "http://example.org/people/api/@me/@avatar" } }
Filter segment and query string parameters included in the request URI apply to each of the individually requested resources just as if separate requests were sent to each resource.
For instance, the request:
GET /api/activity/user-1,user-2/@all/app-1,app-2/@tags/foo,bar?fields=id,title
Is to be interpreted as: for users "user-1" and "user-2", return the id and title fields for all activities generated by applications "app-1" and "app-2" and tagged with "foo" or "bar".
Authentication credentials included in the request MUST be valid and authorized for each of the individually requested resources or the entire request MUST be rejected using either a 401 Unauthorized or 403 Forbidden response.
Modification of multiple resources with a single operation, as well as the use of any unsafe and non-idempotent HTTP method is not allowed. Any method other than GET, HEAD and OPTIONS sent to a request URI specifying multiple resources MUST fail with a response of 405 Method Not Supported
When a request contains either a If-Modified-Since or If-Unmodified-Since request header, the server MUST determine if all of the requested resources or aspects adhere to the condition. If even just one of the requested resources fails to meet the condition, the entire request MUST be rejected using a 406 Not Acceptable response.
Implementations SHOULD place strict limits on the number of distinct resources and aspects that may be included within a single request URI. When a user agent submits a request for too many resources or aspects, the server SHOULD return a 414 Request-URI Too Long response.
If an implementation does not support the specification of multiple resources or aspects within a single request, a 404 Not Found response SHOULD be returned.
For the purpose of simplifying an interaction with various REST services, an OpenSocial implementation that provides Application Container Services (see [core-gadget]) can provide a layer of code that abstracts the REST service request and provides a simplified interface.
In order to better facilitate interoperability within that abstraction layer, OpenSocial REST Services can specify a alias for each logical interaction the application can have with the service. Such aliases take the form:
operation-identifier = service-identifier "." token
For example, the OpenSocial Person Service provides operations that allow a user-agent to request information about specific people. When interacting directly with the REST Service, this request takes the form of an HTTP GET request:
GET /api/people/@me/@self HTTP/1.1 Host: example.org
Within an OpenSocial Application hosted within an OpenSocial container (see [core-gadget]), this same operation can be referenced using the operation identifier "people.get":
<Module> <ModulePrefs> ... </ModulePrefs> <Data> <os:DataRequest key="me" method="people.get" userId="@me" groupId="@self" /> </Data> <Content type="html"> ... </Content> </Module>
Operation identifiers specific to each of the core OpenSocial REST Services are defined within the OpenSocial Social Applications Specifications [social-app].
Whenever date, time, timezone, duration or time period data is used anywhere within an OpenSocial implementation, the following rules MUST be applied.
When encoding a Date and Time together, the date-time construct from [RFC3339] MUST be used. In addition, an uppercase "T" character MUST be used to separate the date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset.
For example:
2012-11-09T12:32:34-08:00 2013-03-23T01:23:43Z
When encoding a Date, the full-date construct from [RFC3339] MUST be used.
For example:
2012-11-09
When encoding a Time, either the partial-time or full-time constructs from [RFC3339] MUST be used. When encoded as a full-time, an uppercase "Z" character MUST be present in the absence of a numeric time zone offset.
For example:
12:32:34-08:00 // full-time 12:32:34 // partial-time
When encoding a Timezone Offset, the time-offset construction from [RFC3339] MUST be used. Note that when denoting a Timezone Offset equal to the Coordinated Universal Time (UTC), an uppercase "Z" character MUST be used.
For example:
-08:00
When encoding a Duration, the duration construction from [RFC3339] MUST be used.
For example:
P3Y6M4DT12H30M5S
When encoding a period of time, the period constructions from [RFC3339] MUST be used. Note that when the period contains explicit date and time components, an uppercase "T" character MUST be used to separate the date and time, and an uppercase "Z" character MUST be used in the absence of a numeric time zone offset.
For example:
P1Y2M10DT2H30M/2008-05-11T15:30:00Z
All Data Objects exposed via REST Services are serialized as JSON Objects as defined by [RFC4627]. Alternative serializations MAY be used but are considered outside the scope of this specification. Previous versions of OpenSocial allowed for Atom [RFC4287] and simple XML serializations that have now been deprecated. Each of these are documented in the OpenSocial Deprecated Support Specification [TODO: Ref Doc]. Implementations MAY support the deprecated formats for backwards compatibility with existing applications.
Unless otherwise stated in the definition of a specific property, the following general serialization rules apply:
A "Collection Object" is a Data Object that represents a set of individual, related Data Objects. Collection Objects are serialized as JSON Objects conforming to the JSON Activity Streams Collection construct as defined in Section 3.5 of [json-activity-streams].
Such serialized objects inherit all of the basic properties of the Activity Streams Collection object:
| Name | Type | Description |
|---|---|---|
| totalItems | JSON Integer | An optional, non-negative integer specifying the total number of items within the collection. This number SHOULD reflect the actual total number of Data Objects that are considered to be members of the set that can be returned after applying any requested filtering operations and not the number of items actually serialized as values in the items property value. |
| items | JSON Array | An array containing a listing of Data Objects. This listing MAY be a subset of the total number of objects considered to be members of the collection. |
| url | JSON String | An optional IRI referencing a JSON Activity Streams document containing the full listing of objects within the collection. |
All other properties defined by the JSON Activity Streams specification for a Collection Object MAY be included in the serialization but their specific use and function is considered out of scope of this specification.
This specification defines the following additional properties that MAY be used:
| Name | Type | Description |
|---|---|---|
| startIndex | JSON Integer | A non-negative integer value that identifies the relative position within the collection of the first object contained in the items property. For instance, if there are 20 items that are considered to be members of a collection, but only the last 10 of those items are serialized within the value of the items property, the value of startIndex would be 10. |
| itemsPerPage | JSON Integer | A non-negative integer that specifies the maximum number of Data Objects that will be serialized within the value of the items property. The actual number of items within the items array SHOULD be equal to or less than the value of the itemsPerPage value. |
The following example shows a subset of a collection of OpenSocial Person objects:
{ "totalItems": 10, "startIndex": 0, "itemsPerPage" : 2, "items" : [ { "displayName":"Joe", "name": { "givenName":"Joe", "familyName":"Smith" } }, { "displayName":"Sally", "name": { "givenName":"Sally", "familyName":"Jones" } } ] }
Collections that consist of a large number of items can often be split into multiple documents, or pages, where each page contains a subset of the total number of items in the complete set as well as links to subsequent or preceding pages.
Within a Collection object, links to pages are represented using the generalized Activity Streams Links mechanism described in [astream-links]. Specifically, the following table lists the additional optional Collection Object properties used to link multiple pages of a collection:
| Name | Type | Description |
|---|---|---|
| $first | String | A String value containing the absolute IRI reference of the furthest preceding page of the multi-page collection. |
| $last | String | A String value containing the absolute IRI reference of the furthest following page of the multi-page collection. |
| $previous | String | A String value containing the absolute IRI reference of the immediately preceding page of the multi-page collection. |
| $next | String | A String value containing the absolute IRI reference of the immediately following page of the multi-page collection. |
| $current | String | A string value containing the absolute IRI reference of a page containing the items that have been updated most recently. |
In order to be considered a paged collection, at least one of these properties MUST be present within the Collection object.
For example,
{ "$first": "http://example.org/activities/@me/@all?count=10", "$next": "http://example.org/activities/@me/@all?count=10&updatedBefore=2012-12-12T12:12:12.123Z", "totalItems": 100, "items": [ // .. list of items ] }
Note that consuming applications SHOULD treat the absolute IRI values used for paging as opaque identifiers and MUST NOT assume that they conform to any particular structure. That said, it is expected that most implementations will use various combinations of the standard query string parameters (e.g. count and startIndex, or count and updatedBefore) to construct paging links.
When using a combination of the count and startIndex query parameters to facilitate paging of a collection whose items change or grow frequently over time, the process of splitting a collection into multiple pages can become "lossy". That is, it is not possible to guarantee that consuming applications will be able to reconstruct the complete contents of the full collection at a particular time because items can be added or changed as the pages are accessed without the consuming application becoming aware of them.
Such data loss can be avoided through the use of the updatedSince and updatedBefore parameters as an alternative to startIndex. That is, rather than basing pages on the relative positioning of items within the overall collection, pages can be constructed to represent distinct periods of time (e.g. the 30 entries updated before a given time; all entries updated within the last hour; etc).
Within an OpenSocial Data Object, a "plural-field" is a property whose value consists of zero or more alternative choices represented as individual elements within a JavaScript Array. Each choice is serialized as a JSON Object with at least the following basic properties:
| Name | Type | Description |
|---|---|---|
| label | JSON String | Provides a human-readable, plain-text, and preferrably localized short description of the object value suitable for display to a user. |
| primary | JSON Boolean | A boolean value indicating whether a particular plural object value is considered to be the primary or preferred alternative within the set. No more than one object in the array of of objects specified as the value of a plural field can have a primary property of True. |
| type | JSON String | Specifies a machine-processable label for this object value that generally identifies it's preferred function. For instance, if the plural field represents a collection of phone numbers, the type property value would specify values such as "work", "home" or "other", to differentiate each phone number by purpose. Unlike the label property which is intended for human-readable display, the type property is intended to be used programmatically and MUST NOT utilize a localized value. |
| value | JSON Primitive, Array or Object | Represents the actual value of the object. |
The example below shows a Data Object with a single plural-field providing alternative contact phone numbers for an individual. Each is labeled, typed and a single number is marked as preferred:
{ "phoneNumbers": [ { "value": "555-123-1234", "type": "home", "label": "Home" }, { "value": "555-123-1235", "type": "work", "label": "Work", "primary": true }, { "value": "555-123-1236", "type": "mobile", "label": "Mobile" } ] }
This specification defines a core set of common Data Objects and an associated set of properties for each. These properties comprise the core vocabulary of the OpenSocial Data Model. Implementations are free to introduce extensions to this vocabulary so long as such extensions do not alter the semantics or requirements associated with any part of the core vocabulary. Such extensions are referred to generically as "foreign properties".
Note that future versions of this specification could introduce new properties and Data Objects to the core vocabulary. Software written to conform to this version of the specification will not be able to process such properties correctly and, in fact, will not be able to distinguish it from other arbitrary types of extensions. For the purpose of this discussion, unrecognized core vocabulary properties introduced by future versions of this specification will be considered to be "foreign properties".
Implementations that encounter foreign properties within a Data Object MUST NOT stop processing or signal an error. It might be the case that the implementation is able to process foreign properties correctly and does so. Otherwise such properties are considered to be "unknown foreign properties".
Whenever unknown foreign properties are encountered, implementations SHOULD ignore the properties and continue processing the Data Object as if they were not present.
The values of extension properties SHOULD be serialized following the same rules specified for core vocabulary properties as defined in Section 4.
Because foreign properties can be added at any time to a Data Object by multiple implementations, and because there is no centralized coordination of such extensions, there is a risk of conflicts arising when multiple implementations attempt to define foreign properties that share the same name.
For example, imagine two separate vendor implementations that extend the basic OpenSocial Person Data Object to include data specific to each implementation. For the sake of illustration, we will label these implementations as "foo.example.org" and "bar.example.com". Each defines a foreign property named "account" that while similar in purpose specify different types of values.
In order to avoid conflicts between the two properties, each implementation SHOULD wrap each of their respective foreign properties into a single root extension property whose name is unique to the implementation and whose value is a JSON Object containing the set of foreign properties unique to that implementation.
By convention, it is RECOMMENDED that the name of the root extension property follow the so-called "reverse-DNS" naming pattern.
For example, the extended Person Data Object described above could be serialized as:
{ "displayName": "Joe", "org.example.foo": { "account": "joes-account" }, "com.example.bar": { "account": { "id"<EMAIL_ADDRESS>} } }
The JSON objects associated with each root extension property can contain any number of foreign properties, depending on the needs of the implementation, allowing all of the foreign properties specific to a particular implementation or serving a common purpose to be grouped together.
By following this convention, implementations can protect themselves from conflicts with each other and with new properties that may be added by future versions of this specification.
Every OpenSocial Data Object has an associated data type identifier in the form of an absolute IRI reference that is used in a number of different places throughout OpenSocial applications. Such IRIs are used for identification purposes only and MUST be compared on a character-by-character basis in a case-insensitive fashion.
All data type identifiers that begin with the prefix "http://opensocial.org/types/" are reserved for use by this specification. Implementations MUST NOT use any data type identifier that begins with the prefix "http://opensocial.org/types/" other than those defined by the OpenSocial specification. Please refer to [social-app] for details on the current set of data types defined by OpenSocial.
Older versions of this specification utilized an alternative, now-deprecated syntax for data type identifiers:
segment = 1*( ALPHA / DIGIT ) prefix = segment "." name = segment legacy-datatype = prefix name
For example, the legacy data type identifier for the OpenSocial Person datatype was "opensocial.Person".
For backwards compatibility purposes with existing applications, implementations MAY continue to support the use of Legacy Data Types. New applications for which backwards compatibility is not a concern, however, SHOULD NOT use legacy data type identifiers.
When a REST Service provides access to protected resources for which authentication is required, the service MUST support the use of either OAuth version 1.0a, OAuth version 2.0 or both as the preferred authentication mechanism. Specific implementations MAY support additional alternative autentication mechanisms but support for such is considered out of the scope of this specification.
REST Services MAY accept requests with no authentication or authorization information for data considered to be public. The service MAY provide a limited "public representation" of a resource if no authorization information is provided in the request.
In the case where no information is available due to lack of authorization, an HTTP 401 Unauthorized response SHOULD be returned to the client. In the case where at least some view of the information is available, it SHOULD be returned using an appropriate 2xx status, with a standard WWW-Authenticate response header indicating that additional information may be available when using a different authorization context.
When utilizing the OAuth protocol, the overall flow is straightforward:
There are several valid ways in which the initial authorization token may be acquired by the client. This specification does not prescribe or require any single acquisition mechanism.
Likewise, there are several valid ways in which an authenticated request can be prepared using the access token once acquired:
When utilizing OAuth version 2.0, all REST Services MUST, at a minimum, support the use of OAuth 2.0 Bearer Tokens as specified in [I-D.ietf-oauth-v2-bearer]. Because such tokens are passed to the server as unencrypted, plain text, all requests containing an OAuth 2.0 Bearer Token MUST be exchanged using TLS 2.0 or SSL.
All access tokens SHOULD be issued with limited scope and short expiration times to limit the risk of potential security breaches due to stolen access tokens. The "scope" of an "access token" identies the range of resources and the types of operations for which the token can be used. The "expiration time" specifies the length of time for which the access token is considered to be valid. The token expiration policy is left to the specific implementation and may vary depending on the client requesting the token. Expiration times of 1 hour or less, and tokens with limited scope may be used with less trusted clients while expiration times of several hours and tokens with increased scope may be used for more trusted clients. Implementations SHOULD document (at least for administrators) how to configure token scopes and expiration times if these values are configurable.

Signed Fetch is a simplified mechanism based on a subset of the OAuth 1.0a protocol that allows a container to "sign" requests sent to a remote endpoint. Such signatures provide only a reasonable assurance that certain content contained within the request has not been modified by a malicious party. Once a receiving endpoint determines that it is able to trust the signed request, it can decide to provide limited access to certain protected resources without having to walk through the entire typical OAuth protocol.
Signed Fetch is described in detail in The OpenSocial Core Gadget Specification [core-gadget].
The ability for server and client implementions to clearly communicate which version of the OpenSocial specification a particular Service API and resource supports is critical.
For the purpose of clearly identifying which version of the OpenSocial specification a particular application is implementing, a Web Link header referencing the base URI of the OpenSocial specification and using a rel attribute value of "profile" [I-D.wilde-profile-link] SHOULD be included within the HTTP request and response message.
For example, the Link would appear within the request:
GET /api/people/@me/@self HTTP/1.1 Host: example.org Link: <http://opensocial.org/specs/3.0>; rel="profile"
And within the response:
HTTP/1.1 200 OK Link: <http://opensocial.org/specs/3.0>; rel="profile"
A server MAY choose to implement additional conventions for identifying the current version, such as including a version indicator within the base URI of the Service API (e.g. http://example.org/v3/api/people). Such conventions are considered out of scope.
When a server implementation of an older version of the OpenSocial specification upgrades to a newer version, it has the responsibility to provide a clear mechanism for either continuing to support client applications using the old version or help clients migrate to the new. Whether a server chooses to continue to support the old and new versions of the OpenSocial specification simultaneously is an implementation and business decision that is out of the scope of this specification. Accordingly, each of the options detailed below are informative in nature only.
However, when a server wishes to indicate to a client application that the server has been upgraded and that the old version of the API is no longer available, it can do so using an Upgrade Required response.
An "Upgrade Required Response" is an HTTP response that uses the 426 Upgrade Required status along with an "profile" Web Link. For instance:
HTTP/1.1 426 Upgrade Required Upgrade: OpenSocial/3.0 Connection: upgrade Link: <http://opensocial.org/specs/3.0>; rel="profile"
When using such responses, the Upgrade header MUST specify an Upgrade Token value of "OpenSocial" and an Upgrade Version Token consisting of the major and minor version identifier as specified in Section 1.2 of [core-gadget].
Use of the 426 Upgrade Required response implies a complete cutover from one version of the specification to another. While such a strategy might be appropriate in some cases, many applications will require a more gradual approach in order to avoid breaking existing clients. Alternatively, a server can choose to migrate client applications incrementally, initially deploying the new version of the application side-by-side with the old.
For example, if a server currently exposes version 3.0 of the OpenSocial Person Service at the URI "http://example.org/api/people", and it wishes to upgrade clients to a hypothetical version 3.1 in the future, without requiring clients to change the URIs used to access the service, it can either continue to support the 3.0 clients transparently or perform an "in place" upgrade.
An example 3.0 client request:
GET /api/people/@me/@self HTTP/1.1 Link: <http://opensocial.org/specs/3.0>; rel="profile"
A server implementing a hypothetical 3.1 version of the OpenSocial spec can continue to respond as if it was a 3.0 implementation:
HTTP/1.1 200 OK Link: <http://opensocial.org/specs/3.0>; rel="profile" Content-Type: application/json {... OpenSocial 3.0 data ...}
Or, it can perform an "in-place" upgrade:
HTTP/1.1 200 OK Upgrade: OpenSocial/3.1 Connection: upgrade Link: <http://opensocial.org/specs/3.1>; rel="profile" Content-Type: application/json {... OpenSocial 3.1 data ...}
Alternatively, the server MAY choose to deploy the new version with a new URI and redirect the down-level client to the new version of the application:
An upgrade redirection from the server:
HTTP/1.1 301 Moved Permanently Location: /v3.1/api/people/@me/@self HTTP/1.1 Upgrade: OpenSocial/3.1 Connection: upgrade Link: <http://opensocial.org/specs/3.1>; rel="profile"
Every REST service is associated with a distinct service-identifier as defined by Section 2.2. The OpenSocial Social Applications Specification [social-app] defines the core set of services and their associated identifiers.
Implementations are free to introduce additional services so long as each is identified by a unique service-identifier. To promote interoperability across implementations, this specification establishes a Registry of Service Identifiers to be hosted and managed by the OpenSocial Foundation. This registry shall contain known, commonly used service identifiers. Whenever an implementor defines and deploys support for new services, the associated identifier SHOULD be added to the registry.
Registrations require review by the OpenSocial community and are subject to the following rules:
The party responsible MUST submit the registration request via email to the mailing list for the OpenSocial Specification Community Group. After a period of 30-days following the date of the email request, if there are no expicit objections from members of the community in response to the registration, the request will be assumed to be automatically accepted.
For each distinctly-named REST Service (see Section 2.2), every individual data object can have zero or more individually identifiable aspects (see Section 2.4). The OpenSocial Social Applications Specification [social-app] defines the core set of services and their associated aspect identifiers.
Implementations are free to introduce additional aspects for any service so long as each is identified by a unique aspect identifier. To promote interoperability across implementations, this specification establishes a Registry of Aspect Identifiers to be hosted and managed by the OpenSocial Foundation. This registry shall contain known, commonly used aspect identifiers. Whenever an implementor defines and deploys support for new aspects, the associated identifier SHOULD be added to the registry.
Registrations require review by the OpenSocial community and are subject to the following rules:
The party responsible MUST submit the registration request via email to the mailing list for the OpenSocial Specification Community Group. After a period of 30-days following the date of the email request, if there are no expicit objections from members of the community in response to the registration, the request will be assumed to be automatically accepted.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3864] | Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |
| [RFC2026] | Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| [RFC6570] | Gregorio, J., Fielding, R., Hadley, M., Nottingham, M. and D. Orchard, "URI Template", RFC 6570, March 2012. |
| [RFC5789] | Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, March 2010. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. |
| [RFC3987] | Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. |
| [RFC3339] | Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. |
| [RFC5849] | Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010. |
| [RFC4627] | Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. |
| [json-activity-streams] | Snell, J., Atkins, M., Norris, W., Messina, C., Wilkinson, M. and R. Dolin, "JSON Activity Streams 1.0", May 2011. |
| [I-D.wilde-profile-link] | Wilde, E, "The 'profile' Link Relation Type", Internet-Draft draft-wilde-profile-link-01, April 2012. |
| [I-D.ietf-httpbis-p1-messaging] | Fielding, R, Lafon, Y and J Reschke, "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Internet-Draft draft-ietf-httpbis-p1-messaging-19, March 2012. |
| [I-D.ietf-httpbis-p2-semantics] | Fielding, R, Lafon, Y and J Reschke, "HTTP/1.1, part 2: Message Semantics", Internet-Draft draft-ietf-httpbis-p2-semantics-19, March 2012. |
| [I-D.ietf-httpbis-p3-payload] | Fielding, R, Lafon, Y and J Reschke, "HTTP/1.1, part 3: Message Payload and Content Negotiation", Internet-Draft draft-ietf-httpbis-p3-payload-19, March 2012. |
| [I-D.ietf-httpbis-p4-conditional] | Fielding, R, Lafon, Y and J Reschke, "HTTP/1.1, part 4: Conditional Requests", Internet-Draft draft-ietf-httpbis-p4-conditional-19, March 2012. |
| [I-D.ietf-httpbis-p5-range] | Fielding, R, Lafon, Y and J Reschke, "HTTP/1.1, part 5: Range Requests and Partial Responses", Internet-Draft draft-ietf-httpbis-p5-range-19, March 2012. |
| [I-D.ietf-httpbis-p6-cache] | Fielding, R, Lafon, Y, Nottingham, M and J Reschke, "HTTP/1.1, part 6: Caching", Internet-Draft draft-ietf-httpbis-p6-cache-19, March 2012. |
| [I-D.ietf-httpbis-p7-auth] | Fielding, R, Lafon, Y and J Reschke, "HTTP/1.1, part 7: Authentication", Internet-Draft draft-ietf-httpbis-p7-auth-19, March 2012. |
| [I-D.ietf-appsawg-json-patch] | Bryan, P, "JSON Patch", Internet-Draft draft-ietf-appsawg-json-patch-01, March 2012. |
| [I-D.snell-merge-patch] | Snell, J, "The application/merge-patch Media Type", Internet-Draft draft-snell-merge-patch-00, March 2012. |
| [I-D.ietf-oauth-v2-bearer] | Jones, M, Hardt, D and D Recordon, "The OAuth 2.0 Authorization Protocol: Bearer Tokens", Internet-Draft draft-ietf-oauth-v2-bearer-19, April 2012. |
| [I-D.ietf-oauth-v2-http-mac] | Hammer-Lahav, E, "HTTP Authentication: MAC Access Authentication", Internet-Draft draft-ietf-oauth-v2-http-mac-01, February 2012. |
| [core-gadget] | OpenSocial Core Gadget Specification v3.0", April 2012. | , "
| [social-app] | OpenSocial Social Application Specification 3.0", April 2012. | , "
| [astream-links] | Snell, J.M., "Links for Activity Streams", April 2012. |
| [RFC4287] | Nottingham, M. and R. Sayre, "The Atom Syndication Format", RFC 4287, December 2005. |


Akothee's emotional tribute ahead of sister in law's burial
by Pauline KatethyaTough times
Days after getting hospitalized, Award winning artiste, Esther Akoth, aka Akothee is mourning the loss of her sister in law Janet, who will be laid to rest tomorrow.
In an emotional post, the singer revealed that her sister in law, Janet will be burried tommorow.
The deceased has left behind two children.
“Today I would celebrate you, but again busy mourning my sister inlaw Janet , who has left 2 children behind😭😭, who will be laid to rest tomorrow at kanyaserega, I want to go and support my brother, but my health cant allow me, I want to risk and mourn with my family, but how do I do it from my hospital bed , should I just risk and go so my heart is at peace 🙏🏾🙏🏾🙏🏾 rest in Peace JAMES OGENDI OYIEKO , REST IN PEACE JANET 🙏🏾🙏🏾🙏🏾🙏🏾” Read her post.
Akothee also reminisced the death of her grandfather, james ogendi oyieko who was buried on a day like this, last year.
“On this day 11.24.2017 I laid you to rest , the gap you left in me is still too big, no one can ever fill it, I try my level best to move on,its hard though, I visit rongo less than I used to ,just because I still have my parents and my grandma who gives me a reason to live, 😭😭😭😭😭”. Added Akothee.
She disclosed that the death of his grandfather had taken a toll on her and that she was still trying to move on.Akothee who has been hospitalized at the Karen Hospital over flue and fatigue went ahead to add that she wanted to go and support her brother but her health couldn’t allow her to do that.
On Thursday, the singer was hospitalized, just a few days after she returned to Kenya from Dubai where she had performed at the One Africa Fest.


Reports conditions relying on variable or expression truthiness.
Perl treats several different things as false value:
It may be safer to use explicit check, like defined $var, $var == 0, etc.
defined $var
$var == 0


$trade[price]
$trade[subject]$thread[price] {$extcredits[$creditstransextra[2]][unit]}{$extcredits[$creditstransextra[2]][title]} {lang thread_reward}: $rewardprice {$extcredits[$creditstransextra[2]][unit]}{$extcredits[$creditstransextra[2]][title]}
{lang activity_already} $applynumbers
{lang activity_about_member}: $aboutmembers
$message
| {lang debate_square} |
|
$debate[affirmdebaters] |
| {lang debate_opponent} |
|
$debate[negadebaters] |


Every time we create a new profile, or update a profile, we have to update our hiera data. This process is error prone and time consuming. Hiera leverages almost any data interchange format (in fact I’d bet if you can write the backend for it, it’ll support it). The writing of that data can easily be automated, so a tool to write the data files for us was an obvious decision.
hiera-template is still in its infancy, and will eventually become a much larger part of our workflow. The main goal of this tool, however, remains the same: automate the generation of our hiera data files from our profile classes.
hiera-template is up in Rubygems, but be forewarned, it is VERY much still in BETA. Your mileage will vary and your bug reporting is appreciated.
Install
1
|
|
Usage
hiera-template accepts a single path to a profile as an argument. It can be a local or fully qualified path.
By default, hiera-template will store all processed yaml’s in ~/.hiera-template/templates/${profile_name}-${hierarchy_level}-template.yaml
1 2 |
|
The above will create a baseline hiera data file from all the explicit hiera() lookups in the profile. Yes, you read that right, it will not work on non-explicit hiera() lookups. That will be a feature down the road. For now, the following like-lines will be parsed:
1
|
|
That line will be written to a yaml file as:
1
|
|
Hierarchy Keys
hiera-template uses #[keys]
in the profile to determine what part of the hierarchy the data resides.
Given the following:
1 2 3 4 5 6 7 8 9 10 |
|
hiera-template will create two yaml files in ~/.hiera-template/templates
:
1 2 |
|
Those templates contain all the keys for the given profile. You can cat *-node-template.yaml > my.new.node.yaml
or cat *-datacenter-template.yaml >> out_dc.yaml
to create or append the keys to data files. Then, all you need to do is fill in your values.
Upcoming
Since writing in data can be so error prone, and hiera is by it’s nature hard to debug, a tool ensures your data written to your data files is the same as what is declared in your profiles - on the flip side, it’ll propogate your errors from the profile data declarations to the data file. Either way, you’re automating it!
To help write the values to the data files I’ll up adding a feature to populate, so you don’t have to worry about all that new-fangled white space that YAML loves to hate you for. Populate will prompt your for each value and write it in automatically, so you don’t have to open vim: you’re prompted with the key, and you type in the value. Done deal.
Debugging
Currently, this tool is not hardened by any means. And like everyone else, I can’t stay on top of everything. So if you’re using it, hit me up with bug reports. There is a -D
option to run at debugger level, and I tried to make it obvious what is going on. That’s no substitution for reading /lib/template.rb
if you get a stack trace though. It’s a very simple tool, and right now everything lives in template.rb
so it should be easy to figure out.
Known issues:
- It will break if you have other comments in the hiera look up declarations other than keys
- It will not work on implicit lookups, you need hiera()
- It’ll probably be buggy, but have fun and support it if you find it useful


| Tapply {car} | R Documentation |
Applies a function, typically to compute a single statistic, like a mean, median, or standard deviation,
within levels of a factor or within combinations of levels of two or more factors to produce a table of statistics. This function provides
a formula interface to the standard R tapply
function.
Tapply(formula, fun, data, na.action = na.pass, ..., targs = list())
formula |
a two-sided formula of the form |
fun |
a function, like |
data |
an optional data frame within which to find the variable and factor(s). |
na.action |
a function to handle missing values, as in statistical modeling functions like |
... |
arguments to pass to the function given in the |
targs |
a list of optional arguments to pass to |
The function given by fun
is applied to the values of the left-hand-side variable in formula
within
(combination of) levels of the factor(s) given in the right-hand side of formula
, producing a table of statistics.
The object returned by tapply
, typically simply printed.
John Fox<EMAIL_ADDRESS>Fox, J. and Weisberg, S. (2019) An R Companion to Applied Regression, Third Edition. Sage.


Nowadays, I’m starting in a new programming language : Python 🐍 . And I am pleased to share some of my knowledge about this new topic , which is image processing.
What is digital image processing
It is a set of techniques whose objective is to obtain a result with a specific application from a source image, improving certain characteristics that allow you to extract information from the image. OK , After a short introduction about the meaning of image processing, Let’s continue with the filters that I will show you in this post.
Median filter
Taken from Artemlezin Blog This filter is used to eliminate the ‘noise’ of the images, mainly is salt-n-pepper noise. There is not much theory beyond the one in the picture. This is how the filter works : gets all the values inside a mask, sorts them and then assigns the mean value to the coordinate. This is how it looks an image with salt and pepper noise : In Python 🐍 the filter works like this, enter to check the result:
from PIL import Image
path = "noise.png" # Your image path
img = Image.open(path)
members = [(0,0)] * 9
newimg = Image.new("RGB",(width,height),"white")
for i in range(1,width-1):
for j in range(1,height-1):
members[0] = img.getpixel((i-1,j-1))
members[1] = img.getpixel((i-1,j))
members[2] = img.getpixel((i-1,j+1))
members[3] = img.getpixel((i,j-1))
members[4] = img.getpixel((i,j))
members[5] = img.getpixel((i,j+1))
members[6] = img.getpixel((i+1,j-1))
members[7] = img.getpixel((i+1,j))
members[8] = img.getpixel((i+1,j+1))
members.sort()
newimg.putpixel((i,j),(members[4]))
And this is the result :
Sobel filter
The Sobel operator is an algorithm for edge detection, a technique to find the limits between regions in an image. The edge detection algorithm help us separate some specific parts of the source image and take them off from the background. There is more interesting theory about edge detection and the Sobel operator , but we will focus on the Python 🐍 implementation. Due to the excitement for the South American World Cup qualifiers I decided to use this image for example : In Python 🐍 the filter works like this, enter to check the result:
from PIL import Image
import math
path = "peru.jpeg" # Your image path
img = Image.open(path)
newimg = Image.new("RGB", (width, height), "white")
for x in range(1, width-1): # ignore the edge pixels for simplicity (1 to width-1)
for y in range(1, height-1): # ignore edge pixels for simplicity (1 to height-1)
# initialise Gx to 0 and Gy to 0 for every pixel
Gx = 0
Gy = 0
# top left pixel
p = img.getpixel((x-1, y-1))
r = p[0]
g = p[1]
b = p[2]
# intensity ranges from 0 to 765 (255 * 3)
intensity = r + g + b
# accumulate the value into Gx, and Gy
Gx += -intensity
Gy += -intensity
# remaining left column
p = img.getpixel((x-1, y))
r = p[0]
g = p[1]
b = p[2]
Gx += -2 * (r + g + b)
p = img.getpixel((x-1, y+1))
r = p[0]
g = p[1]
b = p[2]
Gx += -(r + g + b)
Gy += (r + g + b)
# middle pixels
p = img.getpixel((x, y-1))
r = p[0]
g = p[1]
b = p[2]
Gy += -2 * (r + g + b)
p = img.getpixel((x, y+1))
r = p[0]
g = p[1]
b = p[2]
Gy += 2 * (r + g + b)
# right column
p = img.getpixel((x+1, y-1))
r = p[0]
g = p[1]
b = p[2]
Gx += (r + g + b)
Gy += -(r + g + b)
p = img.getpixel((x+1, y))
r = p[0]
g = p[1]
b = p[2]
Gx += 2 * (r + g + b)
p = img.getpixel((x+1, y+1))
r = p[0]
g = p[1]
b = p[2]
Gx += (r + g + b)
Gy += (r + g + b)
# calculate the length of the gradient (Pythagorean theorem)
length = math.sqrt((Gx * Gx) + (Gy * Gy))
# normalise the length of gradient to the range 0 to 255
length = length / 4328 * 255
length = int(length)
# draw the length in the edge image
#newpixel = img.putpixel((length,length,length))
newimg.putpixel((x,y),(length,length,length))
And this is the result :
Conclusion
I mentioned that there is much more theory about this subject; so, I will leave some articles that, in my opinion, are the most complete and better explained in the web.
References
-
Saush Blog’s , good description about sobel operator and other image processing filter.
-
A detailed article about of median filter. http://homepages.inf.ed.ac.uk/rbf/HIPR2/sobel.htm
Thanks for reading this little post , totally open to feedback. Questions in the comment box and show your support 👏❤ . You can watch my open-source projects in my Github account.


There are some undocumented settings and Adapter methods that provide additional flexibility. We can consider them as experimental features. Most of these features are not tested well and may have some side effects or behave imperfectly.
For example, Adapter.fix method. It has different options for different cases which are discussed below. The options are passed as props of its argument object:
{{adapterFixArgumentDescription}}


In Rails 3.0, a Rails::Application object was introduced which is nothing more than an Engine but with the responsibility of coordinating the whole boot process.
Initialization
Rails::Application is responsible for executing all railties and engines initializers. It also executes some bootstrap initializers (check Rails::Application::Bootstrap) and finishing initializers, after all the others are executed (check Rails::Application::Finisher).
Configuration
Besides providing the same configuration as Rails::Engine and Rails::Railtie, the application object has several specific configurations, for example “cache_classes”, “consider_all_requests_local”, “filter_parameters”, “logger” and so forth.
Check Rails::Application::Configuration to see them all.
Routes
The application object is also responsible for holding the routes and reloading routes whenever the files change in development.
Middlewares
The Application is also responsible for building the middleware stack.
Booting process
The application is also responsible for setting up and executing the booting process. From the moment you require “config/application.rb” in your app, the booting process goes like this:
1) require "config/boot.rb" to setup load paths
2) require railties and engines
3) Define Rails.application as "class MyApp::Application < Rails::Application"
4) Run config.before_configuration callbacks
5) Load config/environments/ENV.rb
6) Run config.before_initialize callbacks
7) Run Railtie#initializer defined by railties, engines and application.
One by one, each engine sets up its load paths, routes and runs its config/initializers/* files.
8) Custom Railtie#initializers added by railties, engines and applications are executed
9) Build the middleware stack and run to_prepare callbacks
10) Run config.before_eager_load and eager_load! if eager_load is true
11) Run config.after_initialize callbacks
- MODULE Rails::Application::Bootstrap
- MODULE Rails::Application::Finisher
- CLASS Rails::Application::Configuration
- CLASS Rails::Application::RoutesReloader
- A
- C
- E
- I
- K
- L
- N
- R
- S
| [RW] | assets | |
| [R] | reloaders | |
| [RW] | sandbox | |
| [RW] | sandbox? |
Source: show
# File ../../.rvm/gems/ruby-2.1.2/gems/railties-4.0.0/lib/rails/application.rb, line 77 def initialize super @initialized = false @reloaders = [] @routes_reloader = nil @app_env_config = nil @ordered_railties = nil @railties = nil end
Implements call according to the Rack API. It simply dispatches the request to the underlying middleware stack.
Source: show
# File ../../.rvm/gems/ruby-2.1.2/gems/railties-4.0.0/lib/rails/application.rb, line 94 def call(env) env["ORIGINAL_FULLPATH"] = build_original_fullpath(env) env["ORIGINAL_SCRIPT_NAME"] = env["SCRIPT_NAME"] super(env) end
Stores some of the Rails initial environment parameters which will be used by middlewares and engines to configure themselves. Currently stores:
* "action_dispatch.parameter_filter" => config.filter_parameters
* "action_dispatch.redirect_filter" => config.filter_redirect
* "action_dispatch.secret_token" => config.secret_token
* "action_dispatch.secret_key_base" => config.secret_key_base
* "action_dispatch.show_exceptions" => config.action_dispatch.show_exceptions
* "action_dispatch.show_detailed_exceptions" => config.consider_all_requests_local
* "action_dispatch.logger" => Rails.logger
* "action_dispatch.backtrace_cleaner" => Rails.backtrace_cleaner
* "action_dispatch.key_generator" => key_generator
* "action_dispatch.http_auth_salt" => config.action_dispatch.http_auth_salt
* "action_dispatch.signed_cookie_salt" => config.action_dispatch.signed_cookie_salt
* "action_dispatch.encrypted_cookie_salt" => config.action_dispatch.encrypted_cookie_salt
* "action_dispatch.encrypted_signed_cookie_salt" => config.action_dispatch.encrypted_signed_cookie_salt
Source: show
# File ../../.rvm/gems/ruby-2.1.2/gems/railties-4.0.0/lib/rails/application.rb, line 138 def env_config @app_env_config ||= begin if config.secret_key_base.blank? ActiveSupport::Deprecation.warn "You didn't set config.secret_key_base. " + "Read the upgrade documentation to learn more about this new config option." if config.secret_token.blank? raise "You must set config.secret_key_base in your app's config." end end super.merge({ "action_dispatch.parameter_filter" => config.filter_parameters, "action_dispatch.redirect_filter" => config.filter_redirect, "action_dispatch.secret_token" => config.secret_token, "action_dispatch.secret_key_base" => config.secret_key_base, "action_dispatch.show_exceptions" => config.action_dispatch.show_exceptions, "action_dispatch.show_detailed_exceptions" => config.consider_all_requests_local, "action_dispatch.logger" => Rails.logger, "action_dispatch.backtrace_cleaner" => Rails.backtrace_cleaner, "action_dispatch.key_generator" => key_generator, "action_dispatch.http_auth_salt" => config.action_dispatch.http_auth_salt, "action_dispatch.signed_cookie_salt" => config.action_dispatch.signed_cookie_salt, "action_dispatch.encrypted_cookie_salt" => config.action_dispatch.encrypted_cookie_salt, "action_dispatch.encrypted_signed_cookie_salt" => config.action_dispatch.encrypted_signed_cookie_salt }) end end
Source: show
# File ../../.rvm/gems/ruby-2.1.2/gems/railties-4.0.0/lib/rails/application.rb, line 62 def inherited(base) raise "You cannot have more than one Rails::Application" if Rails.application super Rails.application = base.instance Rails.application.add_lib_to_load_path! ActiveSupport.run_load_hooks(:before_configuration, base.instance) end
Returns true if the application is initialized.
Source: show
# File ../../.rvm/gems/ruby-2.1.2/gems/railties-4.0.0/lib/rails/application.rb, line 88 def initialized? @initialized end
Return the application's KeyGenerator
Source: show
# File ../../.rvm/gems/ruby-2.1.2/gems/railties-4.0.0/lib/rails/application.rb, line 107 def key_generator # number of iterations selected based on consultation with the google security # team. Details at https://github.com/rails/rails/pull/6952#issuecomment-7661220 @caching_key_generator ||= begin if config.secret_key_base key_generator = ActiveSupport::KeyGenerator.new(config.secret_key_base, iterations: 1000) ActiveSupport::CachingKeyGenerator.new(key_generator) else ActiveSupport::LegacyKeyGenerator.new(config.secret_token) end end end
Reload application routes regardless if they changed or not.
Source: show
# File ../../.rvm/gems/ruby-2.1.2/gems/railties-4.0.0/lib/rails/application.rb, line 101 def reload_routes! routes_reloader.reload! end
Source: show
# File ../../.rvm/gems/ruby-2.1.2/gems/railties-4.0.0/lib/rails/application.rb, line 361 def allow_concurrency? if config.allow_concurrency.nil? config.cache_classes else config.allow_concurrency end end
Source: show
# File ../../.rvm/gems/ruby-2.1.2/gems/railties-4.0.0/lib/rails/application.rb, line 369 def load_rack_cache rack_cache = config.action_dispatch.rack_cache return unless rack_cache begin require 'rack/cache' rescue LoadError => error error.message << ' Be sure to add rack-cache to your Gemfile' raise end if rack_cache == true { metastore: "rails:/", entitystore: "rails:/", verbose: false } else rack_cache end end


In Unity 3D create an environment such as the race circuit, country or city. Create a plot about two rivals competing to win the race. Create engaging action scenes with different camera angles and realistic physics. It does not supposed to be interactive. All animation sequences requires no user interaction.
Our inspiration for animation:
Our intention:
Make physicaly based animation of legendary race in GP Monza 1998 with Mika Häkkinen and Michael Schumacher, with some situation chages (weather...).
Main story points and situations descriptions
Raining, wet track, low visibility from car (splash water from tires - fog effect)
Traditional camera angles as top, behind, front... Special angles as top-cockpit view, front- view, view from curb...
Every car has own engine sound (classic V12 engine), sounds of rain and watter, thunders...
Software which we are planning to use is going to be Unity Engine and Blender.
Positions of models and situations locations:


CHiVE: Examples of prosody transfer
Example 1
| Sentence 1 — recording | Sentence 1 — auto-encoded | Sentence 1 — conditioned on Sentence 2 embedding |
|---|---|---|
| Sentence 1: "What do you call a boomerang that doesn't come back? A stick!" |
| Sentence 2 — recording | Sentence 2 — auto-encoded | Sentence 2 — conditioned on Sentence 1 embedding |
|---|---|---|
| Sentence 2: "What's orange and sounds like a parrot? A carrot." |
The clearest example of prosody being transferred is at the end of the orange dashed line, where it closely mimics the blue solid line.
Example 2
| Sentence 1 — recording | Sentence 1 — auto-encoded | Sentence 1 — conditioned on Sentence 2 embedding |
|---|---|---|
| Sentence 1: "What do you get when you put a vest on an alligator? An investigator." |
| Sentence 2 — recording | Sentence 2 — auto-encoded | Sentence 2 — conditioned on Sentence 1 embedding |
|---|---|---|
| Sentence 2: "What do you get from a pampered cow? Spoiled milk." |
The clearest effect of prosody transfer is visible at the start, where the dashed lines overlap nearly perfectly with the solid lines of the opposing color.
As noted in the paper, the effects wears off as the sentence progresses. Near the end, the two blue line ends up much like each other, without, apparently, following the guidance of the reference prosody embedding. Something similar happens to the orange curves.
As noted in the paper, the effects wears off as the sentence progresses. Near the end, the two blue line ends up much like each other, without, apparently, following the guidance of the reference prosody embedding. Something similar happens to the orange curves.
Example 3
| Sentence 1 — recording | Sentence 1 — auto-encoded | Sentence 1 — conditioned on Sentence 2 embedding |
|---|---|---|
| Sentence 1: "How did the frog burn its tongue? It tried to eat a firefly." |
| Sentence 2 — recording | Sentence 2 — auto-encoded | Sentence 2 — conditioned on Sentence 1 embedding |
|---|---|---|
| Sentence 2: "How did the hipster burn his mouth? He sipped his coffee before it was cool." |
The dashed lines, again, follow the solid lines of opposing color quite perfectly at the start.
Additionally, between frame 300 and 500, there is a clear transfer effect visible, where the dashed lines deviate substantially from their solid counterparts of the same color, and follow the solid lines of the oppsoing color instead.
The dashed orange line drastically differs from the solid orange line at the end. It seems to be guided by the solid blue line in stead, albeit somehwat delayed, due to differences in timing.
Example 4
| Sentence 1 — recording | Sentence 1 — auto-encoded | Sentence 1 — conditioned on Sentence 2 embedding |
|---|---|---|
| Sentence 1: "What do cats eat for breakfast? Mice Crispies." |
| Sentence 2 — recording | Sentence 2 — auto-encoded | Sentence 2 — conditioned on Sentence 1 embedding |
|---|---|---|
| Sentence 2: "What do clouds wear under their shorts? Thunderpants." |
The dip in F0 of the blue dashed line (around frame 300) clearly follows the one of the orange solid line (around frame 350).
Same with the peak of the orange dashed line around frame 600, which coincides which is raised, relative to the peak in the solid orange line, to coincide with the one in the the blue solid line.
Same with the peak of the orange dashed line around frame 600, which coincides which is raised, relative to the peak in the solid orange line, to coincide with the one in the the blue solid line.
Example 5
| Sentence 1 — recording | Sentence 1 — auto-encoded | Sentence 1 — conditioned on Sentence 2 embedding |
|---|---|---|
| Sentence 1: "Why are archaeologists so annoyed? They always have a bone to pick." |
| Sentence 2 — recording | Sentence 2 — auto-encoded | Sentence 2 — conditioned on Sentence 1 embedding |
|---|---|---|
| Sentence 2: "Why are libraries so strict? They have to go by the book." |
This is a negative example, where the dashed curves look a lot like their solid counterparts, and do not seem to be guided much by the reference prosody (the solid lines in the opposing color).
These audio samples go with CHiVE: Varying Prosody in Speech Synthesis with a Linguistically Driven Dynamic Hierarchical Conditional Variational Network, Wan, V., Chan, C.-a., Kenter, T., Vit, J., and Clark, R. A., Proceedings of the Thirty-sixth International Conference on Machine Learning (ICML 2019), 2019, Section 4.3, Figures 5 and 6, plus some additional examples.
The underlying scenario for these examples would be that the text and nothing else is provided for a sentence, and the speech audio for this sentence should be synthesized, not with a default prosody, but with a prosody that is like a reference sentence, for which we do have a recording.
If the dashed lines of one color follows the solid line of the other color, this is taken to be a sign that prosody transfer happened (i.e., if the dashed blue line seems to follow the solid orange line, or vice versa).
If no transfer would take place, lines with the same color would match (i.e., dashed blue lines would match solid blue lines).


Read on about what it is, why it is useful, and how to find your mail index
When we sign-in to multiple Google accounts on a device's web-browser, each mail is assigned an index number, or a position number, so to speak.
The account with which you first logged in gets the index 0. The next account gets the index 1 and so on. These indexes look like
u/1/
in links. Here, index 1 is chosen as an example. Sometimes it also appears in the form of ?authuser=1
.
They all really refer to the same idea. Positioning or indexing the accounts.
The Index 0 Mail is your Default Mail. Appears as u/0/
.
Different services are available on different Google accounts. And then, if some of those accounts are a GSuite account and belong to an organisation, there can be many levels of restrictions.
Whenever you open a link, the Google Account Picker goes through your indexes in order, and usually opens up with the correct account. However, sometimes this is not enough and you need to manually choose the account with which to open the link. This is where index number comes in handy.
If the links mention an index number in it, and if it matches your correct organisation account, you can easily access the resource without having to go through the step to pick the correct account.
This site helps you pick your correct account index and modify all dependent links accordingly, so you can have a more friendly experience.
It's actually pretty simple. Just go to mail.google.com and change accounts to your IISER Pune Student Email ID. If you cannot find your student email ID, you need to Log In first.
Now, notice the URL. It will look something like this: https://mail.google.com/mail/u/2/#inbox
. Do you see
something similar to the u/2
part? The number after u/
represents your account index. That's it.
 Else, if you are on a new device or if you forgot, just follow the instruction above once more, and you will know the account index.


It's very satisfying writing that first test around an old, crufty piece of code you hope to replace.
10/29/2009, 8:46:26 AM
Favs: 0
Retweets: 0
link--- layout: tweet ---
It's very satisfying writing that first test around an old, crufty piece of code you hope to replace.
10/29/2009, 8:46:26 AM
Favs: 0
Retweets: 0
link


exec command -with -flags- Replace with the specified command, clearing environment variables:
exec -c command -with -flags- Replace with the specified command and login using the default shell:
exec -l command -with -flags- Replace with the specified command and change the process name:
exec -a process_name command -with -flags