Add 3DModel type (as a CreativeWork subtype; original proposal was 3DModelObject, subtype of MediaObject)

[vholland]

3D imaging is gaining traction. While we should not pick winners amongst the emerging file formats, it would be nice to be able to express something is a 3D object rather than just an ImageObject.

I propose we add 3DModelObject as a subtype of MediaObject.

[philbarker]

+1 I went to an Elixir Biohackathon last November and people there were interested in how 3d molecular models could be marked up in schema.org. This would help.

[danbri]

We can use https://schema.org/encodingFormat to deal with the huge variety of formats, and make the definition inclusive. There are many kind of file that could usefully be seen as carrying 3D models, we should aim to make sure the definition makes it clear the type should be equally useful for VR, AR, scientific data sharing, geospatial data, 3d molecular data etc.

Draft definition

We'll be needing a definition. How about:

"A media object that represents some kind of 3D content. Many formats are available (e.g. see https://en.wikipedia.org/wiki/Category:3D_graphics_file_formats ); specific encoding formats can be represented using the encodingFormat property."

Zipped files

We will also want to consider and document the situation where a bundle of several files have been packaged as a .zip or similar archive format.

This is a detail, and not specific to 3D formats except that several approaches use multiple files:

This came up elsewhere w.r.t. datasets, where I had this interim advice:

Short version: use "encodingFormat": "text/csv+zip"

Long version:

It does not appear that there is a strong consensus currently on how to do this in the general case (with arbitrary levels of nesting etc.), either using Schema.org or the closely related W3C DCAT format. However I do see that this was discussed in the DCAT community previously, and they reached a recommendation for the situation with zipped CSV files:

See https://joinup.ec.europa.eu/release/how-refer-media-types-within-zip-files for their guidance and discussion.

" The recommendation proposed by IETF should be followed, as to know to add ‘+zip’ as suffix in the structured syntax to the IANA registry for media types and for files within a ZIP package"

I'm a member of the W3C DCAT group and will follow up there to try to improve Schema.org's documentation around this, and make sure that we keep Schema.org and DCAT as close as possible on such details. It is possible that this guidance will evolve over time, but for right now "text/csv+zip" seems the best option.

(I still need to investigate this further, as it does not deal explicitly with several files of different media types, all in the same .zip package.)

See also

• http://edutechwiki.unige.ch/en/3D_file_format
• https://en.wikipedia.org/wiki/Category:3D_graphics_file_formats
• https://helpx.adobe.com/dimension/using/supported-file-types.html
• https://all3dp.com/3d-file-format-3d-files-3d-printer-3d-cad-vrml-stl-obj/
• https://help.sketchfab.com/hc/en-us/articles/202508396-3D-File-Formats
• https://www.quora.com/What-is-the-most-universal-3D-file-format
• https://proteopedia.org/wiki/index.php/Atomic_coordinate_file ...

[thadguidry]

As long as we have 3 separate Types to deal with 1. the CONTENT , 2. the FORMATS, 3. the PACKAGING then I don't really care much here. (Those 3 Types, the trifecta of Information Storage, have been around for 10's of years since the beginning of Information and Storage Retrieval)

[danbri]

I've been talking this over with @vholland, we think it'll work better up at the CreativeWork level (as "3DModel"), leaving a generic MediaObject for the specific downloadable "bag of bits" representation. That way you can either have a simple "one 3DModel and one downloadable media object encoding of it" description, or you can say "there's a 3DModel and here are x, y and z alternate representations to download".

[danbri]

See also #2151 to sanity check the name won't hit any coding assumptions about terms names beginning with letters.

[thadguidry]

@danbri you mean with terms possibly beginning with NUMBERS. :) Long day?

[danbri]

"Assumptions like terms always beginning with letters"; but thanks for the extra email.

[RichardWallis]

Implemented in release 3.5