Closed dlongley closed 5 years ago
I support adding @first
. I'll need to work on it, but I think it would be fairly straightforward.
:+1:
Was there a WG resolution that we should add this?
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.
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...)
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.
This issue was discussed in a meeting.
This issue was discussed in a meeting.
RESOLVED: Change @last (back) to @once, don’t add @first and then figure out testing separately
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