astool tool improvement idea: @context alias normalization

[cjslep]

It remains to be seen how the community of not-really-linked-data implementations (which includes go-fed right now) will handle ActivityPub extensions.

For example, will types be like:

{
  "@context": [
    "https://example.com/issues"
  ],
  "type": "Issue"
}

or

{
  "@context": {
    "ex": "https://example.com/issues"
  },
  "type": "ex:Issue"
}

Right now the behavior is: We set the alias to a literal known at code generation time. We don't expect others to use aliases. That's it.

So one idea is to code-generate the stuff that will be able to handle normalizing any aliases already in a payload (when adding new things), or setting it to a code-generation-time known default (if no alias has previously been used).

It's possible an entirely different solution is needed.

This is also a wider ActivityPub community convention question, one we haven't faced (yet).

[ppwfx]

Hey cj,

I worked on this half a year ago. I used github.com/piprate/json-gold/ld for it. It returns a list of normalized triples, that can map onto your structs.

At point I got really pissed about json-ld tho, when I discovered that the following is valid json-ld.

{
  "@context": {
    "ex": "https://example.com/issues"
  },
  "type": "ex:Issue",
  "type": "Issue"
}

Meaning, in order to become fully json-ld compliant each struct field needs to be a slice.

[ppwfx]

It's https://github.com/21stio/go-rdfgen, if you want to have a look

[cjslep]

Thanks @ppwfx!

Also, note to self, this issue at code-generation time is the equivalent to what I thought I could do at runtime in issue https://github.com/go-fed/activity/issues/113 (which it can't, so that one is closed).