Updated test results for JSON-LD-star

[gkellogg]

(other than annotation folding).

This diverges from the existing spec behavior.

Fixes #49.

[gkellogg]

I wanted to get this out there even though it's not finished, and there are no corresponding spec changes. I haven't done the optional @annotation re-construction in some flatten tests, and the fromRdf tests will need to invoke that solution as well.

There may be some differences in opinion on what the results should look like, particularly for reifications of multiple triples. Also, the use of explicit reifiers is limited. right now..

[pchampin]

I have only reviewed 'compact' and 'expand' so far. Generally LGTM, with a few questions though.

[gkellogg]

Synopsis of algorithm updates:

Expansion Algorithm

• If output object is a triple term (an object containing an @triple key) verify that the only keys in that object are @triple and @annotation.
• When processing each key/value in the input:
  • If expanded property is @annotation, the expanded value is the result of expanding that value, using @annotation as the active property.
  • If expanded property is @reifies:
    • expand value as an array called rei nodes, using null as active property.
    • for each rei node in rei nodes, count the triples generated by calling the Object to RDF Algorithm on that node to verify the no more than one statement is generated.
    • The result is the expanded value as an array using @reifies as the active property.
  • If expanded property is @triple:
    • expand value to tt node, using null as active property.
    • count the statements generated by calling the Object to RDF Algorithm on that node to verify the no more than one triple is generated.
    • tt node must not include the @reverse or @triple keys.
    • The result tt node.
• Before processing nests, if the output object includes @triple, ensure that it includes no keys other than @triple and @annotation.

Compaction Algorithm

• If expanded property is @id, its value can no longer be an object, so text reverts to base JSON-LD 1.1
• Adds entry for expanded property being @triple, which compacts the triple object and returns it.

Flattening Algorithm

• If element is a value object, see if it includes an @annotation key. If so:
  • Remove the @annotation key using the value as annotation
  • construct reification as a new object with @id set to active subject, and active property set to an array containing element.
  • For each annotation:
    • set reifier to the @id key from that annotation, or a new blank node, if there is no such entry.
    • Add key entries for @id and @reifier taken from reifier and reification, respectively.
    • Create an entry in graph map using active graph, and reifier for active subject
• If element is a triple term, see if it includes an @annotation key. If so:
• Remove the @annotation key using the value as annotation
• construct reification as a new object with @id set to active subject, and active property set to an array containing element.
• For each annotation:
  • set reifier to the @id key from that annotation, or a new blank node, if there is no such entry.
  • Add key entries for @id and @reifier taken from reifier and reification, respectively.
  • Create an entry in graph map using active graph, and reifier for active subject
• Use add value to add element as an active property to subject node. (element will only contain @triple).
• Otherwise, element is a node object:
  • Process annotations as above, creating a @reifies entry in node, using element without the @reifies key.

Create Annotations

• Foreach entry in node map having a @reifies key, and for each such value node:
  • set reif id do the value of @id in node.
  • set reifs to the value of @reifies in node. (It must be an array).
  • Set annotation to the a copy of node excluding @id and @reifies.
  • For each reif in reifs:
    • set target id to the value of @id in _reif`.
    • set target node to the entry in node map for target id.
    • If there is no such node, continue to the next reif.
    • set reif prop to the only key in reif other than @id (error if not found)
    • set reif values to the value of reif key in reif, which must be an array with a single entry.
    • set reif value to the only entry in reif values.
    • set target values to the value of reif prop in target node, continuing to the next reif if there are no such values.
    • It is an error if target values is not an array.
    • For each target value in target values
      • Continue to the next target value unless target value exclusive of @annotation is equal to reif value
      • Use add value to add a copy of annotation with @id set to reif id as an @annotation to target value.
      • remove reif from @reifies in node.
  • If the value of @reifies in node is empty, remove that entry from node.

Serialize RDF as JSON-LD Algorithm

• if predicate is rdf:reifies and object is a triple term:
  • set reifiecation to the JSON-LD representation of the triple term and merge the resulting value of @triple into node using the @reifies key.

Object to RDF Algorithm

• If item is a triple term, return the result of using this algorithm on the value of @triple
• When processing each property and _value) in item:
  • If proeprty is @reifies, call this algorithm recursively on each such value, where each resulting triple is treated as a triple term resource.

[w3cbot]

This was discussed during the #json-ld meeting on 04 June 2025.

View the transcript

json-ld/json-ld-star#61

<gb> Pull Request 61 Updated test results for JSON-LD-star (by gkellogg)

gkellogg: this is another call for review of this one
… I do see some feedback from pchampin and he's done a partial review
… the goal is to update JSON-LD-star to catch-up with where RDF 1.2 is
… so, rather than updating the spec, I've updated the tests
… and put in an abbreviated summary of what the changes would be
… so once that's approved, we can work on spec text changes

bigbluehat: these will need to be <ins>/<del> denoted changes?

gkellogg: no, this is on json-ld-star which is a CG report
… so this doesn't disrupt that
… there will, however, be needed work to merge the json-ld-star stuff into the main json-ld-syntax

dlehn: ...there are a lot of test files...

gkellogg: yeah...we're heavy on files
… and maybe a rework would take a different approach
… but as monumental a task as that would be, we're likely better off sticking with what we have now
… I would, however, like to annotate our spec pointing back to the tests
… I've done it elsewhere, but it'd be great here
… YAML-LD does that
… thanks to a push by ivan who did that for publishing WG

<TallTed> *cheers* for the gradual annotating / crosslinking

niklasl: I prefer to work like this than update the algorithms; it's easier for me.
… It would be catagorize tests with those that are more useful.

dlehn: Ordering would be nice, but tagging might be appropriate.

gkellogg: ideally every normative statemen links back to their tests
… but it can be challenging

ivan: We did it for ePub and it turned out to be extremely useful.
… When we had to report back on the PR, we could easily prove that we had a proper test suite.
… It's a heavy setup; The WebAPI people did it well, but I had to add some scripts to address assumptions in ReSpec.

gkellogg: I've been copying pasting from what you've been doing
… there's now a script that does much of the work for me
… it can identify the tests and make links back
… and it can be done asynchronously
… a test repo can iterate separately from the spec
… we have at least 3 specs here and each have their own test suites
… but maybe we could merge them

---