Add '@language' container type

[lanthaler]

The idea of this issue is to set @container of a property to @language to allow L10n of JSON property values as shown in the following example:

{
  "@context": {
    "label": {
      "@id": "http://example.com/label",
      "@container": "@language"
    }
  },
  "@id": "http://buckingham.uk/queenie",
  "label": {
    "en": "The Queen",
    "de": "Die Koenigin"
  }
}

When expanded, this should result in:

[
  {
    "@id": "http://buckingham.uk/queenie",
    "http://example.com/label": [
      { "@value": "The Queen", "@language": "en" },
      { "@value": "Die Königin", "@language": "de" }
    ]
  }
]

Compaction might be a bit trickier if there are other properties that are not language tagged for the same property. They either have to stay under the full IRI in that case or contain at least one keyword to be distinguishable from language maps, something like:

{
  "@context": {
    "label": {
      "@id": "http://example.com/label",
      "@container": "@language"
    }
  },
  "@id": "http://buckingham.uk/queenie",
  "label": [
    {
      "en": "The Queen",
      "de": "Die Koenigin"
    },
    "No language",
    5,
    true,
    {
      "@id": "_:b1",   <-- a keyword MUST be present to distinguish an object from a language map
      "prop": value"
    }
  ]
}

Something similar was discussed before under the term "language map" (#29) and came up again in a discussion Gregg had with @vrandezo. There has also been some discussion on the mailing list:

• http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0010.html
• http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0011.html
• http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0012.html
• http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0013.html
• http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0014.html
• http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0015.html
• http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0018.html

---

Gregg originally proposed to use something he called "folding" for this and #134:

{
  "@context": {
    "en": {"@id": null", "@language": "en", "@fold": true},
    "de": {"@id": null", "@language": "de", "@fold": true},
    "queenie": {"@id": null", "@fold": true}
  },
  "queenie": {
    "@id": "http://buckingham.uk/queenie",
    "label": {
      "en": { "@value": "The Queen" },
      "de": { "@value": "Die Königin"}
    }
  }
}

[gkellogg]

RESOLVED: Attempt to add other @container options, such as "@container": "@language" to support Wikidata's language-map use case.

[dlongley]

I think the general idea can work. I'm against the compaction example that Markus provided, however, because I think it's confusing. It's particularly confusing because I see @container as currently defining how to interpret the JSON value associated with the term.

For example, {"foo": {"@container": "@set"}} currently means to me: the JSON value for the key "foo" is an unordered array. It follows then that {"foo": {"@container": "@language"}} means: the JSON value for the key "foo" is a language map, that is, a JSON object where the keys are language identifiers and the values are language strings. I'm fine with that. However, in the compaction example, the JSON value for "foo" is instead an array, which is actually a @set (presumably), that presumably somewhere contains a language map but also other values that aren't maps at all.

I'd much prefer us to take a different route for handling the compaction case. I might be ok with the JSON value of "foo" being an array, but only so long as each JSON value within that array is a language map, nothing else. This would permit multiple language maps (is there actually a use case for this?). However, IMO, there should definitely be nothing other than language maps for the term "foo". If there exists a value for "foo" that cannot be unambiguously converted to a language map, then it should not be used with that term -- which means selecting the absolute IRI if there are no other applicable terms available.

I think this same compaction behavior should apply to @id and @type maps, etc. (See: #134).

[gkellogg]

So, this is not going in a direction that I was originally proposing, based on the WikiData use-cases. Basically, there are two ways in which you might consider using language maps:

1. As a value-map, where a property contains an object who's keys are language elements, who's values in turn are language-tagged strings.
2. As property-map, where some or all of the keys of a subject definition are language elements, who's values are objects containing properties of the original subject definition.

Consider a typical internationalization use case, where you have a resource with values expressed in multiple language; for example, an abbreviated example from DBPedia:

@prefix dbpedia:    <http://dbpedia.org/resource/> .
@prefix owl:    <http://www.w3.org/2002/07/owl#> .
@prefix rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
@prefix yago:   <http://dbpedia.org/class/yago/> .

dbpedia:Linked_Data rdf:type    yago:Buzzwords ;
owl:sameAs  <http://rdf.freebase.com/ns/m/02r2kb1>, dbpedia:Linked_Data .
dbpedia:Linked_Data rdfs:comment
  "La propuesta de datos vinculados (linked data) surge dentro de marco general de la Web sem\u00E1ntica. El t\u00E9rmino \"datos vinculados\" hace referencia al m\u00E9todo con el que se pueden mostrar, intercambiar y conectar datos a trav\u00E9s de URIs desreferenciables en la Web."@es ,
    "Linked Open Data (LOD) bezeichnet im World Wide Web frei verf\u00FCgbare Daten, die per Uniform Resource Identifier (URI) identifiziert sind und dar\u00FCber direkt per HTTP abgerufen werden k\u00F6nnen und ebenfalls per URI auf andere Daten verweisen. Idealerweise werden zur Kodierung und Verlinkung der Daten das Resource Description Framework (RDF) und darauf aufbauende Standards wie SPARQL und die Web Ontology Language (OWL) verwendet, so dass Linked Open Data gleichzeitig Teil des Semantic Web ist."@de ,
    "I dati collegati (linked data in inglese) sono un aspetto del web semantico. Il termine dati collegati \u00E8 usato per descrivere un metodo di esporre, condividere e connettere dati attraverso URI deferenziabili."@it ,
    "In computing, linked Data describes a method of publishing structured data so that it can be interlinked and become more useful. It builds upon standard Web technologies such as HTTP and URIs, but rather than using them to serve web pages for human readers, it extends them to share information in a way that can be read automatically by computers. This enables data from different sources to be connected and queried."@en ,
    "Le Web des donn\u00E9es (Linked Data, en Anglais) est une initiative du W3C(Consortium World Wide Web) visant \u00E0 favoriser la publication de donn\u00E9es structur\u00E9es sur le Web, non pas sous la forme de silos de donn\u00E9es isol\u00E9s les uns des autres, mais en les reliant entre elles pour constituer un r\u00E9seau global d'informations."@fr ,
    "\u9375\u9023\u8CC7\u6599\u662F\u6B63\u5728\u5FEB\u901F\u767C\u5C55\u7684\u8A9E\u7FA9\u7DB2\u7684\u4E00\u7CFB\u5217\u7684\u6D3B\u52D5\uFF0C\u5B83\u63CF\u8FF0\u4E86\u4E00\u5957\u5728\u5168\u7403\u8CC7\u8A0A\u7DB2\u4E0A\u767C\u4F48\u3001\u5206\u4EAB\u3001\u53CA\u9023\u7D50\u8CC7\u6599\u7684\u65B9\u6CD5\u3002\u4E3B\u8981\u4EE5\u53EF\u53C3\u7167\u7684URI\u4F5C\u70BA\u6700\u57FA\u672C\u7684\u8981\u7D20\u3001\u4EE5RDF\u4F5C\u70BA\u63CF\u8FF0\u9023\u7D50\u7684\u8A9E\u8A00\u3002"@zh ;
rdfs:label
  "Linked Open Data"@de ,
    "Datos vinculados"@es ,
    "\u9375\u9023\u8CC7\u6599"@zh ,
    "Linked Data"@en ,
    "Dati collegati"@it ,
    "Web des donn\u00E9es"@fr ;

Using the value-map syntax, this could be represented as follows:

{
  "@context": {
    ...
    "rdfs:comment": {"@container": "@language"}
    "rdfs:label": {"@container": "@language"}
  },
  "@id": "dbpedia:Linked_Data",
  "owl:sameAs": ["http://rdf.freebase.com/ns/m/02r2kb1", "dbpedia:Linked_Data"],
  "rdfs:comment": {
    "es": "La propuesta de datos vinculados (linked data) surge dentro de marco general de la Web sem\u00E1ntica. El t\u00E9rmino \"datos vinculados\" hace referencia al m\u00E9todo con el que se pueden mostrar, intercambiar y conectar datos a trav\u00E9s de URIs desreferenciables en la Web.",
    "de": "Linked Open Data (LOD) bezeichnet im World Wide Web frei verf\u00FCgbare Daten, die per Uniform Resource Identifier (URI) identifiziert sind und dar\u00FCber direkt per HTTP abgerufen werden k\u00F6nnen und ebenfalls per URI auf andere Daten verweisen. Idealerweise werden zur Kodierung und Verlinkung der Daten das Resource Description Framework (RDF) und darauf aufbauende Standards wie SPARQL und die Web Ontology Language (OWL) verwendet, so dass Linked Open Data gleichzeitig Teil des Semantic Web ist.",
    "it": "I dati collegati (linked data in inglese) sono un aspetto del web semantico. Il termine dati collegati \u00E8 usato per descrivere un metodo di esporre, condividere e connettere dati attraverso URI deferenziabili.",
    "en": "In computing, linked Data describes a method of publishing structured data so that it can be interlinked and become more useful. It builds upon standard Web technologies such as HTTP and URIs, but rather than using them to serve web pages for human readers, it extends them to share information in a way that can be read automatically by computers. This enables data from different sources to be connected and queried.",
    "fr": "Le Web des donn\u00E9es (Linked Data, en Anglais) est une initiative du W3C(Consortium World Wide Web) visant \u00E0 favoriser la publication de donn\u00E9es structur\u00E9es sur le Web, non pas sous la forme de silos de donn\u00E9es isol\u00E9s les uns des autres, mais en les reliant entre elles pour constituer un r\u00E9seau global d'informations.",
    "zh": "\u9375\u9023\u8CC7\u6599\u662F\u6B63\u5728\u5FEB\u901F\u767C\u5C55\u7684\u8A9E\u7FA9\u7DB2\u7684\u4E00\u7CFB\u5217\u7684\u6D3B\u52D5\uFF0C\u5B83\u63CF\u8FF0\u4E86\u4E00\u5957\u5728\u5168\u7403\u8CC7\u8A0A\u7DB2\u4E0A\u767C\u4F48\u3001\u5206\u4EAB\u3001\u53CA\u9023\u7D50\u8CC7\u6599\u7684\u65B9\u6CD5\u3002\u4E3B\u8981\u4EE5\u53EF\u53C3\u7167\u7684URI\u4F5C\u70BA\u6700\u57FA\u672C\u7684\u8981\u7D20\u3001\u4EE5RDF\u4F5C\u70BA\u63CF\u8FF0\u9023\u7D50\u7684\u8A9E\u8A00\u3002";
  },
  "rdfs:label": {
    "es": "Datos vinculados",
    "de": "Linked Open Data",
    "it": "Dati collegati",
    "en": "Linked Data",
    "fr": "Web des donn\u00E9es",
    "zh": "\u9375\u9023\u8CC7\u6599";
  }
}

The problem here, is that indexing of values always requires d-referencing through the property before looking for a language variant. If a developer is looking for all resources that have descriptions in some language, this requires deeper navigation.

If, however the property-map version is used, all values sharing a common language are nicely contained together. This might be represented as follows:

{
  "@context": {
    ...
    "es": {"@container": "@language"},
    "de": {"@container": "@language"},
    ...
  },
  "@id": "dbpedia:Linked_Data",
  "owl:sameAs": ["http://rdf.freebase.com/ns/m/02r2kb1", "dbpedia:Linked_Data"],
  "es": {
    "rdfs:comment": "La propuesta de datos vinculados (linked data) surge dentro de marco general de la Web sem\u00E1ntica. El t\u00E9rmino \"datos vinculados\" hace referencia al m\u00E9todo con el que se pueden mostrar, intercambiar y conectar datos a trav\u00E9s de URIs desreferenciables en la Web.",
    "rdfs:label": "Datos vinculados"
  },
  "de": {
    "rdfs:comment": "Linked Open Data (LOD) bezeichnet im World Wide Web frei verf\u00FCgbare Daten, die per Uniform Resource Identifier (URI) identifiziert sind und dar\u00FCber direkt per HTTP abgerufen werden k\u00F6nnen und ebenfalls per URI auf andere Daten verweisen. Idealerweise werden zur Kodierung und Verlinkung der Daten das Resource Description Framework (RDF) und darauf aufbauende Standards wie SPARQL und die Web Ontology Language (OWL) verwendet, so dass Linked Open Data gleichzeitig Teil des Semantic Web ist.",
    "rdfs:label": "Linked Open Data"
  },
  "it": {
    "rdfs:comment": "La propuesta de datos vinculados (linked data) surge dentro de marco general de la Web sem\u00E1ntica. El t\u00E9rmino \"datos vinculados\" hace referencia al m\u00E9todo con el que se pueden mostrar, intercambiar y conectar datos a trav\u00E9s de URIs desreferenciables en la Web.",
    "rdfs:comment": "I dati collegati (linked data in inglese) sono un aspetto del web semantico. Il termine dati collegati \u00E8 usato per descrivere un metodo di esporre, condividere e connettere dati attraverso URI deferenziabili.",
    "rdfs:label": "Dati collegati"
  },
  "en": {
    "rdfs:comment": "In computing, linked Data describes a method of publishing structured data so that it can be interlinked and become more useful. It builds upon standard Web technologies such as HTTP and URIs, but rather than using them to serve web pages for human readers, it extends them to share information in a way that can be read automatically by computers. This enables data from different sources to be connected and queried.",
    "rdfs:label": "Linked Data"
  },
  "fr": {
    "rdfs:comment": "Le Web des donn\u00E9es (Linked Data, en Anglais) est une initiative du W3C(Consortium World Wide Web) visant \u00E0 favoriser la publication de donn\u00E9es structur\u00E9es sur le Web, non pas sous la forme de silos de donn\u00E9es isol\u00E9s les uns des autres, mais en les reliant entre elles pour constituer un r\u00E9seau global d'informations.",
    "rdfs:label": "Web des donn\u00E9es"
  },
  "zh": {
    "rdfs:comment": "\u9375\u9023\u8CC7\u6599\u662F\u6B63\u5728\u5FEB\u901F\u767C\u5C55\u7684\u8A9E\u7FA9\u7DB2\u7684\u4E00\u7CFB\u5217\u7684\u6D3B\u52D5\uFF0C\u5B83\u63CF\u8FF0\u4E86\u4E00\u5957\u5728\u5168\u7403\u8CC7\u8A0A\u7DB2\u4E0A\u767C\u4F48\u3001\u5206\u4EAB\u3001\u53CA\u9023\u7D50\u8CC7\u6599\u7684\u65B9\u6CD5\u3002\u4E3B\u8981\u4EE5\u53EF\u53C3\u7167\u7684URI\u4F5C\u70BA\u6700\u57FA\u672C\u7684\u8981\u7D20\u3001\u4EE5RDF\u4F5C\u70BA\u63CF\u8FF0\u9023\u7D50\u7684\u8A9E\u8A00\u3002";
    "rdfs:label": "\u9375\u9023\u8CC7\u6599"
  }
}

This mapping chunks properties together sharing a common language, and makes it easier to see all relevant information in the same place, and do a common query for a language (object.en) to find all keys appropriate for that language.

It's possible that we could include both representations. Consider a possible change to Expansion and Value Expansion Algorithms:

For value-map; in Expansion:

Before 2.2:

• If active property is has @container: @language, and every key in element is of the form language (from BCP47) and does not map to an absolute IRI, the return value is an array constructed from the result of performing Value Expansion on each value using a copy of context with @language set to each key from element in turn.

For property-map; in Expansion:

Before 2.2.2:

• If property does not expand to a keyword or absolute IRI and property has @container: @language, value MUST be a JSON object.
  • Process the object using a copy of context with @language set to property using the existing active subject and active property.
  • For each key in the resulting expanded object, either merge value into an existing property property of element, or create a new property property with value as value.

We may want to use different @container values to distinguish the use-cases, but the algorithm can handle each case as is without anything further.

[lanthaler]

Now I see where you are coming from Gregg but I'm still not sure I agree with the proposal. If you model your data in that way isn't that basically the same as having multiple documents - one per language? And if so, wouldn't that be simply solved by using an array at the document's top-level (or @graph) and setting a new default language in each "sub-document". Something like

{
  "@context": { .. shared terms .. }
  "@graph": [
   {
     "@context": { "@language": "en" },
     ... English "sub-document" ...
   },
   {
     "@context": { "@language": "de" }
      ... German "sub-document" ...
  }
 ]
}

The access is not as convenient as in your proposed solution but I think it would adress the same use cases -- even though I doubt you agree :-) -- and wouldn't require any further changes to JSON-LD.

I agree with what Dave said regarding compaction of language maps. Values that can't be brought to language map form should stay under their absolute IRI (or go under another term).

[lanthaler]

RESOLVED: Support language-maps via the "@container": "@language" pattern in @context.

[gkellogg]

Based on today's call, the use of value-map proposal where the value can be a node, as well as a string, makes sense to me. In this case, the node would be anonymous, and use the skos-xl pattern to designate the primary value, but this would also allow other properties to be asserted on the value (such as pronunciation). Extending the example from above, this might be represented as follows:

{
  "@context": {
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "ipa": "http://dbpedia.org/resource/International_Phonetic_Alphabet",
    "skosxl": "http://www.w3.org/2008/05/skos-xl#",
    "label": {"@id": "rdfs:label", "@container": "@language"}
  },
  "@id": "http://dbpedia.org/resource/Queen_Elizabeth",
  "label": {
    "en": {
      "@type": "skosxl:Label",
      "skosxl:literalForm": "Queen Elizabeth",
      "ipa": "kwiːn ʔeˈliːzabɛt əˈlɪzəbəθ"
    },
    "de": {
      "@type": "skosxl:Label",
      "skosxl:literalForm": "Königin Elisabeth",
      "ipa": "ˈkøːnɪɡɪn ʔeˈliːzabɛt"
    }
  }
}

If the @container: @language means to apply the property as a language within a context, this could expand to the following:

[{
  "@id": "http://dbpedia.org/resource/Queen_Elizabeth",
  "http://www.w3.org/2000/01/rdf-schema#label": [
    {
      "@type": "http://www.w3.org/2008/05/skos-xl#Label",
      "http://www.w3.org/2008/05/skos-xl#literalForm": [{
        "@value": "Queen Elizabeth",
        "@language": "en"
      }],
      "http://dbpedia.org/resource/International_Phonetic_Alphabet": [{
        "@value": "kwiːn ʔeˈliːzabɛt əˈlɪzəbəθ",
        "@language": "en"
      }]
    },
    {
      "@type": "http://www.w3.org/2008/05/skos-xl#Label",
      "http://www.w3.org/2008/05/skos-xl#literalForm": [{
        "@value": "Königin Elisabeth",
        "@language": "de"
      }],
      "http://dbpedia.org/resource/International_Phonetic_Alphabet": [{
        "@value": "ˈkøːnɪɡɪn ʔeˈliːzabɛt",
        "@language": "de"
      }]
    }
  ]
}]

In Turtle, this might look like the following:

<http://dbpedia.org/resource/Queen_Elizabeth> rdfs:label
  [ a skosxl:Label;
    skosxl:literalForm "Queen Elizabeth"@en;
    ipa: "kwiːn ʔeˈliːzabɛt əˈlɪzəbəθ"@en ],
  [ a skosxl:Label;
    skosxl:literalForm "Königin Elisabeth"@de;
    ipa: "ˈkøːnɪɡɪn ʔeˈliːzabɛt"@de ],

[lanthaler]

Should this

[{
  "@id": "http://dbpedia.org/resource/Queen_Elizabeth",
  "http://www.w3.org/2000/01/rdf-schema#label": [
    {
      "@type": "http://www.w3.org/2008/05/skos-xl#Label",
      "http://www.w3.org/2008/05/skos-xl#literalForm": [{
        "@value": "Queen Elizabeth",
        "@language": "en"
      }],
      "http://www.example.com": [ { "@value": "not language tagged" } ],
      "http://dbpedia.org/resource/International_Phonetic_Alphabet": [{
        "@value": "kwiːn ʔeˈliːzabɛt əˈlɪzəbəθ",
        "@language": "en"
      }]
    },
    {
      "@type": "http://www.w3.org/2008/05/skos-xl#Label",
      "http://www.w3.org/2008/05/skos-xl#literalForm": [{
        "@value": "Königin Elisabeth",
        "@language": "de"
      }],
      "http://www.example.com": [ { "@value": "not language tagged" } ],
      "http://dbpedia.org/resource/International_Phonetic_Alphabet": [{
        "@value": "ˈkøːnɪɡɪn ʔeˈliːzabɛt",
        "@language": "de"
      }]
    }
  ]
}]

compact to:

{
  "@context": {
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "ipa": "http://dbpedia.org/resource/International_Phonetic_Alphabet",
    "skosxl": "http://www.w3.org/2008/05/skos-xl#",
    "ex": "http://www.example.com",
    "label": {"@id": "rdfs:label", "@container": "@language"}
  },
  "@id": "http://dbpedia.org/resource/Queen_Elizabeth",
  "label": {
    "en": {
      "@type": "skosxl:Label",
      "skosxl:literalForm": "Queen Elizabeth",
      "ex": [ { "@value": "not language tagged" } ],
      "ipa": "kwiːn ʔeˈliːzabɛt əˈlɪzəbəθ"
    },
    "de": {
      "@type": "skosxl:Label",
      "skosxl:literalForm": "Königin Elisabeth",
      "ex": [ { "@value": "not language tagged" } ],
      "ipa": "ˈkøːnɪɡɪn ʔeˈliːzabɛt"
    }
  }
}

or to:

{
  "@context": {
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "ipa": "http://dbpedia.org/resource/International_Phonetic_Alphabet",
    "skosxl": "http://www.w3.org/2008/05/skos-xl#",
    "ex": "http://www.example.com",
    "label": {"@id": "rdfs:label", "@container": "@language"}
  },
  "@id": "http://dbpedia.org/resource/Queen_Elizabeth",
  "rdfs:label": {
      "@type": "skosxl:Label",
      "ex": "not language tagged"
  },
  "label": {
    "en": {
      "skosxl:literalForm": "Queen Elizabeth",
      "ipa": "kwiːn ʔeˈliːzabɛt əˈlɪzəbəθ"
    },
    "de": {
      "skosxl:literalForm": "Königin Elisabeth",
      "ipa": "ˈkøːnɪɡɪn ʔeˈliːzabɛt"
    }
  }
}

[lanthaler]

July 10th, 2012 telecon:

[16:36] markus: What should we do about @value's that are not language-tagged?
[16:36] gkellogg: I think it should remain in expanded form.
[16:37] gkellogg: The way that I was proposing it was that the result is to set the language specified in the key as the default language in the context.
[16:37] gkellogg: The other way to do it would be to override the language definition of 'ex' to say that the language is null...
[16:38] niklasl: It's hard to know what X means here.
[16:38] gkellogg: We need to be careful here about how to set xsd:string - it's an RDF 1.1 model issue, so a back-end should implement it this way, though. A plain literal gets the datatype of xsd:string.
[16:39] gkellogg: From RDF Concepts: "A language-tagged string is any literal whose datatype IRI is equal to http://www.w3.org/1999/02/22-rdf-syntax-ns#langString."

[lanthaler]

... and what about when a property with a language container has a value similar to this one:

    {
      "@type": "http://www.w3.org/2008/05/skos-xl#Label",
      "http://www.example.com/deutsch": [ { "@value": "deutsch", "@language": "de" } ],
      "http://www.example.com/english": [ { "@value": "english", "@language": "en" } ],
      "http://www.example.com/italiano": [ { "@value": "italiano", "@language": "it" } ]
   }

What language should be used for the language map? The first one? That might be non-deterministic (properties are not guaranted to be processed in order) if we don't sort them ourselves first.

[niklasl]

For the simple case of creating a language map of various literals it is quite usable. But deep application of @language might make compaction very (too?) complex.

Still, for the given example, we also discussed another variant of expression. It could be more appropriate in this case to use dc:language to describe the bnode itself as being in/about a specific language. That could warrant a generic extension of @context to take any property references as values (as well as the special @set, @list or @language (and possibly @id or @type)). A property using such a construct would then provide mappings for specific property values within the referenced objects.

The corresponding example would be:

{
  "@context": {
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "dc": "http://purl.org/dc/terms/",
    "skosxl": "http://www.w3.org/2008/05/skos-xl#",
    "ipa": "http://dbpedia.org/resource/International_Phonetic_Alphabet",
    "labelByLang": {"@id": "skosxl:prefLabel", "@container": "dc:language"}
  },
  "@id": "http://dbpedia.org/resource/Queen_Elizabeth",
  "labelByLang": {
    "en": {
      "@type": "skosxl:Label",
      "skosxl:literalForm": "Queen Elizabeth",
      "ipa": "kwiːn ʔeˈliːzabɛt əˈlɪzəbəθ"
    },
    "de": {
      "@type": "skosxl:Label",
      "skosxl:literalForm": "Königin Elisabeth",
      "ipa": "ˈkøːnɪɡɪn ʔeˈliːzabɛt"
    }
  }
}

Yielding:

[{
  "@id": "http://dbpedia.org/resource/Queen_Elizabeth",
  "http://www.w3.org/2008/05/skos-xl#prefLabel": [
    {
      "http://purl.org/dc/terms/language": ["en"],
      "@type": "http://www.w3.org/2008/05/skos-xl#Label",
      "http://www.w3.org/2008/05/skos-xl#literalForm": ["Queen Elizabeth"],
      "http://dbpedia.org/resource/International_Phonetic_Alphabet": ["kwiːn ʔeˈliːzabɛt əˈlɪzəbəθ"]
    },
    {
      "http://purl.org/dc/terms/language": ["de"],
      "@type": "http://www.w3.org/2008/05/skos-xl#Label",
      "http://www.w3.org/2008/05/skos-xl#literalForm": ["Königin Elisabeth"],
      "http://dbpedia.org/resource/International_Phonetic_Alphabet": ["ˈkøːnɪɡɪn ʔeˈliːzabɛt"]
    }
  ]
}]

That is, labelByLang in this context would match anything related to via skosxl:prefLabel which itself has a property dc:language. The @container mechanism would create an object map with keys for each value of that property per related resource. It would not match a resource lacking that property or having more than one value for it.

(.. Nor a non-string value? Or we could specify that at least for this generic variant the actual mapped property and value must also be explicitly repeated in the object? It's certainly something to iron out.)

[linclark]

I'm pretty sure that niklasl's proposal above would work for Drupal's multilingual field use case. This would be helpful, since it would mean we wouldn't have to deal with the complexity of named graphs.

[lanthaler]

RESOLVED: Add support for language maps via the "@container": "@language" annotation in @context. For example: "tags": { "@id": "http://example.com/vocab#tags", "@container": "@language"}. The child property of the term MUST be an associative array. All associative array keys MUST be BCP47 language strings.