Open eeeps opened 7 months ago
@eeeps You are absolutely correct. Most of this is, however, already corrected in the 1.4 version of the specification, and future releases will also improve it even further.
@lrosenthol The links and text above are all from the current public 1.4 version of the specification.
By "corrected", do you mean that Schema.org labels have been marked as deprecated in 1.4, and so these conflicts are not important to resolve because these labels won't be present in the spec at all, soon? I am inclined to agree, except that current tooling does not yet implement Common Metadata, so implementors (like me) might find themselves consulting these deprecated sections to figure out what to do in the meantime.
In the Use of Schema.org section, the spec states,
This somewhat conflicts with this statement in the intro to Labels
(EXIF and IPTC clearly/consistently use the
stds.
prefix).It also conflicts with how the two most important Schema.org assertions – CreativeWork and ClaimReview, are specified and used in examples throughout the spec. Here's the Creative Work section:
Here's the ClaimReview section:
And here's the Standard C2PA Assertion Summary...
A find-in-page for "stds.schema-org." returns 21 results, all for labels of
stds.schema-org.CreativeWork
orstds.schema-org.ClaimReview
. A find-in-page for "schema.org." returns five relevant results, all forclaim_generator.claim_generator_info[].schema.org.SoftwareApplication.operatingSystem
.Most importantly, existing tooling (Verify and c2patool), which does not yet implement the Common Metadata system introduced in v1.4, only reads from
stds.schema-org.CreativeWork
assertions, notschema.org.CreativeWork
.Not sure what the best path forward here is, especially given the depreciation of separate EXIF, IPTC, and Schema.org assertion labels in favor of Common Metadata.