Do we really want to retain type = Object and Version with plain JSON?

[zimeon]

I think I've always doubted the value of including these plain-text types (as opposed to semantic types in JSON-LD) but this was really brought whennhome listening to justification in the talk Rosy and I gave yesterday. I just didn't buy it. What value do they bring in a fixed JSON format? I could see having a type that included a version number at the top level (ie. "type": "ocfl_object_1.0" to match the NAMASTE file) which could then be a consistency/sanity check in validation. I don't see any benefit of having a type for each version object.

[ahankinson]

How do you check an object has the necessary keys in JSON Schema? I would want some sort of check that message wasn't written to type: Object objects, but only to type: Version.

[zimeon]

JSON schema makes no special use of type keys in the data. If you look at https://ocfl.io/draft/spec/inventory_schema.json don't be confused by the "type": "object", line (which simply says that the root is an object not an array), the part where it checks the type key in the data is:

"properties": {
  ...
  "type": {
    "description": "Seems that using `const` would be nicer but that doesn't seem to work with Python jsonschema",
    "enum": [ "Object" ]
  },
...

which simply says there must be a type key with the value Object (and I think that should use the const construct in JSON schema rather than a single value enum, but that did not seem to work with tool I was using)

The JSON schema "looks" at the whole structure of the object and hence type is just one more key to be expected in a given position, albeit with a constant value requirement. Knowing that the root has a versions key with an array of version objects which each must have keys created with datetime type, message with string type, user with object type with name and address keys, etc., etc. is pretty strong validation IMO, adding an extra constant key-value pair adds little.

[neilsjefferies]

It doesn't buy us anything in terms of simplifying validation and I'm not sure it adds anything in terms of readability. Top level version number is, I think, a good idea though.

[zimeon]

I propose that at the top level we have a more OCFL specific key than type in order to record the version number. Following our camelCase convention I think perhaps:

  "ocflObjectVersion": 1.0

[awoods]

An embedded OCFL Object version would be helpful for cross-validation.

[ahankinson]

A few related but not structured thoughts:

• An OCFL inventory can't really stand on its own, and the version is already carried by the namaste file. How would an object version key interact (or conflict) with the namaste declaration?
• Is a simple version number sufficient, or do we want to specify the version with a URI? Given that URIs are ugly in Namaste, this may be a reason to use one in the inventory -- the Namaste file contains the semantic version, while the inventory contains a unique identifier for the identity of the object structure.
• I'll step up and say I like having 'type' on random JSON objects, if for nothing else but for human readability and orientation in a structure. I know that 30 objects into a random array I'm still looking at things of type 'Version' then I can keep scrolling until I find what I'm looking for. Otherwise the object structures just start looking the same.

[neilsjefferies]

+1 for the human readability bit. It's one of the principles behind other bits of OCFL design.

[zimeon]

Discussion on 2018-11-21 editors' call: will remove type on version, will have "type": "https://ocfl.io/1.0/spec/" in the top level of the object which is both a version indication and a helpful link

[zimeon]

On thinking about this more and looking at the current definition of type: "A type for the inventory JSON object.", it seems best to use the URI for the inventory section of the spec, not just the spec URI: https://ocfl.io/1.0/spec/#inventory