Best practices for maintaining list order w/o collections.

[hsolbrig]

What is the best approach if one needs to maintain JSON list order, but does not want to use the LISP-like RDF Collections idiom? Should the ordering information be added to the JSON before conversion? Are there any tricks / tools for post-conversion flattening?

[hsolbrig]

One post-conversion flattening trick that we've used a bit is: https://github.com/hsolbrig/CFGraph

[iherman]

@hsolbrig I am not sure I understand the question. I have the impression, though, that your question is an RDF one and not a JSON-LD one.

There is no other syntactic construct in RDF, but I presume you know that. Schema.org introduced some construct: ListItem-s with a position property, and an itemListElement to contain them as a whole.

I am not sure whether we should add this to the best practices document. My initial feeling is that the answer is 'no', because this is the usage of a particular vocabulary.

[ajs6f]

I think it's legitimate to raise a question about an Issue in RDF for this doc, exactly when it seems likely that prospective users of JSON-LD will run into that issue, and goodness knows that ordered lists are very much such an issue. That's not to say that I think we can do a lot with it (and I agree that calling out to schema.org would not be appropriate) but it might be reasonable to mention RDF Collections, to mention that other solutions are in use, and frankly, to admit that this is a problem area and requires careful attention to work well.

[iherman]

@ajs6f that is a slippery slope. From RDF point of view this spec is a serialization. It is not up to this spec to go into listing the possible problems in RDF. The issue with collections is one, why stop there?

[ajs6f]

@iherman This is not a spec doc, to my understanding. It is a discussion of best practices that accompanies the spec. And for my money, we have the right to discuss in it whatever might be a problem for someone using JSON-LD to semantically enable an API (or other use case).

Consider #24. Isn't that just as slippery a slope? Why not give examples for nginx, too?

[iherman]

Oops, my mistake. For some reason, I thought this was an issue on the syntax document! Sigh, I am getting not only old but also stupid:-(

Yes. For the best practices document something would be appropriate and, actually, I would not even be shocked to refer to the schema.org approach as an example of what can be done.

That being said: coming back to the original question of @hsolbrig : JSON-LD can hide this ugliness pretty well:

{
    "@context" : {
        "isa" : {
            "@id" : "https://www.example.org/isa",
            "@container" : "@list"
        }
   },
  "isa" : [ "list", "with", "several", "items" ]
}

Is this the kind of best practice you were looking for or something more complex? I mean, are you looking for something that looks good even on the triple level, or just on the JSON-LD level?

[hsolbrig]

We need something that looks good even on the triple level. Like Schema.org, we already (sort of) know where we want to be -- (ex:isa [:index 0; :val "list"], [:index 1; :val "with"], ... ). We are looking for approaches to getting there and back.

To be clear, not asking for advice on various alternatives to collections in RDF (the ungulate proboscis) just how best to achieve a selected alternative.

[ajs6f]

@hsolbrig Just to be clear (I'm pretty dense about this stuff), the "selected alternative" is numerical indexing as you show it above? (Which is obviously an extremely common and useful pattern for this need.) Would it be reasonable to show essentially your example above with a note explaining the use of such a pattern and mentioning that many common vocabularies have "out-of-the-box" terms for this pattern?

[hsolbrig]

The problem is that there is no single "selected alternative" -- there are several competing options available, none of which have become de-facto, let alone actual standards. The option we are using in the FHIR community is the numerical indexing.

And yes, we will be happy to share our pattern(s) for this once we figure them out. Had we been more forward thinking when this issue was being discussed, we would have advocated standardizing some sort of relative position variable or template for this purpose...

[ajs6f]

Well, what I was reaching for was something specific enough to use for actual advice or examples in this BP doc. If we're not confident that there is a single form that is evolving, must we show several and discuss their tradeoffs? That might cause more confusion than it resolves.