search

w3c / json-ld-framing

JSON-LD 1.1 Framing Specification
https://w3c.github.io/json-ld-framing/
Other
25 stars 20 forks source link

Explore supporting `"@embed": "@first"` #43

Closed dlongley closed 5 years ago

dlongley commented 5 years ago

My understanding is that the use of @last is intended to ensure that all data related to whatever a frame filters on is not omitted (or duplicated) from the result of a framing operation. The embed location ("last") is actually not important. One use case for this feature is framing subgraphs in JSON-LD documents prior to verifying digital signatures on them.

This form of embedding was the only type available when framing was invented: the choice was to embed this way or not to embed at all; @always came later. I can't remember a good reason why the choice was made to place the only embed for a node wherever it is referenced "last" -- and at this point it feels arbitrary. Certainly the framing user doesn't care because they can't know where "last" is a priori. In fact, in some implementations, the keyword @once was used before @last was adopted instead.

If the case is that it is arbitrary, using "last" clearly has some drawbacks that might be avoided if we supported @first instead for this use case. Using @last requires some post processing that removes previous embeds to ensure that only the last one is used. This is costly in current implementations. I would think that using @first would cause all subsequent occurrences to just use a reference and to add any additional data collected to the first embedded node object, eliminating the need for any post processing.

Of course, not having looked into the framing algorithms in a while, this could also be naive. Therefore, I recommend that implementers (such as me) explore @first as it may be the case that existing implementations can be very easily adapted to support it -- and its simplicity could address a number of issues (for example: performance). If nothing else, a good explanation for why "last" was chosen should come out of this and could be placed into the spec.

Note: The first public description of framing I could find did not help me remember anything: https://lists.w3.org/Archives/Public/public-linked-json/2011Aug/0078.html

gkellogg commented 5 years ago

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

azaroth42 commented 5 years ago

:+1:

azaroth42 commented 5 years ago

Was there a WG resolution that we should add this?

gkellogg commented 5 years ago

No, you’re right, I was premature.

Gregg Kellogg Sent from my iPhone

On Mar 12, 2019, at 6:04 PM, Rob Sanderson notifications@github.com wrote:

Was there a WG resolution that we should add this?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

iherman commented 5 years ago

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...)

gkellogg commented 5 years ago

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.

iherman commented 5 years ago

This issue was discussed in a meeting.

iherman commented 5 years ago

This issue was discussed in a meeting.