JSON-LD serialization: DrupalCon discussion

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

In the meeting at DrupalCon Munich in the Coder's Lounge (Weds, Aug 21), we agreed to the following basic structure for JSON-LD, using the language maps to handle language versions.

{
  "@context": "http://example.org/contexts/node/article.jsonld",
  "@id": "http://example.com/node/1",
  "title": {
    "de": [
      "Deutsch Titel"
    ],
    "en": [
      "English title"
    ]
  },
  "tags": {
    "de": [
      {
        "@id": "http://example.com/taxonomy/term/1"
      },
      {
        "@id": "http://example.com/taxonomy/term/2"
      }
    ],
    "en": [
      {
        "@id": "http://example.com/taxonomy/term/1"
      }
    ]
  }
}

The context available at http://example.org/contexts/node/article.jsonld for this would include the following line to set up the language map.

    "title": "http://example.com/schema/node/article/fields/title",
    "tags": {"@id": "http://example.com/schema/node/article/fields/tags", "@container": "@language"}

NOTE: The URI patterns that I use for the context and site-generated vocabulary are arbitrary and have not yet been finalized. Also, there would be many properties included which I have not shown, such as uuid and vuuid.

Known issue

It is understood that the language version handling that we rely upon in the JSON object does not translate when the object is flattened to RDF. This is because there is no concept of language tagged resources in RDF, only language tagged literals (i.e. strings).

Members of the JSON-LD working group have expressed that supporting compaction and expansion for the language map data structure (maintaining the same data shape when round tripping) is a priority. In addition, Henri Bergius indicated that converting from RDFa to a language mapped JSON-LD structure should be possible within CreateJS. This satisfied our use requirements.

We decided that maintaining the language version handling when objects are flattened to RDF is not a major concern for us.

Other Discussion Points

  • In order to provide access to a limited set of entities, we would provide an API that allows you to restrict requests (e.g. request everything updated since DATE) rather than the paging functionality of Atom.
  • The limited set of entities would be returned as a list of URIs, which the requestor would then dereference to get the full entity. Ethan brought up the fact that this causes problems for many interested in Backbone, etc, where reducing network requests is a priority. May want to consider providing option to return graph containing full entities instead of list of URIs.
  • To reduce response size, we may want to allow clients to list which fields they want using a GET parameter. Concerns were brought up about the semantics of URIs with GET parameters.
  • Questions about what to save when a POST doesn't include all fields came up. Current thinking is to only update fields which have values included in the POST request.

Please add to the wiki if you remember any other discussion points.