check for @graph keyword in manifest

[christopher-johnson]

In the iiif-discuss mailing list, I raised the question of the use of @graph as a possibility in a manifest serialization from RDF. See https://groups.google.com/forum/#!topic/iiif-discuss/yyRjzJl5xHs

I have made a simple change in the manifesto Deserializer @ line 1465 that addresses this.

if (json['@graph']) { json = json['@graph'][0]; }
It would be great to have this in master so I do not have to maintain a fork. If you are interested, please send me a pull request.

Thanks.

[christopher-johnson]

I think that the src file and location for this change would actually be here: https://github.com/viewdir/manifesto/blob/master/src/Serialisation.ts#L18

I will recreate this issue in that repo with a back reference to this one.

[tomcrane]

Note that the implications of that implementation note in the Presentation API led to this issue: IIIF/api#920 (for discussion in The Hague)

[christopher-johnson]

@tomcrane thank you for the reference. The core issue here is how to contractually distinguish between IIIF client expectations and LDP server assumptions, and not specifically with the @graph keyword. Deserialization and "client acceptable" response validation is not typically a server-side task and therefore I truly feel that this type of schema check belongs in a client. If the client does not like the server response, then simply throw an exception and move on. Making formal rules with the intention of preventing the server from doing odd things is an enormous task, because there are literally infinite possibilities.

Additionally, many fromRDF serializations of JSON-LD return a response in the @graph array, and it is an accepted standard in jena, virtuoso, and the json-ld library, to name a few. The IIIF client contract should naturally dictate that the data within the @graph array should conform to the specification and I would not suggest that the client handle an arbitrary graph as @azaroth42 implies. Anything outside of @graph other than @context should just be ignored by an IIIF client. I think supporting @graph could reduce the potential scope of the client contract.

As demonstrated with the scope of this change for the client, it is very minimal. A service implementation to deserialize and reserialize the server-side graph response is much more complicated. My service streams the manifest directly from the jsonld.frame function without intervention and introducing a parser here is definitely sub-optimal.

[azaroth42]

Please consider: IIIF/api#920

[edsilv]

Closing as this seems to not result in an actionable task