Allow created/modified metadata per representation?

[azaroth42]

Per @jronallo's work and discussion in the discovery group, this issue is to track whether or not to add representation level metadata to the APIs, and in particular created and [last] modified dates.

For discovery, the advantage is that the representations are self-describing when it comes to whether they have changed or not and hence should be re-indexed. For debugging, it is also useful to see whether you're accessing a cached, out of date version. As the keys are not in conflict with any of the existing ones, there's no harm in adding beyond the additional informational load.

It is possible that the keys would be confused with metadata about the object, such as a manuscript being created in 1400. Also, the information really /should/ be at the HTTP transport layer, rather than in the representation. This would be a convenience, rather than a necessity, but a convenience that should be discussed.

[jpstroop]

I was not on the discovery call this week, so may have the full picture.

Also, the information really /should/ be at the HTTP transport layer, rather than in the representation.

Yes. So if I have a big set of manifests and I want to refresh/reindex them all, I'm still going to have to check HTTP caching headers (or pull down and parse each manifest if this was added) to see if each manifest has changed, no?

I see the advantage of the manifest containing this info because it means that some other feature of my local application does not have to keep track of it, but unless this was a MUST I'd probably have to build that fallback anyway--we would have two ways to do the same thing, and HTTP feels more elegant.

And then, why favor dates on manifests over etags?

[workergnome]

I'm a big fan of manifests having a place where they can describe information about themselves, not the objects they represent.

I agree that some of that data can and should be communicated via HTTP transport, but if we only support that, it means that information only exists in "live data" and that a documentized version of a IIIF is no longer possible. We'd be pulling in a hard dependency on HTTP and making it so that embedded versions of these services can not communicate that metadata.

In practical, implementation terms, if I care about this data, I'm going to have to store it somewhere—either in the API response or in a sidecar file/database/application. I'd rather have a place to store in in the representation.

[azaroth42]

Given more recent discussions around extensions, do we feel this is important enough to be in the spec, or is it just "dcterms:modified": "datestamp" as an extension?

If we allow this level of self-description, are we opening the door for other document level metadata fields that will (inevitably) take us to HTTP-Range-14 land? Currently it's not valid to have format or profile (for example) on a Manifest.

[workergnome]

What would we be Range-14-ing?

Which is to say, isn't a manifest a document, that describes the structural content and associated metadata of itself? I'm wary of assuming that a manifest identifies an object...the thing depicted...in any way.

I would love more formal clarification around this.

[zimeon]

I am wary of inclusion for the reasons in @jpstroop's https://github.com/IIIF/api/issues/1206#issuecomment-318897493

I think we are also in the range-14 danger zone here ... the Manifest object has a license (for the object described by the document, not the document), a label (for the object described by the document, not the document), metadata (...), navDate (... you get the point...), .... As we say in the description of Manifest "The manifest resource represents a single object and any intellectual work or works embodied within that object." and not the JSON document.

[workergnome]

Interesting. I think this is probably a distinction between museum practice and manuscript practice--the license, in my mind, is the license for the images, not for the artwork. The label is for the image, not for the object. Metadata...yeah, that's odd, but it's also just a set of strings, and is explicitly non-semantic.

That definition of a Manifest makes sense in the context of objects that can only have a single useful digitized representation (i.e., manuscripts), but makes a lot less sense in a museum context, where objects can have many assemblages of images.

And even less in the context of, say, cat photos. "Photos of my Cat, Feb. 2017" is a perfectly valid manifest, but it's not a representation of the cat.

[zimeon]

@workergnome - I agree that the license is for the images -- but that isn't the Manifest document, that is the things that comprise the Manifest. I think the spec language is not really very helpful on this. I posted a slightly more nuanced take on Slack:

I'd say that the Manifest object is a particular representation (dare I say presentation?) comprising a set of digital resources (often page scans). Usually this is a copy or facsimile (the word used in original Shared Canvas) of some physical object (like a book) but need not be (it could be the one and only representation of something new, like the object that is the 13th page of each of 500 books, in some order).

[azaroth42]

Given the lack of enthusiasm, the use of ActivityStreams in the current discovery work, that it can easily be added in a subsequent 3.1 if it is decided to be required, and until then it is an easy extension, I propose defer.

[mikeapp]

Community call 12/20 continue to defer.

[jpstroop]

Editors proposed close. Covered by Change discovery and HTTP.

[azaroth42]

Editors closing after three year grace period of no comments.