# Supplementary File S3. Materials and counting detail

Brian R. Hatten, MD
The Orthopedic Clinic, Daytona Beach, Florida, USA
ORCID 0009-0002-6221-615X

Supplementary file to: Hatten BR. Google's Rich Results Test Displays No More Than 102 Objects per JSON-LD Entity and Accepts an Invalid eventStatus Value. Deposited with the data on Zenodo, concept DOI 10.5281/zenodo.23002802, CC BY 4.0. Section numbers refer to the paper. S1, S2 and S3 numbers refer to the supplementary files.

## S3.1 The entities in version 11.9

Version 11.9 holds 45 entities: one Physician, one WebSite, one MobileApplication, 11 ScholarlyArticle and 4 NewsArticle entities, 9 Organization entities and one GovernmentOrganization, a MedicalClinic, a MedicalBusiness, 3 Event entities, 3 MedicalProcedure entities, 3 Review entities, and one each of FAQPage, MedicalDevice, MedicalTherapy, VideoObject, Dataset and LearningResource.

## S3.2 The second site

The Physician entity in the orthotoc.com graph carries the same @id as the one on My Knee Guide (Section 2). I did this so that both sites identify one person, with the My Knee Guide About page as the full description of me and the practice graph as a spoke on that hub. The orthotoc.com files therefore carry the same entity inside a different graph, with different entities around it. That is what made them useful as a check on the 102 (Section 4.2 and Table 1).

## S3.3 Files in the lineage that cannot be parsed

Nine archived files cannot be parsed as saved and are marked as not measured. One of them, version 7.5, has smart quotes in place of JSON quotation marks. A repaired copy is included and labeled.

## S3.4 The counter

Counting "type" rows alone undercounts, because untyped items under some properties are displayed without a type row. object_count2.py (Section 3.4) was corrected eight times during the study, each time from a capture that disagreed with it.

The eight, none of which was predicted, were:

1. Plain text given as an author is displayed as an object (the second version saved January 8, 2026).
2. A nested object whose @id is also an entity in the graph is displayed merged with that entity (the January 9 version).
3. When the two merged copies carry the same property, the objects under it are both displayed, even when they are identical (the third version saved January 8, 2026).
4. A reference back to an entity that is already open displays nothing (the January 9 version).
5. Plain text given as the item of a ListItem is displayed as an object (the January 9 version).
6. Plain text given as a department is displayed as an Organization (version 6.9).
7. A second block elsewhere in the graph that carries the entity's own @id is merged into the entry, and the objects under it count. The merge appears in three captures (the February 27 version, version 4.8 and the March 1 version). That its objects count was worked out from one, the March 1 version.
8. Plain text given as an action target is displayed as an EntryPoint, and as an "-input" value it is displayed as a PropertyValueSpecification (a variant of the orthotoc.com graph with the WebSite entity after the Physician).

Two things seen on September 26, 2026 are recorded here as observations, not as rules. In the two Review entities of S1.8, the objects left out came from inside a nested entity, itemReviewed, with everything after it displayed to the end of the file. This is the selection inside nested entities that the counter does not model, seen before in archived versions run from the Code tab (Section 4.4) and seen here for the first time on an indexed page. And the counter indexes only the entities listed at the top level of the @graph, so it misses an entity that reaches the display through a typed block nested in another entity. That is why it counts 68 objects in the MobileApplication of S1.8 where the capture shows 69.

## S3.5 The test files

Each built test file differs from an already captured file by one change (Section 3.5). Each build was checked by reloading it and confirming that nothing else had changed.

For Finding 2, five test files were run in April 2026 and again in September 2026 (Section 5). The original April files were not kept. The files used in September were regenerated from the appendix of the April case study using field values from the production graph, and they are labeled as regenerated.

## S3.6 The result links

The Rich Results Test's share button produces a link to a result (Section 3.3). Google's help page says the links are valid for approximately 90 days. A link from March 21, 2026 was gone when I opened it on September 19, 2026, and a link from May 2, 2026 was gone on September 27, 2026, 148 days after it was made. Each returned the message "Invalid snapshot number." Links made from September 19 to 24 still opened on September 27. From September 19 the result link was pasted at the end of each capture file, and the capture, not the link, is the record.

## S3.7 Ruler Files 3D and 3E

Both were built inside the full version 11.8 graph (Section 4.2). 3D is the Physician with 300 items under subjectOf and nothing else, and its entry ended at Ruler 0101. 3E splits the ruler as 3B does, 80 items under knowsAbout and 300 under subjectOf, and its entry ended at Ruler B 0101. The top of the 3E entry showed the Physician's type, name and id and then Ruler B 0001. Telephone, address and the 80 knowsAbout items were not shown. Counted as objects, that entry is the Physician and 101 ruler items, 102. The top of the 3D entry was not read, so its count is consistent with 102 only if it displayed as 3E did. Both readings are from screenshots (IMG_7497 and IMG_7498 in the deposit, with IMG_7499 for the top of 3E).

## S3.8 The captures of the second part

The second part of the study is the runs that were predicted before the capture (Section 3.7). Seventeen archived files were run as saved. Fourteen are versions of the My Knee Guide graph from the lineage. One is a test variant of that graph built in March 2026, which is not one of the 215 lineage files and is deposited with the test files. Two are versions of the orthotoc.com graph. With versions 4.8 and 11.8 from the first part, nineteen archived files were run in all, and sixteen of them are lineage versions of My Knee Guide.

Of the 34 captures in the second part, 29 were predicted before the capture, and the predicted total held in every one of the 29. Four of the other five, version 4.8, two variants of it and version 11.8, were captured before the rules were written. The fifth is a second capture of version 11.8, made for comparison. Where a prediction was written for a ladder file in the first part, it concerned which properties would be kept, and some of those failed.