header for JSON-LD ???

# Michael A. Peters (6 days ago)

I am (finally) starting to implement JSON-LD on a site, it generates a lot of data that is useless to the non-bot typical user.

I'd prefer to only stick it in the head when the client is a crawler that wants it.

Wouldn't it be prudent if agents that want JSON-LD can send a standardized header as part of their request so web apps can optionally choose to only send the JSON-LD data to clients that want it? Seems it would be kinder to mobile users on limited bandwidth if they didn't have to download a bunch of JSON that is meaningless to them.

Is this the right group to suggest that?

Contact us to advertise here
# Jeffrey Yasskin (5 days ago)

2¢: This list tends to disapprove of JSON-LD, so you should probably first run your proposal by a group that likes JSON-LD. Maybe public-rdf-comments at w3.org referenced from www.w3.org/TR/json-ld/? Or an issue against json-ld/json-ld.org?

Jeffrey

On Fri, Jul 21, 2017 at 2:21 PM, Michael A. Peters <mpeters at domblogger.net>

wrote:

# Dan Brickley (5 days ago)

Hypothetically, if search engines were to start picking up JSON-LD from linked files, which link rel type would this group consider most appropriate?

Dan

# Michael A. Peters (5 days ago)

Interesting. It's a beautiful way to create structured data separate from the content, just like layout (CSS) is best kept separate from the content.

I wonder why people on this list don't like it. Reading about it was an epiphany for me, it's (in my opinion) the right way to do structured data, and far superior to sticking a bunch of attributes in tags - just like CSS selectors are far superior to sticking style attributes in tags.

Not meaning to start a holy war, it's just I didn't come across anything negative about it during my initial research on JSON-LD. Other than my own observation that it bloats the content sent to every client, hence the desire for a header specifying it is actually wanted before it is stuffed in the document head node.

# Qebui Nehebkau (4 days ago)

On 23 July 2017 at 14:12, Michael A. Peters <mpeters at domblogger.net> wrote:

It's a beautiful way to create structured data separate from the content, just like layout (CSS) is best kept separate from the content. [...] I wonder why people on this list don't like it. Reading about it was an epiphany for me, it's (in my opinion) the right way to do structured data, and far superior to sticking a bunch of attributes in tags - just like CSS selectors are far superior to sticking style attributes in tags.

I can't speak for anyone else - I can barely speak for myself - but I think I'd argue that, intuitively, if your structured data isn't logically part of your content, there's a good chance that it doesn't belong there at all.

# Michael A. Peters (4 days ago)

On 07/23/2017 02:42 PM, Qebui Nehebkau wrote:

On 23 July 2017 at 14:12, Michael A. Peters <mpeters at domblogger.net> wrote:

It's a beautiful way to create structured data separate from the content, just like layout (CSS) is best kept separate from the content. [...] I wonder why people on this list don't like it. Reading about it was an epiphany for me, it's (in my opinion) the right way to do structured data, and far superior to sticking a bunch of attributes in tags - just like CSS selectors are far superior to sticking style attributes in tags.

I can't speak for anyone else - I can barely speak for myself - but I think I'd argue that, intuitively, if your structured data isn't logically part of your content, there's a good chance that it doesn't belong there at all.

It logically describes the content, and because it is separate from the content it describes, is much easier to manage and inspect and bugfix.

Just for example, with an audio, I can describe the creator as a person including the company the person works for etc. in JSON-LD without needing to have tags in the content for those things to add attributes to. That's information that is useful to machines especially when linking different objects from domains together but it isn't necessarily useful to the person reading the web page.

So keeping the structured data separate from the content allows richer details to be added to the structured data for machines to read without needing to alter the design intended for the human readers of the page.

Two audiences are thus served without needing to compromise the design for either, both machine and human.

But the content for machines doesn't need to be sent to humans where they don't care about it, hence the desire for a standard header machines that do want it can send to have it included.

# Michael A. Peters (4 days ago)

On 07/23/2017 03:33 PM, Michael A. Peters wrote:

On 07/23/2017 02:42 PM, Qebui Nehebkau wrote:

snip >

I can't speak for anyone else - I can barely speak for myself - but I think I'd argue that, intuitively, if your structured data isn't logically part of your content, there's a good chance that it doesn't belong there at all.

It logically describes the content, and because it is separate from the content it describes, is much easier to manage and inspect and bugfix.

Just for example, with an audio, I can describe the creator as a person including the company the person works for etc. in JSON-LD without needing to have tags in the content for those things to add attributes to. That's information that is useful to machines especially when linking different objects from domains together but it isn't necessarily useful to the person reading the web page.

So keeping the structured data separate from the content allows richer details to be added to the structured data for machines to read without needing to alter the design intended for the human readers of the page.

Two audiences are thus served without needing to compromise the design for either, both machine and human.

But the content for machines doesn't need to be sent to humans where they don't care about it, hence the desire for a standard header machines that do want it can send to have it included.

A better example.

I run an audio site (all legal, no piracy, I'm anti-DRM but also pro intellectual property) where users can select a category.

There could be, say, 12 audios in that category, but the web page only displays one. If the user wants to listen to a different audio, they use a select menu. If its the same artist, there's enough info in the data-* attributes of the select menu items to swap the audio node w/o even an ajax call, If different artist, I do make an ajax call because more than just the audio node changes.

With JSON-LD I can put structured data for all audios the person can play from that page into the JSON-LD. I can't do that with tag based structured data unless I make a div display display:none to contain all the other audios.

I use libxml2 to create pages so I can modify any part of the DOM at any point allowing me to create the JSON-LD from the same data used to generate the page, so it is always in sync. I then can stuff it in the head node at the end.

That's not possible with many platforms that send content before it is finished generating all the page, so JSON-LD for many may not have the kind of advantage I can from it, but the ability to describe objects available through user actions (such as select menu) but aren't part of the DOM when the page is sent is a huge benefit to me over tag based implementations of structured data.

Hope that sheds some light on why I had an epiphany when I finally stopped to read about JSON-LD.

Now, back on topic, a header would be nice so I only have to stuff it in the head when a machine is asking for it ;)

# Jonathan Zuckerman (4 days ago)

I think one of the best aspects of the web platform is that there can be a single node in the network that is accessible to all. The linked data approach hides the information from humans. The structured data alternative you suggest (div display none) still hides the information from humans. Here's a better alternative that is accessible to both humans and robots: simply display the div. What's your objection to displaying this information to humans? How can you justify displaying different content to different classes of user?

On Sun, Jul 23, 2017 at 8:13 PM Michael A. Peters <mpeters at domblogger.net>

wrote:

# Philipp Serafin (4 days ago)

...pardon, I meant to reply to the group. Thank you for the notice.

Reposting to group:

Am 24.07.2017 5:41 nachm. schrieb "Jonathan Zuckerman" < j.zuckerman at gmail.com>:

How about a hyperlink to an artist page with complete info about the artist? This has been the established pattern since the inception of the internet - there is a single canonical source of information about a piece of data, the data may change over time but old references won't require complicated syncing.

The ajax example doesn't figure into the debate - the fact that some content may not be in the DOM before some Javascript gets a chance to execute is irrelevant to both humans and robots in terms of semantics (although there is an ongoing UX conversation about the merits of such approaches - indeed most client-side web frameworks have implemented server-side rendering, see React Server, Ember FastBoot etc..)

Did you mean to reply to the group, or only to me?

# Melvin Carvalho (4 days ago)

On 21 July 2017 at 23:21, Michael A. Peters <mpeters at domblogger.net> wrote:

I am (finally) starting to implement JSON-LD on a site, it generates a lot of data that is useless to the non-bot typical user.

I'd prefer to only stick it in the head when the client is a crawler that wants it.

Wouldn't it be prudent if agents that want JSON-LD can send a standardized header as part of their request so web apps can optionally choose to only send the JSON-LD data to clients that want it? Seems it would be kinder to mobile users on limited bandwidth if they didn't have to download a bunch of JSON that is meaningless to them.

Is this the right group to suggest that?

Firstly, well done for going the extra mile and producing structured data on the web

Typically, if I am primarily interested in JSON-LD data, there is a mechanism in web architecture which allows me to specify this.

I would use an accept header such as

Accept: application/ld+json

In this way, machines can receive machine readable data, and humans can receive human readable.

# Michael A. Peters (3 days ago)

When too much is displayed, the website is too busy.

If there are 12 audios in a group, the person can only listen to one at a time so it is pointless to have 12 audio nodes present.

But you can display one and have the other 11 accessible via a select menu, so that if and when the user wants them, they select the audio they want and JS swaps out the audio node.

But if you define your structured data as attributes then information about the other 11 is not available to machines that fetch the page and want to know what the page offers.

That's why JSON-LD is superior to the other methods of structured data. You can have the structured data for all 12 audios since all 12 audios are part of the page but only one has an (x)html audio node in the html as sent by the initial GET request.

Web pages aren't static, even after the client received the page the DOM can be altered without reloading the page.

Structured data separate from the content is the only logical way to account for that.

# Qebui Nehebkau (3 days ago)

On 24 July 2017 at 19:21, Michael A. Peters <mpeters at domblogger.net> wrote:

But if you define your structured data as attributes then information about the other 11 is not available to machines that fetch the page and want to know what the page offers.

It sounds like the machines probably want to fetch some kind of index page, not the page for a particular item. I think that if you find yourself wanting to send two different sets of content to different users, you probably need to be directing them to different resources.

# Michael A. Peters (3 days ago)

On 07/24/2017 04:43 PM, Qebui Nehebkau wrote:

On 24 July 2017 at 19:21, Michael A. Peters <mpeters at domblogger.net> wrote:

But if you define your structured data as attributes then information about the other 11 is not available to machines that fetch the page and want to know what the page offers.

It sounds like the machines probably want to fetch some kind of index page, not the page for a particular item. I think that if you find yourself wanting to send two different sets of content to different users, you probably need to be directing them to different resources.

No, the structured data should be generated the same time as the content.

It's just if it resides in a single script node in the head that can end up being quite large, there's no need to include that node when the client has no use for it.

Right now, I only send it if the client is an honest bot. But there may be some browser add-ons that make use of it, so they should be able to announce they want it and get it.

# Jonathan Zuckerman (3 days ago)

This suggestion might have more success with the W3C? I'm not completely clear on the politics and history of the two orgs, but it seems like the W3C has supported JSON-LD in the past, so they might have some interest in expanding it.

On a personal note, I think you've got really far down the path of a hammer looking for a nail. Spend more time working with the web you've got before trying to change it. I've responded inline with a few suggestions for your audio website case.

On Mon, Jul 24, 2017 at 7:21 PM Michael A. Peters <mpeters at domblogger.net>

wrote:

When too much is displayed, the website is too busy.

I disagree that displaying related content to the user is "too busy". If you can't figure out how to organize the content of your website in a way that users will understand, I don't think it's fair to expect that search engine bots will be able to do it for you. This is a design problem, or a UX problem, or a business problem. The technology we currently have is perfectly capable of resolving your issues.

If there are 12 audios in a group, the person can only listen to one at a time so it is pointless to have 12 audio nodes present.

Use URLs e.g. example.com/group/7/audio/3 and the history API to build a decent interface which loads a single audio at a time while also indicating its role in the group (and includes controls to navigate around the group)

But you can display one and have the other 11 accessible via a select menu, so that if and when the user wants them, they select the audio they want and JS swaps out the audio node.

Hiding the other audios behind a select input seems like a bad experience for the user, I'm confident you'll find poor discovery of those other audios by actual users. I'd follow the lead of successful audio applications like Spotify or Soundcloud until you can do your own research, but if you insist on keeping the UI very minimal then a single link back to the "group" or playlist of audios might be worth trying.

But if you define your structured data as attributes then information about the other 11 is not available to machines that fetch the page and want to know what the page offers.

Not true, if you have a single URL for each audio node and another one for the group.

That's why JSON-LD is superior to the other methods of structured data. You can have the structured data for all 12 audios since all 12 audios are part of the page but only one has an (x)html audio node in the html as sent by the initial GET request.

Web pages aren't static, even after the client received the page the DOM can be altered without reloading the page.

Structured data separate from the content is the only logical way to account for that.

Respectfully disagree ;)

# Michael A. Peters (2 days ago)

On 07/25/2017 10:45 AM, Jonathan Zuckerman wrote:

This suggestion might have more success with the W3C? I'm not completely clear on the politics and history of the two orgs, but it seems like the W3C has supported JSON-LD in the past, so they might have some interest in expanding it.

On a personal note, I think you've got really far down the path of a hammer looking for a nail. Spend more time working with the web you've got before trying to change it.

Fuck you. Seriously. I've been working with the web since the late 90s.

I don't need condensing crap like that.

No, I don't have a hammer looking for nail.

JSON-LD is a beautiful implementation of structured data, that potentially includes the ability to only include it when the client wants it included.

I'm sorry you are too biased against it to open your mind and see it.

Learn some fucking manners.

# Qebui Nehebkau (2 days ago)

Wow, that was unnecessary. "Working with the web since the late 90s" doesn't intrinsically make you any more right or any better a web designer than some 12-year-old from Geocities. If maintaining your worldview depends on assuming that anyone who disagrees is "too biased", your worldview is wrong. And, btw, your worldview is wrong. Content that only some users want is separate content that should be in a separate resource.

# Michael A. Peters (2 days ago)

On 07/25/2017 02:29 PM, Qebui Nehebkau wrote:

Wow, that was unnecessary. "Working with the web since the late 90s" doesn't intrinsically make you any more right or any better a web designer than some 12-year-old from Geocities. If maintaining your worldview depends on assuming that anyone who disagrees is "too biased", your worldview is wrong. And, btw, your worldview is wrong. Content that only some users want is separate content that should be in a separate resource.

Nor does his assumption that I am "new" to the web somehow disqualify me from making suggestions with current use cases that could reduce the bloat of traffic.

# Qebui Nehebkau (2 days ago)

On 25 July 2017 at 17:32, Michael A. Peters <mpeters at domblogger.net> wrote:

Nor does his assumption that I am "new" to the web somehow disqualify me from making suggestions with current use cases that could reduce the bloat of traffic.

Oh, then I think you misunderstood his statement. As I read it, "spend more time working with the web you have before trying to change it" was a suggestion to look for a way to do what you want with current technology, not an argument that you don't have enough web experience. "Spend more time" on this particular project, not in general.

# Jonathan Zuckerman (2 days ago)

Michael, I was truly dismayed to see your reaction to my email. Qebui's interpretation is close to my intent, but upon re-reading it I agree that it seems condescending so, right on for calling that out. I want to point out that I am nobody at the WHATWG - I just lurk on this list and pipe up when the conversation heads towards topics I enjoy or have experience with

  • so please don't think of my personal comments as something that represents the organization.

I also have been developing since the 90s, I suspect we have a lot in common. Please email me off the main list if you're interested in continuing the discussion.

# Michael A. Peters (2 days ago)

On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:

On 25 July 2017 at 17:32, Michael A. Peters <mpeters at domblogger.net> wrote:

Nor does his assumption that I am "new" to the web somehow disqualify me from making suggestions with current use cases that could reduce the bloat of traffic.

Oh, then I think you misunderstood his statement. As I read it, "spend more time working with the web you have before trying to change it" was a suggestion to look for a way to do what you want with current technology, not an argument that you don't have enough web experience. "Spend more time" on this particular project, not in general.

I have a way to do what I want with current technology.

I can detect bots based upon user agent and only send the JSON-LD when I do so.

However there are some things that may be of use to a browser with accessibility functions, such as declarations regarding whether or not a page (or resource on a page) has flashing content or has simulated motion. So there are legitimate reasons why an end user client may want the JSON-LD data before rendering a page.

Just like the accept header for WebP, an accept header for JSON-LD could solve this problem. Bots and non-bot users agents that want it send it. Webmasters who understand people in undeveloped countries benefit from non-bloated paged can then choose to only send the JSON-LD in their pages when it is wanted.

Much better to implement this now when JSON-LD is still relatively young.

Whether JSON-LD is the best way to add structured data to a page probably depends upon a lot of different factors, that's a different discussion. But it is being used. That's the discussion, reducing the drawbacks of bloated content for clients that ignore it anyway.

# Ian Hickson (2 days ago)

On Tue, Jul 25, 2017 at 2:21 PM Michael A. Peters <mpeters at domblogger.net>

wrote:

On 07/25/2017 10:45 AM, Jonathan Zuckerman wrote:

This suggestion might have more success with the W3C? I'm not completely clear on the politics and history of the two orgs, but it seems like the W3C has supported JSON-LD in the past, so they might have some interest in expanding it.

On a personal note, I think you've got really far down the path of a hammer looking for a nail. Spend more time working with the web you've got before trying to change it.

Fuck you. Seriously. I've been working with the web since the late 90s.

I don't need condensing crap like that.

[...]

I'm sorry you are too biased against it to open your mind and see it.

Learn some fucking manners.

Disrespect of fellow members of the list is unacceptable.

Michael has been banned from the list for two weeks.

Please peruse our code of conduct if the reasoning behind this action is unclear to you: whatwg.org/code-of-conduct

Thanks.

# Jonathan Zuckerman (2 days ago)

I agree that reducing the bloat of JSON-LD is a noble goal. Sorry to belabor this point, but can you explain why JSON-LD is needed in the first place? I've tried to point out that HTML is capable of doing it without another spec, which obviates the need for content duplication and bloat that JSON-LD introduces (and the extra headers you are suggesting). To your other example, CSS media queries can be employed by authors to respect user preferences for reduced motion or other visual features. This makes a lot of sense because it colocates those rules in the place where the problematic feature would be defined in the first place. Why should a problem introduced by CSS be fixed by some other technology?

What I'm saying is that there are alternatives to JSON-LD which are superior and (this is crucial) already supported globally. I'm confident that we can expand the scenarios endlessly and still not come across one where JSON-LD accomplishes something HTML couldn't already do better. Can you explain why you are such a fan of JSON-LD? I'm open minded, I'm ready to be convinced, but I feel like I've suggested obviously superior alternatives to each of the use cases you've presented (if I missed any, please remind me and I'll be happy to circle back) I was honestly quite ambivalent about JSON-LD when this discussion started but I'm convinced now that it's a bad direction for the web.

In case you haven't seen it, schema.org suggests an approach to structured data that works with HTML instead of sidestepping it. Google provides a Structured Data Testing Tool search.google.com/structured-data/testing-tool

so you can be sure that the search engine is interpreting the cues correctly.

Ok so, I think I've made clear my opinion of JSON-LD ;) taking a big step back, no action can be taken by the WHATWG about the new header because those are defined (a quick web search reveals) by the IANA and IETF. The header you suggest can be implemented at any time by website owners, you just need to bring this up with the search engines so their bots start sending the appropriate header. If you can get search engines on board (or convince enough site owners to only return JSON-LD when the appropriate request header is present so the search engines are forced to send it) then your job will be done.

On Tue, Jul 25, 2017 at 18:41 Michael A. Peters <mpeters at domblogger.net>

wrote:

# Mark Kaplun (2 days ago)

hmmm blog.schema.org/2013/06/schemaorg-and-json-ld.html

If you use a CMS like wordpress for your content, and you are just a content person, it is a big meh to try to add manually the attributes, and it is also a meh to develop software that will need to parse the content to add it as you might break the structure required for the proper functioning of CSS and JS. You can have all kinds of "macros" for that, but the result is unreadable content on the editing side.

Whatever are the cons of disconnecting the data from the content, it is probably more likely that you will have the data, or at least it will be more complete if you can use json-ld as it is easier to manage.

On Wed, Jul 26, 2017 at 3:11 PM, Jonathan Zuckerman <j.zuckerman at gmail.com>

wrote:

# Jonathan Zuckerman (2 days ago)

After reading just a bit more - it seems like JSON-LD and schema.org have slightly different goals - schema.org suggests conventions for data cues in HTML, JSON-LD suggests it for JSON (e.g. API responses for dynamic websites) - exactly how "best practice" is this pattern of stuffing JSON-LD into the script tag of an HTML document? Most of the articles I could find on the subject come from Google, not the JSON-LD community...

# Melvin Carvalho (2 days ago)

On 26 July 2017 at 15:04, Jonathan Zuckerman <j.zuckerman at gmail.com> wrote:

After reading just a bit more - it seems like JSON-LD and schema.org have slightly different goals - schema.org suggests conventions for data cues in HTML, JSON-LD suggests it for JSON (e.g. API responses for dynamic websites) - exactly how "best practice" is this pattern of stuffing JSON-LD into the script tag of an HTML document? Most of the articles I could find on the subject come from Google, not the JSON-LD community...

JSON-LD is open ended

schema.org is a vocabulary that allows you to say different things

You could think of JSON-LD as a language syntax and schema.org as verbs, subjects and objects

# Mark Kaplun (2 days ago)

Well, in practice, since it is an SEO signal what google does in practice is more important than any theoretical discussion.

Not being in any way affiliated with google, my own impression is that google do not care which format you use as long as it can be parsed by them.

The main problem with the metadata that I see as a developer is that it bloats the HTML, while adding very little value to the human browsing the web page, this means that pages are being served slower which is probably a bigger concern on mobile and slower networks. One thing that google support with JSON-LD is asynchronous loading of it. Basically the HTML is loaded first, and at some point you can have some JS that will load the JSON by an AJAX request. google is happy to get the JSON-LD this way, to the human eye the page loads fater, the only thing not being solved is that there is still communication bloat even if now it is divided into two requests instead of one.

I assume that what Micheal was trying to say is that instead of hacks as described above, it might be a better thing to be able to specify in some way where the JSON-LD is located (link with relevant rel attribute ?).

just my 2 cents. I currently work in a team that develops a meta data plugin for wordpress that utilizes JSON-LD. I do not claim to fully understand the historical reasons why things are like they are right now.

On Wed, Jul 26, 2017 at 4:04 PM, Jonathan Zuckerman <j.zuckerman at gmail.com>

wrote:

# Melvin Carvalho (2 days ago)

On 26 July 2017 at 15:43, Mark Kaplun <mark at marksw.com> wrote:

Well, in practice, since it is an SEO signal what google does in practice is more important than any theoretical discussion.

Not being in any way affiliated with google, my own impression is that google do not care which format you use as long as it can be parsed by them.

The main problem with the metadata that I see as a developer is that it bloats the HTML, while adding very little value to the human browsing the web page, this means that pages are being served slower which is probably a bigger concern on mobile and slower networks. One thing that google support with JSON-LD is asynchronous loading of it. Basically the HTML is loaded first, and at some point you can have some JS that will load the JSON by an AJAX request. google is happy to get the JSON-LD this way, to the human eye the page loads fater, the only thing not being solved is that there is still communication bloat even if now it is divided into two requests instead of one.

While this is typically true of today's browsers, which are human oriented. I have been experimenting for some time with a next generation browser (via addon/shim) which can view both human readable data and machine readable data. Typically what you would do is take the data, and pass it over to a 'viewer' which acts as a display app. I've had very good experiences with this. My personal hope is that data browsing will become more common over time, so instead of seeing JSON as plain text, or a tree, it will come a bit more to life as browsers get more features.

# Philipp Serafin (2 days ago)

Mark Kaplun <mark at marksw.com> schrieb am Mi., 26. Juli 2017 um 15:43 Uhr:

[...] Basically the HTML is loaded first, and at some point you can have some JS that will load the JSON by an AJAX request. google is happy to get the JSON-LD this way [...]

This sounds like an interesting approach - however, that would require a (e.g. non-browser-)client to support javascript and potentially fetch and execute the complete page JS - all that just to get meta-data, would it?

That sounds like a very expensive solution for a technology that was supposed to enable bots to consume web pages without needing to cut through all the bloat.

# Mark Kaplun (2 days ago)

On Wed, Jul 26, 2017 at 5:52 PM, Philipp Serafin <phil127 at gmail.com> wrote:

Mark Kaplun <mark at marksw.com> schrieb am Mi., 26. Juli 2017 um 15:43 Uhr:

[...] Basically the HTML is loaded first, and at some point you can have some JS that will load the JSON by an AJAX request. google is happy to get the JSON-LD this way [...]

This sounds like an interesting approach - however, that would require a (e.g. non-browser-)client to support javascript and potentially fetch and execute the complete page JS - all that just to get meta-data, would it?

That sounds like a very expensive solution for a technology that was supposed to enable bots to consume web pages without needing to cut through all the bloat.

As far as I know, google now runs whatever JS there is on a page, so yes, it is an expensive technology, but since they already do it in any case I assume there is no extra expanse for them.

Obviously it is a barrier to entry for other players.

# Roger Hågensen (2 days ago)

On 2017-07-26 07:49, Ian Hickson wrote:

Disrespect of fellow members of the list is unacceptable. ... Please peruse our code of conduct if the reasoning behind this action is unclear to you: whatwg.org/code-of-conduct

Thanks.

Thank you.

# Philipp Serafin (2 days ago)

Paving the cowpaths is all well and good, but if it ends up recommending technologies which unilaterally favor some parties, that sounds like a big argument to develop a better technology.

Mark Kaplun <mark at marksw.com> schrieb am Mi., 26. Juli 2017 um 17:07 Uhr:

# Roger Hågensen (2 days ago)

On 2017-07-26 16:52, Philipp Serafin wrote:

That sounds like a very expensive solution for a technology that was supposed to enable bots to consume web pages without needing to cut through all the bloat.

Yeah. As far as I know, content is still king at Google. So extra weight will be given to whatever is shown to the visitors (seeing or non-seeing).

This article by one of the guys behind JDON-LD is also interesting. manu.sporny.org/2014/json-ld-origins-2

The semantic web was at the bottom of his list when making the specification, so JSON-LD is not really designed for semantics.

To me JSON-LD looks like a standardized way to store common data using JSON.

Myself in my apps I would not use JSON-LD as my own apps would use a internal API or I'd define a custom API using JSON.

JSON-LD would be overkill for the play history for a web player for example, as you'd have to support all of the JSON-LD specs if you want to remain compliant. No browser support JSON-LD, so you'd need a larger library to handle it. I rely on native browser functionality as possible to avoid 3rd party libraries.

Something like JSON-LD would make more sense with something like The Internet Archive and so on, as part of a official public API etc.

Want more features?

Request early access to our private beta of readable email premium.