Problem/Motivation

Drupal wants to use JSON-LD to send messages between the dev and live instances of a site, but also to communicate with outside parties. When communicating with outside parties, a Drupal site would use a vocabulary such as Schema.org, which provides a domain model which basically follows RDF vocabulary common practice. However, some Drupal field types are modeled in a unusual way, which would mean that the external consumer could not use the data.

The full Drupal domain model will be supported in one version of the JSON-LD serialization. However, we want another version of JSON-LD that can be used by outside consumers, and we need a way to map to the outside consumers' domain model.

Literal fields don't match

The Entity API handles literal field values in a way that is inconsistent with common practice for most RDF-ish domain models.

Drupal body field

Schema.org

In the Drupal version, there is an intermediary structure (called a 'blank node' in RDF) for tying all of the related values (value, summary, format) together. For field types such as text and numbers, using a blank node is a unusual way to model the field.

In addition, some fields contain information that is more like configuration (e.g. the format). Most RDF domain models that Drupal sites would want to use do not include this information about literals, or would include it as datatype information.

Other fields DO match

However, for some field types, using an intermediary node does match the RDF way of modeling. An example of such a field is Addressfield.

Drupal Addressfield

Schema.org

Proposed resolution

Microdata module has a way of handling this.

The use of an intermediary blank node can be toggled on and off on a field-by-field basis, using an '#is_item' flag. For example, the '#is_item' flag would be TRUE for the Addressfield, as shown above. If the '#is_item' flag is false, the field properties are directly related to the parent entity, as in the case of the body and summary.

In Microdata module, each field property has to assert that it supports microdata. For example, the 'value' and 'summary' properties of the body field support microdata, but the 'format' does not. This feature from microdata isn't as necessary, since a user could just leave the mapping empty for unwanted field properties.

CommentFileSizeAuthor
#1 1813328-literal-handling__for-testing.patch23.36 KBlinclark
#1 1813328-literal-handling__for-review.txt2.45 KBlinclark
schemaorg-addressfield.png78.72 KBlinclark
drupal-addressfield.png67.2 KBlinclark
schemaorg-literal-body.png45.38 KBlinclark
drupal-literal-body.png51.27 KBlinclark

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Active » Needs review
FileSize
1813328-literal-handling__for-review.txt2.45 KB
1813328-literal-handling__for-testing.patch23.36 KB

I'm attaching a patch for testing that produces the following JSON-LD output. I've removed language handling to make the data model difference clear.

{
    "@id": "http://d8.l/entity_test/1",
    "id_value": 1,
    "uuid_value": "a00eefe6-2446-4234-9c00-c76eedb13c2b",
    "langcode_value": "und",
    "name_value": "This is title",
    "user_id": [
        {
            "value": 1
        }
    ],
    "field_test_text_value": "This is test",
    "field_test_text_format": null
}

The patch for review shows the changes to rdf.module and system.module that enable this. It is unlikely that this is the way we want to do it, but I just wanted to post something that we could start talking about.

Status: Needs review » Needs work

The last submitted patch, 1813328-literal-handling__for-testing.patch, failed testing.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Title: Enable standard literal handling for RDF-ish domain models » Enable literal handling in common RDF-ish domain models

I used the word standard where, for clarity's sake, I really should use common.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Issue summary: View changes

Clarified that this isn't a non-standard, but rather an unusual way to model fields.

scor’s picture

scor CreditAttribution: scor commented
Issue summary: View changes
Status: Needs work » Closed (won't fix)

This issue is outdated now that JSON-LD is no longer in core. The is handled at the field formatter level in RDFa.