`compact` does not recognize string default when @type is not provided

[jaxoncreed]

In the following example:

  const inputData: JsonLd = [
    {
      "@id": "http://a.example/Employee7",
      "http://xmlns.com/foaf/0.1/givenName": [
        {
          "@value": "Robert",
        },
        {
          "@value": "Taylor",
        },
      ],
      "http://xmlns.com/foaf/0.1/familyName": [
        {
          "@value": "Johnson",
        },
      ],
      "http://xmlns.com/foaf/0.1/mbox": [
        {
          "@id": "mailto:[email protected]",
        },
      ],
    },
  ];
  const inputContext: ContextDefinition = {
    givenName: {
      "@id": "http://xmlns.com/foaf/0.1/givenName",
      "@type": "http://www.w3.org/2001/XMLSchema#string",
      "@container": "@set",
    },
    familyName: {
      "@id": "http://xmlns.com/foaf/0.1/familyName",
      "@type": "http://www.w3.org/2001/XMLSchema#string",
    },
    phone: { "@id": "http://xmlns.com/foaf/0.1/phone", "@container": "@set" },
    mbox: { "@id": "http://xmlns.com/foaf/0.1/mbox" },
  };
  const compactJsonLd = await compact(inputData, inputContext);
  console.log(compactJsonLd);

  // Logs:
  // {
  //     '@id': 'http://a.example/Employee7',
  //     'http://xmlns.com/foaf/0.1/familyName': 'Johnson',
  //     'http://xmlns.com/foaf/0.1/givenName': [ 'Robert', 'Taylor' ],
  //     mbox: { '@id': 'mailto:[email protected]' }
  //   }

Notice that "familyName" and "givenName" are not transformed. This is probably because these fields both of the @type http://www.w3.org/2001/XMLSchema#string. Setting the @type in the input data does not cause this problem. But, you shouldn't be required to provide a @type for strings as http://www.w3.org/2001/XMLSchema#string should be assumed if no type has been provided.

[ethieblin]

I have the same issue when trying to round-trip from a framed JSON-LD to RDF and from the produced RDF to a framed JSON-LD.

{
  "@context": {
    "td": "http://example.org/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "title": {
      "@id": "td:title",
      "@type": "xsd:string"
    },
    "@language": "en"
  },
  "@id": "urn:something",
  "title": "the title"
}

The xsd:string typing in RDF is omitted as it is considered the default type which is fine.

<urn:something> <http://example.org/title> "the title" .

playground toRDF

When transforming the RDF data to JSON-LD again, we get

[
  {
    "@id": "urn:something",
    "http://example.org/title": [
      {
        "@value": "the title"
      }
    ]
  }
]

And when trying to frame back the data with the same context, we get

{
  "@context": {
    "td": "http://example.org/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "title": {
      "@id": "td:title",
      "@type": "xsd:string"
    },
    "@language": "en"
  },
  "@id": "urn:something",
  "td:title": {
    "@value": "the title"
  }
}

playground framing with original context

It seems that the presence of "@type":"xsd:string" prevents the "title" term to be matched and framed

[davidlehn]

I haven't had the time to look into this. Some of the rules around these things are a bit nuanced and the behaviors may be intentional for one reason or another. I would ask that you please file issues on https://github.com/w3c/json-ld-api and/or https://github.com/w3c/json-ld-framing to clarify what the behavior should be. If the behavior of this implementation is incorrect, we'll need fixes, but there needs to be tests added to the main test suites so all implementations have the same behavior. There may be a need for more documentation to avoid confusion, positive tests, and negative tests.