Guidance to application developers on expressing arrays

[chrysn]

After #33 is resolved, there are 3 ways in which an array in an application can be mapped to CoRAL:

• as a literal: <subject> <predicate> "[\"a\", \"b"\, \"c\", \"d\"]"^^cbor .

  This is easy to do, but the content of the array is not accessible through any CBOR mechanisms, and the only thing one can do in a patch is to replace the statement (a process that may be guided by the predicate being an owl:FunctionalProperty, or by the patch format)

  This does not convert well to any RDF format other than CoRAL.

• as a set of properties: <subject> <predicate> "1", "2", "3", "4" . (which is a compact way of writing <subject> <predicate> "1". <subject> <predicate> "2". …)

  This is what I think makes sense a lot of the time, but users should be made aware that (outside of the structured information model) there is no order, and that stating emptiness is not possible in an open-world setting. Obtaining emptiness in a patch requires explicit support for removing statements in PATCH (but we'll want to have that anyway).

  This is also what by default comes out of a JSON-LD array, if the ingredients example of https://json-ld.org/playground/ is any indication.

• RDF sequence: <subject> <predicate> [ a rdf:Seq, rdf:_1 "1", rdf:_2 "2", … ] (<subject> <predicate> _:blank . _:blank rdf:1 "1" . …).

  That's the original RDF sequence style, which has order and allows access to individual elements, but I don't think it'd be used a lot, and it'll be tricky to get the rdf:_1 etc values usably into packed.

  I don't know if this is used anywhere.

  CoRAL could use extra syntac for this (as does RDF-XML), but I'd rather not without a good use case.

• RDF collection style: <subject> <predicate> ("1" "2" "3" "4") . (<subject> <predicate> [rdfs:first "1", rdfs:rest [rdfs:fist "2", rdfs:rest […]]] .)

  Some might also call this linked list or Lisp list style. I don't know whether this pre- or postdates the RDF sequences.

  I don't know if this is used anywhere.

  CoRAL could use extra syntax for this (as does RDF-XML and Turtle), but I'd rather not without a good use case.

Authors for formats based on CoRAL will need some guidance on which of those options to choose; in parallel, we may want to do some searching to confirm that we really don't want to go out of our way to make the latter two easy to use. Note that there is often the temptation to fall into the latter two before embracing an open-world concept.

One concrete example is in @marco-tiloca-sics's gm-admin-coral:

Editor's note: this should change to using an empty CBOR array or an empty CBOR map as appropriate, once this is made explicitly possible in the binary format of link items in CoRAL (see Section 3.1.4 of [I-D.ietf-core-coral]).