Framing blank node unnamed graphs

[dlongley]

I'm trying to create an "identity frame" for some data that uses "@container": "@graph". The data looks like this:

{
  "@context": {
    "@version": 1.1,
    "id": "@id",
    "claim": {"@id": "ex:claim", "@container": "@graph"},
    "name": "ex:name",
    "proof": {"@id": "ex:proof", "@type": "@id", "@container": "@graph"},
    "signer": {"@id": "ex:signer", "@type": "@id"},
    "subject": {"@id": "ex:subject", "@type": "@id"},
    "knows": {"@id": "ex:knows", "@type": "@id"}
  },
  "id": "ex:cred",
  "issuer": {
    "id": "ex:issuer",
    "name": "Foo"
  },
  "subject": {
    "id": "ex:subject",
    "name": "the subject",
    "knows": {
      "id": "ex:issuer",
      "name": "Someone else"
    }
  },
  "proof": {
    "@type": "ex:Proof",
    "name": "the proof",
    "signer": {
      "id": "ex:subject",
      "name": "something different"
    }
  }
}

And the frame like this:

{
  "@context": {
    "@version": 1.1,
    "id": "@id",
    "claim": {"@id": "ex:claim"},
    "name": "ex:name",
    "proof": {"@id": "ex:proof", "@type": "@id"},
    "signer": {"@id": "ex:signer", "@type": "@id"},
    "subject": {"@id": "ex:subject", "@type": "@id"},
    "knows": {"@id": "ex:knows", "@type": "@id"}
  },
  "subject": {
    "@embed": "@always"
  },
  "proof": {}
}

A link to the playground is here: http://tinyurl.com/yaewmkk5

The goal is for the output to match the input, but it does not. Does anyone know what tweaks are necessary to accomplish this? Do we have proper support for framing blank node named graphs? From looking at the jsonld.js implementation, it seemed like only non-blank node named graphs were supported... and the spec doesn't seem to give any examples with blank nodes. It seems we have both a spec and an implementation gap here. If not, could someone share a working example?

[gkellogg]

Note that the frame will need to have @graph to start with the default graph, rather than the merged graph.

It should do more than that, although my implementation doesn't quite get there. Use the following frame in my distiller:

{
  "@context": {
    "@version": 1.1,
    "id": "@id",
    "claim": {"@id": "ex:claim"},
    "name": "ex:name",
    "proof": {"@id": "ex:proof", "@type": "@id"},
    "signer": {"@id": "ex:signer", "@type": "@id"},
    "subject": {"@id": "ex:subject", "@type": "@id"},
    "knows": {"@id": "ex:knows", "@type": "@id"}
  },
  "@graph": {
    "subject": {
      "@embed": "@always"
    },
    "proof": {}
  }
}

I get the following output:

{
  "@context": {
    "@version": 1.1,
    "id": "@id",
    "claim": {
      "@id": "ex:claim"
    },
    "name": "ex:name",
    "proof": {
      "@id": "ex:proof",
      "@type": "@id"
    },
    "signer": {
      "@id": "ex:signer",
      "@type": "@id"
    },
    "subject": {
      "@id": "ex:subject",
      "@type": "@id"
    },
    "knows": {
      "@id": "ex:knows",
      "@type": "@id"
    }
  },
  "@graph": [
    {
      "ex:proof": {
        "@graph": [
          {
            "@type": "ex:Proof",
            "name": "the proof",
            "signer": "ex:subject"
          },
          {
            "id": "ex:subject",
            "name": "something different"
          }
        ]
      },
      "id": "ex:cred",
      "subject": {
        "id": "ex:subject",
        "knows": {
          "id": "ex:issuer",
          "name": "Someone else"
        },
        "name": "the subject"
      }
    }
  ]
}

The JavaScript implementation doesn't quite do this, and generates an error in any case using this frame.

I'll need to see why the proof term isn't being used, and why we're not dropping the @graph elements. We also don't embed ex:subject, which needs to be investigated.

The step at 4.4.1 in the Framing Algorithm should handle finding the graph and embed it. It should also work on the merged graph, I think, but doesn't seem to for me. I need to see if these are implementation issues, or if the algorithm is missing something. Help appreciated if you can look at it from your end.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: close framing#27 wontfix, as there’s no justification for the required RDF layer requirement that the blank node identity of the named graph is the default subject of the triples in the graph {: #resolution15 .resolution}

View the transcript

Framing blank node unnamed graphs
Rob Sanderson: ref: #27
Gregg Kellogg: how can SHeX validate verifiable claims?
… there was no reasonable way for SHeX to figure out where to start in that graph to begin validation. Why not just reuse the blank node as the default subject of the graph?
Ivan Herman: I remember, and I am opposed to this.
Rob Sanderson: if it was not a blank node, does the problem go away?
Gregg Kellogg: if it had an identity, it wouldn’t get to this point.
Gregg Kellogg: if you use a graph container, should we use the blank node as the default subject for the graph?
Ivan Herman: that’s semantically wrong.
Rob Sanderson: is this a RDF problem?
Ivan Herman: no. A blank node for the graph and a blank node within the graph are two different things.
Gregg Kellogg: JSON people have a tree-based view, and graphs are not required to have a root.
… so it’s not unreasonable to add a property to indicate in the root.
Gregg Kellogg: this is used in framing, where the top node has a id
Harold Solbrig: I object to bnode, because if there’s not a stake in the ground, having magic to b-nodes…
Gregg Kellogg: fragment identifiers would be a better solution.
Proposed resolution: close framing#27 wontfix, as there’s no justification for the required RDF layer requirement that the blank node identity of the named graph is the default subject of the triples in the graph (Rob Sanderson)
Gregg Kellogg: +1
Rob Sanderson: +1
David Newbury: +1
Ivan Herman: +1
Harold Solbrig: +1!
David I. Lehn: +1
Jeff Mixter: +1
Adam Soroka: +0
Resolution #15: close framing#27 wontfix, as there’s no justification for the required RDF layer requirement that the blank node identity of the named graph is the default subject of the triples in the graph {: #resolution15 .resolution}

[dlongley]

@iherman,

The conversation doesn't seem to apply to this issue but rather to this other one about SHeX and blank node identifier reuse:

w3c/json-ld-api#26

Was the wrong issue closed?

[dlongley]

This issue has to do with a bug in either the framing algorithm or the spec (or both) ... it is unrelated to SHeX or reusing blank nodes with named graph subjects/etc.

[iherman]

@dlongley I just did what the resolution said in the minutes... @azaroth42, has there been a mistake in the minutes?

(I am on my way to the airport, I cannot check it now.)

[gkellogg]

Yes, this is an issue we didn’t discuss and needs to be reopened.

[iherman]

Can somebody send me the changes on the minutes? Better: do the changes?