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

Framing primitive types vs typed literals #795

Open
MajewskiKrzysztof opened this issue Sep 14, 2022 · 1 comment
Open

Framing primitive types vs typed literals #795

MajewskiKrzysztof opened this issue Sep 14, 2022 · 1 comment

Comments

@MajewskiKrzysztof
Copy link

I have such data as an example:

{
  "http://example.com/test": true,
  "http://example.com/test2": {
    "@value": true,
    "@type": "http://www.w3.org/2001/XMLSchema#boolean"
  }
}

Both of these properties have boolean values. One of them is defined as a primitive type and the other one is a typed literal.

When I convert it to triples I can see that both of them are properly interpreted as xsd:boolean datatypes:

_:b0 <http://example.com/test2> "true"^^<http://www.w3.org/2001/XMLSchema#boolean> .
_:b0 <http://example.com/test> "true"^^<http://www.w3.org/2001/XMLSchema#boolean> .

But when I try to use a frame where I explicitly define both of them as an xsd:boolean:

{
  "@context": {
    "test": {
      "@id": "http://example.com/test",
      "@type": "http://www.w3.org/2001/XMLSchema#boolean"
    },
    "test2": {
      "@id": "http://example.com/test2",
      "@type": "http://www.w3.org/2001/XMLSchema#boolean"
    }
  }
}

only one is recognised:

{
  "@context": {
    "test": {
      "@id": "http://example.com/test",
      "@type": "http://www.w3.org/2001/XMLSchema#boolean"
    },
    "test2": {
      "@id": "http://example.com/test2",
      "@type": "http://www.w3.org/2001/XMLSchema#boolean"
    }
  },
  "http://example.com/test": true,
  "test2": true
}

Why is this happening?

@gkellogg
Copy link
Member

This is not an artifact of framing, but of compaction. Specifically, the term selection algorithm. That algorithm attempts to select the most appropriate term when compacting,p. Terms with at @type generally are there to interpret string values, not other native types such as Boolean. The term selection algorithm echos this bias by not favoring a term having a matching @type in the selection.

Generally, using non-string values short-circuits most special logic for expansion and compaction.

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

No branches or pull requests

2 participants