John Flatness

We should have something for this. We have to decide whether to cram it into Item Showcase or to Media... the lines between these are a little blurry unfortunately.

@kimisgold this is really a theme issue I guess, though it affects the fallback theme views of course. The label text "Resource Class" I forsee being kind of a barrier...

I don't think we want to go down the road of using different terms for the same thing... if we _do_ have a label for it it should probably be...

None of "Item," "Agent," "Resource," etc. are going to be acceptable terminology in that context I wouldn't imagine. Another way around here is to have a simple way of turning...

So this is specifically just a problem with including the same item set (or media) ID twice in an API create/update request?

Alternatively since they all have actual visible text content could we eliminate all the `title`s? I don't know that they're really providing anything here, are they? On board with consistency...

That's a lot of arguments to add, even though they're optional. I wonder what you'd think about having this use a partial (which the theme could override) instead?

As you've noticed, the API creates JSON-LD compatible output but requires S-specific json-only keys to do certain things, and properties/values for resources is a big one. So, the current API...

@ptsefton You can currently use the `properties` API endpoint to look up properties based on their prefix and local name with the GET parameter `term` (so `?term=dcterms:title`). We don't accept...

It's another one of these things where we're _publishing_ the JSON-LD standard way but _reading_ a parallel key of our own, in this case it's `o:resource_class[o:id]`.