infinite recursion in @reverse properties

[gkellogg]

From json-ld/json-ld.org#653

It would be nice to have the same possiblity of infinite recursion in the @reverse properties as there are in non-reverse ones (example), currently recursion only works as many times as the frame defines it (example).

Copy/pasting the examples (and removing @contexts):

in the working case, I have

{
  "@graph": [
    {
      "@id": "bdr:O9TAXTBRC201605",
      "@type": "Taxonomy",
      "taxHasSubClass": [
        {
          "@id": "bdr:O9TAXTBRC201605_0001"
        },
        {
          "@id": "bdr:O9TAXTBRC201605_0010"
        }
      ]
    },
    {
      "@id": "bdr:O9TAXTBRC201605_0001",
      "@type": "Taxonomy",
      "taxHasSubClass": {
        "@id": "bdr:O9TAXTBRC201605_0002"
      }
    },
    {
      "@id": "bdr:O9TAXTBRC201605_0002",
      "@type": "Taxonomy"
    },
    {
      "@id": "bdr:O9TAXTBRC201605_0010",
      "@type": "Taxonomy"
    }
  ]
}

and frame

{ 
  "@id" : "bdr:O9TAXTBRC201605",
  "@context" : {
    "children": { "@reverse": "http://purl.bdrc.io/ontology/core/taxSubclassOf" }, 
    "taxSubclassOf" : {
      "@id" : "http://purl.bdrc.io/ontology/core/taxSubclassOf",
      "@type" : "@id"
    },
    "@vocab" : "http://purl.bdrc.io/ontology/core/",
    "bdr" : "http://purl.bdrc.io/resource/"
  }
}

that produces the nice

{
  "@graph": [
    {
      "@id": "bdr:O9TAXTBRC201605",
      "@type": "Taxonomy",
      "taxHasSubClass": [
        {
          "@id": "bdr:O9TAXTBRC201605_0001",
          "@type": "Taxonomy",
          "taxHasSubClass": {
            "@id": "bdr:O9TAXTBRC201605_0002",
            "@type": "Taxonomy"
          }
        },
        {
          "@id": "bdr:O9TAXTBRC201605_0010",
          "@type": "Taxonomy"
        }
      ]
    }
  ]
}

but for the opposite:

{
  "@graph": [
    {
      "@id": "bdr:O9TAXTBRC201605",
      "@type": "Taxonomy"
    },
    {
      "@id": "bdr:O9TAXTBRC201605_0001",
      "@type": "Taxonomy",
      "taxSubclassOf": "bdr:O9TAXTBRC201605"
    },
    {
      "@id": "bdr:O9TAXTBRC201605_0002",
      "@type": "Taxonomy",
      "taxSubclassOf": "bdr:O9TAXTBRC201605_0001"
    },
    {
      "@id": "bdr:O9TAXTBRC201605_0010",
      "@type": "Taxonomy",
      "taxSubclassOf": "bdr:O9TAXTBRC201605"
    }
  ]
}

and the frame

{
  "@id": "bdr:O9TAXTBRC201605",
  "@context": {
    "children": {
      "@reverse": "http://purl.bdrc.io/ontology/core/taxSubclassOf"
    },
    "taxSubclassOf": {
      "@id": "http://purl.bdrc.io/ontology/core/taxSubclassOf",
      "@type": "@id"
    },
    "@vocab": "http://purl.bdrc.io/ontology/core/",
    "bdr": "http://purl.bdrc.io/resource/"
  },
  "children": {}
}

I'm not getting all the recursion, only

{
  "@graph": [
    {
      "@id": "bdr:O9TAXTBRC201605",
      "children": [
        {
          "@id": "bdr:O9TAXTBRC201605_0001",
          "@type": "Taxonomy",
          "taxSubclassOf": "bdr:O9TAXTBRC201605"
        },
        {
          "@id": "bdr:O9TAXTBRC201605_0010",
          "@type": "Taxonomy",
          "taxSubclassOf": "bdr:O9TAXTBRC201605"
        }
      ],
      "@type": "Taxonomy"
    }
  ]
}

[azaroth42]

👍 to the use case. Have you tried implementing a solution to this, @gkellogg ?

[gkellogg]

I generally implement things before considering a specification update, and I'll take a look, in due course. (Unless, of course @dlongley or @davidlehn beat me to it!).

[azaroth42]

Resolution on the WG call of 2018-09-14 was to accept this issue as valid and valuable, and to seek additional implementation experience for potential solutions.

[gkellogg]

So, this ends up running afoul of the general framing algorithm. When framing a property with a node value, it looks for a frame associated with the property, if there is none, it constructs one using @embed, @explicit and @requireAll:

From Framing 4.4.2.3.2:

... If frame does not exist, create a new frame using a new dictionary with properties for @embed, @explicit and @requireAll taken from embed, explicit and requireAll.

The requested logic would require us to construct a new frame based on properties of the existing frame, which could have wide implications.

The best we can do without radical changes would be to make the sub-frames explicit (playground):

{ 
  "@context" : {
    "@vocab" : "http://purl.bdrc.io/ontology/core/",
    "taxSubclassOf" : {
      "@id" : "http://purl.bdrc.io/ontology/core/taxSubclassOf",
      "@type" : "@id"
    },
    "bdr" : "http://purl.bdrc.io/resource/",
    "children": { "@reverse": "http://purl.bdrc.io/ontology/core/taxSubclassOf" }
  },
  "@id" : "bdr:O9TAXTBRC201605",
  "children": {
    "children": {
      "children": {}
    }
  }
}

This generates the following, with backwards and forwards links:

{
  "@context" : {
    "@vocab" : "http://purl.bdrc.io/ontology/core/",
    "taxSubclassOf" : {
      "@id" : "http://purl.bdrc.io/ontology/core/taxSubclassOf",
      "@type" : "@id"
    },
    "bdr" : "http://purl.bdrc.io/resource/",
    "children": { "@reverse": "http://purl.bdrc.io/ontology/core/taxSubclassOf" }
  },
  "@id" : "bdr:O9TAXTBRC201605",
  "children": [{
    "@id": "bdr:O9TAXTBRC201605_0001",
    "@type": "Taxonomy",
    "taxSubclassOf": "bdr:O9TAXTBRC201605",
    "children": {
      "@id": "bdr:O9TAXTBRC201605_0002",
      "@type": "Taxonomy",
      "taxSubclassOf": "bdr:O9TAXTBRC201605_0001"
    }
  }, {
    "@id": "bdr:O9TAXTBRC201605_0010",
    "@type": "Taxonomy",
    "taxSubclassOf": "bdr:O9TAXTBRC201605"
  }]
}

(Note that unused repetitions of "children" are ignored if there are no children).

This seems like an acceptable solution to me requiring no change.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Add a note to the framing spec about the asymmetry, and longer explanation with examples in the primer document for issue framing#5 on @reverse recursion

View the transcript

3.1. Infinite @reverse framing recursion (Gregg’s findings)
Rob Sanderson: link: #5
Gregg Kellogg: raises question about framing design criteria
… if there is no frame to be matched, algo constructs one
… so if you have something that infinitely recurses on @reverse, would mean a change to algo
Gregg Kellogg: #5 (comment)
Gregg Kellogg: solution suggested in my latest comment is to use frame as really intended
… you would create necessary children finitely
Rob Sanderson: does this mean it works any differently for @reverse?
Gregg Kellogg: not really. In the absence of a property in the reverse it would create it.
Rob Sanderson: so if wanted to be explicit in the non-reverse direction you would just ???
Gregg Kellogg: no change, but describe behavior / example in primer
Rob Sanderson: questions?
Rob Sanderson: s/???/include them explicitly in the frame, the same as for @reverse/
Rob Sanderson: if not, how do we want to resolve? example in spec or note in primer?
Benjamin Young: willing to take a crack at what should go into primer
Adam Soroka: agree
Rob Sanderson: a note in the spec and then a longer discussion in primer?
Proposed resolution: Add a note to the framing spec about the asymmetry, and longer explanation with examples in the primer document for issue framing#5 on @reverse recursion (Rob Sanderson)
Gregg Kellogg: +1
Rob Sanderson: +1
Benjamin Young: +1
Ivan Herman: +1
Tim Cole: +1
Adam Soroka: +1
Simon Steyskal: +1
Jeff Mixter: +1
Rob Sanderson: +1
Benjamin Young: +1
Resolution #2: Add a note to the framing spec about the asymmetry, and longer explanation with examples in the primer document for issue framing#5 on @reverse recursion

[azaroth42]

Moved to Editorial given Resolution above.