New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DataDownload is subtype MediaObject - definition of latter needs tweaking #1190

Closed
danbri opened this Issue May 31, 2016 · 5 comments

Comments

Projects
None yet
5 participants
@danbri
Contributor

danbri commented May 31, 2016

Considering #1083 http://schema.org/DataDownload is technically a MediaObject, however this is mostly about images/videos. If we keep this, the definition of MediaObject should be updated. Otherwise we could take the best properties from it and attach them to DataDownload directly.

@agbeltran

This comment has been minimized.

Show comment
Hide comment
@agbeltran

agbeltran Jun 1, 2016

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.

agbeltran commented Jun 1, 2016

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.

@sballesteros

This comment has been minimized.

Show comment
Hide comment
@sballesteros

sballesteros Jun 1, 2016

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.

sballesteros commented Jun 1, 2016

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.

@tfrancart

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Jun 8, 2016

Contributor

See also #1153

Contributor

tfrancart commented Jun 8, 2016

See also #1153

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 16, 2016

Contributor

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...

Contributor

danbri commented Jun 16, 2016

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...

@darobin

This comment has been minimized.

Show comment
Hide comment
@darobin

darobin Jun 20, 2016

Contributor

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 :)

Contributor

darobin commented Jun 20, 2016

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment