iiif:Image or not?

[VladimirAlexiev]

http://iiif.io/api/image/2/info_frame.json shows "@type": "iiif:Image".
However, the table at the beginning of http://iiif.io/api/image/2.0/#image-information and the example at the end of this section don't show such type in the response.
Should there be such type or not? I'm working on mapping Getty CONA images to RDF thereon IIIF and will appreciate a quick answer very much :-)

[azaroth42]

Clearly (given the typo of the trailing comma) that frame has never been used for anything practical :)

So should there be a type or not ... is a very good question. Without the type, I think the framing algorithm won't know which resource to have at the top level, so my instinct is to say that it's needed in the ontology, but that it should be omitted from the serialization. I have no idea if that's actually possible with JSON-LD framing though. More research needed, I'm afraid!

[azaroth42]

There's an open issue about Frame matching on exactly this topic:
json-ld/json-ld.org#110

As Framing didn't make it out of the CG, we're unlikely to see any changes. So I think we go ahead and use the CG defined algorithm.

See http://json-ld.org/spec/latest/json-ld-framing/#framing-algorithm
In step 2.3 it matches on the properties specified by the frame. So we can do away with iiif:Image if we specify at least "protocol".

In the case where there is an icon with an image API service that has a protocol ... I think results are undefined 😖

[azaroth42]

Frame Playground example: http://tinyurl.com/pccenmp -- Note that it is seriously broken! I wouldn't trust it, but feedback would be useful.
Fix Branch: http://friday_issues.iiif.io/api/image/2/info_frame.json

[azaroth42]

Properly ready for review now (after repository state fix). I think we keep the frame as is, despite the bug in implementation. Markus responded to the issue on json-ld at least, but who knows when/if it'll get fixed.

[jpstroop]

👍

[VladimirAlexiev]

So no iiif:Image then? Coming from an RDF background, I am wary of unclassed nodes (as #523 says).
It's fine if you don't want to require such type in the JSONLD representation (I guess you view it as "parasitic"). But at least allow it, and state that it's the recommended type for these sort of nodes.