I think it would be better to make DataDownload not a subtype of MediaObject, as MediaObject name already has some connotation about 'media' files (even if its definition could change) and it is not generic enough for any Dataset.

I wonder if it would not make sense for schema.org to have a systematic separation between creative works and their 'encodings'.
For instance:

• Dataset (work) and DataDownload (encoding)
• Image (work, currently non existing) and ImageObject (encoding)
• Video (work , currently non existing) and VideoObject (encoding)
• etc.

That will make it super easy to use the encoding property of CreativeWork (or distribution for Dataset). While I am at this, it may make sense to deprecate the distribution property of Dataset and just have encoding.

In that world it would be great to have DataDownload as a subclass of the parent class for all things encoding (right now that parent class seems to be MediaObject).

So we would have 2 parent classes CreativeWork and Encoding (currently MediaObject). A sort of super simplified FRBR model.

See also #1153

Doing a FRBR-lite is a perpetual temptation. For now I would like to make some minimal tweak to the MediaObject definition to make DataDownload a more acceptable subtype. Scanning CreativeWork for all FRBR-like structures and reconciling them is a much larger job. It might be that we could put most CreativeWork subtypes somewhere on a Work-Expression-Manifestation-Item spectrum...

For us FRBR-light is a bit more than a temptation. We have our own SA ontology that only contains the things that we couldn't do with schema.org. Just scanning it quickly, we've added: Audio, Formula/FormulaObject (for math resources), Image, TableObject, Video. Apart from the formula bit where we defined both entity and encoding classes, the others all complement a schema.org construct.

We absolutely don't need the full FRBR but we rely on the entity/encoding couple a lot. That's how we do figures with responsive images, or multiple video encodings, etc.

I would also like to support the distribution -> encoding move, I'm tired of special-casing that one :)