The initial package registry proposal doesn't spend much time discussing the use of JSON-LD, but it's something I'd like to develop further for the next iteration.
I think this is fundamentally a skill gap and tooling issue. As a community, we aren't familiar with the semantic web or its tech stack. And without an appreciation of the value of encoding information in a knowledge graph, it can feel like overkill compared to a list of key-value pairs.
There are a few different ways to close this gap:
- Intermediate representation, as @Max_Desiatov mentioned
- Tooling, such as:
- An interactive wizard (similar to
npm init) - A validator
- A Swift library or Playground
- An interactive wizard (similar to
- GUI, such as a web form
- Documentation
Of these, I think an intermediate representation has a weaker cost/benefit analysis than some of the alternatives, but yes — it could certainly work. If you do go that route, I'd recommend looking at JSON schema or CUE for examples of how to define and validate this structure.
The question is whether the complexity of something like SoftwareSourceCode is accidental or essential. A few folks have called out the standard as being complex, which is a fair point. However, if that complexity is essential, then you'll find that a solution that starts off as simple will become more complex over time as it fills in the missing pieces.
Validation is something you'll need to do no matter how you encode project information. Better to have an explicit schema and errors than implicit parsing behavior and silent failure. The benefit of plugging into JSON-LD is that it encodes strong, semantic guarantees about the structure of information and comes with existing tooling.