Problem/Motivation

JSON-LD is closely aligned with RDF. This leads to the assumption that you can easily move from RDF to JSON-LD and back. However, as explained in a g.d.o. post, the way we want to handle data doesn't neatly map to the RDF data model.

The JSON-LD WG encouraged us to use the language maps proposal and has been working with us to ensure it meets our requirements. An example serialization using language maps was developed at DrupalCon Munich.

The problem is that in RDF, you can't have different entity references based on language.

In JSON-LD, we would have:

"@id": "node/1",
"tags": {
    "de": [
      {
        "@id": "http://example.com/taxonomy/term/1"
      },
      {
        "@id": "http://example.com/taxonomy/term/2"
      }
    ],
    "en": [
      {
        "@id": "http://example.com/taxonomy/term/1"
      }
    ]
}

Based on discussions with Manu about how this would be processed, it would result in the following:

site:node/1 site:tags site:term/1
site:node/1 site:tags site:term/2

There would be no distinguishing between the values that apply to the English version and the values that apply to the German version.

I personally think this is OK. Most people will be using the object in its JSON form, without ever needing to convert it to a different RDF syntax. Even if they do flatten to RDF, the data that is lost is minimal. I believe the complexity of other options outweighs the benefit. I would be happy to discuss the options, though, if anyone is concerned about this.

Proposed resolution

JSON-LD with language maps gives us all of the benefits of RDF, plus the additional language version handling we need, without adding complexity for the end-user developer.

I believe we should accept this limitation and document it.

Remaining tasks

Discuss and decide.

Comments

Anonymous’s picture

Anonymous (not verified) commented
Issue tags: +json-ld

Forgot to tag.

fago’s picture

fago
Primary language German
Location Vienna
commented

Yeah, having a RDF serialization that works with languages as well would be nice, but we really should focus on getting our main use-cases right. If RDF falls apart, we can still do a separate RDF mapping for that I guess.. (also see http://drupal.org/node/1797210#comment-6536394)

scor’s picture

scor commented

I don't think this is a big deal. Drupal doesn't rely on RDF as a canonical representation of its data to function anyways. I have yet to see a real world examples of this lossiness occurring in the wild. Note that RDF can support text translations, it's only the relations between entities which are not supported. So for this edge case to happen, first, the site needs to use translation, and then when creating a translation, the person translating actually has to remove or add relations (e.g. node or term reference) which are not part of the other translations. In my opinion, translations should be as close as possible to the data model it is being translated from (I'm emphasizing data model here, not the actual pieces of text can be translated and expressed in RDF). I understand there are exeptions, but how common are they?

Let's take common situation where a node in English is tagged with the term "dog", and someone wants to translate it in French. It would be a problem if that person was to create a new term for the tag in French "chien", but from an information architecture standpoint, the best practice should be to reuse the existing term and translate it into French, so that you end with the following JSON-LD:

"@id": "node/1",
"tags": {
    "de": [
      {
        "@id": "http://example.com/taxonomy/term/1"
      },
    ],
    "en": [
      {
        "@id": "http://example.com/taxonomy/term/1"
      }
    ]
}

This use case is very common I think and supported by RDF (all the translations would have the same relation
tags <http://example.com/taxonomy/term/1>.

If someone wanted to stick to the RDF capabilities only, it should be possible to write a module in contrib to "force" the entity property API to share all properties across languages, which is essentially what RDF forces you to do, except that this would be made explicit at the UI level by the module.

In a nutshell, as long as this limitation is documented somewhere, this is not a blocker and not something core should worry about.

Anonymous’s picture

Anonymous (not verified) commented
Title: Decide whether slight lossiness of JSON-LD <-> RDF transformation is acceptable » Document the slight lossiness of JSON-LD <-> RDF transformation
Status: Active » Postponed
Issue tags: +Needs documentation

Great, it seems we are agreed on this.

I'm going to mark this as postponed, Needs Documentation. We can come back through and add it to the docs once we have a module.

Anonymous’s picture

Anonymous (not verified) commented
Status: Postponed » Closed (works as designed)

As I had somewhat expected, it seems the RDF WG has told the JSON-LD CG that language maps must round trip to RDF. This would require all sorts of contortions in the data which would make them no longer work for us. For example, with one proposal we wouldn't be able to use Schema.org terms without violating its range constraints.

As such, the language maps proposal simply does not work for us anymore... good news is, we don't have to document the lossiness anymore.