Closed azaroth42 closed 5 years ago
This seems like the same situation as when a JSON-LD file typically used as a context document also contains its own data. It's a valuable feature, but does lead to some confusion of intent.
Maybe we need a pros/cons list for the value/risk of using a single JSON-LD document as a context, a frame, and a data document?
This issue was discussed in a meeting.
RESOLVED: Use ld+json with a profile for media type of frames, import frame keywords to syntax with reference out. {: #resolution7 .resolution}
RESOLVED: the use of the media type for a frame is RECOMMENDED not a MUST {: #resolution8 .resolution}
Hm. I am a bit bothered, but maybe for no good reasons.
The frame objects allow for, say, something like "@id":{}
, right? But that means I can put this into any context whatsover: what does it mean?
In general, there is nothing that distinguish a frame object from any other constituents of a context, so is it absolutely clear what the API does if it encounters such statements as part of normal processing like expansion? If there is already (I presume ignoring) that should be made much more clearly in the document.
The expansion algorithm will throw an error unless it is invoked with a framing option.
There are some other things that are legal for frames that don’t involve keywords that we should describe as well, but the would all be either in frame objects, or immediate values of frame objects.
Frames are just JSON-LD documents, but result in special processing. #21 is to register a new IANA media type for frames, but is this sufficient or should the document be recognizable without the HTTP response context?