Generating a default context?

[iherman]

It is possible to come up with the generation of a simple @context file for a generated vocabulary. This would not aim to be the final and best @context file in the sense that a human curation to improve the vocabulary might be necessary, but it gives a first version. For many, simple vocabularies, it may just be good enough.

Here is, roughly, how it could be constructed

• includes the basic idiomatic mappings like id->@id,
• for each class defined in the vocabulary
  • add, of course, the mapping to its ID
  • collect all properties defined in the vocabulary, defined with a domain on that class into an embedded context
• list all properties with no domain as part of the "top level" context
• each property, whether embedded or not, would contain the mapping to its ID and, possibly the range translation into a type.

The yml format may be extended to include an extra field for "container", to allow for containers like graphs for some properties.

At least in the VC area, if end users want to use JSON-LD, they are required to produce a @context file. If this mapping is added to the mix, they could define the vocabulary using YAML, which may be more user-friendly, and generate all the necessary files for deployment (more) easily.

@msporny @dlongley @OR13 @mprorock WDYT?

[msporny]

I think this is an excellent idea. People have always complained that it was difficult to build a JSON-LD Context. If we give them a good starting place, this will make things easier for the ecosystem.

[iherman]

Ok, I will do it at some point. (It is not a huge job, the overall structure is there.) One thing I will probably not do, at least not in the first round, is the inclusion of a container setting. Although it is easy to do the right thing if the container is a graph, I am not sure what to do with other possibilities (eg, lists). Maybe I can simply add the possibility for a graph only; that may be important in the VC world and that is the easy case.

If this issue comes up during the discussion (and it may well come) then you can refer to this issue...

[OR13]

We generate the traceability context from a folder of annotated Open API specification 3 schemas using this tool :

https://github.com/transmute-industries/verifiable-data/blob/main/packages/jsonld-schema/README.md

https://w3c-ccg.github.io/traceability-vocab/#open-api

[iherman]

@OR13 that is fine if a developer starts with a JSON Schema. This tool is more centered on developers around the JSON-LD/RDF world, who are required to create a bona fide RDF vocabulary in the first place.

I believe that, in view of the JSON-LD controversy, the more the merrier in terms of such tools...

[OR13]

I am in favor of generating vocabularies (and contexts) from YAML, if that is the question asked.

[iherman]

Well, this was actually fairly easy to do, using all the various things and data that were already in the library, see #7.

I would not use it to generate a @context file for something like the security or the credential vocabularies. Both of those vocabularies include extra things that are better curated by hand, not the list that (e.g., the credential context) combines terms from different vocabularies (which is the thing to do, of course). But this new feature may be useful for simple vocabularies in the VC application area.

Actually... does any of you have a relatively simple but real example at hand for a vocabulary that is used in the VC world as an extra vocabulary? I would be happy to see whether converting that into yaml is easy or not, and whether the generation of the various files is indeed satisfactory. You know, the way to test the pudding...