new container type leveraging RDF-star to encode order

[pchampin]

There has been some discussions about how RDF-star can help with ordered multiple values in RDF. Example:

<#book> dct:creator <#alice> {| ex:order 1 |};
        dct:creator <#bob> {| ex:order 2 |}.

I would like a new kind of container in JSON-LD that would translate to the triples above. The compact form could look like that:

{ "@context": {
    "creator": {
        "@id": "http://purl.org/dc/terms/creator",
        "@type": "@id",
        "@container": [ "@ordered"]
     }
  },
  "@id": "#book", "creator": [ "#alice", "#bob" ]
}

and the expanded form could look like

{
    "#alice": {
        "http://purl.org/dc/terms/creator": {
            "@ordered": [
                { "@id": "#alice" },
                { "@id": "#bob" },
            ]
        }
    }
}

[gkellogg]

We always had the idea that there might be more ways to interpret an array of values. It might be a bit generic to use. @ordered, unless becomes a really common pattern, but it’s certainly a reasonable thing to do.

why ”@container”: [ “@ordered”] and not simply ”@contsiner”: “@ordered”?

[pchampin]

why ”@container”: [ “@ordered”] and not simply ”@contsiner”: “@ordered”?

no particular reason... :)

[pchampin]

@danbri any opinion on that proposal?

[niklasl]

I think adding a specifiable sort mechanism to JSON-LD could be valuable in general. But I don't think it should be contingent upon RDF-star, which is an advanced mechanism mostly suitable for triple provenance and similar out-of-band marginalia (and on the level of named graphs in terms of comprehensibility, or beyond, since it turns RDF into hypergraphs).

I'd much rather be able to specify which sort key(s) to use for the nodes in a @set (i.e. a non-@list JSON-LD array). That'd look e.g. like: "creator": {"@container": "@set", "@sort": ["familyName", "givenName"]}}, or for this specific case: "creator": {"@container": "@set", "@sort": [["@annotation", "ex:order"]]} (albeit then not being able to coerce annotated nodes to to strings).

For the specific example given in this issue though, the "only" thing required is for the "RDF to JSON-LD" step to ensure that the triples are fed into the JSON-LD algorithm in a predictable order. I am assuming the order here is "the order in which they were stated in". Of course, not all have that level of control. But I'd certainly expect such a level of control if you, in the source RDF, is actually able to add and keep track of ex:order data for each triple.

(The RDF parsers of LDTR and TRLD both work like that, since they transcribe the source RDF into JSON-LD. Just in case anyone needs this level of syntactic preservation right now.)

[pchampin]

I think adding a specifiable sort mechanism to JSON-LD could be valuable in general.

I agree, but that is not what I am proposing here :)
But I grant you that the choice of the keyword @ordered was misleading.

My goal is to have something similar to @list, in the sense that:

"foo": { "@list": [ "b", "a", "c" ] }

is a concise representation of a pattern widely used in RDF graphs (the infamous first-rest ladder).
Except that the target pattern here would be RDF-star specific (instead of using a list to capture the order of the authors, I would annotate each dct:creator triple with a dedicated propetry).

Note that this is really exploratory; for the moment, this new pattern for ordered value is being discussed in different places, but may never be adopted in the wild...

For the specific example given in this issue though, the "only" thing required is for the "RDF to JSON-LD" step to ensure that the triples are fed into the JSON-LD algorithm in a predictable order.

Except that this very notion of predictable order is explicitly ruled out by the definition of the RDF abstract model: an RDF graph is a set of triple, and a set is inherently unordered. Some implementations may preserve some ordering from the initial serialization, but this can not be required of any implementation.

[gkellogg]

I think if we’re going to peruse alternative ordering mechanisms leveraging RDF-star, we should be considering other serialization forms, and implications for SPARQL queries. Probably need to consider entailment considerations, open/closed world and well-formedness expectations.

This certainly dove-tails with recent perma-thread on the semweb and Easier RDF lists that I confess to have tuned out of.