Explore supporting `"@embed": "@first"` about json-ld-framing HOT 8 CLOSED

I support adding @first. I'll need to work on it, but I think it would be fairly straightforward.

from json-ld-framing.

👍

from json-ld-framing.

Was there a WG resolution that we should add this?

from json-ld-framing.

from json-ld-framing.

It may be too late to consider this but... I am a little bit bothered by this feature altogether. Looking at, e.g., example 12, and if I understand it right, we are looking at

{
    "@id": "http://example.org/library",
    "@type": "Library",
    "books": "http://example.org/library/the-republic",
    "contains": "http://example.org/library/the-republic"
}

and the value of @first or @last refers to the order of books and contains to choose among them. However, the order of keys within a JSON object does not matter. (There are plenty of references in, e.g., stackoverflow question to various specs stating that.) Nor does the order matter in RDF. So how come we introduce a feature that explicitly refers to the order of keys?

(I may misunderstand something, though...)

from json-ld-framing.

Both @first and @last depend on the algorithm sorting keys, whichi is optional. There’s an inline editors not about using something like @sample to use the first one found irrespective of order, which would lead to reproducibility issues.

We may simply need to stick with key ordering to make these work.

from json-ld-framing.

This issue was discussed in a meeting.

• No actions or resolutions

from json-ld-framing.

This issue was discussed in a meeting.

• RESOLVED: Change @last (back) to @once, don’t add @first and then figure out testing separately

from json-ld-framing.