Is the intention that a data miner would see this property in metadata, and then save time and I/O by not having to read the EXIF data?

Is the intention that a data miner would see this property in metadata, and then save time and I/O by not having to read the EXIF data?

The intention is that somebody using this data would know that there are restrictions on how it can be used. Someone reading this data may not even have access to the image file, or the image format may not support EXIF data.

This data is used by search engines like Google (which uses it as an alternative to EXIF data when it's unavailable or fields are missing), so presumably Google would follow the restrictions. A common restriction would be "Prohibited except for search engine indexing".

A lot of organisations may have thousands or even millions of images online. Retroactively modifying all of these images to have a new EXIF field can be time consuming and expensive (costs of data transfers for cloud providers). It's can be much easier to update metadata for a web page, especially if it's generated from a database.

Also note that I am suggesting this attribute be added to the parent CreativeWork class. Certainly MediaObjects and DigitalDocuments would be appropriate.

http://schema.org/BusinessFunction seems to have prior art for how to import a third-party enumeration type to the http://schema.org/ namespace while referencing its original enumeration values.

We could suggest the following values from http://ns.useplus.org/LDF/ldf-XMPSpecification#DataMining:

http://ns.useplus.org/ldf/vocab/DMI-UNSPECIFIED (Unspecified - no prohibition defined)
http://ns.useplus.org/ldf/vocab/DMI-ALLOWED (Allowed)
http://ns.useplus.org/ldf/vocab/DMI-PROHIBITED-AIMLTRAINING (Prohibited for AI/ML training)
http://ns.useplus.org/ldf/vocab/DMI-PROHIBITED-GENAIMLTRAINING (Prohibited for Generative AI/ML training)
http://ns.useplus.org/ldf/vocab/DMI-PROHIBITED-EXCEPTSEARCHENGINEINDEXING (Prohibited except for search engine indexing)
http://ns.useplus.org/ldf/vocab/DMI-PROHIBITED (Prohibited)
http://ns.useplus.org/ldf/vocab/DMI-PROHIBITED-SEECONSTRAINT (Prohibited, see Other Constraints property)
http://ns.useplus.org/ldf/vocab/DMI-PROHIBITED-SEEEMBEDDEDRIGHTSEXPR (Prohibited, see Embedded Encoded Rights Expression property)
http://ns.useplus.org/ldf/vocab/DMI-PROHIBITED-SEELINKEDRIGHTSEXPR (Prohibited, see Linked Encoded Rights Expressio

How would "see Other Constraints property" etc. work here -- would the Other Constraints property have to be embedded in the file, or would that too correspond to some schema.org property?

How would "see Other Constraints property" etc. work here -- would the Other Constraints property have to be embedded in the file, or would that too correspond to some schema.org property?

Cut and paste from the spec.

But then again, perhaps we should also add an "otherConstraints" field, similar to http://ns.useplus.org/LDF/ldf-XMPSpecification#OtherConstraints

It may also be worth "embeddedEncodedRightsExpression" and "linkedEncodedRightsExpression" if we want to implement all of these values.

See #3392 which has some overlap

This issue is being nudged due to inactivity.