Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compact does not recognize string default when @type is not provided #466

Open
jaxoncreed opened this issue Jan 23, 2022 · 2 comments · May be fixed by #487
Open

compact does not recognize string default when @type is not provided #466

jaxoncreed opened this issue Jan 23, 2022 · 2 comments · May be fixed by #487

Comments

@jaxoncreed
Copy link

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:rtj@example.com",
        },
      ],
    },
  ];
  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:rtj@example.com' }
  //   }

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
Copy link

ethieblin commented Jun 2, 2022

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants