Breadth first serialization?

[azaroth42]

Current algorithm is to do depth first serialization. The advantage is that the first time a resource is encountered, reading from the top down (note that the key order is processed before the recursion to ensure this). This means that (for example) in a transfer of custody from the current owner, the owner ends up inside the object, and referenced from the top level property.

Consider: https://linked.art/example/activity/44.json

However JSON objects are unordered. The serialization is entirely dependent on our OrderedDict / key order hack. It's suitable for humans (aka developers) but when it comes to writing code to find the description of the (e.g.) owner, in the context of a transfer of custody, I would expect it to be in the transferred_custody_from field, not embedded in transferred_custody_of.current_owner.

So ... I propose a change to breadth first serialization. Walk through all of the properties of the current object and record new things to serialize. Then step back and serialize them if needed. More complex in the code as it's not just recursive descent, but the end result I think will be better.

Thoughts @alyxrossetti @joshuago78 @workergnome?

[alyxrossetti]

Despite the fact that it sounds a little daunting to make the switch, I completely agree with the thoughts outlined above @azaroth42

[workergnome]

At what point is this just re-implementing the JSON-LD Framing algorithm?

Or am I misinterpreting what you're trying to do here?

[azaroth42]

What I'm trying to accomplish is a baseline serialization routine that produces a good-enough JSON document, readable by humans and machines without specifying a bunch of per-class frames.

Framing would be another way to do it, but getting the human readable side to work at the same time (e.g. ordering the keys, etc) would be even more complicated. Also ... going from object structure to JSON is easy, rather than object structure to graph to nquads to json-ld via frames :)