Description
As a task within workarea #3391, we should have a schema.org native enumeration matching the codes standardized at IPTC for synthetic media. Also a property to use them on a MediaObject.
IPTC docs:
- https://www.iptc.org/std/photometadata/documentation/userguide/
- https://www.iptc.org/std/photometadata/documentation/userguide/#_about_the_iptc_photo_metadata_user_guide
- https://iptc.org/news/iptc-releases-draft-of-digital-source-type-vocabulary-to-support-synthetic-media/
See https://cv.iptc.org/newscodes/digitalsourcetype/ for details. Here's a copy of their current wording format for one term, see link for full version:
Concept ID (QCode) = digsrctype:positiveFilm, ID (URI) = http://cv.iptc.org/newscodes/digitalsourcetype/positiveFilm
--
Type: cpnat:abstract | created: 2008-01-01T01:00:00+00:00 | modified: 2010-12-15T21:54:47+00:00 | retired:
Name(en-GB): Digitised from a positive on film
Definition(en-GB): The digital image was digitised from a positive on a transparency or any other transparent medium
Member of scheme: http://cv.iptc.org/newscodes/digitalsourcetype/
As always there is the question of adapting vs leaving unchanged when bringing in external mappings. Having tried some variations, I propose this:
- DigitalCaptureDigitalSource
- NegativeFilmDigitalSource
- PositiveFilmDigitalSource
- PrintDigitalSource
- MinorHumanEditsDigitalSource
- CompositeCaptureDigitalSource
- AlgorithmicallyEnhancedDigitalSource
- DataDrivenMediaDigitalSource
- DigitalArtDigitalSource
- VirtualRecordingDigitalSource
- CompositeSyntheticDigitalSource
- TrainedAlgorithmicMediaDigitalSource
- CompositeWithTrainedAlgorithmicMediaDigitalSource
- AlgorithmicMediaDigitalSource
All of these within IPTCDigitalSource which is a subtype of (for now, we can add more and more structure) MediaEnumeration. I will also move the MediaReview enumeration beneath there.
To reference this list, for now we can simply use a digitalSource property. Other designs could reference these, or these plus others, in more ambitious ways. Note that in schema.org we never write enumeration types, enumeration members or anything else but properties using an initial lower case letter. This is why "print" becomes "PrintDigitalSource". The "DigitalSource" also stops us "using up" very general terms when we mean something quite specific. This is more of an issue for us at Schema.org since we do not use explicit sub-namespacing mechanisms, whereas at IPTC these terms are within an area already scoped to "digital source types".