Define media profile for frames about json-ld-framing HOT 13 CLOSED

Why do we need a separate media type, rather than registering a profile for application/ld+json like expanded or compacted?

Frames are just JSON-LD documents that have special processing implications when applied to other JSON-LD documents.

As Framing does not have backwards compatibility requirements, I think we should consider our options. Especially with respect to w3c/dxwg#261.

from json-ld-framing.

Probably too early, but I wanted to get an issue set so we don’t forget to do it.

from json-ld-framing.

@gkellogg in as much as the direct processing model is identical to application/ld+json) and only the context (sorry) in which it's used changes it's "meaning"--i.e. makes it a "frame" vs. a data document--I'd recommend avoiding another media type and leaning on profile as done for compact, expanded, and flattended: https://www.iana.org/assignments/profile-uris/profile-uris.xhtml

That said, there could be a case made for the MIME type registration's value in association with editors and file extensions...but sadly you can't state a file extension for non-Web use in association with a profile="" registry entry (which would've been nice for Web Annotation...).

from json-ld-framing.

If they're inconsistent, then we should pick one. However, I think the profile solution is likely best.

from json-ld-framing.

@gkellogg could you change the title here to reflect this new proposal? Or close in favor of an issue focused on the profile proposal?

I'd like to get it on the agenda for a future call.

from json-ld-framing.

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}

from json-ld-framing.

@akuckartz : the idea is that the syntax document, more exactly the grammar of JSON-LD, should include the frame specific terms, too, which means that, from a media type point of view, a frame document would be a bona fide JSON-LD document. Ie, no need for a separate media type.

from json-ld-framing.

Fine with me. We can then proceed through the usual route. But I guess it is too early to register, isn't it?

from json-ld-framing.

Also fixed a wee typo in that section in 120c32b

from json-ld-framing.

A frame does have some elements that a normal JSON-LD document wouldn't, such as @default and other flags. But, it is a subtle distinction. I could see using a profile instead of an independent type.

@BigBlueHat that wasn't a typo, but it is debatable if application/frame-ld+json is better (or more correct) than application/ld-frame+json.

from json-ld-framing.

@gkellogg it wasn't? 😕 The registration info was for application/ld-frame+json, so application/frame-ld+json seemed incorrect. Sorry if I've totally misunderstood what was being expressed there.

Regardless, I'd suggest we stick with profiles if at their core they can all be processed as application/ld+json.

from json-ld-framing.

Related to w3c/json-ld-syntax#8

from json-ld-framing.

I do not understand the resolution. Was it in favor of a specific Media Type for frames or not?

from json-ld-framing.