JSON-LD explained for personal websites
hawksley.dev
JSON-LD explained for personal websites
1–10 of 94 posts
Re: JSON-LD explained for personal websites
#2A bit disappointing that (IIUC) for the common parsers you have to say everything twice, in HTML and in the accompanying JSON-LD form even though RDFa exists for the exact purpose of letting you point at the values already present in your markup. (Admittedly RDFa is perhaps too flexible for its own good when you just want to mark up some stuff, but if you’re writing a full parser anyway dealing with a bit of excessive cleverness in the format should not be too bad.)
Re: JSON-LD explained for personal websites
#3We have semantic HTML, but for some weird reason we need to yet again re-express the semantic meaning of our website in bespoke weird JSON in a script tag that the browser won't process.
Re: JSON-LD explained for personal websites
#4A bit disappointing that (IIUC) for the common parsers you have to say everything twice, in HTML and in the accompanying JSON-LD form even though RDFa exists for the exact purpose of letting you point at the values already present in your markup. (Admittedly RDFa is perhaps too flexible for its own good when you just want to mark up some stuff, but if you’re writing a full parser anyway dealing with a bit of excessiv…
And then there is https://schema.org/
It's the item* attributes, e.g.: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Also Dublin Core in tags.
Why do they keep adding conflicting meta data formats to HTML!?!
Re: JSON-LD explained for personal websites
#5A bit disappointing that (IIUC) for the common parsers you have to say everything twice, in HTML and in the accompanying JSON-LD form even though RDFa exists for the exact purpose of letting you point at the values already present in your markup. (Admittedly RDFa is perhaps too flexible for its own good when you just want to mark up some stuff, but if you’re writing a full parser anyway dealing with a bit of excessiv…
And then there is https://schema.org/ It's the item* attributes, e.g.: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Also Dublin Core in tags. Why do they keep adding conflicting meta data formats to HTML!?!
Re: JSON-LD explained for personal websites
#6We have semantic HTML, but for some weird reason we need to yet again re-express the semantic meaning of our website in bespoke weird JSON in a script tag that the browser won't process.
I have used JSON-LD in my own websites and found that it fills a separate need from semantic HTML. Your semantic HTML will specify things that the browser processes, like the title and headings. The JSON-LD data is metadata, like date created, date updated, tags, authorship. These things can be expressed in the HTML using micro data, but I stopped using micro data because JSON-LD was easier.
The JSON-LD I populate from the same data that I use to generate my site, and I use the JSON-LD metadata to generate things like index pages (list of blog posts from 2024, all posts related to topic X, etc). The main consumers of JSON-LD are search engines.
If you are interested in getting offended, then think about how we are also putting OpenGraph metadata in our web pages. Two different metadata formats for the same page.
Re: JSON-LD explained for personal websites
#7[deleted]
Re: JSON-LD explained for personal websites
#8We have semantic HTML, but for some weird reason we need to yet again re-express the semantic meaning of our website in bespoke weird JSON in a script tag that the browser won't process.
What I see as the ideal would be a world where servers and browsers could do content negotitation, and have browsers attempting first to request only the json-ld from the website and using its own internal renderer format.
Re: JSON-LD explained for personal websites
#9A bit disappointing that (IIUC) for the common parsers you have to say everything twice, in HTML and in the accompanying JSON-LD form even though RDFa exists for the exact purpose of letting you point at the values already present in your markup. (Admittedly RDFa is perhaps too flexible for its own good when you just want to mark up some stuff, but if you’re writing a full parser anyway dealing with a bit of excessiv…
And then there is https://schema.org/ It's the item* attributes, e.g.: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Also Dublin Core in tags. Why do they keep adding conflicting meta data formats to HTML!?!
There is also microformats.
Re: JSON-LD explained for personal websites
#10A bit disappointing that (IIUC) for the common parsers you have to say everything twice, in HTML and in the accompanying JSON-LD form even though RDFa exists for the exact purpose of letting you point at the values already present in your markup. (Admittedly RDFa is perhaps too flexible for its own good when you just want to mark up some stuff, but if you’re writing a full parser anyway dealing with a bit of excessiv…
IMO this is going overboard. Any time you are duplicating data from HTML into JSON-LD, consider just omitting that data from JSON-LD, unless the data isn’t consistently present in HTML (because it is a bitch to be consistent about this stuff).
I tried using RDFa and liked the property that it was theoretically less redundant, but switched to JSON-LD because it JSON-LD is just easier to get working. And this is speaking as somebody who uses a hand-rolled static site generator—the issue here is that whether information is present in the raw HTML is something contextual, and if something isn’t present in the HTML then you need to put it somewhere else or it’s not mechanically parseable from the page. Like, to a human reader, a post on “Alice’s Blog” is assumed to be authored by Alice, so I may omit the “by Alice” text from the document, and then I would want to put that metadata in the page some other way.
Putting the metadata in JSON-LD lets me just be dumb about it. The metadata is always in JSON-LD, and the HTML may or may not contain an explicit representation of that same metadata. Easy.
But the JSON-LD does not need to contain the URL of the page (which is ) or the title (which is in ), for example.