So the whole idea of JSON revolves around object->arrays presented in a simple text format. The LD variant is no different. When combined with Schema.org it turns into a flexible display API that many things can consume, very similar to legacy feeds. Unlike feeds though, it's primarily consumed by search engines as inline script data on the page, and that makes things tedious and annoying from an independent API or automation perspective.So, why do search engines want JSON-LD + Schema.org to go against the API grain in regards to forcing sites to use inline data? Why must we make our code that much larger with duplicate data such as main content for human viewing and then separately defined again within the JSON-LD script(s)? What I mean is, if LD is intended for semantic consumption, why can't we put the LD objects into a separate page, route, or file? The data duplication in source drives me nuts, especially for long content!As it stands now, no search engine validators understand the following use case:Example.com has a full templated page for each product, with a url like https://www.example.com/this-product-name. This page is validated HTML with all the bells and whistles. It does not include any Schema.org markup within the templated view.Example.com also has a JSON-LD generation function which comes right from a controller, and makes an API endpoint for each product. All that is returned is the LD object->arrays in JSON format...no template. This is ready for consumption and similar to the way to an XML feed works for aggregators. Adding /json to the URL renders this kind of LD API object response instead of the full templated page. So the route would be: https://www.example.com/this-product-name/jsonThe full templated page for each product includes a <link /> in <head> that points to its alternate LD endpoint described above. This is the same way ATOM feeds operate, pointing a visitor to the alternate format for the data which their feed readers consume. So the alternate for the LD would look like this: <link rel=alternate type=application/ld+json title=This Products Consumption API (JSON-LD + Schema.org) href=https://www.example.com/this-product-name/json/>The JSON-LD response includes sameAs and something like potentialAction pointing back to the full templated version of the page (the first bullet point above). This is similar to how alternate works in ATOM feeds themselves...making a circle of alternates.The ATOM feed also includes these alternates, exposing the /json endpoints. Basically there is a 3 (or more) way going on between templated page, JSON-LD endpoint, ATOM feed, etc. All the data is the same, it's just different methods of displaying consumption formats for different purposes.Running https://www.example.com/this-product-name through the snippet test results in no structured data found even when including the path to the script src like <script type=application/ld+json src=https://www.example.com/this-product-name/json></script>. Running consumption endpoint https://www.example.com/this-product-name/json through results in correct validation.So is it just the validation tool, or is there really no way to get the bots to understand the alternate assimilation? Is there any way I can get the JSON-LD off my templated page and into an alternate API route, like JSON spec itself does so well already? Am I missing some huge reason why search engines chose to require LD put exclusively inline instead of allowing sane-endpoint abilities?
Why don't search engines support JSON-LD + Schema.org as seperated endpoints via rel=alternate or script src?
schema.org;structured data;json ld;rel alternate;knowledge graph