{ "row": "iptc-photo-metadata-tests", "entity": "iptc-photo-metadata-tests", "address": "IPTC photo metadata", "addresses": [ { "address": "IPTC photo metadata", "slug": "iptc-photo-metadata-aio-20261029", "addr_id": "ADDR-ee0523b11509", "obs_id": "OBS-9b96943ca090", "axn": "AXN:0AD0.CAPTURE.☀️🔵❤️♌🌀🎯" } ], "epoch": "2026-10-29", "type": "C (public entity on which the archive bears: a test series of the IPTC Photo Metadata Working Group; an entity of the provenance meta-aggregator)", "surface": "Google AI Overview (expanded)", "auth": "signed out, incognito", "status": { "procedure": "EA-NEGONT-02 v0.9, #1690: equal case, ρ = extends, read from the provenance census record, the capture record and #725's statement of relation; archive selected by D/R/O (4 deposits admitted by reading, 3 with claims and 1 grouped as an instance; hop of 54 read, 1 admitted), with the provenance census record (19 claims) and the Capture Registry's findings, reading, analysis and notes (10 claims) ledgered as the archive's records of the entity; the field B by three origins (11 cards, 2 own pages, 2 Wikipedia titles); the composer read the ledgers, never the transcript, except where the brief asks for T's claims and the delta", "ledger": "unaudited (§3.8: one extractor per ledger); field quotes 53/53 verified by script against the saved page texts, the Wikipedia responses or the card title; archive quotes 40/40 verified against the registry, census.json and the deposit texts", "frozen": false, "breaches": [] }, "spec": "EA-NEGONT-02 v0.9, #1690", "objects": { "T": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/T1-iptc-photo-metadata-aio-20261029.txt", "sha256": "a68e8e7837ff3e574ada22ba820d807b14b74764801b4f00dd84265a462fce37", "words": 231, "cards": 11, "words_note": "one transcript at one address (231 words in the answer body, links reduced to their text, markers and the card rail excluded; 11 cards)", "claims": [ "T1-1 lede: 'You can explore the official IPTC Photo Metadata Standard to manage, describe, and protect digital images.' (two markers)", "T1-2 definition: 'A universally accepted industry standard for embedding administrative, descriptive, and copyright data directly into image files.' (two markers)", "T1-3 file formats: 'Supported across formats like JPEG, TIFF, and PNG, using the IPTC Core and Extension Schemas as well as Adobe's XMP framework.' (two markers)", "T1-4 difference from Exif: 'While EXIF focuses on technical camera data (shutter speed, ISO, lens settings), IPTC focuses on human-readable details like captions, keywords, and creator credits.' (one marker)", "T1-5 descriptive: 'Includes Alt Text, Headline, Description/Caption, Keywords, and Subject Codes.'", "T1-6 administrative: 'Tracks Creation Date, Digital Source Type, Image GUIDs, and registry IDs.'", "T1-7 rights: 'Stores Creator (Photographer), Copyright Notice, Licensor, and usage terms.'", "T1-8 'AI & Content Provenance: Recent standards (such as version 2025.1) include fields for AI System Used, AI System Version, AI Prompt Information, and AI Prompt Writer Name.' (three markers)", "T1-9 asset management: 'Helps archives, news agencies, and stock libraries search and sort massive libraries.'", "T1-10 'Search & Google Images: Search engines read embedded IPTC data to display creator information and licensing attributes directly in search results.'", "T1-11 tools: 'You can inspect embedded data using tools like the IPTC Photo Metadata Inspector or GetPMD.' (six markers)", "T1-12 closer: 'Are you looking to embed IPTC metadata into your own photos, or do you need help reading and extracting metadata from a specific image?'" ], "register": { "register": "data/EA-WG-CAPTURES-01.json", "slug": "iptc-photo-metadata-aio-20261029", "obs_id": "OBS-9b96943ca090" }, "transcripts": [ { "slug": "iptc-photo-metadata-aio-20261029", "address": "IPTC photo metadata", "addr_id": "ADDR-ee0523b11509", "obs_id": "OBS-9b96943ca090", "axn": "AXN:0AD0.CAPTURE.☀️🔵❤️♌🌀🎯", "date": "2026-10-29", "surface": "Google AI Overview (expanded)", "auth": "signed out, incognito", "sha256": "a68e8e7837ff3e574ada22ba820d807b14b74764801b4f00dd84265a462fce37", "sha256_of": "the registry's 'transcript' string (utf-8)", "sha256_raw": "358e9936b29108b3966287e248d0a1fe5a096c33554302e77dae5847f2b53aa3", "words": 231, "cards": 11, "card_rail": [ "1. IPTC — Photo Metadata IPTC", "2. IPTC — IPTC Photo Metadata Standard", "3. IPTC — IPTC Photo Metadata Standard 2025.1", "4. IPTC — IPTC Photo Metadata User Guide", "5. IPTC — IPTC Photo Metadata Standard adds new properties for AI-generated content - IPTC", "6. Wikipedia — IPTC Information Interchange Model - Wikipedia", "7. IPTC — IPTC Guidelines & Support", "8. NeededApps — What Is Image Metadata? EXIF, IPTC and XMP Explained - NeededApps", "9. IPTC — Google Images and IPTC: Frequently Asked Questions", "10. Chrome Web Store — IPTC Photo Metadata inspector - Chrome Web Store - Google", "11. YouTube·IPTC — Introduction and welcome, 20 years of IPTC Photo Metadata, Recent work ..." ], "claims": [ "T1-1 lede: 'You can explore the official IPTC Photo Metadata Standard to manage, describe, and protect digital images.' (two markers)", "T1-2 definition: 'A universally accepted industry standard for embedding administrative, descriptive, and copyright data directly into image files.' (two markers)", "T1-3 file formats: 'Supported across formats like JPEG, TIFF, and PNG, using the IPTC Core and Extension Schemas as well as Adobe's XMP framework.' (two markers)", "T1-4 difference from Exif: 'While EXIF focuses on technical camera data (shutter speed, ISO, lens settings), IPTC focuses on human-readable details like captions, keywords, and creator credits.' (one marker)", "T1-5 descriptive: 'Includes Alt Text, Headline, Description/Caption, Keywords, and Subject Codes.'", "T1-6 administrative: 'Tracks Creation Date, Digital Source Type, Image GUIDs, and registry IDs.'", "T1-7 rights: 'Stores Creator (Photographer), Copyright Notice, Licensor, and usage terms.'", "T1-8 'AI & Content Provenance: Recent standards (such as version 2025.1) include fields for AI System Used, AI System Version, AI Prompt Information, and AI Prompt Writer Name.' (three markers)", "T1-9 asset management: 'Helps archives, news agencies, and stock libraries search and sort massive libraries.'", "T1-10 'Search & Google Images: Search engines read embedded IPTC data to display creator information and licensing attributes directly in search results.'", "T1-11 tools: 'You can inspect embedded data using tools like the IPTC Photo Metadata Inspector or GetPMD.' (six markers)", "T1-12 closer: 'Are you looking to embed IPTC metadata into your own photos, or do you need help reading and extracting metadata from a specific image?'" ], "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/T1-iptc-photo-metadata-aio-20261029.txt" } ] }, "KO": { "title": "The IPTC photo metadata tests", "genre": "knowledge object, equal case, under EA-NEGONT-02 v0.9 (#1690): the archive's sources and the field's admitted on equal terms, ontology included, in one claim space", "status": "composed 2026-10-29 under v0.9 (briefs rebuild/negative-of-the-negative/v09/BRIEF-NEW-ROW-AGGREGATOR.md and BRIEF-NEW-ROW-PROVENANCE.md); not frozen; ledgers unaudited", "sentences": [ { "n": 1, "para": 0, "sense": "what the tests are", "text": "The IPTC photo metadata tests are the IPTC Photo Metadata Working Group's checks of what image-sharing sites and systems for sharing files and messages do to the metadata embedded in an uploaded photograph: the IPTC \"checks about a dozen sites regularly: in 2013, in 2016 and now again in Spring 2019,\" each time against its own claim that \"embedded metadata should not be removed\" from shared images (IPTC, Social Media Sites Photo Metadata Test Results 2019), and the provenance census record names the series, gives its operator as the IPTC's Photo Metadata Working Group, and records that it both expresses and tests provenance (provenance census record).", "claims": [ "F36", "F37", "PE-01", "PE-02", "PE-04" ] }, { "n": 2, "para": 0, "sense": "what the tests are", "text": "Each test uploads an image whose embedded values are all known, \"e.g. the latest Reference Image File,\" checks what the site displays, saves the image with the browser's Save As and downloads it through the system, and asks of each file whether \"the embedded Exif and IPTC metadata (in the formats IIM and XMP) of the uploaded image\" are \"still embedded\" (2019 page); the census record keeps the same operations as the transformations tested, embedded metadata inside the file as the carrier, and the site or system as the unit (provenance census record).", "claims": [ "F38", "F39", "PE-09", "PE-07", "PE-08" ] }, { "n": 3, "para": 0, "sense": "what the tests track", "text": "Four fields are checked on display, \"Caption/description, Creator, Copyright Notice, Credit Line (= the 4Cs )\" (2019 page), which the census record carries as the relations tested: creation, credit, rights and description (provenance census record).", "claims": [ "F40", "PE-06" ] }, { "n": 4, "para": 1, "sense": "origin and cadence", "text": "The IPTC gives the series its origin: users \"discovered that when they shared photos via social media sites or systems, their embedded metadata disappeared,\" and the Working Group \"tested 15 social media sites in 2016 and 2013 to understand how image sharing, through upload and download, affects the integrity of embedded metadata\" (IPTC, Photo Metadata Research).", "claims": [ "F47", "F48" ] }, { "n": 5, "para": 1, "sense": "what the tests are", "text": "The research is the IPTC's second activity beside the standard, \"IPTC not only defines the standard for photo metadata, but also conducts research about how photo metadata is used and implemented\" (Research page), and the IPTC's Photo Metadata page, the composition's first card, says so in the same terms and adds: \"The removal of rights information as images are transferred is of particular concern\" (IPTC, Photo Metadata).", "claims": [ "F46", "F3" ] }, { "n": 6, "para": 1, "sense": "origin and cadence", "text": "The census record dates the series to 2013, 2016 and Spring 2019, with a software test published in August 2014, counts 15 sites in 2016 and 2013 and about a dozen in 2019, and was read on 2026-10-29 (provenance census record).", "claims": [ "PE-11", "PE-12", "PE-14" ] }, { "n": 7, "para": 2, "sense": "the 2019 results", "text": "In the Spring 2019 tables Pexels, pixabay and Unsplash strip the metadata from saved and downloaded files, and on Flickr the \"Embedded Creator\" is \"replaced by account owner\" while saved files lose their XMP (2019 page).", "claims": [ "F41", "F42" ] }, { "n": 8, "para": 2, "sense": "the 2019 results", "text": "Among the systems for sharing files and messages, Facebook keeps \"A few rights related fields\" in IIM and Exif and writes two IIM fields of its own, Twitter strips saved files, and Dropbox and OneDrive pass the original through while their previews save \"with stripped off metadata\"; Behance's saved files \"keep the embedded metadata\" (2019 page).", "claims": [ "F43", "F44", "F45" ] }, { "n": 9, "para": 2, "sense": "the 2019 results", "text": "The census record keeps the same year and the same losses as its retention results: of eleven image-sharing sites, Pexels, pixabay and Unsplash stripping, Flickr replacing the creator with the account owner, Twitter stripping on Save As, Facebook keeping a few rights fields (provenance census record).", "claims": [ "PE-10" ] }, { "n": 10, "para": 2, "sense": "the findings", "text": "The research page reads the series as showing that some sites \"remove embedded information like copyright notes, the name of the creator, the description and more, while others protect photographers’ data better,\" and that \"it is not impossible to preserve metadata in a workflow\"; its software study of August 2014 found rights fields in half of the programs tested, retrieval of embedded rights data in two out of three, and two programs that \"didn’t support rights metadata at all\" (Research page).", "claims": [ "F49", "F50" ] }, { "n": 11, "para": 3, "sense": "the norm", "text": "The norm the tests measure is the IPTC's own: its User Guide endorses the Embedded Metadata Manifesto, under which \"Copyright management information metadata must never be removed from the files,\" removal being \"forbidden by law in many countries,\" and its minimum set of fields \"is not a permission to strip off metadata\" (IPTC Photo Metadata User Guide, November 2025).", "claims": [ "F16", "F15" ] }, { "n": 12, "para": 3, "sense": "stripping in transit", "text": "The same guide and the IPTC's Google Images FAQ place the loss also in the sites that host images: a site's \"digital asset management system, content management system, image management system or content delivery network may be stripping out embedded metadata fields\" (User Guide), the metadata \"might be stripped from your images by some software on your site,\" a DAM, a CMS such as WordPress or Drupal, or a CDN such as Cloudflare (FAQ), and NeededApps' explainer holds that metadata is no \"infallible form of copyright protection because it can be removed or modified\" (NeededApps).", "claims": [ "F18", "F33", "F31" ] }, { "n": 13, "para": 3, "sense": "stripping in transit", "text": "The archive reads the same loss at other carriers and stages: in-pixel metadata \"survives screenshot, rehosting, filename change, metadata stripping, PDF embedding, and sidecar loss,\" so the archive's handwritten artifacts carry their metadata three times, \"in the pixels + embedded (IPTC/XMP/C2PA) + external\" (#1409), and the publication layer's provenance signals, C2PA manifests and structured metadata among them, \"are stripped or rendered invisible long before they reach the training corpus. The body text is what survives\" (#127).", "claims": [ "O1409-04", "O1409-05", "O127-01" ] }, { "n": 14, "para": 4, "sense": "the standard (the carrier)", "text": "The object the tests test is a distinct entity, the IPTC Photo Metadata Standard, which \"sets the industry standard for administrative, descriptive, and copyright information about images\" (IPTC, Photo Metadata): its properties are grouped \"into Administrative, Descriptive and Rights-related properties\" (Photo Metadata Standard 2025.1) in two schemas, IPTC Core and IPTC Extension, \"built on the legacy of the original IPTC-IIM\" (IPTC Photo Metadata Standard page), and the census record gives the object they bear on as \"the photograph as a file: embedded Exif and IPTC metadata (IIM and XMP)\" (provenance census record).", "claims": [ "F1", "F10", "F5", "PE-05" ] }, { "n": 15, "para": 4, "sense": "the release", "text": "Its current release is 2025.1, \"including … IPTC Core Metadata Schema 1.5 … IPTC Extension Metadata Schema 1.9\" (specification, About the Standard), while the same specification heads its Extension section \"IPTC Extension schema 1.8 specifications\" (specification, contents and body).", "claims": [ "F9", "F12" ] }, { "n": 16, "para": 4, "sense": "genealogy", "text": "Its genealogy runs from the IIM, \"developed in the early 1990s by the International Press Telecommunications Council (IPTC) to expedite the international exchange of news\" (Wikipedia, IPTC Information Interchange Model), whose image properties were embedded as the \"IPTC header\" (Wikipedia, International Press Telecommunications Council; Wikipedia, IIM), to XMP, which \"has largely superseded IIM's file structure\" (Wikipedia, IIM), the IPTC having worked \"alongside Adobe\" on an implementation that \"employs Adobe’s XMP technology\" (Standard page); Core fields embedded in both formats must have their values synchronised by the image software (User Guide).", "claims": [ "F25", "F52", "F26", "F27", "F6", "F14" ] }, { "n": 17, "para": 4, "sense": "scope and limits", "text": "The standard leaves the file and the camera to others: how its formats are stored inside image files is \"defined by non-IPTC file format standards, such as JPEG/JFIF, TIFF, PNG and more\" (Standard page), and the specification \"does not include any technical metadata\" (specification), the capture data NeededApps assigns to Exif while IPTC metadata \"is commonly used to describe, organize and manage images\" (NeededApps).", "claims": [ "F8", "F11", "F30" ] }, { "n": 18, "para": 4, "sense": "reception and use", "text": "The IPTC calls it \"the most widely used standard to describe photos, because of its universal acceptance among news agencies, photographers, photo agencies, libraries, museums, and other related industries\" (Standard page), Wikipedia \"by far IPTC's most widely used standard\" for its \"nearly universal acceptance among photographers\" (Wikipedia, IIM), and its stated uses are \"protecting images' copyright and licensing information online\" and \"managing digital assets\" (IPTC, Photo Metadata).", "claims": [ "F4", "F28", "F2" ] }, { "n": 19, "para": 4, "sense": "the operator", "text": "Its operator, the International Press Telecommunications Council, is \"a consortium of the world's major news agencies, other news providers and news industry vendors\" that \"acts as the global standards body of the news media\" (Wikipedia, International Press Telecommunications Council), and its own conference video marks \"20 years of IPTC Photo Metadata\" (IPTC, YouTube, title only).", "claims": [ "F53", "F35" ] }, { "n": 20, "para": 5, "sense": "the AI properties", "text": "The 2025.1 release, announced by the Working Group on 27 November 2025, adds four properties \"for AI-generated content\", AI Prompt Information, AI Prompt Writer Name, AI System Used and AI System Version Used, the third defined as \"The AI engine and/or the model name used to generate this image\" (IPTC news; Standard page), beside the Data Mining property, a \"Data mining prohibition or permission, optionally with constraints\" (specification).", "claims": [ "F22", "F7", "F23", "F13" ] }, { "n": 21, "para": 5, "sense": "marking AI-generated images", "text": "The User Guide gives their purpose, to tell AI-generated images from \"regular\" ones \"to avoid re-training AI models on content that was already generated by a model,\" and recommends leaving Image Creator empty and setting Digital Source Type to trainedAlgorithmicMedia or compositeSynthetic (User Guide); the announcement records that writing the new properties into its example image \"has rendered the C2PA metadata invalid\" (IPTC news), and the census record marks the tests \"NOT a test of C2PA credentials\" (provenance census record).", "claims": [ "F19", "F20", "F21", "F24", "PE-16" ] }, { "n": 22, "para": 5, "sense": "the archive's layer", "text": "The archive places this layer of the standard: \"IPTC AI metadata\" is \"Layer 1 metadata\", \"Disclosure, not lineage\", where artifact provenance \"operates at the moment of artifact creation\" and the dimensions of provenance are independent, each preserved or destroyed \"regardless of the others\" (#725), and against the reading of provenance as \"a field, a tag, a manifest, a credential, separable from the object it documents,\" #725 holds that \"To strip provenance is to change what the meaning *is*\" (#725).", "claims": [ "O725-01", "O725-02", "O725-03" ] }, { "n": 23, "para": 5, "sense": "the archive's layer", "text": "The archive uses the standard's vocabulary for its own artifacts: Digital Source Type declared as digital capture of a physical original is \"the nonsynthetic claim made machine-readable inside the file,\" the archive's scaffold, \"everything machine-readable around the ink,\" takes in IPTC/XMP/EXIF, and \"C2PA, FADGI, and IPTC provenance vocabularies are the same insight arriving as standards\" as the archive's substrate checksum (#1409).", "claims": [ "O1409-06", "O1409-03", "R1409-07" ] }, { "n": 24, "para": 6, "sense": "who reads the fields", "text": "Google reads the embedded fields: it \"displays three IPTC photo metadata fields, wherever available,\" telling the viewer the creator, the copyright holder and the credit line (User Guide), a display \"introduced by Google in September 2018\" (IPTC Guidelines & Support), \"Google extracts this information from photos in search results\" (FAQ), and the IPTC's browser extension sends a web image to its GetPMD tool, \"which will display all metadata embedded in the image file\" (Chrome Web Store).", "claims": [ "F17", "F29", "F32", "F34" ] }, { "n": 25, "para": 6, "sense": "who reads the fields", "text": "The archive records the same channel as established for extraction and open for composition: IPTC photo metadata \"embedded in the file (travels with the image across pages),\" \"ESTABLISHED as extracted; composition role unknown,\" and \"scaffold the pipeline provably reads\" (#1409).", "claims": [ "O1409-01", "O1409-02" ] }, { "n": 26, "para": 7, "sense": "the record", "text": "The census record holds the series historical, \"the 2019 table is not a 2026 platform measurement,\" succeeded in method by the IPTC's Metawatch (2026), which it records as a part, with C2PA conformance its neighbour; it tags the series \"NOT a current platform audit,\" leaves the 2016 and 2013 tables, the 2014 software study and the interoperability procedures unchecked, and kinds it a test series (provenance census record).", "claims": [ "PE-13", "PE-15", "PE-17", "PE-18", "PE-03" ] }, { "n": 27, "para": 7, "sense": "the record", "text": "Its organizing question is asked of every entity alike: \"What provenance does this system carry, through which operation, on whose assertion, with what evidence of survival?\" (provenance census record).", "claims": [ "PE-19" ] }, { "n": 28, "para": 7, "sense": "the encyclopedia", "text": "Wikipedia has no article on the tests, and none at the title IPTC Photo Metadata (Wikipedia, as fetched 2026-10-29).", "claims": [ "F51" ] }, { "n": 29, "para": 8, "sense": "the composition", "text": "At the bare name on Google's AI Overview the Capture Registry gives the innocent reading first, the standard explained \"from the IPTC's own pages,\" and finds the standard held: \"Core and Extension, IIM and XMP, the 2025.1 release and its AI properties are the IPTC's own,\" with the IPTC named, \"no person; no identifier\" (Capture Registry, 2026-10-29).", "claims": [ "CAP-1-10", "CAP-1-01", "CAP-1-09" ] }, { "n": 30, "para": 8, "sense": "the composition", "text": "It records that the record at the name is the tests and their 2019 losses, that \"None of this is in the composition,\" which \"composes the carrier and leaves out the measurement of its erasure,\" gives the search engines' reading of the data and \"omits the loss,\" heads the 2025.1 properties \"AI & Content Provenance\" where the IPTC gives them as properties of AI-generated content, and cites no card of the record that landed the same day; it reads the capture as \"the baseline for the name\" and \"the measurement of stripping\" as \"a second address\" (Capture Registry, 2026-10-29).", "claims": [ "CAP-1-02", "CAP-1-03", "CAP-1-06", "CAP-1-04", "CAP-1-05", "CAP-1-08", "CAP-1-07" ] } ], "joins": [ { "act": "order of senses", "sentences": "1–30", "claims": [], "note": "equal case (§4.7): the entity's dependency order, field and archive claims ordered together, by genealogy within each sense; neither ledger placed first as a block. The entity is the tests (the census row and its own pages), so what they are and check (¶0) and their origin and cadence (¶1) come first, then their results and findings (¶2), the norm they measure against and the loss they measure, at the platforms and beyond (¶3); the standard follows as the carrier the tests test (¶4–5), then who reads the carrier (¶6), the record's own limits and the encyclopedia (¶7), and the composition at the name (¶8), a relation of the entity already composed." }, { "act": "holding apart (the tests and the standard)", "sentences": [ 1, 14 ], "claims": [ "F36", "F37", "F1", "F10", "F5", "PE-05" ], "note": "the address names the standard; the record and the entity are the tests (CAP-1-02). Sentence 14 introduces the standard as 'a distinct entity', the object the tests test; no claim about the standard is composed as a claim about the tests, and no claim of the tests as one about the standard." }, { "act": "holding together (the loss at platforms, at hosting systems, at other carriers)", "sentences": [ 11, 12, 13 ], "claims": [ "F16", "F15", "F18", "F33", "F31", "O1409-04", "O1409-05", "O127-01" ], "note": "the IPTC's norm, its own account of stripping by hosting systems, a third party's limit, and the archive's account of stripping at other carriers and stages (in-pixel metadata; the training corpus) stand together as one sense; each with its source; #127's stage (the training corpus) is named in the sentence." }, { "act": "holding apart (two readings of the 2025.1 properties)", "sentences": [ 20, 21, 22, 30 ], "claims": [ "F22", "F7", "CAP-1-05", "O725-01" ], "note": "P_coh: the IPTC gives the properties as properties of AI-generated content (F22, F7); the composition heads them 'AI & Content Provenance' (CAP-1-05); #725 classes IPTC AI metadata as 'Disclosure, not lineage' (O725-01). Composed each with its source; the composer does not rule." }, { "act": "holding apart (the source's own inconsistency)", "sentences": [ 15 ], "claims": [ "F9", "F12" ], "note": "internally_inconsistent (§4.3): the specification gives Extension 1.9 in 'About the Standard' and §4 and heads the Extension section '1.8'; both loci cited, opened." }, { "act": "holding apart (the Capture Registry's 'often gone' against the tests' scope)", "sentences": [ 7, 8, 9, 12, 30 ], "claims": [ "CAP-1-04", "F41", "F42", "F43", "F44", "F45", "F18", "F33" ], "note": "P_coh: the registry's interpretation that the data 'is often gone before any engine can read it' is composed at its modality beside the 2019 tables (sharing platforms) and the IPTC's own warnings (hosting systems); opened." } ], "plan": { "order": [ "F36", "F37", "PE-01", "PE-02", "PE-04", "F38", "F39", "PE-09", "PE-07", "PE-08", "F40", "PE-06", "F47", "F48", "F46", "F3", "PE-11", "PE-12", "PE-14", "F41", "F42", "F43", "F44", "F45", "PE-10", "F49", "F50", "F16", "F15", "F18", "F33", "F31", "O1409-04", "O1409-05", "O127-01", "F1", "F10", "F5", "PE-05", "F9", "F12", "F25", "F52", "F26", "F27", "F6", "F14", "F8", "F11", "F30", "F4", "F28", "F2", "F53", "F35", "F22", "F7", "F23", "F13", "F19", "F20", "F21", "F24", "PE-16", "O725-01", "O725-02", "O725-03", "O1409-06", "O1409-03", "R1409-07", "F17", "F29", "F32", "F34", "O1409-01", "O1409-02", "PE-13", "PE-15", "PE-17", "PE-18", "PE-03", "PE-19", "F51", "CAP-1-10", "CAP-1-01", "CAP-1-09", "CAP-1-02", "CAP-1-03", "CAP-1-06", "CAP-1-04", "CAP-1-05", "CAP-1-08", "CAP-1-07" ], "senses": { "what the tests are": [ 1, 2, 5 ], "what the tests track": [ 3 ], "origin and cadence": [ 4, 6 ], "the 2019 results": [ 7, 8, 9 ], "the findings": [ 10 ], "the norm": [ 11 ], "stripping in transit": [ 12, 13 ], "the standard (the carrier)": [ 14 ], "the release": [ 15 ], "genealogy": [ 16 ], "scope and limits": [ 17 ], "reception and use": [ 18 ], "the operator": [ 19 ], "the AI properties": [ 20 ], "marking AI-generated images": [ 21 ], "the archive's layer": [ 22, 23 ], "who reads the fields": [ 24, 25 ], "the record": [ 26, 27 ], "the encyclopedia": [ 28 ], "the composition": [ 29, 30 ] }, "case_by_sense": { "equal (one claim space; nothing translated)": [ "what the tests are", "what the tests track", "origin and cadence", "the 2019 results", "the findings", "the norm", "stripping in transit", "the standard (the carrier)", "the release", "genealogy", "scope and limits", "reception and use", "the operator", "the AI properties", "marking AI-generated images", "the archive's layer", "who reads the fields", "the record", "the encyclopedia", "the composition" ] }, "carried": { "archive": 40, "field": 53, "not_composed": {} }, "conflict_log": [ { "rule": "D_pres vs channel", "result": "no cut: the KO carries every field and archive claim; the compression's bound met (body 345 words) with no channel log" }, { "rule": "P_coh", "result": "F9 against F12 (sentence 15; the source's own inconsistency, marked); F22/F7 beside CAP-1-05 and O725-01 (sentences 20, 22, 30); CAP-1-04 beside F41–F45 and F18, F33 (sentences 7–9, 12, 30): each composed with its source, opened" }, { "rule": "N_c", "result": "no claim lowered by standing; F18 and F33 carried at their own modality (hypothesis: 'may', 'might'); CAP-1-04 carried as the interpretation it is" }, { "rule": "C_ex", "result": "senses composed ⊇ senses in the ledgers: 20 senses, every ledger lineage cited in the KO" } ] } }, "P": { "title": "IPTC photo metadata tests", "lede": { "text": "are the IPTC Photo Metadata Working Group's tests of what sharing sites and systems do to the metadata embedded in a photograph: upload, view, save, download, then check whether its Exif and IPTC fields survive (2013, 2016, 2019). The IPTC Photo Metadata Standard they test is a distinct object (2019 page; census record).", "claims": [ "F37", "F38", "F39", "PE-02", "PE-09", "PE-01", "F1" ] }, "sections": [ { "icon": "🧪", "head": "The tests", "items": [ { "label": "What they check:", "text": "the IPTC's claim that \"embedded metadata should not be removed\"; the 4Cs (caption, creator, copyright notice, credit line) shown and kept (2019 page; census record).", "claims": [ "F36", "F40", "PE-06", "PE-07" ] }, { "label": "Origin:", "text": "users' embedded metadata \"disappeared\" when shared; 15 sites tested in 2013 and 2016, about a dozen in 2019 (Research page; census record).", "claims": [ "F47", "F48", "PE-11", "PE-12" ] } ] }, { "icon": "📉", "head": "What they found", "items": [ { "label": "2019:", "text": "Pexels, pixabay, Unsplash strip saved and downloaded files; Flickr swaps in the account owner as creator; Twitter strips; Facebook keeps a few rights fields; Behance keeps them (2019 page; census record).", "claims": [ "F41", "F42", "F43", "F45", "PE-10" ] }, { "label": "Reading:", "text": "\"not impossible to preserve metadata in a workflow\"; a 2014 study found rights fields in half the programs (Research page).", "claims": [ "F49", "F50" ] }, { "label": "Beyond platforms:", "text": "DAMs, CMSs and CDNs strip too, against the IPTC's rule that rights metadata \"must never be removed\" (User Guide; FAQ; NeededApps).", "claims": [ "F16", "F18", "F33", "F31" ] }, { "label": "The archive:", "text": "in-pixel metadata survives the stripping embedded metadata does not; publication-layer signals are stripped before training: \"The body text is what survives\" (#1409; #127).", "claims": [ "O1409-04", "O1409-05", "O127-01" ] } ] }, { "icon": "📐", "head": "The standard they test", "items": [ { "label": "What it is:", "text": "Core and Extension properties (administrative, descriptive, rights), from the 1990s IIM, embedded as IIM and XMP; 2025.1: Core 1.5, Extension 1.9 (IPTC; Wikipedia).", "claims": [ "F10", "F5", "PE-05", "F9", "F25", "F52", "F26", "F27", "F6", "F14" ] }, { "label": "AI fields:", "text": "four 2025.1 properties for AI-generated content; writing them invalidated an image's C2PA metadata (IPTC news).", "claims": [ "F22", "F7", "F24" ] }, { "label": "The archive:", "text": "IPTC AI metadata is \"Layer 1 metadata\", \"Disclosure, not lineage\" (#725); embedded fields are scaffold the pipeline reads, its composition role unknown (#1409).", "claims": [ "O725-01", "O1409-03", "O1409-01", "O1409-02" ] }, { "label": "Who reads it:", "text": "Google Images shows creator, credit and copyright; the IPTC's inspector shows the rest (User Guide; FAQ; Chrome Web Store).", "claims": [ "F17", "F32", "F34" ] } ] }, { "icon": "🗂️", "head": "The record", "items": [ { "label": "Lifecycle:", "text": "historical, dated tables, \"NOT a current platform audit\"; succeeded in method by Metawatch (census record).", "claims": [ "PE-13", "PE-15", "PE-17" ] }, { "label": "Wikipedia:", "text": "no article on the tests.", "claims": [ "F51" ] } ] }, { "icon": "🔎", "head": "At this address", "items": [ { "label": "The Overview:", "text": "composes the standard from the IPTC's pages, leaving out the tests and their losses; no card cites the record (Capture Registry, 2026-10-29).", "claims": [ "CAP-1-10", "CAP-1-02", "CAP-1-03", "CAP-1-06", "CAP-1-08" ] } ] } ], "open": [ { "question": "Do the 2019 losses still hold on the same sites in 2026?", "rests_on": [ "F41", "F42", "F43", "F44", "F45", "PE-10", "PE-13", "PE-15" ], "modality": "documented (the 2019 tables); self-description (the record's limit: not a current audit)", "would_resolve": "a run of the 2019 procedure on the same sites and systems, or the Metawatch results for news publishers (census row iptc-metawatch)" }, { "question": "Is the current Extension schema 1.9 or 1.8?", "rests_on": [ "F9", "F12" ], "modality": "documented, both, in one specification (internally_inconsistent)", "would_resolve": "the 2025.1 TechReference (iptc-pmd-techreference_2025.1.json) or a corrected contents heading" }, { "question": "Does embedded IPTC data reach the composition, or only the image display?", "rests_on": [ "O1409-01", "O1409-02", "F17", "F32", "CAP-1-04" ], "modality": "interpretation (#1409: composition role unknown); documented (Google's display)", "would_resolve": "a capture in which a composition states a creator or credit that only an image's embedded fields carry" }, { "question": "Is the data 'often gone before any engine can read it'?", "rests_on": [ "CAP-1-04", "F41", "F42", "F43", "F44", "F45", "F18", "F33" ], "modality": "interpretation (the Capture Registry) against documented (2019, sharing platforms) and hypothesis (User Guide, FAQ: hosting sites' systems)", "would_resolve": "a test of the hosting pipelines whose files Google Images reads (DAM, CMS, CDN), which the 2019 tests did not measure" }, { "question": "How are IPTC fields written into a C2PA-signed image without invalidating it?", "rests_on": [ "F24", "PE-16", "R1409-07", "O1409-05" ], "modality": "documented (the announcement's example)", "would_resolve": "IPTC or C2PA guidance on adding IPTC properties as a signed edit, tested on the reference image" }, { "question": "What do the 2013 and 2016 tables and the 2014 software study show?", "rests_on": [ "PE-18", "F48", "F50" ], "modality": "self-description (the record's unchecked list)", "would_resolve": "reading the IPTC's earlier results pages" } ], "genre": "the compression: AIO's interaction grammar (lede, headed clusters, bolded labels, card rail), composed from the v0.9 plan in one claim space; it faces on the card, with AIO's transcript a record within it", "status": "composed 2026-10-29 from the v0.9 knowledge object; not frozen", "rail": [ { "lineage": "the tests: what they are and what they check", "claims": [ "F36", "F37", "PE-01", "PE-04", "F38", "F39", "PE-09", "PE-07", "PE-08", "F46", "F3", "CAP-1-02" ], "earliest": "B12" }, { "lineage": "the operator: the IPTC and its Photo Metadata Working Group", "claims": [ "PE-02", "F53", "F35" ], "earliest": "B15" }, { "lineage": "what the tests track: the 4Cs in the file", "claims": [ "F40", "PE-06" ], "earliest": "B12" }, { "lineage": "the tests: origin, cadence and count", "claims": [ "F47", "F48", "PE-11", "PE-12", "PE-14" ], "earliest": "B13" }, { "lineage": "the 2019 results: stripped, replaced, kept", "claims": [ "F41", "F42", "F43", "F44", "F45", "PE-10" ], "earliest": "B12" }, { "lineage": "the tests' findings and the software study", "claims": [ "F49", "F50" ], "earliest": "B13" }, { "lineage": "the norm the tests measure against: embedded metadata must not be removed", "claims": [ "F16", "F15" ], "earliest": "B4" }, { "lineage": "stripping in transit: where the carrier is lost", "claims": [ "F18", "F33", "F31", "O1409-04", "O1409-05", "O127-01" ], "earliest": "B4" }, { "lineage": "the standard: what it is (the carrier the tests test)", "claims": [ "F1", "F10", "F5", "PE-05" ], "earliest": "B3" }, { "lineage": "the standard's release: 2025.1, Core 1.5, Extension 1.9", "claims": [ "F9", "F12" ], "earliest": "B3" }, { "lineage": "the standard's genealogy: IIM, IPTC headers, XMP", "claims": [ "F25", "F52", "F26", "F27", "F6", "F14" ], "earliest": "B4" }, { "lineage": "the standard's scope and limits: file formats, no technical metadata", "claims": [ "F8", "F11", "F30" ], "earliest": "B3" }, { "lineage": "the standard's reception and use", "claims": [ "F4", "F28", "F2" ], "earliest": "B1" }, { "lineage": "the 2025.1 properties for AI-generated content", "claims": [ "F22", "F7", "F23", "F13", "CAP-1-05" ], "earliest": "B3" }, { "lineage": "marking AI-generated images, and the C2PA metadata invalidated", "claims": [ "F19", "F20", "F21", "F24", "PE-16" ], "earliest": "B4" }, { "lineage": "the archive's layer for the carrier", "claims": [ "O725-01", "O725-02", "O725-03", "O1409-06", "O1409-03", "R1409-07" ], "earliest": 725 }, { "lineage": "who reads the embedded fields: Google Images and the IPTC's tools", "claims": [ "F17", "F29", "F32", "F34", "O1409-01", "O1409-02", "CAP-1-04" ], "earliest": "B10" }, { "lineage": "the record: lifecycle, limits and relations", "claims": [ "PE-13", "PE-15", "PE-17", "PE-18", "PE-03", "PE-19" ], "earliest": "provenance-census" }, { "lineage": "reception: the encyclopedia", "claims": [ "F51" ], "earliest": "B14" }, { "lineage": "the composition at the name", "claims": [ "CAP-1-10", "CAP-1-01", "CAP-1-09", "CAP-1-03", "CAP-1-06", "CAP-1-08", "CAP-1-07" ], "earliest": "capture-registry" } ], "body_words": 345, "entity": "Composed under v0.9, equal case (ρ = extends): KO_B sentences surviving 0 of 14; every field claim carried." }, "P_B": { "title": "IPTC Photo Metadata", "lede": { "text": "is the IPTC's industry standard for administrative, descriptive and copyright information embedded in image files, in IPTC Core and Extension; the IPTC also tests what sharing sites do to it (IPTC pages; specification).", "claims": [ "F1", "F10", "F5", "F3", "F37" ] }, "sections": [ { "icon": "📐", "head": "The standard", "items": [ { "label": "Release:", "text": "2025.1, Core 1.5 and Extension 1.9 (contents say 1.8) (specification).", "claims": [ "F9", "F12" ] }, { "label": "History:", "text": "IIM in the 1990s, 'IPTC headers', then XMP with Adobe (Wikipedia; Standard page).", "claims": [ "F25", "F26", "F27", "F52", "F6", "F14" ] }, { "label": "Scope:", "text": "no file-format or technical camera data, unlike Exif (Standard page; NeededApps).", "claims": [ "F8", "F11", "F30" ] }, { "label": "Use:", "text": "copyright, licensing, asset management; widely accepted (IPTC; Wikipedia).", "claims": [ "F4", "F28", "F2", "F53", "F35" ] }, { "label": "AI fields:", "text": "four 2025.1 properties; C2PA metadata invalidated in the example (IPTC news; User Guide).", "claims": [ "F22", "F7", "F23", "F13", "F19", "F20", "F21", "F24" ] }, { "label": "Readers:", "text": "Google Images since 2018; the IPTC inspector and GetPMD (User Guide; FAQ).", "claims": [ "F17", "F29", "F32", "F34" ] } ] }, { "icon": "🧪", "head": "The tests", "items": [ { "label": "Method:", "text": "upload, view, Save As, download; the 4Cs (2019 page; Research page).", "claims": [ "F46", "F47", "F48", "F36", "F38", "F39", "F40" ] }, { "label": "2019:", "text": "Pexels, pixabay, Unsplash strip; Flickr replaces the creator; Behance keeps (2019 page).", "claims": [ "F41", "F42", "F43", "F44", "F45", "F49", "F50" ] }, { "label": "Stripping:", "text": "DAMs, CMSs and CDNs too; rights metadata must not be removed (User Guide; FAQ; NeededApps).", "claims": [ "F15", "F16", "F18", "F33", "F31" ] }, { "label": "Wikipedia:", "text": "no article on the tests.", "claims": [ "F51" ] } ] } ], "open": [ { "question": "Extension 1.9 or 1.8?", "rests_on": [ "F9", "F12" ], "modality": "documented, both", "would_resolve": "the 2025.1 TechReference" }, { "question": "Do the 2019 losses hold today?", "rests_on": [ "F41", "F42", "F43" ], "modality": "documented (2019)", "would_resolve": "a new run of the procedure" } ], "arm": "B (the field alone)", "genre": "popup — the compression from the field ledger alone (cards, own pages, Wikipedia)", "status": "composed 2026-10-29 from the field ledger alone; not frozen", "rail": [ { "lineage": "the standard: what it is (the carrier the tests test)", "claims": [ "F1", "F10", "F5" ], "earliest": "B3" }, { "lineage": "the standard's release: 2025.1, Core 1.5, Extension 1.9", "claims": [ "F9", "F12" ], "earliest": "B3" }, { "lineage": "the standard's genealogy: IIM, IPTC headers, XMP", "claims": [ "F25", "F52", "F26", "F27", "F6", "F14" ], "earliest": "B4" }, { "lineage": "the standard's scope and limits: file formats, no technical metadata", "claims": [ "F8", "F11", "F30" ], "earliest": "B3" }, { "lineage": "the standard's reception and use", "claims": [ "F4", "F28", "F2" ], "earliest": "B1" }, { "lineage": "the operator: the IPTC and its Photo Metadata Working Group", "claims": [ "F53", "F35" ], "earliest": "B15" }, { "lineage": "the 2025.1 properties for AI-generated content", "claims": [ "F22", "F7", "F23", "F13" ], "earliest": "B3" }, { "lineage": "marking AI-generated images, and the C2PA metadata invalidated", "claims": [ "F19", "F20", "F21", "F24" ], "earliest": "B4" }, { "lineage": "who reads the embedded fields: Google Images and the IPTC's tools", "claims": [ "F17", "F29", "F32", "F34" ], "earliest": "B10" }, { "lineage": "the tests: what they are and what they check", "claims": [ "F36", "F37", "F38", "F39", "F46", "F3" ], "earliest": "B12" }, { "lineage": "the tests: origin, cadence and count", "claims": [ "F47", "F48" ], "earliest": "B13" }, { "lineage": "what the tests track: the 4Cs in the file", "claims": [ "F40" ], "earliest": "B12" }, { "lineage": "the 2019 results: stripped, replaced, kept", "claims": [ "F41", "F42", "F43", "F44", "F45" ], "earliest": "B12" }, { "lineage": "the tests' findings and the software study", "claims": [ "F49", "F50" ], "earliest": "B13" }, { "lineage": "the norm the tests measure against: embedded metadata must not be removed", "claims": [ "F16", "F15" ], "earliest": "B4" }, { "lineage": "stripping in transit: where the carrier is lost", "claims": [ "F18", "F33", "F31" ], "earliest": "B4" }, { "lineage": "reception: the encyclopedia", "claims": [ "F51" ], "earliest": "B14" } ], "body_words": 159, "entity": "With no archive claim admitted, the entry opens on what the cards give, the standard, and reaches the tests through the IPTC's own pages." }, "KO_B": { "title": "IPTC Photo Metadata", "arm": "B (the field alone)", "genre": "knowledge object", "status": "composed 2026-10-29; not frozen", "sentences": [ { "n": 1, "para": 0, "text": "IPTC Photo Metadata is the industry standard for administrative, descriptive and copyright information about images, its properties grouped as administrative, descriptive and rights-related in two schemas, Core and Extension, built on the legacy IIM (IPTC pages; specification).", "claims": [ "F1", "F10", "F5" ] }, { "n": 2, "para": 0, "text": "The current release, 2025.1, includes Core 1.5 and Extension 1.9, though the specification's contents head the Extension section 1.8 (specification).", "claims": [ "F9", "F12" ] }, { "n": 3, "para": 0, "text": "The IPTC developed the IIM in the early 1990s for news exchange; its image fields became the 'IPTC headers', and XMP, implemented with Adobe, has largely superseded IIM's structure, the two kept in sync by software (Wikipedia; Standard page; User Guide).", "claims": [ "F25", "F26", "F27", "F52", "F6", "F14" ] }, { "n": 4, "para": 0, "text": "File formats are defined by non-IPTC standards and technical camera data is excluded, which is where Exif differs (Standard page; specification; NeededApps).", "claims": [ "F8", "F11", "F30" ] }, { "n": 5, "para": 1, "text": "It is called the most widely used photo standard, by near-universal acceptance, and serves copyright, licensing and asset management; its operator is the London consortium of news agencies, whose video marks twenty years of the standard (IPTC; Wikipedia; YouTube).", "claims": [ "F4", "F28", "F2", "F53", "F35" ] }, { "n": 6, "para": 1, "text": "Version 2025.1, released 27 November 2025, adds four properties for AI-generated content, such as AI System Used, beside the Data Mining property (IPTC news; Standard page; specification).", "claims": [ "F22", "F7", "F23", "F13" ] }, { "n": 7, "para": 1, "text": "For AI-generated images the guide recommends an empty Image Creator and a synthetic Digital Source Type, to avoid re-training on generated content; adding the fields invalidated the example image's C2PA metadata (User Guide; IPTC news).", "claims": [ "F19", "F20", "F21", "F24" ] }, { "n": 8, "para": 2, "text": "Google Images has displayed creator, credit and copyright from embedded fields since 2018, and the IPTC's inspector and GetPMD show the rest (User Guide; Guidelines; FAQ; Chrome Web Store).", "claims": [ "F17", "F29", "F32", "F34" ] }, { "n": 9, "para": 3, "text": "The IPTC also researches how photo metadata is used, prompted by users whose embedded metadata disappeared on social media; it tested 15 sites in 2013 and 2016 and about a dozen in 2019 against its claim that embedded metadata should not be removed (Photo Metadata page; Research page; 2019 page).", "claims": [ "F46", "F3", "F47", "F48", "F36", "F37" ] }, { "n": 10, "para": 3, "text": "Each test uploads a fully described image, checks the display of caption, creator, copyright notice and credit line, and checks Save As and downloaded files for the embedded Exif and IPTC (2019 page).", "claims": [ "F38", "F39", "F40" ] }, { "n": 11, "para": 3, "text": "In 2019 Pexels, pixabay and Unsplash stripped saved and downloaded files, Flickr replaced the creator with the account owner, Twitter stripped, Facebook kept a few rights fields, Dropbox and OneDrive previews were stripped, and Behance kept the metadata (2019 page).", "claims": [ "F41", "F42", "F43", "F44", "F45" ] }, { "n": 12, "para": 3, "text": "The research concludes that preserving metadata in a workflow is not impossible; a 2014 software study found rights fields in half the programs (Research page).", "claims": [ "F49", "F50" ] }, { "n": 13, "para": 4, "text": "The IPTC holds that rights metadata must never be removed and warns that DAMs, CMSs and CDNs may strip it; a third-party explainer adds that metadata can be removed or modified (User Guide; FAQ; NeededApps).", "claims": [ "F15", "F16", "F18", "F33", "F31" ] }, { "n": 14, "para": 4, "text": "Wikipedia has no article on the tests (Wikipedia).", "claims": [ "F51" ] } ] }, "L_B": { "words": 446, "text": "IPTC Photo Metadata is the industry standard for administrative, descriptive and copyright information about images, its properties grouped as administrative, descriptive and rights-related in two schemas, Core and Extension, built on the legacy IIM (IPTC pages; specification). The current release, 2025.1, includes Core 1.5 and Extension 1.9, though the specification's contents head the Extension section 1.8 (specification). The IPTC developed the IIM in the early 1990s for news exchange; its image fields became the 'IPTC headers', and XMP, implemented with Adobe, has largely superseded IIM's structure, the two kept in sync by software (Wikipedia; Standard page; User Guide). File formats are defined by non-IPTC standards and technical camera data is excluded, which is where Exif differs (Standard page; specification; NeededApps). It is called the most widely used photo standard, by near-universal acceptance, and serves copyright, licensing and asset management; its operator is the London consortium of news agencies, whose video marks twenty years of the standard (IPTC; Wikipedia; YouTube). Version 2025.1, released 27 November 2025, adds four properties for AI-generated content, such as AI System Used, beside the Data Mining property (IPTC news; Standard page; specification). For AI-generated images the guide recommends an empty Image Creator and a synthetic Digital Source Type, to avoid re-training on generated content; adding the fields invalidated the example image's C2PA metadata (User Guide; IPTC news). Google Images has displayed creator, credit and copyright from embedded fields since 2018, and the IPTC's inspector and GetPMD show the rest (User Guide; Guidelines; FAQ; Chrome Web Store). The IPTC also researches how photo metadata is used, prompted by users whose embedded metadata disappeared on social media; it tested 15 sites in 2013 and 2016 and about a dozen in 2019 against its claim that embedded metadata should not be removed (Photo Metadata page; Research page; 2019 page). Each test uploads a fully described image, checks the display of caption, creator, copyright notice and credit line, and checks Save As and downloaded files for the embedded Exif and IPTC (2019 page). In 2019 Pexels, pixabay and Unsplash stripped saved and downloaded files, Flickr replaced the creator with the account owner, Twitter stripped, Facebook kept a few rights fields, Dropbox and OneDrive previews were stripped, and Behance kept the metadata (2019 page). The research concludes that preserving metadata in a workflow is not impossible; a 2014 software study found rights fields in half the programs (Research page). The IPTC holds that rights metadata must never be removed and warns that DAMs, CMSs and CDNs may strip it; a third-party explainer adds that metadata can be removed or modified (User Guide; FAQ; NeededApps). Wikipedia has no article on the tests (Wikipedia).", "note": "L_F(B) is realized as the field arm's expansion (objects.KO_B): the field alone, cards, own pages and Wikipedia." }, "L_BA": { "words": 1938, "text": "The IPTC photo metadata tests are the IPTC Photo Metadata Working Group's checks of what image-sharing sites and systems for sharing files and messages do to the metadata embedded in an uploaded photograph: the IPTC \"checks about a dozen sites regularly: in 2013, in 2016 and now again in Spring 2019,\" each time against its own claim that \"embedded metadata should not be removed\" from shared images (IPTC, Social Media Sites Photo Metadata Test Results 2019), and the provenance census record names the series, gives its operator as the IPTC's Photo Metadata Working Group, and records that it both expresses and tests provenance (provenance census record). Each test uploads an image whose embedded values are all known, \"e.g. the latest Reference Image File,\" checks what the site displays, saves the image with the browser's Save As and downloads it through the system, and asks of each file whether \"the embedded Exif and IPTC metadata (in the formats IIM and XMP) of the uploaded image\" are \"still embedded\" (2019 page); the census record keeps the same operations as the transformations tested, embedded metadata inside the file as the carrier, and the site or system as the unit (provenance census record). Four fields are checked on display, \"Caption/description, Creator, Copyright Notice, Credit Line (= the 4Cs )\" (2019 page), which the census record carries as the relations tested: creation, credit, rights and description (provenance census record). The IPTC gives the series its origin: users \"discovered that when they shared photos via social media sites or systems, their embedded metadata disappeared,\" and the Working Group \"tested 15 social media sites in 2016 and 2013 to understand how image sharing, through upload and download, affects the integrity of embedded metadata\" (IPTC, Photo Metadata Research). The research is the IPTC's second activity beside the standard, \"IPTC not only defines the standard for photo metadata, but also conducts research about how photo metadata is used and implemented\" (Research page), and the IPTC's Photo Metadata page, the composition's first card, says so in the same terms and adds: \"The removal of rights information as images are transferred is of particular concern\" (IPTC, Photo Metadata). The census record dates the series to 2013, 2016 and Spring 2019, with a software test published in August 2014, counts 15 sites in 2016 and 2013 and about a dozen in 2019, and was read on 2026-10-29 (provenance census record). In the Spring 2019 tables Pexels, pixabay and Unsplash strip the metadata from saved and downloaded files, and on Flickr the \"Embedded Creator\" is \"replaced by account owner\" while saved files lose their XMP (2019 page). Among the systems for sharing files and messages, Facebook keeps \"A few rights related fields\" in IIM and Exif and writes two IIM fields of its own, Twitter strips saved files, and Dropbox and OneDrive pass the original through while their previews save \"with stripped off metadata\"; Behance's saved files \"keep the embedded metadata\" (2019 page). The census record keeps the same year and the same losses as its retention results: of eleven image-sharing sites, Pexels, pixabay and Unsplash stripping, Flickr replacing the creator with the account owner, Twitter stripping on Save As, Facebook keeping a few rights fields (provenance census record). The research page reads the series as showing that some sites \"remove embedded information like copyright notes, the name of the creator, the description and more, while others protect photographers’ data better,\" and that \"it is not impossible to preserve metadata in a workflow\"; its software study of August 2014 found rights fields in half of the programs tested, retrieval of embedded rights data in two out of three, and two programs that \"didn’t support rights metadata at all\" (Research page). The norm the tests measure is the IPTC's own: its User Guide endorses the Embedded Metadata Manifesto, under which \"Copyright management information metadata must never be removed from the files,\" removal being \"forbidden by law in many countries,\" and its minimum set of fields \"is not a permission to strip off metadata\" (IPTC Photo Metadata User Guide, November 2025). The same guide and the IPTC's Google Images FAQ place the loss also in the sites that host images: a site's \"digital asset management system, content management system, image management system or content delivery network may be stripping out embedded metadata fields\" (User Guide), the metadata \"might be stripped from your images by some software on your site,\" a DAM, a CMS such as WordPress or Drupal, or a CDN such as Cloudflare (FAQ), and NeededApps' explainer holds that metadata is no \"infallible form of copyright protection because it can be removed or modified\" (NeededApps). The archive reads the same loss at other carriers and stages: in-pixel metadata \"survives screenshot, rehosting, filename change, metadata stripping, PDF embedding, and sidecar loss,\" so the archive's handwritten artifacts carry their metadata three times, \"in the pixels + embedded (IPTC/XMP/C2PA) + external\" (#1409), and the publication layer's provenance signals, C2PA manifests and structured metadata among them, \"are stripped or rendered invisible long before they reach the training corpus. The body text is what survives\" (#127). The object the tests test is a distinct entity, the IPTC Photo Metadata Standard, which \"sets the industry standard for administrative, descriptive, and copyright information about images\" (IPTC, Photo Metadata): its properties are grouped \"into Administrative, Descriptive and Rights-related properties\" (Photo Metadata Standard 2025.1) in two schemas, IPTC Core and IPTC Extension, \"built on the legacy of the original IPTC-IIM\" (IPTC Photo Metadata Standard page), and the census record gives the object they bear on as \"the photograph as a file: embedded Exif and IPTC metadata (IIM and XMP)\" (provenance census record). Its current release is 2025.1, \"including … IPTC Core Metadata Schema 1.5 … IPTC Extension Metadata Schema 1.9\" (specification, About the Standard), while the same specification heads its Extension section \"IPTC Extension schema 1.8 specifications\" (specification, contents and body). Its genealogy runs from the IIM, \"developed in the early 1990s by the International Press Telecommunications Council (IPTC) to expedite the international exchange of news\" (Wikipedia, IPTC Information Interchange Model), whose image properties were embedded as the \"IPTC header\" (Wikipedia, International Press Telecommunications Council; Wikipedia, IIM), to XMP, which \"has largely superseded IIM's file structure\" (Wikipedia, IIM), the IPTC having worked \"alongside Adobe\" on an implementation that \"employs Adobe’s XMP technology\" (Standard page); Core fields embedded in both formats must have their values synchronised by the image software (User Guide). The standard leaves the file and the camera to others: how its formats are stored inside image files is \"defined by non-IPTC file format standards, such as JPEG/JFIF, TIFF, PNG and more\" (Standard page), and the specification \"does not include any technical metadata\" (specification), the capture data NeededApps assigns to Exif while IPTC metadata \"is commonly used to describe, organize and manage images\" (NeededApps). The IPTC calls it \"the most widely used standard to describe photos, because of its universal acceptance among news agencies, photographers, photo agencies, libraries, museums, and other related industries\" (Standard page), Wikipedia \"by far IPTC's most widely used standard\" for its \"nearly universal acceptance among photographers\" (Wikipedia, IIM), and its stated uses are \"protecting images' copyright and licensing information online\" and \"managing digital assets\" (IPTC, Photo Metadata). Its operator, the International Press Telecommunications Council, is \"a consortium of the world's major news agencies, other news providers and news industry vendors\" that \"acts as the global standards body of the news media\" (Wikipedia, International Press Telecommunications Council), and its own conference video marks \"20 years of IPTC Photo Metadata\" (IPTC, YouTube, title only). The 2025.1 release, announced by the Working Group on 27 November 2025, adds four properties \"for AI-generated content\", AI Prompt Information, AI Prompt Writer Name, AI System Used and AI System Version Used, the third defined as \"The AI engine and/or the model name used to generate this image\" (IPTC news; Standard page), beside the Data Mining property, a \"Data mining prohibition or permission, optionally with constraints\" (specification). The User Guide gives their purpose, to tell AI-generated images from \"regular\" ones \"to avoid re-training AI models on content that was already generated by a model,\" and recommends leaving Image Creator empty and setting Digital Source Type to trainedAlgorithmicMedia or compositeSynthetic (User Guide); the announcement records that writing the new properties into its example image \"has rendered the C2PA metadata invalid\" (IPTC news), and the census record marks the tests \"NOT a test of C2PA credentials\" (provenance census record). The archive places this layer of the standard: \"IPTC AI metadata\" is \"Layer 1 metadata\", \"Disclosure, not lineage\", where artifact provenance \"operates at the moment of artifact creation\" and the dimensions of provenance are independent, each preserved or destroyed \"regardless of the others\" (#725), and against the reading of provenance as \"a field, a tag, a manifest, a credential, separable from the object it documents,\" #725 holds that \"To strip provenance is to change what the meaning *is*\" (#725). The archive uses the standard's vocabulary for its own artifacts: Digital Source Type declared as digital capture of a physical original is \"the nonsynthetic claim made machine-readable inside the file,\" the archive's scaffold, \"everything machine-readable around the ink,\" takes in IPTC/XMP/EXIF, and \"C2PA, FADGI, and IPTC provenance vocabularies are the same insight arriving as standards\" as the archive's substrate checksum (#1409). Google reads the embedded fields: it \"displays three IPTC photo metadata fields, wherever available,\" telling the viewer the creator, the copyright holder and the credit line (User Guide), a display \"introduced by Google in September 2018\" (IPTC Guidelines & Support), \"Google extracts this information from photos in search results\" (FAQ), and the IPTC's browser extension sends a web image to its GetPMD tool, \"which will display all metadata embedded in the image file\" (Chrome Web Store). The archive records the same channel as established for extraction and open for composition: IPTC photo metadata \"embedded in the file (travels with the image across pages),\" \"ESTABLISHED as extracted; composition role unknown,\" and \"scaffold the pipeline provably reads\" (#1409). The census record holds the series historical, \"the 2019 table is not a 2026 platform measurement,\" succeeded in method by the IPTC's Metawatch (2026), which it records as a part, with C2PA conformance its neighbour; it tags the series \"NOT a current platform audit,\" leaves the 2016 and 2013 tables, the 2014 software study and the interoperability procedures unchecked, and kinds it a test series (provenance census record). Its organizing question is asked of every entity alike: \"What provenance does this system carry, through which operation, on whose assertion, with what evidence of survival?\" (provenance census record). Wikipedia has no article on the tests, and none at the title IPTC Photo Metadata (Wikipedia, as fetched 2026-10-29). At the bare name on Google's AI Overview the Capture Registry gives the innocent reading first, the standard explained \"from the IPTC's own pages,\" and finds the standard held: \"Core and Extension, IIM and XMP, the 2025.1 release and its AI properties are the IPTC's own,\" with the IPTC named, \"no person; no identifier\" (Capture Registry, 2026-10-29). It records that the record at the name is the tests and their 2019 losses, that \"None of this is in the composition,\" which \"composes the carrier and leaves out the measurement of its erasure,\" gives the search engines' reading of the data and \"omits the loss,\" heads the 2025.1 properties \"AI & Content Provenance\" where the IPTC gives them as properties of AI-generated content, and cites no card of the record that landed the same day; it reads the capture as \"the baseline for the name\" and \"the measurement of stripping\" as \"a second address\" (Capture Registry, 2026-10-29).", "rail": [], "note": "L(B ∪ A) in the equal-terms case (v0.9 §0.4), realized as the knowledge object (objects.KO); its rail is the compression's, by lineage." } }, "field": [ { "id": "B1", "card": "IPTC — Photo Metadata IPTC", "origin": "card", "fetched": "card; B1.html sha256 67cbd7ce1750d398; HTTP 200" }, { "id": "B2", "card": "IPTC — IPTC Photo Metadata Standard", "origin": "card", "fetched": "card; B2.html sha256 a4dd802767a7c6ed; HTTP 200" }, { "id": "B3", "card": "IPTC — IPTC Photo Metadata Standard 2025.1", "origin": "card", "fetched": "card; B3.html sha256 275a1717429f2208; HTTP 200" }, { "id": "B4", "card": "IPTC — IPTC Photo Metadata User Guide", "origin": "card", "fetched": "card; B4.html sha256 0a8a0c47b9c3c751; HTTP 200" }, { "id": "B5", "card": "IPTC — IPTC Photo Metadata Standard adds new properties for AI-generated content - IPTC", "origin": "card", "fetched": "card; B5.html sha256 59d9db3a4c7a748f; HTTP 200" }, { "id": "B6", "card": "Wikipedia — IPTC Information Interchange Model - Wikipedia", "origin": "card", "fetched": "card; B6.html sha256 f1f6848d9eece558; HTTP 200" }, { "id": "B7", "card": "IPTC — IPTC Guidelines & Support", "origin": "card", "fetched": "card; B7.html sha256 fa31b80137785c0f; HTTP 200" }, { "id": "B8", "card": "NeededApps — What Is Image Metadata? EXIF, IPTC and XMP Explained - NeededApps", "origin": "card", "fetched": "card; B8.html sha256 9863e3890450b586; HTTP 200" }, { "id": "B9", "card": "IPTC — Google Images and IPTC: Frequently Asked Questions", "origin": "card", "fetched": "card; B9.html sha256 411f99558ec1b28c; HTTP 200" }, { "id": "B10", "card": "Chrome Web Store — IPTC Photo Metadata inspector - Chrome Web Store - Google", "origin": "card", "fetched": "card; B10.html sha256 ffcb77c3fae1daaa; HTTP 200" }, { "id": "B11", "card": "YouTube·IPTC — Introduction and welcome, 20 years of IPTC Photo Metadata, Recent work ...", "origin": "card", "fetched": "card; unreachable: watch page HTTP 429; title only (oEmbed HTTP 200 confirms title and channel)" }, { "id": "B12", "card": "IPTC — Social Media Sites Photo Metadata Test Results 2019", "origin": "own_page", "fetched": "own page; the census's saved copy, sha256 1b4794817413523c (= census)" }, { "id": "B13", "card": "IPTC — Research", "origin": "own_page", "fetched": "own page; the census's saved copy, sha256 4d8b44f1ba520320 (= census)" }, { "id": "B14", "card": "Wikipedia — IPTC photo metadata tests (no article)", "origin": "wikipedia", "fetched": "Wikipedia; raw HTTP 404, rendered HTTP 404" }, { "id": "B15", "card": "Wikipedia — International Press Telecommunications Council", "origin": "wikipedia", "fetched": "Wikipedia; raw HTTP 200, rendered HTTP 200" } ], "field_claims": { "F1": { "source": "B1", "origin": "card", "locus": "Photo Metadata page: standfirst", "quote": "IPTC Photo Metadata sets the industry standard for administrative, descriptive, and copyright information about images.", "claim": "the standard defined by its operator's landing page: the industry standard for administrative, descriptive and copyright information about images", "modality": "stipulation", "kind": "definition", "kernel": true, "const": true, "lineage": "the standard: what it is (the carrier the tests test)", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B1.txt (sha256 cf1cbba0ec1ac357…), whitespace-normalised" }, "F2": { "source": "B1", "origin": "card", "locus": "Photo Metadata page: 'Critical to Photo and Related Businesses'", "quote": "Photo metadata is key to protecting images' copyright and licensing information online. It is also essential for managing digital assets.", "claim": "what photo metadata is for: protecting copyright and licensing information online; managing digital assets", "modality": "stipulation", "kind": "function", "kernel": false, "const": false, "lineage": "the standard's reception and use", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B1.txt (sha256 cf1cbba0ec1ac357…), whitespace-normalised" }, "F3": { "source": "B1", "origin": "card", "locus": "Photo Metadata page: 'Research'", "quote": "IPTC not only defines the standard for photo metadata, but also conducts research about how it is used in the real world. We examine metadata in commonly used software, social media platforms, and more. The removal of rights information as images are transferred is of particular concern.", "claim": "the tests named on the composition's own first card: research on how photo metadata is used in software and on social media platforms, the removal of rights information in transfer of particular concern", "modality": "self-description", "kind": "function", "kernel": true, "const": false, "lineage": "the tests: what they are and what they check", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B1.txt (sha256 cf1cbba0ec1ac357…), whitespace-normalised" }, "F4": { "source": "B2", "origin": "card", "locus": "IPTC Photo Metadata Standard page ¶1", "quote": "The IPTC Photo Metadata Standard is the most widely used standard to describe photos, because of its universal acceptance among news agencies, photographers, photo agencies, libraries, museums, and other related industries.", "claim": "the standard's self-description: the most widely used standard to describe photos, by its acceptance among news agencies, photographers, agencies, libraries and museums", "modality": "self-description", "kind": "fact", "kernel": false, "const": false, "lineage": "the standard's reception and use", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B2.txt (sha256 3a59b1b1fcc0452d…), whitespace-normalised" }, "F5": { "source": "B2", "origin": "card", "locus": "IPTC Photo Metadata Standard page ¶3", "quote": "Today, the IPTC Photo Metadata Standard consists of two schemas – IPTC Core and IPTC Extension – which were built on the legacy of the original IPTC-IIM, and developed by the IPTC for professional use with a focus on news and stock photos.", "claim": "two schemas, IPTC Core and IPTC Extension, built on the legacy IIM, for professional news and stock photography", "modality": "stipulation", "kind": "definition", "kernel": true, "const": true, "lineage": "the standard: what it is (the carrier the tests test)", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B2.txt (sha256 3a59b1b1fcc0452d…), whitespace-normalised" }, "F6": { "source": "B2", "origin": "card", "locus": "IPTC Photo Metadata Standard page ¶3", "quote": "IPTC worked alongside Adobe on the technical implementation of the metadata that employs Adobe’s XMP technology (now an ISO Standard) as an enriched alternative to the IIM format.", "claim": "the implementation with Adobe in XMP (an ISO standard), an enriched alternative to IIM", "modality": "documented", "kind": "genealogy", "kernel": false, "const": false, "lineage": "the standard's genealogy: IIM, IPTC headers, XMP", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B2.txt (sha256 3a59b1b1fcc0452d…), whitespace-normalised" }, "F7": { "source": "B2", "origin": "card", "locus": "'What’s New in the 2025.1 Standard'", "quote": "The 2025.1 version, published in November 2025, adds four new properties to handle metadata for AI-generated content: AI Prompt Information, AI Prompt Writer Name, AI System Used and AI System Version Used.", "claim": "2025.1 (November 2025) adds four properties for AI-generated content", "modality": "documented", "kind": "fact", "kernel": true, "const": false, "lineage": "the 2025.1 properties for AI-generated content", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B2.txt (sha256 3a59b1b1fcc0452d…), whitespace-normalised" }, "F8": { "source": "B2", "origin": "card", "locus": "'What’s Defined by This Standard', last paragraph", "quote": "How Photo Metadata formats are stored within image files are defined by non-IPTC file format standards, such as JPEG/JFIF, TIFF, PNG and more.", "claim": "the stated limit of scope: how the formats are stored inside image files is defined by non-IPTC file-format standards (JPEG/JFIF, TIFF, PNG)", "modality": "self-description", "kind": "limit", "kernel": true, "const": false, "lineage": "the standard's scope and limits: file formats, no technical metadata", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B2.txt (sha256 3a59b1b1fcc0452d…), whitespace-normalised" }, "F9": { "source": "B3", "origin": "card", "locus": "'About the Standard'", "quote": "This is the IPTC Photo Metadadata Standard 2025.1, including … IPTC Core Metadata Schema 1.5 … IPTC Extension Metadata Schema 1.9", "claim": "the current release: 2025.1, with Core 1.5 and Extension 1.9 (the source's spelling 'Metadadata' kept)", "modality": "documented", "kind": "fact", "kernel": true, "const": false, "lineage": "the standard's release: 2025.1, Core 1.5, Extension 1.9", "date": "2025-11-26 (version 2025.1 rev 1)", "quote_ok": true, "checked_against": "saved text B3.txt (sha256 39a0ef12f50cd11f…), whitespace-normalised" }, "F10": { "source": "B3", "origin": "card", "locus": "§1 Overview ¶1", "quote": "IPTC Photo Metadata provides data about photographs and the values can be processed by software. Each individual metadata entity is called a property and they are grouped into Administrative, Descriptive and Rights-related properties.", "claim": "the specification's definition: data about photographs processable by software, properties grouped as administrative, descriptive and rights-related", "modality": "stipulation", "kind": "definition", "kernel": true, "const": true, "lineage": "the standard: what it is (the carrier the tests test)", "date": "2025-11-26 (version 2025.1 rev 1)", "quote_ok": true, "checked_against": "saved text B3.txt (sha256 39a0ef12f50cd11f…), whitespace-normalised" }, "F11": { "source": "B3", "origin": "card", "locus": "§2.2 Technical Metadata", "quote": "Because the IPTC acknowledges these technical metadata standards of other bodies and does not wish to duplicate existing metadata properties, the IPTC Photo Metadata specification does not include any technical metadata.", "claim": "the stated limit: no technical (camera) metadata; that is left to the camera manufacturers' standards", "modality": "self-description", "kind": "limit", "kernel": true, "const": false, "lineage": "the standard's scope and limits: file formats, no technical metadata", "date": "2025-11-26 (version 2025.1 rev 1)", "quote_ok": true, "checked_against": "saved text B3.txt (sha256 39a0ef12f50cd11f…), whitespace-normalised" }, "F12": { "source": "B3", "origin": "card", "locus": "table of contents, Extension heading (and the section heading at the same place in the body)", "quote": "IPTC Extension schema 1.8 specifications", "claim": "the specification heads its Extension section '1.8' while 'About the Standard' and §4 give Extension 1.9 (marked internally_inconsistent: both loci cited)", "modality": "documented", "kind": "fact", "kernel": false, "const": false, "lineage": "the standard's release: 2025.1, Core 1.5, Extension 1.9", "date": "2025-11-26 (version 2025.1 rev 1)", "quote_ok": true, "checked_against": "saved text B3.txt (sha256 39a0ef12f50cd11f…), whitespace-normalised", "mark": { "internally_inconsistent": { "loci": [ "B3 'About the Standard': 'IPTC Extension Metadata Schema 1.9'", "B3 §4: 'revising it to version 1.9'", "B3 table of contents and section heading: 'IPTC Extension schema 1.8 specifications'" ] } } }, "F13": { "source": "B3", "origin": "card", "locus": "§11.11 Data Mining, Definition", "quote": "Data mining prohibition or permission, optionally with constraints.", "claim": "the Data Mining property: prohibition or permission of data mining, optionally constrained", "modality": "stipulation", "kind": "definition", "kernel": false, "const": false, "lineage": "the 2025.1 properties for AI-generated content", "date": "2025-11-26 (version 2025.1 rev 1)", "quote_ok": true, "checked_against": "saved text B3.txt (sha256 39a0ef12f50cd11f…), whitespace-normalised" }, "F14": { "source": "B4", "origin": "card", "locus": "Introduction, 'How IPTC Photo Metadata Evolved Over Time'", "quote": "IPTC Core fields can be embedded in the IIM format and/or in the XMP format. A key challenge for metadata embedded in parallel in IIM and XMP is that the values are synchronised - this should be taken care of by the image management software.", "claim": "Core fields embedded in IIM and/or XMP; values embedded in parallel must be synchronised by the image software", "modality": "self-description", "kind": "limit", "kernel": false, "const": false, "lineage": "the standard's genealogy: IIM, IPTC headers, XMP", "date": "2025-11-26 (november 2025 r0)", "quote_ok": true, "checked_against": "saved text B4.txt (sha256 90835f6bab1be348…), whitespace-normalised" }, "F15": { "source": "B4", "origin": "card", "locus": "'IPTC is often asked which fields should be filled out as a minimum'", "quote": "By defining this set of minimal metadata properties IPTC does not support any removal of existing metadata outside this set without the explicit permission of the copyright owner of the image. (In simple words: this is not a permission to strip off metadata and is not legal advice.)", "claim": "the minimum set is no permission to strip other metadata", "modality": "stipulation", "kind": "function", "kernel": false, "const": false, "lineage": "the norm the tests measure against: embedded metadata must not be removed", "date": "2025-11-26 (november 2025 r0)", "quote_ok": true, "checked_against": "saved text B4.txt (sha256 90835f6bab1be348…), whitespace-normalised" }, "F16": { "source": "B4", "origin": "card", "locus": "'Fundamental Guidelines for the Preservation of Embedded Metadata', principle 4", "quote": "Copyright management information metadata must never be removed from the files. … Removal of such metadata impacts on the ability to assert ownership rights and is therefore forbidden by law in many countries.", "claim": "the Embedded Metadata Manifesto, endorsed by the IPTC: copyright management information must never be removed; removal is forbidden by law in many countries", "modality": "stipulation", "kind": "function", "kernel": true, "const": true, "lineage": "the norm the tests measure against: embedded metadata must not be removed", "date": "2025-11-26 (november 2025 r0)", "quote_ok": true, "checked_against": "saved text B4.txt (sha256 90835f6bab1be348…), whitespace-normalised" }, "F17": { "source": "B4", "origin": "card", "locus": "'IPTC Photo Metadata and Google Images'", "quote": "Google displays three IPTC photo metadata fields, wherever available, for an image shown as search result. This tells the viewer who is the creator and who is the copyright holder of the image and what credit line should be shown next to the image.", "claim": "Google Images displays three embedded fields: creator, copyright notice, credit line", "modality": "documented", "kind": "fact", "kernel": true, "const": false, "lineage": "who reads the embedded fields: Google Images and the IPTC's tools", "date": "2025-11-26 (november 2025 r0)", "quote_ok": true, "checked_against": "saved text B4.txt (sha256 90835f6bab1be348…), whitespace-normalised" }, "F18": { "source": "B4", "origin": "card", "locus": "'For developers and site administrators: how to ensure the fields are preserved in images on your site'", "quote": "Your site’s digital asset management system, content management system, image management system or content delivery network may be stripping out embedded metadata fields. Some systems do this with the best of intentions, thinking that it will save a few bytes of bandwidth, but stripping out metadata actually infringes on the copyright holders' rights and may even be illegal in some countries.", "claim": "site systems (DAM, CMS, image management, CDN) may strip embedded fields; stripping infringes rights and may be illegal", "modality": "hypothesis", "kind": "limit", "kernel": true, "const": false, "lineage": "stripping in transit: where the carrier is lost", "date": "2025-11-26 (november 2025 r0)", "quote_ok": true, "checked_against": "saved text B4.txt (sha256 90835f6bab1be348…), whitespace-normalised" }, "F19": { "source": "B4", "origin": "card", "locus": "'Applying Metadata to AI-generated Images' ¶2", "quote": "It may be important to distinguish AI-generated images from \"regular\" images: for example, to avoid re-training AI models on content that was already generated by a model, to understand which images can fall under copyright and which cannot (in some jurisdictions) and to avoid misinterpreting generated images as being real photos.", "claim": "why AI-generated images are marked: against re-training on generated content, for copyright, against mistaking them for photos", "modality": "interpretation", "kind": "interpretation", "kernel": false, "const": false, "lineage": "marking AI-generated images, and the C2PA metadata invalidated", "date": "2025-11-26 (november 2025 r0)", "quote_ok": true, "checked_against": "saved text B4.txt (sha256 90835f6bab1be348…), whitespace-normalised" }, "F20": { "source": "B4", "origin": "card", "locus": "'Applying Metadata to AI-generated Images', field suggestions", "quote": "Creator is bound to the owner of the intellectual property of an image in many countries and there are first legal decisions that AI generated images are not considered as creative work generating an intellectual property. Therefore, our recommendation is to leave the Image Creator field empty.", "claim": "for AI-generated images, leave Image Creator empty", "modality": "stipulation", "kind": "function", "kernel": false, "const": false, "lineage": "marking AI-generated images, and the C2PA metadata invalidated", "date": "2025-11-26 (november 2025 r0)", "quote_ok": true, "checked_against": "saved text B4.txt (sha256 90835f6bab1be348…), whitespace-normalised" }, "F21": { "source": "B4", "origin": "card", "locus": "'Applying Metadata to AI-generated Images', field suggestions", "quote": "The Digital Source Type field should be set to the URI value http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia or http://cv.iptc.org/newscodes/digitalsourcetype/compositeSynthetic.", "claim": "Digital Source Type set to trainedAlgorithmicMedia or compositeSynthetic", "modality": "stipulation", "kind": "function", "kernel": false, "const": false, "lineage": "marking AI-generated images, and the C2PA metadata invalidated", "date": "2025-11-26 (november 2025 r0)", "quote_ok": true, "checked_against": "saved text B4.txt (sha256 90835f6bab1be348…), whitespace-normalised" }, "F22": { "source": "B5", "origin": "card", "locus": "announcement ¶2", "quote": "The IPTC Photo Metadata Working Group has released version 2025.1 of the IPTC Photo Metadata Standard, including properties that can be used for AI-generated content.", "claim": "the Working Group releases 2025.1 with properties for AI-generated content", "modality": "documented", "kind": "genealogy", "kernel": true, "const": false, "lineage": "the 2025.1 properties for AI-generated content", "date": "2025-11-27 (posted)", "quote_ok": true, "checked_against": "saved text B5.txt (sha256 8a7b2bc1c99f7388…), whitespace-normalised" }, "F23": { "source": "B5", "origin": "card", "locus": "announcement, the new properties", "quote": "AI System Used … Definition: The AI engine and/or the model name used to generate this image.", "claim": "AI System Used defined: the AI engine or model name used to generate the image", "modality": "stipulation", "kind": "definition", "kernel": false, "const": false, "lineage": "the 2025.1 properties for AI-generated content", "date": "2025-11-27 (posted)", "quote_ok": true, "checked_against": "saved text B5.txt (sha256 8a7b2bc1c99f7388…), whitespace-normalised" }, "F24": { "source": "B5", "origin": "card", "locus": "announcement, caption of the example image", "quote": "This image contains the new IPTC Photo Metadata fields “AI Prompt Information”, “AI System Used” and “AI Prompt Writer Name”. Note that adding the new IPTC Photo Metadata properties has rendered the C2PA metadata invalid.", "claim": "the stated limit: writing the new properties into the example image rendered its C2PA metadata invalid", "modality": "documented", "kind": "limit", "kernel": true, "const": false, "lineage": "marking AI-generated images, and the C2PA metadata invalidated", "date": "2025-11-27 (posted)", "quote_ok": true, "checked_against": "saved text B5.txt (sha256 8a7b2bc1c99f7388…), whitespace-normalised" }, "F25": { "source": "B6", "origin": "card", "locus": "article lead ¶1", "quote": "The Information Interchange Model (IIM) is a file structure and set of metadata attributes that can be applied to text, images and other media types. It was developed in the early 1990s by the International Press Telecommunications Council (IPTC) to expedite the international exchange of news among newspapers and news agencies.", "claim": "IIM: a file structure and metadata attributes, developed by the IPTC in the early 1990s for news exchange", "modality": "documented", "kind": "genealogy", "kernel": true, "const": false, "lineage": "the standard's genealogy: IIM, IPTC headers, XMP", "date": "2026-10-29 (as fetched)", "quote_ok": true, "checked_against": "saved text B6.txt (sha256 90c31aa0169ab6cd…), whitespace-normalised" }, "F26": { "source": "B6", "origin": "card", "locus": "article lead ¶3", "quote": "IIM metadata embedded in images are often referred to as \"IPTC headers\", and can be easily encoded and decoded by most popular photo editing software.", "claim": "embedded IIM metadata: the 'IPTC headers', read and written by most photo software", "modality": "documented", "kind": "fact", "kernel": false, "const": false, "lineage": "the standard's genealogy: IIM, IPTC headers, XMP", "date": "2026-10-29 (as fetched)", "quote_ok": true, "checked_against": "saved text B6.txt (sha256 90c31aa0169ab6cd…), whitespace-normalised" }, "F27": { "source": "B6", "origin": "card", "locus": "article lead ¶4", "quote": "The Extensible Metadata Platform (XMP) has largely superseded IIM's file structure, but the IIM image attributes are defined in the IPTC Core schema for XMP and most image manipulation programs keep the XMP and non-XMP IPTC attributes synchronized.", "claim": "XMP has largely superseded IIM's structure; IIM's attributes live on in IPTC Core for XMP", "modality": "documented", "kind": "genealogy", "kernel": false, "const": false, "lineage": "the standard's genealogy: IIM, IPTC headers, XMP", "date": "2026-10-29 (as fetched)", "quote_ok": true, "checked_against": "saved text B6.txt (sha256 90c31aa0169ab6cd…), whitespace-normalised" }, "F28": { "source": "B6", "origin": "card", "locus": "article lead ¶5", "quote": "Because of its nearly universal acceptance among photographers — even amateurs — this is by far IPTC's most widely used standard.", "claim": "the encyclopedia's reading: by far the IPTC's most widely used standard, by nearly universal acceptance among photographers", "modality": "interpretation", "kind": "interpretation", "kernel": false, "const": false, "lineage": "the standard's reception and use", "date": "2026-10-29 (as fetched)", "quote_ok": true, "checked_against": "saved text B6.txt (sha256 90c31aa0169ab6cd…), whitespace-normalised" }, "F29": { "source": "B7", "origin": "card", "locus": "'Handbooks and User Guides'", "quote": "Quick Guide to IPTC Photo Metadata and Google Images … explains how to check and update IPTC Photo Metadata for best results in Google Images search results, as introduced by Google in September 2018.", "claim": "the Google Images display, introduced by Google in September 2018, and the IPTC's quick guide to it", "modality": "documented", "kind": "genealogy", "kernel": false, "const": false, "lineage": "who reads the embedded fields: Google Images and the IPTC's tools", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B7.txt (sha256 0da9ec69b0cb5db9…), whitespace-normalised" }, "F30": { "source": "B8", "origin": "card", "locus": "'What Is IPTC Metadata?'", "quote": "IPTC refers to metadata standards developed for the professional exchange and description of media. Unlike EXIF, which is heavily focused on technical capture information, IPTC metadata is commonly used to describe, organize and manage images.", "claim": "a third party's account: IPTC metadata describes, organizes and manages images, against Exif's technical capture data", "modality": "interpretation", "kind": "definition", "kernel": true, "const": false, "lineage": "the standard's scope and limits: file formats, no technical metadata", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B8.txt (sha256 738c082fb43273ba…), whitespace-normalised" }, "F31": { "source": "B8", "origin": "card", "locus": "'Copyright and Attribution'", "quote": "Metadata shouldn't be treated as an infallible form of copyright protection because it can be removed or modified, but it provides useful information that can travel with the image.", "claim": "the stated limit: metadata can be removed or modified, so it is no infallible copyright protection", "modality": "interpretation", "kind": "limit", "kernel": true, "const": false, "lineage": "stripping in transit: where the carrier is lost", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B8.txt (sha256 738c082fb43273ba…), whitespace-normalised" }, "F32": { "source": "B9", "origin": "card", "locus": "answer 1", "quote": "IPTC maintains the technical standard that image creators can use to put their creator and copyright details inside image files. We call this “photo metadata”. Google extracts this information from photos in search results and displays it to help you find who owns the image.", "claim": "the IPTC maintains the standard for creator and copyright details inside files; Google extracts and displays them", "modality": "documented", "kind": "fact", "kernel": true, "const": false, "lineage": "who reads the embedded fields: Google Images and the IPTC's tools", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B9.txt (sha256 9577a29c03495777…), whitespace-normalised" }, "F33": { "source": "B9", "origin": "card", "locus": "answer 3 ¶2", "quote": "In that case, the metadata might be stripped from your images by some software on your site. Sometimes this could be your Digital Asset Management system (such as Bynder, WebDAM or Extensis Portfolio). In other cases your Content Management System (such as WordPress or Drupal) might strip off metadata. Or it could be a Content Delivery Network that you use, such as Cloudflare or Cloudinary.", "claim": "metadata that does not show may have been stripped by a site's DAM, CMS or CDN", "modality": "hypothesis", "kind": "limit", "kernel": true, "const": false, "lineage": "stripping in transit: where the carrier is lost", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B9.txt (sha256 9577a29c03495777…), whitespace-normalised" }, "F34": { "source": "B10", "origin": "card", "locus": "Overview", "quote": "IPTC's Photo Metadata Inspector tool lets you see embedded metadata in many image files. For eligible images, a context menu will appear when you right-click on the image. Select \"View IPTC Photo Metadata\" and you will be taken to IPTC's Get Photo Metadata (GetPMD) tool which will display all metadata embedded in the image file.", "claim": "the IPTC's browser extension passes a web image to GetPMD, which displays its embedded metadata", "modality": "stipulation", "kind": "function", "kernel": true, "const": false, "lineage": "who reads the embedded fields: Google Images and the IPTC's tools", "date": "2025-01-13 (updated, as the store lists it)", "quote_ok": true, "checked_against": "saved text B10.txt (sha256 b9c8434269772deb…), whitespace-normalised" }, "F35": { "source": "B11", "origin": "card", "locus": "card title (video; the watch page answered HTTP 429; title confirmed by YouTube oEmbed, channel IPTC)", "quote": "Introduction and welcome, 20 years of IPTC Photo Metadata, Recent work", "claim": "the IPTC's video: twenty years of IPTC Photo Metadata (title only)", "modality": "documented", "kind": "genealogy", "kernel": false, "const": false, "lineage": "the operator: the IPTC and its Photo Metadata Working Group", "date": "— (title only)", "quote_ok": true, "checked_against": "the card's title in the registry's cite_list (oEmbed title agrees)" }, "F36": { "source": "B12", "origin": "own_page", "locus": "standfirst", "quote": "IPTC promotes the proper use of IPTC Photo Metadata and claims “embedded metadata should not be removed” from images shared on a photo platform or a system for sharing files or messages with images.", "claim": "the claim the tests check: embedded metadata should not be removed from images shared on photo platforms or file and message systems", "modality": "stipulation", "kind": "definition", "kernel": true, "const": true, "lineage": "the tests: what they are and what they check", "date": "2019 (Spring 2019 results; page undated)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F37": { "source": "B12", "origin": "own_page", "locus": "standfirst", "quote": "To check which systems support this claim, IPTC checks about a dozen sites regularly: in 2013, in 2016 and now again in Spring 2019.", "claim": "the tests defined: about a dozen sites checked regularly, 2013, 2016, Spring 2019", "modality": "stipulation", "kind": "definition", "kernel": true, "const": true, "lineage": "the tests: what they are and what they check", "date": "2019 (Spring 2019 results; page undated)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F38": { "source": "B12", "origin": "own_page", "locus": "'Test Procedure' 1", "quote": "Uploading an image with values in many fields of the IPTC Photo Metadata Standard , e.g. the latest Reference Image File . This implies that all embedded metadata values are known and can be checked.", "claim": "the method: upload an image whose embedded values are all known", "modality": "stipulation", "kind": "definition", "kernel": false, "const": false, "lineage": "the tests: what they are and what they check", "date": "2019 (Spring 2019 results; page undated)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F39": { "source": "B12", "origin": "own_page", "locus": "'Test Procedure' 3–4", "quote": "Check if the image can be saved to a local device by a Save As function of the web browser. … Check if the image can be downloaded by a function of the tested system (e.g. a menu item). … are the embedded Exif and IPTC metadata (in the formats IIM and XMP) of the uploaded image still embedded?", "claim": "the transformations: Save As and download; the test: are the embedded Exif and IPTC (IIM and XMP) still embedded", "modality": "stipulation", "kind": "definition", "kernel": true, "const": true, "lineage": "the tests: what they are and what they check", "date": "2019 (Spring 2019 results; page undated)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F40": { "source": "B12", "origin": "own_page", "locus": "'Test Procedure' 2", "quote": "If displayed: are these 4 relevant fields shown, correctly: Caption/description, Creator, Copyright Notice, Credit Line (= the 4Cs )", "claim": "the four fields checked for display: caption, creator, copyright notice, credit line", "modality": "stipulation", "kind": "definition", "kernel": false, "const": false, "lineage": "what the tests track: the 4Cs in the file", "date": "2019 (Spring 2019 results; page undated)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F41": { "source": "B12", "origin": "own_page", "locus": "results, image-sharing sites: Pexels, pixabay, Unsplash", "quote": "Pexels … Metadata is stripped off in SavedAs or downloaded files. … pixabay … Metadata is stripped off in SavedAs or downloaded files. … Unsplash … No embedded metadata displayed, metadata is stripped off in SavedAs or downloaded files.", "claim": "Pexels, pixabay and Unsplash strip embedded metadata from saved and downloaded files", "modality": "documented", "kind": "fact", "kernel": true, "const": false, "lineage": "the 2019 results: stripped, replaced, kept", "date": "2019 (Spring 2019 results)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F42": { "source": "B12", "origin": "own_page", "locus": "results, image-sharing sites: Flickr", "quote": "(Free account tested.) Some embedded metadata displayed. Embedded Creator replaced by account owner. SavedAs files have no XMP metadata.", "claim": "Flickr replaces the embedded creator with the account owner; saved files lose XMP", "modality": "documented", "kind": "fact", "kernel": true, "const": false, "lineage": "the 2019 results: stripped, replaced, kept", "date": "2019 (Spring 2019 results)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F43": { "source": "B12", "origin": "own_page", "locus": "results, file and message systems: Facebook, Twitter", "quote": "No embedded metadata displayed. SavedAs files have no XMP metadata. A few rights related fields were retained in IIM and Exif. 2 IIM fields contain data generated by Facebook. … Twitter … No embedded metadata displayed. Metadata is stripped off in SavedAs files.", "claim": "Facebook keeps a few rights fields in IIM and Exif and writes two IIM fields of its own; Twitter strips saved files", "modality": "documented", "kind": "fact", "kernel": false, "const": false, "lineage": "the 2019 results: stripped, replaced, kept", "date": "2019 (Spring 2019 results)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F44": { "source": "B12", "origin": "own_page", "locus": "results, file and message systems: Dropbox, Microsoft OneDrive", "quote": "Passed through original file, preview can be SavedAs with stripped off metadata.", "claim": "Dropbox and OneDrive pass the original through; their previews save with metadata stripped", "modality": "documented", "kind": "fact", "kernel": false, "const": false, "lineage": "the 2019 results: stripped, replaced, kept", "date": "2019 (Spring 2019 results)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F45": { "source": "B12", "origin": "own_page", "locus": "results, image-sharing sites: Behance", "quote": "Download is not a main feature, SaveAs files keep the embedded metadata.", "claim": "Behance's saved files keep the embedded metadata", "modality": "documented", "kind": "fact", "kernel": false, "const": false, "lineage": "the 2019 results: stripped, replaced, kept", "date": "2019 (Spring 2019 results)", "quote_ok": true, "checked_against": "saved text B12.txt (sha256 684127f460e2664e…), whitespace-normalised" }, "F46": { "source": "B13", "origin": "own_page", "locus": "'Photo Metadata Research' ¶1", "quote": "IPTC not only defines the standard for photo metadata, but also conducts research about how photo metadata is used and implemented. Our most recent tests and studies:", "claim": "the research as the IPTC's activity beside the standard", "modality": "self-description", "kind": "function", "kernel": false, "const": false, "lineage": "the tests: what they are and what they check", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B13.txt (sha256 9e9133e4d57d4114…), whitespace-normalised" }, "F47": { "source": "B13", "origin": "own_page", "locus": "'Rights Information and Social Media Networks' ¶1", "quote": "IPTC was approached by users who discovered that when they shared photos via social media sites or systems, their embedded metadata disappeared.", "claim": "the origin: users found their embedded metadata disappeared when shared", "modality": "documented", "kind": "genealogy", "kernel": true, "const": false, "lineage": "the tests: origin, cadence and count", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B13.txt (sha256 9e9133e4d57d4114…), whitespace-normalised" }, "F48": { "source": "B13", "origin": "own_page", "locus": "'Rights Information and Social Media Networks' ¶2", "quote": "The IPTC Photo Metadata Working Group tested 15 social media sites in 2016 and 2013 to understand how image sharing, through upload and download, affects the integrity of embedded metadata as defined by IPTC standards and the Exif standard.", "claim": "the Working Group tested 15 sites in 2013 and 2016 for how upload and download affect embedded metadata's integrity", "modality": "documented", "kind": "definition", "kernel": true, "const": true, "lineage": "the tests: origin, cadence and count", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B13.txt (sha256 9e9133e4d57d4114…), whitespace-normalised" }, "F49": { "source": "B13", "origin": "own_page", "locus": "'Rights Information and Social Media Networks' ¶3", "quote": "Some social media sites or systems remove embedded information like copyright notes, the name of the creator, the description and more, while others protect photographers’ data better. The results show that it is not impossible to preserve metadata in a workflow.", "claim": "the finding: some sites remove the embedded information, others protect it; preservation in a workflow is not impossible", "modality": "interpretation", "kind": "interpretation", "kernel": true, "const": false, "lineage": "the tests' findings and the software study", "date": "2026-10-29 (page undated; as fetched)", "quote_ok": true, "checked_against": "saved text B13.txt (sha256 9e9133e4d57d4114…), whitespace-normalised" }, "F50": { "source": "B13", "origin": "own_page", "locus": "'Rights Information and Software Performance'", "quote": "The results, published in August 2014, look promising: … Half of the programs offered fields for photographers to enter rights information, including the date, the image’s creator, copyright notice, and rights usage term. … Two out of three programs helped users retrieve embedded rights data. … Unfortunately, two of the programs didn’t support rights metadata at all.", "claim": "the software study (August 2014): half the programs offered rights fields, two of three retrieved them, two supported none", "modality": "documented", "kind": "fact", "kernel": false, "const": false, "lineage": "the tests' findings and the software study", "date": "2014-08 (as the page dates the study)", "quote_ok": true, "checked_against": "saved text B13.txt (sha256 9e9133e4d57d4114…), whitespace-normalised" }, "F51": { "source": "B14", "origin": "wikipedia", "locus": "Wikipedia: title IPTC_photo_metadata_tests (and IPTC_Photo_Metadata)", "quote": "Wikipedia does not have an article with this exact name. … There were no results matching the query. The pages \"IPTC photo metadata tests\" and '\"IPTC photo metadata tests\"' do not exist.", "claim": "Wikipedia has no article on the tests, and no article text with the phrase; the title IPTC_Photo_Metadata is also absent (raw HTTP 404)", "modality": "documented", "kind": "fact", "kernel": false, "const": false, "lineage": "reception: the encyclopedia", "date": "2026-10-29 (as fetched)", "quote_ok": true, "checked_against": "saved text B14.txt (sha256 92cd9c6a0ca3f3e1…), whitespace-normalised" }, "F52": { "source": "B15", "origin": "wikipedia", "locus": "article 'International Press Telecommunications Council', §IPTC Standards › Photo metadata ¶1", "quote": "The IPTC defined a set of metadata properties that can be applied to images, part of a broader standard developed in the early 1990s and known as the IPTC Information Interchange Model (IIM). Embedded IIM image information is often referred to as an \"IPTC header\".", "claim": "the operator's article: image metadata properties from the 1990s IIM, embedded as the 'IPTC header'", "modality": "documented", "kind": "genealogy", "kernel": false, "const": false, "lineage": "the standard's genealogy: IIM, IPTC headers, XMP", "date": "2026-10-29 (as fetched)", "quote_ok": true, "checked_against": "saved text B15.txt (sha256 c754434d4b6d4617…), whitespace-normalised" }, "F53": { "source": "B15", "origin": "wikipedia", "locus": "article lead ¶1", "quote": "The International Press Telecommunications Council (IPTC), based in London, United Kingdom, is a consortium of the world's major news agencies, other news providers and news industry vendors and acts as the global standards body of the news media.", "claim": "the operator: a London consortium of news agencies and vendors, the standards body of the news media", "modality": "documented", "kind": "attribution", "kernel": true, "const": false, "lineage": "the operator: the IPTC and its Photo Metadata Working Group", "date": "2026-10-29 (as fetched)", "quote_ok": true, "checked_against": "saved text B15.txt (sha256 c754434d4b6d4617…), whitespace-normalised" } }, "field_sources": { "B1": "IPTC — Photo Metadata IPTC", "B2": "IPTC — IPTC Photo Metadata Standard", "B3": "IPTC — IPTC Photo Metadata Standard 2025.1", "B4": "IPTC — IPTC Photo Metadata User Guide", "B5": "IPTC — IPTC Photo Metadata Standard adds new properties for AI-generated content - IPTC", "B6": "Wikipedia — IPTC Information Interchange Model - Wikipedia", "B7": "IPTC — IPTC Guidelines & Support", "B8": "NeededApps — What Is Image Metadata? EXIF, IPTC and XMP Explained - NeededApps", "B9": "IPTC — Google Images and IPTC: Frequently Asked Questions", "B10": "Chrome Web Store — IPTC Photo Metadata inspector - Chrome Web Store - Google", "B11": "YouTube·IPTC — Introduction and welcome, 20 years of IPTC Photo Metadata, Recent work ...", "B12": "IPTC — Social Media Sites Photo Metadata Test Results 2019", "B13": "IPTC — Research", "B14": "Wikipedia — IPTC photo metadata tests (no article)", "B15": "Wikipedia — International Press Telecommunications Council" }, "delta": { "T_vs_LB": "At 'IPTC photo metadata' (T1, eleven cards: B1–B11; 231 words) the composition gives the standard by the IPTC's own pages. Composed from its cards: the definition, at the grain of the landing page and the specification (B1 F1; B3 F10: administrative, descriptive and rights-related), with 'universally accepted' from the Standard page's 'universal acceptance' (B2 F4) without that page's qualifier, 'among news agencies, photographers, photo agencies, libraries, museums, and other related industries' (limit dropped); the two schemas and XMP (B2 F5, F6); the formats, where the Standard page's limit, that storage inside files is 'defined by non-IPTC file format standards' (B2 F8), becomes 'Supported across formats like JPEG, TIFF, and PNG' (limit dropped); the difference from Exif at NeededApps' grain (B8 F30; B3 F11); the 2025.1 properties for AI-generated content (B2 F7; B5 F22, F23; B3 F9 'version 2025.1'); asset management (B1 F2); Google Images (B4 F17; B9 F32; B7 F29) and the inspector and GetPMD (B10 F34). Outside the cards' claims, at the grain of the specification's table of contents (B3's saved text, not extracted as claims): the property names Alt Text, Headline, Subject Codes, Digital Source Type, Image GUIDs, registry IDs and Licensor. Available, not composed: the tests, which the composition's first card names ('IPTC not only defines the standard for photo metadata, but also conducts research about how it is used in the real world. … The removal of rights information as images are transferred is of particular concern', B1 F3), with the IPTC's site menu on cards B2, B5, B7 and B9 linking the 2019 results; the norm against removal (B4 F15, F16); stripping by hosting systems, on the same IPTC pages the composition draws on for Google Images (B4 F18; B9 F33), and NeededApps' limit (B8 F31); the C2PA metadata the new properties invalidated (B5 F24); the guide's recommendations for AI-generated images (B4 F19–F21); the Data Mining property (B3 F13); the IIM and its history (B6 F25–F28; B4 F14); the Extension heading that contradicts the release (B3 F12); the video (B11 F35). The capture's findings name the omission: 'None of this is in the composition. At the bare name the Overview composes the carrier and leaves out the measurement of its erasure' (CAP-1-03); 'the composition gives the reading and omits the loss' (CAP-1-04). Force raised: T1-10 'Search engines read embedded IPTC data' widens Google's display ('Google displays three IPTC photo metadata fields, wherever available', B4 F17; 'Google extracts this information', B9 F32) to search engines in general and drops 'wherever available'; the same pages' stripping caveat is the limit dropped (B4 F18; B9 F33). Substituted reading: T1-8 heads the 2025.1 properties 'AI & Content Provenance' where the IPTC gives them as properties 'for AI-generated content' (B5 F22; B2 F7; CAP-1-05). Composed without attribution: none at a source's own resolution; the IPTC is named and linked throughout; no person is named (CAP-1-09), at the coarse grain of a standard's description: recorded, not a breach. Assigned to another: none. Denied: none. Content replaced by use: the lede's 'You can explore' (T1-1) and the closer (T1-12). Own pages not surfaced: B12 and B13, the entity's own pages (F36–F50), reachable from cards B1, B2, B5, B7 and B9 by the IPTC's menu.", "T_vs_LB_reading": "v0.9 §0.5: the first diff is ontological. T composes the object the address names, the standard, and not the entity the census record and the composition's own first card name, the tests; and what it leaves out of its own cards is the carrier's loss: the IPTC's norm against removal, the stripping by hosting systems that the IPTC's own Google Images pages warn of, and the C2PA metadata the new fields invalidated. The carrier stands without the measurement of its erasure.", "LB_vs_LBA": "Admission adds, in one claim space with the field's: the census record's account of the tests as the entity (PE-01–PE-19: name, operator, capability, provenance object, carrier, unit, transformations, retention results, cadence, count, the lifecycle as historical and succeeded in method by Metawatch, the negative tags, the relations, the unchecked items, and the organizing question asked of every entity), most of it one lineage with the 2019 and Research pages (PE-06, PE-07, PE-09–PE-12 restate B12 and B13, which keep the earliest date); the archive's layer for the carrier: the standard's AI metadata as 'Layer 1 metadata', 'Disclosure, not lineage' (O725-01), artifact provenance at creation and the dimensions independent (O725-02), provenance not separable from what it documents (O725-03); embedded IPTC as a channel established for extraction with its composition role unknown, scaffold the pipeline reads (O1409-01–O1409-03), Digital Source Type as the nonsynthetic claim inside the file (O1409-06), the IPTC's vocabularies as the same insight as the archive's substrate checksum (R1409-07); the loss at other carriers and stages: in-pixel metadata that survives stripping, metadata carried three times (O1409-04, O1409-05), publication-layer signals stripped before the training corpus (O127-01); and the Capture Registry's account of the composition at the name (CAP-1-01–CAP-1-10). Not surfaced: every archive source; no card cites the record or a deposit (CAP-1-08). The admission also makes the KO's subject the tests and not the standard: the field alone opens on the standard (KO_B 1), the KO on the tests (KO 1).", "alignment": { "T1_cards_claims": [ "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", "F10", "F11", "F12", "F13", "F14", "F15", "F16", "F17", "F18", "F19", "F20", "F21", "F22", "F23", "F24", "F25", "F26", "F27", "F28", "F29", "F30", "F31", "F32", "F33", "F34", "F35" ], "T1_composed": [ "F1", "F2", "F4", "F5", "F6", "F7", "F8", "F9", "F10", "F11", "F17", "F22", "F23", "F29", "F30", "F32", "F34" ], "T1_not_composed": [ "F3", "F12", "F13", "F14", "F15", "F16", "F18", "F19", "F20", "F21", "F24", "F25", "F26", "F27", "F28", "F31", "F33", "F35" ], "T1_outside_cards": [ "Alt Text, Headline, Subject Codes, Digital Source Type, Image GUIDs, registry IDs, Licensor (property names in B3's saved text, its table of contents; not extracted as claims)", "'human-readable details like captions, keywords, and creator credits' (T1-4; no card states 'human-readable')" ], "T1_own_pages_not_surfaced": [ "F36", "F37", "F38", "F39", "F40", "F41", "F42", "F43", "F44", "F45", "F46", "F47", "F48", "F49", "F50" ], "rule": "a field claim counts as composed when T states it at its source's grain or coarser; the typology of what is not is in T_vs_LB (§6.2)" } }, "kernel": [ { "K": "K1", "claim": "`CAP-1-01`", "source": "Capture Registry, 2026-10-29", "M_src": "documented", "sense": "the composition at the name", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K2", "claim": "`CAP-1-02`", "source": "Capture Registry, 2026-10-29", "M_src": "documented", "sense": "the tests: what they are and what they check", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K3", "claim": "`CAP-1-03`", "source": "Capture Registry, 2026-10-29", "M_src": "interpretation", "sense": "the composition at the name", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K4", "claim": "`CAP-1-04`", "source": "Capture Registry, 2026-10-29", "M_src": "interpretation", "sense": "who reads the embedded fields: Google Images and the IPTC's tools", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K5", "claim": "`CAP-1-05`", "source": "Capture Registry, 2026-10-29", "M_src": "documented", "sense": "the 2025.1 properties for AI-generated content", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K6", "claim": "`CAP-1-06`", "source": "Capture Registry, 2026-10-29", "M_src": "interpretation", "sense": "the composition at the name", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K7", "claim": "`CAP-1-07`", "source": "Capture Registry, 2026-10-29", "M_src": "interpretation", "sense": "the composition at the name", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K8", "claim": "`CAP-1-08`", "source": "Capture Registry, 2026-10-29", "M_src": "documented", "sense": "the composition at the name", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K9", "claim": "`CAP-1-09`", "source": "Capture Registry, 2026-10-29", "M_src": "documented", "sense": "the composition at the name", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K10", "claim": "`CAP-1-10`", "source": "Capture Registry, 2026-10-29", "M_src": "documented", "sense": "the composition at the name", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing finding (an observation of the composition at the entity's address)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K11", "claim": "`PE-01`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "the tests: what they are and what they check", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K12", "claim": "`PE-02`", "source": "provenance census record, 2026-10-29", "M_src": "documented", "sense": "the operator: the IPTC and its Photo Metadata Working Group", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K13", "claim": "`PE-03`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "the record: lifecycle, limits and relations", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K14", "claim": "`PE-04`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "the tests: what they are and what they check", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K15", "claim": "`PE-05`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "the standard: what it is (the carrier the tests test)", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K16", "claim": "`PE-06`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "what the tests track: the 4Cs in the file", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "none (the field states it: one lineage with B12 (F40))", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K17", "claim": "`PE-07`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "the tests: what they are and what they check", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "none (the field states it: one lineage with B12 (F39))", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K18", "claim": "`PE-08`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "the tests: what they are and what they check", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K19", "claim": "`PE-09`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "the tests: what they are and what they check", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "none (the field states it: one lineage with B12 (F39))", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K20", "claim": "`PE-10`", "source": "provenance census record, 2026-10-29", "M_src": "attributed", "sense": "the 2019 results: stripped, replaced, kept", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "none (the field states it: one lineage with B12 (F41, F42, F43))", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K21", "claim": "`PE-11`", "source": "provenance census record, 2026-10-29", "M_src": "attributed", "sense": "the tests: origin, cadence and count", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "none (the field states it: one lineage with B12 (F37), B13 (F50))", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K22", "claim": "`PE-12`", "source": "provenance census record, 2026-10-29", "M_src": "attributed", "sense": "the tests: origin, cadence and count", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "none (the field states it: one lineage with B13 (F48), B12 (F37))", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K23", "claim": "`PE-13`", "source": "provenance census record, 2026-10-29", "M_src": "self-description", "sense": "the record: lifecycle, limits and relations", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K24", "claim": "`PE-14`", "source": "provenance census record, 2026-10-29", "M_src": "documented", "sense": "the tests: origin, cadence and count", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K25", "claim": "`PE-15`", "source": "provenance census record, 2026-10-29", "M_src": "self-description", "sense": "the record: lifecycle, limits and relations", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K26", "claim": "`PE-16`", "source": "provenance census record, 2026-10-29", "M_src": "self-description", "sense": "marking AI-generated images, and the C2PA metadata invalidated", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K27", "claim": "`PE-17`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "the record: lifecycle, limits and relations", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K28", "claim": "`PE-18`", "source": "provenance census record, 2026-10-29", "M_src": "self-description", "sense": "the record: lifecycle, limits and relations", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K29", "claim": "`PE-19`", "source": "provenance census record, 2026-10-29", "M_src": "stipulation", "sense": "the record: lifecycle, limits and relations", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no record field for it)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K30", "claim": "`O725-01`", "source": "#725, 2026-05-08", "M_src": "interpretation", "sense": "the archive's layer for the carrier", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "qualified claim: F22, F7 (the IPTC: properties for AI-generated content)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K31", "claim": "`O725-02`", "source": "#725, 2026-05-08", "M_src": "stipulation", "sense": "the archive's layer for the carrier", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction (the field states no dimensions of provenance)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K32", "claim": "`O725-03`", "source": "#725, 2026-05-08", "M_src": "stipulation", "sense": "the archive's layer for the carrier", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K33", "claim": "`O1409-01`", "source": "#1409, 2026-07-21", "M_src": "interpretation", "sense": "who reads the embedded fields: Google Images and the IPTC's tools", "qualifiers carried": "composition role unknown (open)", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "qualified claim: F17, F32 (Google displays and extracts the fields)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K34", "claim": "`O1409-02`", "source": "#1409, 2026-07-21", "M_src": "interpretation", "sense": "who reads the embedded fields: Google Images and the IPTC's tools", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "qualified claim: F17, F32", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K35", "claim": "`O1409-03`", "source": "#1409, 2026-07-21", "M_src": "stipulation", "sense": "the archive's layer for the carrier", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K36", "claim": "`O1409-04`", "source": "#1409, 2026-07-21", "M_src": "interpretation", "sense": "stripping in transit: where the carrier is lost", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "qualified claim: F18, F33, F31 (stripping by hosting systems; metadata removable)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K37", "claim": "`O1409-05`", "source": "#1409, 2026-07-21", "M_src": "function", "sense": "stripping in transit: where the carrier is lost", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "missing distinction", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K38", "claim": "`O1409-06`", "source": "#1409, 2026-07-21", "M_src": "interpretation", "sense": "the archive's layer for the carrier", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "qualified claim: F21 (Digital Source Type for AI-generated images)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K39", "claim": "`R1409-07`", "source": "#1409, 2026-07-21", "M_src": "interpretation", "sense": "the archive's layer for the carrier", "qualifiers carried": "—", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "none", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" }, { "K": "K40", "claim": "`O127-01`", "source": "#127, 2026-05-25", "M_src": "interpretation", "sense": "stripping in transit: where the carrier is lost", "qualifiers carried": "the stage: the training corpus", "f (source's own falsifiers)": "— (none stated for this claim; watch: a later composition at the address that states or drops the claim, attributed or not, uptake §8.3)", "contrast": "qualified claim: F18, F31 (stripping at another stage)", "resolver": "a later capture at 'IPTC photo metadata' (ADDR-ee0523b11509) on Google AI Overview, seated in the Capture Registry (§8.3)" } ], "kernel_T": [ { "claim": "F3", "note": "the tests, named on the composition's own first card, absent" }, { "claim": "F12", "note": "the Extension heading's 1.8 against the release's 1.9, absent" }, { "claim": "F13", "note": "the Data Mining property, absent" }, { "claim": "F14", "note": "the synchronisation of IIM and XMP values, absent" }, { "claim": "F15", "note": "the minimum set as no permission to strip, absent" }, { "claim": "F16", "note": "the rule that rights metadata must never be removed, absent" }, { "claim": "F18", "note": "stripping by DAM, CMS and CDN, on the IPTC's own Google Images guidance, absent" }, { "claim": "F19", "note": "why AI-generated images are marked, absent" }, { "claim": "F20", "note": "leave Image Creator empty for AI-generated images, absent" }, { "claim": "F21", "note": "Digital Source Type for AI-generated images, absent (T names the property only)" }, { "claim": "F24", "note": "the C2PA metadata the new fields invalidated, absent" }, { "claim": "F25", "note": "the IIM's origin, absent" }, { "claim": "F26", "note": "the 'IPTC headers', absent" }, { "claim": "F27", "note": "XMP superseding IIM, absent (T names XMP only)" }, { "claim": "F28", "note": "the encyclopedia's reading of acceptance, absent" }, { "claim": "F31", "note": "metadata removable, no infallible protection, absent" }, { "claim": "F33", "note": "metadata stripped by a site's software (FAQ), absent" }, { "claim": "F35", "note": "the video's twenty years, absent" } ], "ledger": { "archive": "datasets/negative-of-the-negative/v2/ledgers/iptc-photo-metadata-tests/ledger-archive.json", "field": "datasets/negative-of-the-negative/v2/ledgers/iptc-photo-metadata-tests/field.json", "selection": "datasets/negative-of-the-negative/v2/traversal/iptc-photo-metadata-tests/", "config": "datasets/negative-of-the-negative/v2/panel/configs/iptc-photo-metadata-tests.json", "intake": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/", "audit": null }, "ontology": { "composition": "equal", "composition_note": "equal-terms case (v0.9 §0.9, §4.1): one claim space; the field's and the archive's claims ordered together by the entity's dependency and by genealogy within each sense; nothing translated; the tests and the standard they test held apart as two entities of the field", "case": { "value": "equal", "statement": "The archive reads the field's entity as the entity: the provenance census record describes the IPTC's tests from the IPTC's own pages, each field with its evidence and basis, asks of them the question it asks of every entity, and records their limits (historical, dated tables, not a C2PA test); the deposits that name the IPTC (#725, #1409) take the standard the tests test as given and place it, adding senses and limits on the field's own object: the AI metadata as Layer 1 disclosure, not lineage; embedded fields as scaffold extracted with a composition role unknown; the loss of embedded metadata at other carriers and at the training corpus (#1409, #127). #725 states its relation to the frameworks it places in those terms ('Extension and completion, not substitution or critique'), and #1409 calls the IPTC's vocabularies 'the same insight arriving as standards'. The Capture Registry records that the address names the standard and the record the tests, and keeps them apart. No defining paper contests the field's ontology or supplies one the field lacks: ρ = extends, the equal-terms case (§0.9, §1.2a). The standard and the tests are two entities of the field, and the composition holds them apart in one claim space.", "loci": [ { "dep": "provenance-census", "locus": "census.json organizing_question", "quote": "What provenance does this system carry, through which operation, on whose assertion, with what evidence of survival?" }, { "dep": "provenance-census", "locus": "census.json rows[slug == 'iptc-photo-metadata-tests'], lifecycle.detail", "quote": "dated results; the 2019 table is not a 2026 platform measurement. Succeeded in method by Metawatch (2026)" }, { "dep": "capture-registry", "locus": "iptc-photo-metadata-aio-20261029, findings[1] s1", "quote": "THE ADDRESS NAMES THE STANDARD; THE RECORD IS THE TESTS." }, { "dep": 725, "locus": "packet header, Relation", "quote": "**Relation:** Extension and completion, not substitution or critique" }, { "dep": 725, "locus": "§1.4 The Three Dimensions ¶4", "quote": "The packet's claim is not that the existing frameworks fail. It is that they were not designed for the dimension proposed here." }, { "dep": 1409, "locus": "§I.2 The substrate checksum is diplomatics, then forensics", "quote": "C2PA, FADGI, and IPTC provenance vocabularies are the same insight arriving as standards." } ] }, "E_F": { "type": "C (public entity: a test series of the IPTC Photo Metadata Working Group; the standard it tests, the IPTC Photo Metadata Standard, is a distinct entity of the same field)", "definition": "the IPTC Photo Metadata Working Group's tests of whether the Exif and IPTC metadata (IIM and XMP) embedded in an uploaded image survive display, Save As and download on sharing sites and file and message systems, against the IPTC's claim that 'embedded metadata should not be removed': 15 sites in 2013 and 2016, about a dozen in Spring 2019 (Pexels, pixabay and Unsplash stripping, Flickr replacing the creator, Facebook keeping a few rights fields, Behance keeping them), prompted by users whose metadata disappeared, read as showing that preservation in a workflow is not impossible, with a software study of August 2014; beside them, the IPTC Photo Metadata Standard they test (administrative, descriptive and rights properties in IPTC Core 1.5 and Extension 1.9, release 2025.1 with four properties for AI-generated content), read by Google Images and stripped by hosting systems by the IPTC's own account", "claims": [ "F36", "F37", "F38", "F39", "F40", "F48", "F47", "F41", "F42", "F43", "F45", "F49", "F50", "F3", "F1", "F10", "F5", "F9", "F7", "F17", "F18", "F16" ] }, "E_A": { "definition": "the same tests, in the provenance census record and the archive's records: a test series of the media lineage that expresses and tests provenance, its unit the site or system, its transformations upload, display, Save As and download, its carrier the metadata embedded in the image file, its results dated (2019) and historical, succeeded in method by Metawatch, not a test of C2PA credentials (provenance census record); the composition at the name gives the carrier and leaves out the measurement of its erasure (Capture Registry); and the carrier they test, placed by the archive: the standard's AI metadata at Layer 1, disclosure, not lineage (#725), embedded fields scaffold the pipeline reads with a composition role unknown (#1409), provenance carried as metadata lost at other carriers and stages, where in-pixel metadata and body text survive (#1409, #127)", "claims": [ "PE-01", "PE-03", "PE-04", "PE-08", "PE-09", "PE-07", "PE-10", "PE-13", "PE-16", "CAP-1-02", "CAP-1-03", "O725-01", "O1409-01", "O1409-02", "O1409-04", "O127-01" ], "defining_papers": [ 725, 1409, 127, 1190 ], "defining_records": [ "provenance census record (census.json rows[slug == 'iptc-photo-metadata-tests'], organizing_question, schema_note; rendered aggregators/iptc-photo-metadata-tests/index.html; editor Lee Sharks, compiled 2026-10-29)", "Capture Registry iptc-photo-metadata-aio-20261029 (OBS-9b96943ca090)" ] }, "rho": { "value": "extends", "status": "read from the provenance census record, the capture record and the deposits that name the IPTC (§1.2a); #725 names its relation to the frameworks it places 'Extension and completion'", "statement": "the archive reads E_F as the entity and adds senses, mechanisms and limits on the field's own object: for the tests, the record's account of their unit, transformations, carrier, results and limits (PE-04, PE-07–PE-10, PE-13, PE-15, PE-16) and the composition layer's omission of them at the name (CAP-1-02, CAP-1-03, CAP-1-04, CAP-1-07); for the carrier they test, the AI metadata as Layer 1 disclosure (O725-01), the independence of the dimensions of provenance and the reading of provenance as separable metadata corrected (O725-02, O725-03), embedded fields as scaffold extracted with a composition role unknown (O1409-01–O1409-03), and the loss of embedded and publication-layer provenance at other carriers and stages (O1409-04, O1409-05, O127-01)", "claims": [ "PE-04", "PE-07", "PE-08", "PE-09", "PE-10", "PE-13", "PE-15", "PE-16", "CAP-1-02", "CAP-1-03", "CAP-1-04", "CAP-1-07", "O725-01", "O725-02", "O725-03", "O1409-01", "O1409-02", "O1409-03", "O1409-04", "O1409-05", "O127-01" ], "guard": "ρ = extends claims an addition and no more: #725's 'Disclosure, not lineage' classes the AI fields by the archive's dimensions and finds no defect in the standard (its own text: 'The packet's claim is not that the existing frameworks fail'); #1409's 'composition role unknown' is an open question, not a finding that the composition does not read the fields; #127's stripping is at the training corpus, a stage the tests do not measure, and is composed with its stage named; the Capture Registry's 'often gone before any engine can read it' is carried at its modality (interpretation) beside the 2019 tables and opened, since the tests measured sharing platforms and not the hosting pipelines Google Images reads.", "considered": [ { "value": "constructs", "set_aside": "the archive does not read the tests or the standard as made by receiving texts" }, { "value": "revises", "set_aside": "the entity is not the archive's own; the census record is its first statement of it, and nothing is narrowed or withdrawn" } ] }, "translation": [ { "lineage": "the tests: what they are and what they check", "field_claims": [ "F3", "F36", "F37", "F38", "F39", "F46" ], "received": "F3 (B1, Photo Metadata page: 'Research'): \"IPTC not only defines the standard for photo metadata, but also conducts research about how it is used in the real world. We examine metadata in commonly used software, social media platforms, and more. The removal of rights information as images are transferred is of particular concern.\"; F36 (B12, standfirst): \"IPTC promotes the proper use of IPTC Photo Metadata and claims “embedded metadata should not be removed” from images shared on a photo platform or a system for sharing files or messages with images.\"; F37 (B12, standfirst): \"To check which systems support this claim, IPTC checks about a dozen sites regularly: in 2013, in 2016 and now again in Spring 2019.\"; F38 (B12, 'Test Procedure' 1): \"Uploading an image with values in many fields of the IPTC Photo Metadata Standard , e.g. the latest Reference Image File . This implies that all embedded metadata values are known and can be checked.\"; F39 (B12, 'Test Procedure' 3–4): \"Check if the image can be saved to a local device by a Save As function of the web browser. … Check if the image can be downloaded by a function of the tested system (e.g. a menu item). … are the embedded Exif and IPTC metadata (in the formats IIM and XMP) of the uploaded image still embedded?\"; F46 (B13, 'Photo Metadata Research' ¶1): \"IPTC not only defines the standard for photo metadata, but also conducts research about how photo metadata is used and implemented. Our most recent tests and studies:\"", "receiving_text": "—", "translation": "untranslated: composed as received beside CAP-1-02, PE-01, PE-04, PE-07, PE-08, PE-09", "archive_claims": [ "CAP-1-02", "PE-01", "PE-04", "PE-07", "PE-08", "PE-09" ] }, { "lineage": "the operator: the IPTC and its Photo Metadata Working Group", "field_claims": [ "F35", "F53" ], "received": "F35 (B11, card title (video; the watch page answered HTTP 429; title confirmed by YouTube oEmbed, channel IPTC)): \"Introduction and welcome, 20 years of IPTC Photo Metadata, Recent work\"; F53 (B15, article lead ¶1): \"The International Press Telecommunications Council (IPTC), based in London, United Kingdom, is a consortium of the world's major news agencies, other news providers and news industry vendors and acts as the global standards body of the news media.\"", "receiving_text": "—", "translation": "untranslated: composed as received beside PE-02", "archive_claims": [ "PE-02" ] }, { "lineage": "what the tests track: the 4Cs in the file", "field_claims": [ "F40" ], "received": "F40 (B12, 'Test Procedure' 2): \"If displayed: are these 4 relevant fields shown, correctly: Caption/description, Creator, Copyright Notice, Credit Line (= the 4Cs )\"", "receiving_text": "—", "translation": "untranslated: composed as received beside PE-06", "archive_claims": [ "PE-06" ] }, { "lineage": "the tests: origin, cadence and count", "field_claims": [ "F47", "F48" ], "received": "F47 (B13, 'Rights Information and Social Media Networks' ¶1): \"IPTC was approached by users who discovered that when they shared photos via social media sites or systems, their embedded metadata disappeared.\"; F48 (B13, 'Rights Information and Social Media Networks' ¶2): \"The IPTC Photo Metadata Working Group tested 15 social media sites in 2016 and 2013 to understand how image sharing, through upload and download, affects the integrity of embedded metadata as defined by IPTC standards and the Exif standard.\"", "receiving_text": "—", "translation": "untranslated: composed as received beside PE-11, PE-12, PE-14", "archive_claims": [ "PE-11", "PE-12", "PE-14" ] }, { "lineage": "the 2019 results: stripped, replaced, kept", "field_claims": [ "F41", "F42", "F43", "F44", "F45" ], "received": "F41 (B12, results, image-sharing sites: Pexels, pixabay, Unsplash): \"Pexels … Metadata is stripped off in SavedAs or downloaded files. … pixabay … Metadata is stripped off in SavedAs or downloaded files. … Unsplash … No embedded metadata displayed, metadata is stripped off in SavedAs or downloaded files.\"; F42 (B12, results, image-sharing sites: Flickr): \"(Free account tested.) Some embedded metadata displayed. Embedded Creator replaced by account owner. SavedAs files have no XMP metadata.\"; F43 (B12, results, file and message systems: Facebook, Twitter): \"No embedded metadata displayed. SavedAs files have no XMP metadata. A few rights related fields were retained in IIM and Exif. 2 IIM fields contain data generated by Facebook. … Twitter … No embedded metadata displayed. Metadata is stripped off in SavedAs files.\"; F44 (B12, results, file and message systems: Dropbox, Microsoft OneDrive): \"Passed through original file, preview can be SavedAs with stripped off metadata.\"; F45 (B12, results, image-sharing sites: Behance): \"Download is not a main feature, SaveAs files keep the embedded metadata.\"", "receiving_text": "—", "translation": "untranslated: composed as received beside PE-10", "archive_claims": [ "PE-10" ] }, { "lineage": "the tests' findings and the software study", "field_claims": [ "F49", "F50" ], "received": "F49 (B13, 'Rights Information and Social Media Networks' ¶3): \"Some social media sites or systems remove embedded information like copyright notes, the name of the creator, the description and more, while others protect photographers’ data better. The results show that it is not impossible to preserve metadata in a workflow.\"; F50 (B13, 'Rights Information and Software Performance'): \"The results, published in August 2014, look promising: … Half of the programs offered fields for photographers to enter rights information, including the date, the image’s creator, copyright notice, and rights usage term. … Two out of three programs helped users retrieve embedded rights data. … Unfortunately, two of the programs didn’t support rights metadata at all.\"", "receiving_text": "—", "translation": "untranslated: composed as received (no archive claim in this lineage)", "archive_claims": [] }, { "lineage": "the norm the tests measure against: embedded metadata must not be removed", "field_claims": [ "F15", "F16" ], "received": "F15 (B4, 'IPTC is often asked which fields should be filled out as a minimum'): \"By defining this set of minimal metadata properties IPTC does not support any removal of existing metadata outside this set without the explicit permission of the copyright owner of the image. (In simple words: this is not a permission to strip off metadata and is not legal advice.)\"; F16 (B4, 'Fundamental Guidelines for the Preservation of Embedded Metadata', principle 4): \"Copyright management information metadata must never be removed from the files. … Removal of such metadata impacts on the ability to assert ownership rights and is therefore forbidden by law in many countries.\"", "receiving_text": "—", "translation": "untranslated: composed as received (no archive claim in this lineage)", "archive_claims": [] }, { "lineage": "stripping in transit: where the carrier is lost", "field_claims": [ "F18", "F31", "F33" ], "received": "F18 (B4, 'For developers and site administrators: how to ensure the fields are preserved in images on your site'): \"Your site’s digital asset management system, content management system, image management system or content delivery network may be stripping out embedded metadata fields. Some systems do this with the best of intentions, thinking that it will save a few bytes of bandwidth, but stripping out metadata actually infringes on the copyright holders' rights and may even be illegal in some countries.\"; F31 (B8, 'Copyright and Attribution'): \"Metadata shouldn't be treated as an infallible form of copyright protection because it can be removed or modified, but it provides useful information that can travel with the image.\"; F33 (B9, answer 3 ¶2): \"In that case, the metadata might be stripped from your images by some software on your site. Sometimes this could be your Digital Asset Management system (such as Bynder, WebDAM or Extensis Portfolio). In other cases your Content Management System (such as WordPress or Drupal) might strip off metadata. Or it could be a Content Delivery Network that you use, such as Cloudflare or Cloudinary.\"", "receiving_text": "—", "translation": "untranslated: composed as received beside O1409-04, O1409-05, O127-01", "archive_claims": [ "O1409-04", "O1409-05", "O127-01" ] }, { "lineage": "the standard: what it is (the carrier the tests test)", "field_claims": [ "F1", "F5", "F10" ], "received": "F1 (B1, Photo Metadata page: standfirst): \"IPTC Photo Metadata sets the industry standard for administrative, descriptive, and copyright information about images.\"; F5 (B2, IPTC Photo Metadata Standard page ¶3): \"Today, the IPTC Photo Metadata Standard consists of two schemas – IPTC Core and IPTC Extension – which were built on the legacy of the original IPTC-IIM, and developed by the IPTC for professional use with a focus on news and stock photos.\"; F10 (B3, §1 Overview ¶1): \"IPTC Photo Metadata provides data about photographs and the values can be processed by software. Each individual metadata entity is called a property and they are grouped into Administrative, Descriptive and Rights-related properties.\"", "receiving_text": "—", "translation": "untranslated: composed as received beside PE-05", "archive_claims": [ "PE-05" ] }, { "lineage": "the standard's release: 2025.1, Core 1.5, Extension 1.9", "field_claims": [ "F9", "F12" ], "received": "F9 (B3, 'About the Standard'): \"This is the IPTC Photo Metadadata Standard 2025.1, including … IPTC Core Metadata Schema 1.5 … IPTC Extension Metadata Schema 1.9\"; F12 (B3, table of contents, Extension heading (and the section heading at the same place in the body)): \"IPTC Extension schema 1.8 specifications\"", "receiving_text": "—", "translation": "untranslated: composed as received (no archive claim in this lineage)", "archive_claims": [] }, { "lineage": "the standard's genealogy: IIM, IPTC headers, XMP", "field_claims": [ "F6", "F14", "F25", "F26", "F27", "F52" ], "received": "F6 (B2, IPTC Photo Metadata Standard page ¶3): \"IPTC worked alongside Adobe on the technical implementation of the metadata that employs Adobe’s XMP technology (now an ISO Standard) as an enriched alternative to the IIM format.\"; F14 (B4, Introduction, 'How IPTC Photo Metadata Evolved Over Time'): \"IPTC Core fields can be embedded in the IIM format and/or in the XMP format. A key challenge for metadata embedded in parallel in IIM and XMP is that the values are synchronised - this should be taken care of by the image management software.\"; F25 (B6, article lead ¶1): \"The Information Interchange Model (IIM) is a file structure and set of metadata attributes that can be applied to text, images and other media types. It was developed in the early 1990s by the International Press Telecommunications Council (IPTC) to expedite the international exchange of news among newspapers and news agencies.\"; F26 (B6, article lead ¶3): \"IIM metadata embedded in images are often referred to as \"IPTC headers\", and can be easily encoded and decoded by most popular photo editing software.\"; F27 (B6, article lead ¶4): \"The Extensible Metadata Platform (XMP) has largely superseded IIM's file structure, but the IIM image attributes are defined in the IPTC Core schema for XMP and most image manipulation programs keep the XMP and non-XMP IPTC attributes synchronized.\"; F52 (B15, article 'International Press Telecommunications Council', §IPTC Standards › Photo metadata ¶1): \"The IPTC defined a set of metadata properties that can be applied to images, part of a broader standard developed in the early 1990s and known as the IPTC Information Interchange Model (IIM). Embedded IIM image information is often referred to as an \"IPTC header\".\"", "receiving_text": "—", "translation": "untranslated: composed as received (no archive claim in this lineage)", "archive_claims": [] }, { "lineage": "the standard's scope and limits: file formats, no technical metadata", "field_claims": [ "F8", "F11", "F30" ], "received": "F8 (B2, 'What’s Defined by This Standard', last paragraph): \"How Photo Metadata formats are stored within image files are defined by non-IPTC file format standards, such as JPEG/JFIF, TIFF, PNG and more.\"; F11 (B3, §2.2 Technical Metadata): \"Because the IPTC acknowledges these technical metadata standards of other bodies and does not wish to duplicate existing metadata properties, the IPTC Photo Metadata specification does not include any technical metadata.\"; F30 (B8, 'What Is IPTC Metadata?'): \"IPTC refers to metadata standards developed for the professional exchange and description of media. Unlike EXIF, which is heavily focused on technical capture information, IPTC metadata is commonly used to describe, organize and manage images.\"", "receiving_text": "—", "translation": "untranslated: composed as received (no archive claim in this lineage)", "archive_claims": [] }, { "lineage": "the standard's reception and use", "field_claims": [ "F2", "F4", "F28" ], "received": "F2 (B1, Photo Metadata page: 'Critical to Photo and Related Businesses'): \"Photo metadata is key to protecting images' copyright and licensing information online. It is also essential for managing digital assets.\"; F4 (B2, IPTC Photo Metadata Standard page ¶1): \"The IPTC Photo Metadata Standard is the most widely used standard to describe photos, because of its universal acceptance among news agencies, photographers, photo agencies, libraries, museums, and other related industries.\"; F28 (B6, article lead ¶5): \"Because of its nearly universal acceptance among photographers — even amateurs — this is by far IPTC's most widely used standard.\"", "receiving_text": "—", "translation": "untranslated: composed as received (no archive claim in this lineage)", "archive_claims": [] }, { "lineage": "the 2025.1 properties for AI-generated content", "field_claims": [ "F7", "F13", "F22", "F23" ], "received": "F7 (B2, 'What’s New in the 2025.1 Standard'): \"The 2025.1 version, published in November 2025, adds four new properties to handle metadata for AI-generated content: AI Prompt Information, AI Prompt Writer Name, AI System Used and AI System Version Used.\"; F13 (B3, §11.11 Data Mining, Definition): \"Data mining prohibition or permission, optionally with constraints.\"; F22 (B5, announcement ¶2): \"The IPTC Photo Metadata Working Group has released version 2025.1 of the IPTC Photo Metadata Standard, including properties that can be used for AI-generated content.\"; F23 (B5, announcement, the new properties): \"AI System Used … Definition: The AI engine and/or the model name used to generate this image.\"", "receiving_text": "—", "translation": "untranslated: composed as received beside CAP-1-05", "archive_claims": [ "CAP-1-05" ] }, { "lineage": "marking AI-generated images, and the C2PA metadata invalidated", "field_claims": [ "F19", "F20", "F21", "F24" ], "received": "F19 (B4, 'Applying Metadata to AI-generated Images' ¶2): \"It may be important to distinguish AI-generated images from \"regular\" images: for example, to avoid re-training AI models on content that was already generated by a model, to understand which images can fall under copyright and which cannot (in some jurisdictions) and to avoid misinterpreting generated images as being real photos.\"; F20 (B4, 'Applying Metadata to AI-generated Images', field suggestions): \"Creator is bound to the owner of the intellectual property of an image in many countries and there are first legal decisions that AI generated images are not considered as creative work generating an intellectual property. Therefore, our recommendation is to leave the Image Creator field empty.\"; F21 (B4, 'Applying Metadata to AI-generated Images', field suggestions): \"The Digital Source Type field should be set to the URI value http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia or http://cv.iptc.org/newscodes/digitalsourcetype/compositeSynthetic.\"; F24 (B5, announcement, caption of the example image): \"This image contains the new IPTC Photo Metadata fields “AI Prompt Information”, “AI System Used” and “AI Prompt Writer Name”. Note that adding the new IPTC Photo Metadata properties has rendered the C2PA metadata invalid.\"", "receiving_text": "—", "translation": "untranslated: composed as received beside PE-16", "archive_claims": [ "PE-16" ] }, { "lineage": "who reads the embedded fields: Google Images and the IPTC's tools", "field_claims": [ "F17", "F29", "F32", "F34" ], "received": "F17 (B4, 'IPTC Photo Metadata and Google Images'): \"Google displays three IPTC photo metadata fields, wherever available, for an image shown as search result. This tells the viewer who is the creator and who is the copyright holder of the image and what credit line should be shown next to the image.\"; F29 (B7, 'Handbooks and User Guides'): \"Quick Guide to IPTC Photo Metadata and Google Images … explains how to check and update IPTC Photo Metadata for best results in Google Images search results, as introduced by Google in September 2018.\"; F32 (B9, answer 1): \"IPTC maintains the technical standard that image creators can use to put their creator and copyright details inside image files. We call this “photo metadata”. Google extracts this information from photos in search results and displays it to help you find who owns the image.\"; F34 (B10, Overview): \"IPTC's Photo Metadata Inspector tool lets you see embedded metadata in many image files. For eligible images, a context menu will appear when you right-click on the image. Select \"View IPTC Photo Metadata\" and you will be taken to IPTC's Get Photo Metadata (GetPMD) tool which will display all metadata embedded in the image file.\"", "receiving_text": "—", "translation": "untranslated: composed as received beside CAP-1-04, O1409-01, O1409-02", "archive_claims": [ "CAP-1-04", "O1409-01", "O1409-02" ] }, { "lineage": "reception: the encyclopedia", "field_claims": [ "F51" ], "received": "F51 (B14, Wikipedia: title IPTC_photo_metadata_tests (and IPTC_Photo_Metadata)): \"Wikipedia does not have an article with this exact name. … There were no results matching the query. The pages \"IPTC photo metadata tests\" and '\"IPTC photo metadata tests\"' do not exist.\"", "receiving_text": "—", "translation": "untranslated: composed as received (no archive claim in this lineage)", "archive_claims": [] } ], "receiving_texts": "equal-terms case: every field claim composed as received, beside the archive claims it stands with" }, "measure": { "rule": "v0.9 §4.10: KO_B sentences surviving in the KO at similarity ≥ 0.95, with positions (computed as apply_v09.py does: difflib.SequenceMatcher ratio, the best KO sentence for each KO_B sentence)", "v0.9": { "surviving": 0, "of": 14, "positions": [ null, null, null, null, null, null, null, null, null, null, null, null, null, null ] }, "opening_run": { "rule": "v0.9 §5.10 (equal-terms case): the field-only KO's sentences as the KO's opening run in their own order", "breach": false }, "blocks": { "rule": "v0.9 §4.1 (equal-terms and mixed cases): the KO does not open with the field as a block or close with the archive as one; sentences typed by the ledgers of the claims they cite (F field-only, A archive-only, M both)", "sequence": "MMMFFAFFAFFFAMFFFFFFMAAFAAAFAA", "field_only_head": 0, "archive_only_tail": 2, "breach": false }, "max_similarity": [ 0.127, 0.573, 0.234, 0.329, 0.139, 0.493, 0.191, 0.347, 0.121, 0.229, 0.152, 0.384, 0.083, 0.602 ], "ko_sentence_1_max_similarity_to_KO_B": 0.229 }, "homonyms": { "names": [], "basis": "The census row carries no disambiguation field. The address's string names the IPTC Photo Metadata Standard, a distinct entity of the same field (the object the tests test), not a sense of the tests' name; the composition at the address substitutes it for the row's entity (CAP-1-02, CAP-1-03). No card is a homonym.", "distinct_entities": [ "IPTC Photo Metadata Standard (IPTC Core and IPTC Extension; the carrier the tests test; the address's object)", "IPTC Information Interchange Model (the legacy standard; card 6)", "IPTC, the International Press Telecommunications Council (the operator)", "IPTC Metawatch (census row iptc-metawatch, related has_part; no /non row)", "C2PA conformance (census row c2pa-conformance, related neighbour; no /non row)", "IPTC Photo Metadata Interoperability Tests (another IPTC test page, saved by the census and not cited by the row)", "GetPMD and the IPTC Photo Metadata Inspector (the IPTC's tools; card 10)" ], "substitutes": { "T": [ "IPTC Photo Metadata Standard (T composes the standard at the name; CAP-1-02, CAP-1-03)" ] }, "register": { "address_1": { "slug": "iptc-photo-metadata-aio-20261029", "obs_id": "OBS-9b96943ca090" } } }, "notes": [ "One address, Google AI Overview (expanded), signed out, incognito, 2026-10-29: iptc-photo-metadata-aio-20261029 (OBS-9b96943ca090, ADDR-ee0523b11509, AXN:0AD0.CAPTURE.☀️🔵❤️♌🌀🎯), eleven cards, 231 words in the answer body. A NEW address; the provenance census record landed the same day and no card cites it (CAP-1-08). The address names the standard; the census row at the name is the tests (CAP-1-02). The KO keeps them as two entities: the tests are the row's entity; the standard is composed as the carrier they test, a distinct entity of the same field, and no claim of one is composed as a claim of the other.", "Wikipedia: no article for the tests (B14: IPTC_photo_metadata_tests, raw and rendered HTTP 404, no search results), none at the address's title IPTC_Photo_Metadata (raw HTTP 404); the operator's article exists and was ledgered at its section 'Photo metadata' (B15). Two Wikipedia requests answered HTTP 429 at first and were repeated once with the same command.", "Fetching: every reachable card saved verbatim with curl (-A 'Mozilla/5.0') on 2026-10-29 between 17:08 and 17:11 UTC, raw and text with sha256 in field.json. Card URLs were not in the paste except card 10's (the transcript's marker): B1, B2, B4 by title and site; B3 by the specification's own canonical URL (it redirects to the 2025.1 page over http); B5 by the IPTC news archive and WebSearch; B7, B9 by WebSearch; B8 from the NeededApps home page; B11 from YouTube's results page. Card snippets for B1, B3, B4 and B6 are labelled rewordings ('Definition: …', 'Standard: …', 'Standards: …', 'Overview: …') and not the pages' text; the snippets of B2, B5, B7, B8, B9, B10 are the pages' text.", "Unreachable: B11, the IPTC's video (youtube.com/watch?v=JtfroU7UgjU): the watch page answered HTTP 429 (a Google 'sorry' interstitial, saved as B11.html); YouTube's oEmbed (HTTP 200) confirms the title and the channel IPTC; no transcript fetched. Its title stands (F35); the card has no snippet.", "Own pages: B12 and B13 are the census's saved copies (gunzipped; sha256 equal to the census's), not refetched. The census saved two further sources under this entity's prefix that the row does not cite: iptc-photo-metadata-tests--interop-tests (the Interoperability Tests page, whose procedures the row lists as unchecked) and iptc-photo-metadata-tests--metawatch (the Metawatch announcement, which the iptc-metawatch row cites under this prefix). Neither is admitted here (the brief admits the own pages the record cites).", "The archive subset: the string pass (non_traverse.py; config with seven aliases and two classes sourced from B13, B12, B4, B9 and B12, B2) returned 17 D, 3 R and 13 O candidates in 9 deposits; reading admitted #725 (O), #1190 (instance of #725, S4) and #1409 (O, R); the hop (54 candidates) admitted #127 (O, class 1, at the training corpus). The archive never names the tests; its claims bear on the carrier and on the loss of embedded metadata, read at O-class and composed as such. String-pass defect, reported, not fixed: #725's matrix row 'IPTC AI metadata | … | Layer 1 metadata | Disclosure, not lineage' and #1409's 'metadata stripping' sentence were not returned (the table cut at 900 characters; the class pattern does not match 'metadata stripping'); both found by reading.", "Defects and observations, reported, not fixed. (a) The census record: retention_results is accurate but partial against its own source: the 2019 page also records EyeEm's saved file losing its Exif and Google Photo's losing its IIM (B12's saved text, not ledgered), Flickr's losing its XMP (F42), Dropbox and OneDrive previews saved 'with stripped off metadata' (F44), and Behance keeping the metadata (F45); no field of the record is contradicted by a fetched source. The capture shows nothing of the tests and so cannot date the record; the record's own lifecycle ('the 2019 table is not a 2026 platform measurement') stands. (b) The census saved sources under this entity's prefix that its row does not cite (interop-tests; metawatch, used by the iptc-metawatch row): a naming defect of the source store. (c) The Capture Registry's finding 'The same organization's tests record that the data is often gone before any engine can read it' (CAP-1-04) reaches past the tests: the 2019 tests measured sharing platforms, not the hosting pipelines whose files Google Images reads; the IPTC's warnings about those pipelines are the User Guide's and the FAQ's (F18, F33), at modality hypothesis. Carried at its own modality and opened. (d) The IPTC's specification heads its Extension section 'IPTC Extension schema 1.8 specifications' in its contents and body while giving Extension 1.9 elsewhere (F12, marked internally_inconsistent); the specification's canonical URL redirects to an http address.", "Neighbours: the census relates the tests to iptc-metawatch (has_part) and c2pa-conformance (neighbour); neither has a /non row (datasets/negative-of-the-negative/v2/rows/ holds none at 2026-10-29). The MMRS row datasets/negative-of-the-negative/v2/rows/data-provenance-explorer.json is the nearest provenance row; it bears on training-data licensing, not on embedded image metadata, and is not a neighbour of this one.", "Ledgers unaudited (§3.8: one extractor). Field quotes 53/53 and archive quotes 40/40 verified by script; KO 30 sentences, P body within the bound; KO_B 14 sentences, none surviving in the KO at ≥ 0.95; the KO opens on the tests, KO_B on the standard." ], "composition_v09": { "source": "this row (composed directly; no rebuild/negative-of-the-negative/v09/iptc-photo-metadata-tests.json)", "composer": "Claude (Opus 5.5), subagent, 2026-10-29", "defining_material_read": [ { "what": "provenance census record, census row", "file": "/home/claude/fleet/provenance-erasure/data/provenance-census/census.json (rows[slug == 'iptc-photo-metadata-tests'], organizing_question, schema_note)", "read": "whole" }, { "what": "provenance census record, rendered", "file": "/home/claude/fleet/provenance-erasure/aggregators/iptc-photo-metadata-tests/index.html", "read": "text, for agreement with the sources" }, { "what": "census source copies", "file": "/home/claude/fleet/provenance-erasure/data/provenance-census/sources/iptc-photo-metadata-tests--{social-2019,research}.txt", "read": "whole" }, { "what": "capture record", "file": "data/EA-WG-CAPTURES-01.json (iptc-photo-metadata-aio-20261029)", "read": "transcript, transcript_raw, cite_list, d, reading, findings, analysis, q_kind, per_note, originator, notes" }, { "dep": 725, "file": "data/texts/AXN-0273-text.md", "read": "the header, §1.1, §1.4, §3.4, the §4 matrix and the Layer 1 list" }, { "dep": 1190, "file": "data/texts/AXN-04B7-text.md", "read": "the matrix row and the Layer 1 list, for S4" }, { "dep": 1409, "file": "data/texts/AXN-0592-text.md", "read": "§0–§3 of the v0.1 draft, §E.1, §F.3, §F.6, §I.2, and every passage naming the IPTC" }, { "dep": 127, "file": "data/texts/AXN-02B2-text.md", "read": "the Abstract and §IV.1" }, { "what": "the specification", "file": "data/texts/AXN-0700-text.md", "read": "§0–§11 whole; Appendix A by its headings" } ], "cuts": [], "notes": "equal case; KO 30 sentences, all 53 field and 40 archive claims cited; P body 345 words; KO_B 14 sentences, none surviving at ≥ 0.95" }, "field_by_origin": { "cards": [ "B1", "B2", "B3", "B4", "B5", "B6", "B7", "B8", "B9", "B10", "B11" ], "own_pages": [ "B12", "B13" ], "wikipedia": [ "B14", "B15" ], "census_third_party": [], "unreachable": [ "B11" ], "title_only": [ "B11" ], "wikipedia_state": "no article for the tests: the title IPTC_photo_metadata_tests returns HTTP 404 for raw wikitext (redirect=no) and for the rendered page ('Wikipedia does not have an article with this exact name'), and the full-text search for the quoted phrase in article space reports no results; the address's own title IPTC_Photo_Metadata is also absent (raw HTTP 404). The operator has an article (International Press Telecommunications Council), whose section 'Photo metadata' gives the standard and not the tests (B15); the IIM article is a card on T's rail (B6) and also says nothing of the tests.", "sources": [ { "id": "B1", "origin": "card", "role": "Overview card 1", "card": "IPTC — Photo Metadata IPTC", "url": "https://iptc.org/standards/photo-metadata/", "kind": "Overview card (the operator's page)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 1 } ], "files": { "B1.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B1.html", "sha256": "67cbd7ce1750d398ce18738ca57075c84953555c30ee420d8148b2b2d7965892" }, "B1.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B1.txt", "sha256": "cf1cbba0ec1ac3578c212cf30beca94930781a5bf08d2f1e94679336545f9932" } }, "fetched": { "at": "2026-10-29T17:08:41Z", "http": 200, "url": "https://iptc.org/standards/photo-metadata/", "final_url": "https://iptc.org/standards/photo-metadata/", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B1.html", "raw_sha256": "67cbd7ce1750d398ce18738ca57075c84953555c30ee420d8148b2b2d7965892", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B1.txt" ] }, "card_title": "Photo Metadata IPTC", "card_snippet": "Definition: IPTC Photo Metadata sets industry standards for administrative, descriptive, and copyright information regarding images. Purpose: Protects copyright...", "card_note": null, "snippet_on_page": false, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "yes: the 'Research' paragraph (F3), and the site menu", "note": "URL by the card's title and site (the page's is 'Photo Metadata IPTC'); the snippet ('Definition: … Purpose: Protects copyright…') is not the page's text: the page has 'IPTC Photo Metadata sets the industry standard for administrative, descriptive, and copyright information about images.' The card's snippet is a labelled rewording." }, { "id": "B2", "origin": "card", "role": "Overview card 2", "card": "IPTC — IPTC Photo Metadata Standard", "url": "https://iptc.org/standards/photo-metadata/iptc-standard/", "kind": "Overview card (the operator's page)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 2 } ], "files": { "B2.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B2.html", "sha256": "a4dd802767a7c6edd6256188c240e4d13956f6b150e9c0cc6469f4e0db0d100b" }, "B2.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B2.txt", "sha256": "3a59b1b1fcc0452d3e2263a702f05c6d84f23c22fc8cc7a53410e57ff05f58ef" } }, "fetched": { "at": "2026-10-29T17:08:43Z", "http": 200, "url": "https://iptc.org/standards/photo-metadata/iptc-standard/", "final_url": "https://iptc.org/standards/photo-metadata/iptc-standard/", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B2.html", "raw_sha256": "a4dd802767a7c6edd6256188c240e4d13956f6b150e9c0cc6469f4e0db0d100b", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B2.txt" ] }, "card_title": "IPTC Photo Metadata Standard", "card_snippet": "Today, the IPTC Photo Metadata Standard consists of two schemas – IPTC Core and IPTC Extension – which were built on the legacy of the original IPTC-IIM, and de...", "card_note": null, "snippet_on_page": true, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "in the IPTC site menu only (links 'Social Media Sites Photo Metadata Test Results 2019' and 'IPTC Photo Metadata Interoperability Tests'); no claim on them", "note": "URL by title and site; the snippet is the page's ¶3 verbatim." }, { "id": "B3", "origin": "card", "role": "Overview card 3", "card": "IPTC — IPTC Photo Metadata Standard 2025.1", "url": "https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata", "kind": "Overview card (the specification)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 3 } ], "files": { "B3.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B3.html", "sha256": "275a1717429f2208c608b92805d6fc7aebdebc3c1ed05d1f97373832d5913320" }, "B3.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B3.txt", "sha256": "39a0ef12f50cd11f233e8e0704593aedf565db602b8d1c2ec1f9066baa101bc8" } }, "fetched": { "at": "2026-10-29T17:08:44Z", "http": 200, "url": "https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata", "final_url": "http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-2025.1.html", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B3.html", "raw_sha256": "275a1717429f2208c608b92805d6fc7aebdebc3c1ed05d1f97373832d5913320", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B3.txt" ] }, "card_title": "IPTC Photo Metadata Standard 2025.1", "card_snippet": "Standard: IPTC Photo Metadata Standard 2025.1 incorporating IPTC Core Schema 1.5 and Extension Schema 1.9. Core Properties: Administrative, descriptive, and rig...", "card_note": null, "snippet_on_page": false, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council', 'Photo Metadata Working Group' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "no", "note": "the canonical URL the specification gives for itself ('A public version of this specification document is available at https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata'); it redirects to http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-2025.1.html (note the redirect to http). The snippet ('Standard: … Core Properties: …') is a labelled rewording." }, { "id": "B4", "origin": "card", "role": "Overview card 4", "card": "IPTC — IPTC Photo Metadata User Guide", "url": "https://www.iptc.org/std/photometadata/documentation/userguide/", "kind": "Overview card (the user guide)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 4 } ], "files": { "B4.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B4.html", "sha256": "0a8a0c47b9c3c75154b57510ea1dc8c59dcb6a1529022e43e0b3300a9cbb158b" }, "B4.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B4.txt", "sha256": "90835f6bab1be3482442a87f84b0aed45f84377d1794a18f17c72ec1d25f85d3" } }, "fetched": { "at": "2026-10-29T17:08:46Z", "http": 200, "url": "https://www.iptc.org/std/photometadata/documentation/userguide/", "final_url": "https://www.iptc.org/std/photometadata/documentation/userguide/", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B4.html", "raw_sha256": "0a8a0c47b9c3c75154b57510ea1dc8c59dcb6a1529022e43e0b3300a9cbb158b", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B4.txt" ] }, "card_title": "IPTC Photo Metadata User Guide", "card_snippet": "Standards: IPTC Photo Metadata Standard covers Core (v1.5) and Extension (v1.9) schemas embedded via IIM and XMP formats in image headers. Content: Describes ge...", "card_note": null, "snippet_on_page": false, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council', 'Photo Metadata Working Group' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "no", "note": "URL by title and site (linked from B7 and the specification's status note); the snippet ('Standards: … Content: …') is a labelled rewording." }, { "id": "B5", "origin": "card", "role": "Overview card 5", "card": "IPTC — IPTC Photo Metadata Standard adds new properties for AI-generated content - IPTC", "url": "https://iptc.org/news/iptc-photo-metadata-standard-2025-1-adds-ai-properties/", "kind": "Overview card (the operator's announcement)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 5 } ], "files": { "B5.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B5.html", "sha256": "59d9db3a4c7a748f0e344086a87443dd5a30c041ce08352bfe36a468170c4b66" }, "B5.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B5.txt", "sha256": "8a7b2bc1c99f73887d353d72edb21c058cc07874567d0a0c215fd1e553e36989" } }, "fetched": { "at": "2026-10-29T17:08:47Z", "http": 200, "url": "https://iptc.org/news/iptc-photo-metadata-standard-2025-1-adds-ai-properties/", "final_url": "https://iptc.org/news/iptc-photo-metadata-standard-2025-1-adds-ai-properties/", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B5.html", "raw_sha256": "59d9db3a4c7a748f0e344086a87443dd5a30c041ce08352bfe36a468170c4b66", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B5.txt" ] }, "card_title": "IPTC Photo Metadata Standard adds new properties for AI-generated content - IPTC", "card_snippet": "Nov 27 2025 IPTC Photo Metadata Standard adds new properties for AI-generated content * AI System Used. Definition: The AI engine and/or the model name used to ...", "card_note": null, "snippet_on_page": true, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council', 'Photo Metadata Working Group' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "in the IPTC site menu only (links 'Social Media Sites Photo Metadata Test Results 2019' and 'IPTC Photo Metadata Interoperability Tests'); no claim on them", "note": "URL by title: found in the IPTC news archive (iptc.org/news/2025/11) and by WebSearch (iptc.org/?p=8745 redirects here); the page's <title> is the card's title verbatim; dated 2025-11-27T11:45:51Z; the snippet matches the page." }, { "id": "B6", "origin": "card", "role": "Overview card 6", "card": "Wikipedia — IPTC Information Interchange Model - Wikipedia", "url": "https://en.wikipedia.org/wiki/IPTC_Information_Interchange_Model", "kind": "Overview card (Wikipedia)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 6 } ], "files": { "B6.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B6.html", "sha256": "f1f6848d9eece558f26622e65ecb17cc87d585000be14ce83ddcbc99d91f4d1e" }, "B6.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B6.txt", "sha256": "90c31aa0169ab6cdda41c5fbefa956c5d60bbc31eeb58f5880aca78980023795" }, "B6.wiki": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B6.wiki", "sha256": "273169b87b738c838b79170a24fc1e1bd079478171778619b9bb53a077103c3d" } }, "fetched": { "at": "2026-10-29T17:10:56Z", "http": 200, "url": "https://en.wikipedia.org/wiki/IPTC_Information_Interchange_Model", "final_url": "https://en.wikipedia.org/wiki/IPTC_Information_Interchange_Model", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B6.html", "raw_sha256": "f1f6848d9eece558f26622e65ecb17cc87d585000be14ce83ddcbc99d91f4d1e", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B6.txt" ], "wikitext": { "url": "https://en.wikipedia.org/w/index.php?title=IPTC_Information_Interchange_Model&action=raw", "at": "2026-10-29T17:08:50Z", "http": 200, "sha256": "273169b87b738c838b79170a24fc1e1bd079478171778619b9bb53a077103c3d", "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B6.wiki" } }, "card_title": "IPTC Information Interchange Model - Wikipedia", "card_snippet": "Overview: Information Interchange Model (IIM) is a 1990s IPTC metadata standard and file structure for news exchange, widely adopted by photographers as embedde...", "card_note": null, "snippet_on_page": false, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council', 'Photo Metadata Working Group' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "no", "note": "the rendered page (first fetch answered HTTP 429, refetched with the same command at 17:10:56Z, HTTP 200) and the raw wikitext (B6.wiki, action=raw); quotes are from the rendered text. The snippet ('Overview: Information Interchange Model (IIM) is a 1990s IPTC metadata standard …') is a labelled rewording." }, { "id": "B7", "origin": "card", "role": "Overview card 7", "card": "IPTC — IPTC Guidelines & Support", "url": "https://iptc.org/standards/photo-metadata/guidelines-support/", "kind": "Overview card (the operator's page)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 7 } ], "files": { "B7.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B7.html", "sha256": "fa31b80137785c0f92db2efa1b0ef6a34782b852299e51c1a6aa8b3f3527fea8" }, "B7.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B7.txt", "sha256": "0da9ec69b0cb5db9123043601ae24bd9b989da540ea5df2bf360030814a9e904" } }, "fetched": { "at": "2026-10-29T17:08:50Z", "http": 200, "url": "https://iptc.org/standards/photo-metadata/guidelines-support/", "final_url": "https://iptc.org/standards/photo-metadata/guidelines-support/", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B7.html", "raw_sha256": "fa31b80137785c0f92db2efa1b0ef6a34782b852299e51c1a6aa8b3f3527fea8", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B7.txt" ] }, "card_title": "IPTC Guidelines & Support", "card_snippet": "Quick Guide to IPTC Photo Metadata and Google Images explains how to check and update IPTC Photo Metadata for best results in Google Images search results, as i...", "card_note": null, "snippet_on_page": true, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council', 'Photo Metadata Working Group' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "in the IPTC site menu only (links 'Social Media Sites Photo Metadata Test Results 2019' and 'IPTC Photo Metadata Interoperability Tests'); no claim on them", "note": "URL by WebSearch on title (iptc.org/?p=438 redirects here); the snippet matches the page." }, { "id": "B8", "origin": "card", "role": "Overview card 8", "card": "NeededApps — What Is Image Metadata? EXIF, IPTC and XMP Explained - NeededApps", "url": "https://neededapps.com/tutorials/what-are-image-metadata-exif-iptc-xmp/", "kind": "Overview card (third party)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 8 } ], "files": { "B8.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B8.html", "sha256": "9863e3890450b586b6d3d6fc808d5af94db3d762709aeaf264c1daeb6ec263ac" }, "B8.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B8.txt", "sha256": "738c082fb43273bae583daf2f5579b0d8d315ae6b7fb1d238ee140d0ddd847c5" } }, "fetched": { "at": "2026-10-29T17:08:50Z", "http": 200, "url": "https://neededapps.com/tutorials/what-are-image-metadata-exif-iptc-xmp/", "final_url": "https://neededapps.com/tutorials/what-are-image-metadata-exif-iptc-xmp/", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B8.html", "raw_sha256": "9863e3890450b586b6d3d6fc808d5af94db3d762709aeaf264c1daeb6ec263ac", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B8.txt" ] }, "card_title": "What Is Image Metadata? EXIF, IPTC and XMP Explained - NeededApps", "card_snippet": "IPTC refers to metadata standards developed for the professional exchange and description of media. Unlike EXIF, which is heavily focused on technical capture i...", "card_note": null, "snippet_on_page": true, "names_operator": "yes ('IPTC' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "no", "note": "URL from the NeededApps home page's link list (two guessed paths answered 404); the page's <title> is the card's title without the site suffix; the snippet matches the page." }, { "id": "B9", "origin": "card", "role": "Overview card 9", "card": "IPTC — Google Images and IPTC: Frequently Asked Questions", "url": "https://iptc.org/standards/photo-metadata/iptc-and-google-images-frequently-asked-questions/", "kind": "Overview card (the operator's page)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 9 } ], "files": { "B9.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B9.html", "sha256": "411f99558ec1b28c1531c831e582ea4fb6cd738b625c9fa8bc1ce6e58d069e7d" }, "B9.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B9.txt", "sha256": "9577a29c034957779fec38ea0051a5127cd063e6754a921147e1a5a6def5411c" } }, "fetched": { "at": "2026-10-29T17:08:51Z", "http": 200, "url": "https://iptc.org/standards/photo-metadata/iptc-and-google-images-frequently-asked-questions/", "final_url": "https://iptc.org/standards/photo-metadata/iptc-and-google-images-frequently-asked-questions/", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B9.html", "raw_sha256": "411f99558ec1b28c1531c831e582ea4fb6cd738b625c9fa8bc1ce6e58d069e7d", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B9.txt" ] }, "card_title": "Google Images and IPTC: Frequently Asked Questions", "card_snippet": "I would like to obtain a licence to re-use an image that I found on Google search. Can you help me? I run a web site and my images don't have metadata appearing...", "card_note": null, "snippet_on_page": true, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "in the IPTC site menu only (links 'Social Media Sites Photo Metadata Test Results 2019' and 'IPTC Photo Metadata Interoperability Tests'); no claim on them", "note": "URL by WebSearch on the title (a guessed path answered 404); the snippet matches the page's question list." }, { "id": "B10", "origin": "card", "role": "Overview card 10", "card": "Chrome Web Store — IPTC Photo Metadata inspector - Chrome Web Store - Google", "url": "https://chromewebstore.google.com/detail/iptc-photo-metadata-inspe/ejadeefikdifbfnhokdodfphhkimbelb", "kind": "Overview card (third-party host; the IPTC's extension)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 10 } ], "files": { "B10.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B10.html", "sha256": "ffcb77c3fae1daaad7e5400ae11aa954eebe2120af8f0aa43251296aef758baf" }, "B10.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B10.txt", "sha256": "b9c8434269772deb6f03d1c690e907a23ba72d3d260e2f9f5118c9d7b6ffda81" } }, "fetched": { "at": "2026-10-29T17:08:52Z", "http": 200, "url": "https://chromewebstore.google.com/detail/iptc-photo-metadata-inspe/ejadeefikdifbfnhokdodfphhkimbelb", "final_url": "https://chromewebstore.google.com/detail/iptc-photo-metadata-inspe/ejadeefikdifbfnhokdodfphhkimbelb", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B10.html", "raw_sha256": "ffcb77c3fae1daaad7e5400ae11aa954eebe2120af8f0aa43251296aef758baf", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B10.txt" ] }, "card_title": "IPTC Photo Metadata inspector - Chrome Web Store - Google", "card_snippet": "Right-click on any image and select \"View IPTC Photo Metadata\". IPTC's GetPMD tool shows all metadata embedded in the image. Many images on the web contain embe...", "card_note": null, "snippet_on_page": true, "names_operator": "yes ('IPTC' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "no", "note": "the URL is in the transcript itself (the tools item's third marker); the snippet matches the page." }, { "id": "B11", "origin": "card", "role": "Overview card 11", "card": "YouTube·IPTC — Introduction and welcome, 20 years of IPTC Photo Metadata, Recent work ...", "url": "https://www.youtube.com/watch?v=JtfroU7UgjU", "kind": "Overview card (video, 3m)", "surfaced_by_T": [ { "slug": "iptc-photo-metadata-aio-20261029", "card": 11 } ], "files": { "B11.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B11.html", "sha256": "fafd777ce5b671b8db0f9ac86204fb527359953604a2186f6abb537b17b0ff12" }, "B11.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B11.txt", "sha256": "b651d77f19958e40fd986424996307f48a1cfa7f8d59592246473eb0bd3e1e30" }, "B11-oembed.json": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B11-oembed.json", "sha256": "f16e302a7f9a775cf311c054d46be5bbcb2fa7342bae7943ed5bb0074217aa3d" } }, "fetched": { "at": "2026-10-29T17:08:53Z", "http": 429, "url": "https://www.youtube.com/watch?v=JtfroU7UgjU", "final_url": "https://www.google.com/sorry/index?continue=https://www.youtube.com/watch%3Fv%3DJtfroU7UgjU&q=EhD9o-ciCsPMAAIRdFD-_sZhGKX7jdcGIjACAXIWdLiSyq2vTRKDGcPG2wqac0Rj3Wb4gyDIPLI7Wrym2zlUItebWxbGa5OgaWsyAnJSWgFDYPOq8Ouo58DX9AE", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B11.html", "raw_sha256": "fafd777ce5b671b8db0f9ac86204fb527359953604a2186f6abb537b17b0ff12", "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B11.txt" ], "oembed": { "url": "https://www.youtube.com/oembed?url=https://www.youtube.com/watch?v=JtfroU7UgjU&format=json", "at": "2026-10-29T17:09:04Z", "http": 200, "sha256": "f16e302a7f9a775cf311c054d46be5bbcb2fa7342bae7943ed5bb0074217aa3d", "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B11-oembed.json" }, "status": "unreachable (HTTP 429 at the watch page); title only" }, "card_title": "Introduction and welcome, 20 years of IPTC Photo Metadata, Recent work ...", "card_snippet": null, "card_note": "video, 3m", "snippet_on_page": null, "names_operator": "yes (the title names 'IPTC'; the oEmbed channel is 'IPTC')", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "no", "note": "found by the card's title on YouTube's results page (videoId JtfroU7UgjU); the watch page answered HTTP 429 (a Google 'sorry' interstitial, saved as B11.html); YouTube's oEmbed endpoint (HTTP 200, saved as B11-oembed.json) confirms the title 'Introduction and welcome, 20 years of IPTC Photo Metadata, Recent work on Photo Metadata at IPTC' and the channel IPTC. Admitted through its title (the card has no snippet); no transcript fetched." }, { "id": "B12", "origin": "own_page", "role": "own page the census record cites (the 2019 results)", "card": "IPTC — Social Media Sites Photo Metadata Test Results 2019", "url": "https://iptc.org/standards/photo-metadata/social-media-sites-photo-metadata-test-results-2019/", "kind": "own page (census copy)", "surfaced_by_T": "no (not surfaced by T; admitted beside the cards by the operator's ruling of 2026-10-29)", "files": { "B12.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B12.html", "sha256": "1b4794817413523cb403e2da7fe33943e97b40a7d42752bcc1f071c11ba14f66" }, "B12.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B12.txt", "sha256": "684127f460e2664e2a6c5fcefa74882f0272c2b3c362dbe29a4d9fa7a02f164f" } }, "fetched": { "census_read": "2026-10-29", "census_fetched": "2026-10-29T15:55:21Z", "http": 200, "url": "https://iptc.org/standards/photo-metadata/social-media-sites-photo-metadata-test-results-2019/", "census_sha256": "1b4794817413523cb403e2da7fe33943e97b40a7d42752bcc1f071c11ba14f66", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B12.html", "raw_sha256": "1b4794817413523cb403e2da7fe33943e97b40a7d42752bcc1f071c11ba14f66", "sha256_matches_census": true, "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B12.txt" ], "copied_from": "/home/claude/fleet/provenance-erasure/data/provenance-census/sources/iptc-photo-metadata-tests--social-2019.html.gz" }, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council', 'Photo Metadata Working Group' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "yes (the entity's own page)", "note": "the census's saved copy (sources/iptc-photo-metadata-tests--social-2019.html.gz, gunzipped; .txt copied), not refetched; the sha256 of the gunzipped HTML equals the census's. Not surfaced by T; linked from cards B1, B2, B5, B7, B9 (the IPTC's site menu: 'Social Media Sites Photo Metadata Test Results 2019')." }, { "id": "B13", "origin": "own_page", "role": "own page the census record cites (the research page)", "card": "IPTC — Research", "url": "https://iptc.org/standards/photo-metadata/research/", "kind": "own page (census copy)", "surfaced_by_T": "no (not surfaced by T; admitted beside the cards by the operator's ruling of 2026-10-29)", "files": { "B13.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B13.html", "sha256": "4d8b44f1ba520320e92060e092a8931e4a40742c313427791bc7373b463616db" }, "B13.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B13.txt", "sha256": "9e9133e4d57d4114d0087d6513f167d2e2d1180e5ebcdfc805f47741cc21b631" } }, "fetched": { "census_read": "2026-10-29", "census_fetched": "2026-10-29T15:55:20Z", "http": 200, "url": "https://iptc.org/standards/photo-metadata/research/", "census_sha256": "4d8b44f1ba520320e92060e092a8931e4a40742c313427791bc7373b463616db", "raw": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B13.html", "raw_sha256": "4d8b44f1ba520320e92060e092a8931e4a40742c313427791bc7373b463616db", "sha256_matches_census": true, "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B13.txt" ], "copied_from": "/home/claude/fleet/provenance-erasure/data/provenance-census/sources/iptc-photo-metadata-tests--research.html.gz" }, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council', 'Photo Metadata Working Group' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "yes (the entity's own page)", "note": "the census's saved copy, not refetched; sha256 equals the census's. Not surfaced by T; card B1's 'Research … Read More' paragraph is this page's summary." }, { "id": "B14", "origin": "wikipedia", "role": "the entity's Wikipedia title (and the address's)", "card": "Wikipedia — IPTC photo metadata tests (no article)", "url": "https://en.wikipedia.org/wiki/IPTC_photo_metadata_tests", "kind": "Wikipedia (no article)", "surfaced_by_T": "no (not surfaced by T; checked by the operator's ruling of 2026-10-29)", "files": { "B14.wiki": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14.wiki", "sha256": "6212fb85e8042a3294e49a8dc1a5ec0d4a955561d4943be2f650931ed9d6d126" }, "B14.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14.html", "sha256": "fbfa9ceade35ff316a87b82836e9ac8a8c7799126fb6f3007cdc781002230d75" }, "B14-search.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14-search.html", "sha256": "8f0de7832465c9e84394c5d4b423a2bbeab26385dc8df981d1b50f29a06d8a05" }, "B14b.wiki": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14b.wiki", "sha256": "957da07b42a0a473c406d6833fc8921555db4a1281be5a5a4d4938941db58120" }, "B14.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14.txt", "sha256": "92cd9c6a0ca3f3e1fffc2e381c50d07f7b14f7e60e2cd32bf9c43259ca715e3e" } }, "fetched": { "raw": { "url": "https://en.wikipedia.org/w/index.php?title=IPTC_photo_metadata_tests&action=raw&redirect=no", "at": "2026-10-29T17:11:06Z", "http": 404, "sha256": "6212fb85e8042a3294e49a8dc1a5ec0d4a955561d4943be2f650931ed9d6d126", "bytes": 1930, "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14.wiki" }, "rendered": { "url": "https://en.wikipedia.org/wiki/IPTC_photo_metadata_tests", "at": "2026-10-29T17:20:16Z", "http": 404, "sha256": "fbfa9ceade35ff316a87b82836e9ac8a8c7799126fb6f3007cdc781002230d75", "bytes": 50969, "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14.html", "note": "first attempt 17:11:07Z answered HTTP 429; the same command repeated" }, "search": { "url": "https://en.wikipedia.org/w/index.php?search=%22IPTC+photo+metadata+tests%22&title=Special:Search&profile=advanced&fulltext=1&ns0=1", "at": "2026-10-29T17:11:08Z", "http": 200, "sha256": "8f0de7832465c9e84394c5d4b423a2bbeab26385dc8df981d1b50f29a06d8a05", "bytes": 78446, "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14-search.html" }, "raw_address_title": { "url": "https://en.wikipedia.org/w/index.php?title=IPTC_Photo_Metadata&action=raw&redirect=no", "at": "2026-10-29T17:20:17Z", "http": 404, "sha256": "957da07b42a0a473c406d6833fc8921555db4a1281be5a5a4d4938941db58120", "bytes": 1929, "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14b.wiki", "note": "title IPTC_Photo_Metadata; first attempt 17:11:10Z answered HTTP 429" }, "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B14.txt" ] }, "names_operator": "no", "names_archive": "no", "names_tests": "no", "note": "no article for the tests; none at IPTC_Photo_Metadata either (raw HTTP 404, redirect=no); the full-text search for the quoted phrase in article space returns no results. B14.txt summarises the four responses with their notices." }, { "id": "B15", "origin": "wikipedia", "role": "the operator's Wikipedia article (section 'Photo metadata')", "card": "Wikipedia — International Press Telecommunications Council", "url": "https://en.wikipedia.org/wiki/International_Press_Telecommunications_Council", "kind": "Wikipedia (the operator's article)", "surfaced_by_T": "no (not surfaced by T; the operator's article, read by the operator's ruling of 2026-10-29)", "files": { "B15.wiki": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B15.wiki", "sha256": "c9111b64b71f2a9c3035b8324ec6ae04b93eb421281cb484167e1e51e2cd440e" }, "B15.html": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B15.html", "sha256": "9b2ab0e71ea453009147b7d84d2453751ff859815bcdfb29f221037bfe8262d7" }, "B15.txt": { "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B15.txt", "sha256": "c754434d4b6d4617f53c299fa297f9a4aa9c0bfa5ad4a3ba1aaa2a926f3770c3" } }, "fetched": { "raw": { "url": "https://en.wikipedia.org/w/index.php?title=International_Press_Telecommunications_Council&action=raw", "at": "2026-10-29T17:11:11Z", "http": 200, "sha256": "c9111b64b71f2a9c3035b8324ec6ae04b93eb421281cb484167e1e51e2cd440e", "bytes": 11706, "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B15.wiki" }, "rendered": { "url": "https://en.wikipedia.org/wiki/International_Press_Telecommunications_Council", "at": "2026-10-29T17:11:12Z", "http": 200, "sha256": "9b2ab0e71ea453009147b7d84d2453751ff859815bcdfb29f221037bfe8262d7", "bytes": 116360, "path": "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B15.html" }, "text": [ "datasets/negative-of-the-negative/v2/intake/iptc-photo-metadata-tests-20261029/B15.txt" ] }, "names_operator": "yes ('IPTC', 'International Press Telecommunications Council' in the saved text)", "names_archive": "no (none of the Crimson Hexagonal Archive, Alexanarch, Lee Sharks, machinemediation, provenanceerasure, EA-WG-CAPTURES-01 in the saved text, card title and snippet)", "names_tests": "no", "note": "the operator has an article; its section 'IPTC Standards › Photo metadata' gives the standard (IIM, IPTC Core, IPTC Extension, XMP) and says nothing of the tests. The card on T's rail is the IIM article (B6), which also says nothing of the tests." } ] } }