Notice that there is only one top concept, which is a blank node representing an RDF:List not a skosConcept.
I understand that this was intended to maintain the order within concept schemes, but it is the wrong way to do that. If you want to maintain the order of concepts etc. without listIDs you'll have to fall back on JSON lists being ordered; this isn't the way to do it.
The solution is to remove the "@container": "@list" statements from the context file and put something in the handbook saying things should generally be rendered in the order they appear in the JSON (at least in terms of Registry JSON) when no other ordering construct is available.
In the JSON-LD context file, several properties are declared with the
@list
keyword for their@container
, for example:This has unintended consequences. It means that data such as
transforms to the RDF statements
(see this in the JSON-LD playground)
Notice that there is only one top concept, which is a blank node representing an RDF:List not a
skosConcept
.I understand that this was intended to maintain the order within concept schemes, but it is the wrong way to do that. If you want to maintain the order of concepts etc. without listIDs you'll have to fall back on JSON lists being ordered; this isn't the way to do it.
The solution is to remove the
"@container": "@list"
statements from the context file and put something in the handbook saying things should generally be rendered in the order they appear in the JSON (at least in terms of Registry JSON) when no other ordering construct is available.