Confusion regarding @default and @embed in JSON-LD 1.1?

[cboettig]

In this json-ld playground example I believe the 5 @ids for the char property used to be returned given the displayed frame under JSON-LD 1.0 spec, but are dropped under the current spec for reasons I don't entirely understand. I think this has to do with the changed behavior of omitGraph? I am not sure how to update my frame.

I believe the reason has to do with duck typing and the presence of the states property under char in my frame. In this data, I'm not able to declare a specific type for the char object, which can sometimes contain the states property. I need the frame to assert that if it has the states property, it should use "@embed": "@never" so I cannot simply omit that assertion; even though that would in this example allow the char ids to display. I'd greatly appreciate clarification on the possible change in behavior between the spec and the best/right way to address the issue in this example.

[dlongley]

I think this is just a bug in the jsonld.js implementation:

https://github.com/digitalbazaar/jsonld.js/issues/323

I propose we close and fix it over there. If the fix results in any other tests breaking we can raise a new issue.

[gkellogg]

It doesn't match because the Frame Matching Algorithm doesn't match any of the nodes which are a part of "char".

Consider a simplified use case (playground link):

Input:

{
  "@context": {
    "@base": "http://example.org/",
    "@vocab": "http://example.org/vocab#",
    "@version": 1.1
  },
  "characters": {
    "@id": "m3",
    "@type": "ContinuousCells",
    "label": "Continuous characters",
    "format": {
      "char": [
        {
          "@id": "ContinuousCharacter1",
          "label": "this is character 1"
        },
        {
          "@id": "ContinuousCharacter2"
        },
        {
          "@id": "ContinuousCharacter3"
        },
        {
          "@id": "ContinuousCharacter4"
        },
        {
          "@id": "ContinuousCharacter5"
        }
      ]
    }
  }
}

Frame:

{
  "@context": {
    "@base": "http://example.org/",
    "@vocab": "http://example.org/vocab#",
    "@version": 1.1
  },
  "characters": {
    "format": {
      "char": {
        "states": {
          "@default": {}
        }
      }
    }
  }
}

In this case, we have the sub-frame {"states": {"@default": {}}}, with each of the inputs with id "ContinuousCharacter?".

The algorithm matches if it has no properties (it has properties, @id), @type matches (no @type), or any property which isn't a keyword matches (only "ContinuousCharacter1" has a property, so it matches).

To get them to match you would need to add "@id": {} to wildcard match each node having an @id. With the updated frame it should work:

{
  "@context": {
    "@base": "http://example.org/",
    "@vocab": "http://example.org/vocab#",
    "@version": 1.1
  },
  "characters": {
    "format": {
      "char": {
        "@id": {},
        "states": {
          "@default": {}
        }
      }
    }
  }
}

It does work in my implementation, but doesn't in jsonld.js, which is a bug there.

The expected result is:

{
  "@context": {
    "@base": "http://example.org/",
    "@vocab": "http://example.org/vocab#",
    "@version": 1.1
  },
  "characters": {
    "@id": "m3",
    "@type": "ContinuousCells",
    "label": "Continuous characters",
    "format": {
      "char": [{
        "@id": "ContinuousCharacter1",
        "label": "this is character 1",
        "states": {}
      }, {
        "@id": "ContinuousCharacter2",
        "states": {}
      }, {
        "@id": "ContinuousCharacter3",
        "states": {}
      }, {
        "@id": "ContinuousCharacter4",
        "states": {}
      }, {
        "@id": "ContinuousCharacter5",
        "states": {}
      }]
    }
  }
}

The matching behavior may be different to that before, but that was never standardized.

[cboettig]

Thanks @gkellogg, that makes sense. The expected result as shown by your implementation looks good!

I had actually tried adding an "@id": {} to char but as you note, no look on the jsonld.js implementation in playground (which is also what I'm using via R).

[cboettig]

@gkellogg I'm still not getting the expected behavior you document in https://github.com/w3c/json-ld-framing/issues/58#issuecomment-518872021 when I try your example at https://json-ld.org/playground/ . What's the process for #62 to show up in the playground instance?

[gkellogg]

The playground is not up to date, and is being worked on to conform. You might try http://rdf.greggkellogg.net/distiller, which is more up to date.

[cboettig]

@gkellogg Wow, thanks Gregg. Everything is work exactly as expected when I use your version! This resolves a good handful issues I have been having with framing elsewhere.

In my use cases I'm mostly calling against the R bindings @jeroen has written to the javascript library (e.g as linked above). I think we'll just need to point that to the latest version of the 1.1. jsonld.js library -- what's the canonical location for the up-to-date js source?

[jeroen]

For R we need a single JS bundle transpiled to ES5 (many servers run an old version of V8).

[davidlehn]

@cboettig jsonld.js is at https://github.com/digitalbazaar/jsonld.js. It's in the process of being updated to latest 1.1 spec. We'll be rolling out releases, and updating the playground, as features get finished. You can check the test runner for skipped tests now. We'll get a test conformance report out soon, I think, so people can more easily follow progress.

@jeroen Feel free to bring up issues over on the jsonld.js project. Not sure if the default bundle goes back to pure ES5. Newer V8 performance is much much better. Benchmarking reports are a work in progress.

[cboettig]

Thanks @davidlehn, really appreciate it! It's wonderful how supportive and helpful Gregg and the rest of your community has been with all this. (From what I can tell, the travis logs there do seem to be running the test added in #62; https://travis-ci.org/digitalbazaar/jsonld.js/jobs/585843847#L1412, so I take that as a good sign it's already got the fix!).

@jeroen Do you think you can bundle this into the R package? Guess we can continue the discussion over at https://github.com/ropensci/jsonld/issues/17

[jeroen]

I have opened a PR that upgrades the R bindings to to jsonld.js 1.8.0: https://github.com/ropensci/jsonld/pull/18. Can you test if this works for you?

[cboettig]

@dlongley @gkellogg Using the 1.8 release from https://cdnjs.com/libraries/jsonld, I still get the same bug documented above (which I also see on the Playground but is all resolved on Gregg's http://rdf.greggkellogg.net/distiller. Perhaps I've done something wrong, or are there any other pointers to where we can get the sources where this has been fixed? Or should we just sit tight and this'll work it's way into the pipes?

[davidlehn]

@cboettig The distiller is using a server side ruby library, https://github.com/ruby-rdf/json-ld, and the playground is using a client side javascript library, https://github.com/digitalbazaar/jsonld.js. Unless you want to help port over fixes, you may have to wait. @gkellogg is in the process of helping to port over the ruby fixes to js and py. We'll get them released as soon as we can.

[cboettig]

@davidlehn Thanks for the explanation, that makes sense! We'll keep an eye out then and thanks again for all you folks are doing.