[whatwg] header for JSON-LD ???

[Michael A. Peters]

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?

[Jeffrey Yasskin]

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-***@w3.org referenced from https://www.w3.org/TR/json-ld/?
Or an issue against https://github.com/json-ld/json-ld.org?

Jeffrey

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?

[Dan Brickley]

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

Post by Jeffrey Yasskin
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
Or an issue against https://github.com/json-ld/json-ld.org?
Jeffrey

Post by Michael A. Peters
I am (finally) starting to implement JSON-LD on a site, it generates a

lot

Post by Michael A. Peters
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

Post by Michael A. Peters
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

Post by Michael A. Peters
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?

[Michael A. Peters]

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.

Post by Jeffrey Yasskin
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
Or an issue against https://github.com/json-ld/json-ld.org?
Jeffrey

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?

[Michael A. Peters]

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]

Post by Michael A. Peters

*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]

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?

Post by Michael A. Peters

Post by Michael A. Peters

*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

Post by Michael A. Peters

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 ;)

[Philipp Serafin]

...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" <
***@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?

Because it's annoying for human users if there is too much information
cluttering up the page that is nor relevant in the current context. E.g.
for the "audio artist" case, would you really want that the avatar,
complete track list, signature, etc of an artist is always shown when an
artist is mentioned? (Assuming your goal is *also* to keep the page
machine-readable)
Also, the argument mixes user experience and technical implementation.
Today's reality is already that a lot of pages that show information about
an entity don't actually contain that information in the HTML - its
post-fetched via Ajax. In the same way, you might have good technical
reasons not to include data in the HTML even when you *want* to display it
to the user.
Am 24.07.2017 5:01 nachm. schrieb "Jonathan Zuckerman" <
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.
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?

Post by Michael A. Peters

Post by Michael A. Peters

*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

Post by Michael A. Peters

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

Post by Michael A. Peters

Post by Michael A. Peters
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 ;)

[Michael A. Peters]

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.

Post by Jonathan Zuckerman
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.
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?

Post by Michael A. Peters

Post by Michael A. Peters

*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

Post by Michael A. Peters

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 ;)

[Michael A. Peters]

Post by Michael A. Peters
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]

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.

Post by Michael A. Peters
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.

Post by Michael A. Peters
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)

Post by Michael A. Peters
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.

Post by Michael A. Peters
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.

Post by Michael A. Peters
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 ;)

Post by Michael A. Peters

Post by Jonathan Zuckerman
I think one of the best aspects of the web platform is that there can be

a

Post by Jonathan Zuckerman
single node in the network that is accessible to *all*. The linked data
approach hides the information from humans. The structured data

alternative

Post by Jonathan Zuckerman
you suggest (div display none) still hides the information from humans.
simply *display the div*. What's your objection to displaying this
information to humans? How can you justify displaying different content

to

Post by Jonathan Zuckerman
different classes of user?
On Sun, Jul 23, 2017 at 8:13 PM Michael A. Peters <

Post by Michael A. Peters

Post by Michael A. Peters

*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

Post by Michael A. Peters

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

Post by Jonathan Zuckerman

Post by Michael A. Peters

Post by Michael A. Peters
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 ;)

[Michael A. Peters]

Post by Jonathan Zuckerman
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.

[Michael A. Peters]

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.

[Jonathan Zuckerman]

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.

On Tue, Jul 25, 2017 at 5:43 PM Qebui Nehebkau <

Post by Michael A. Peters
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

Post by Michael A. Peters
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.

[Michael A. Peters]

Post by Michael A. Peters
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]

Post by Jonathan Zuckerman

Post by Jonathan Zuckerman
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

Post by Jonathan Zuckerman
expanding it.
On a personal note, I think you've got really far down the path of a

hammer

Post by Jonathan Zuckerman
looking for a nail. Spend more time working with the web you've got

before

Post by Jonathan Zuckerman
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: https://whatwg.org/code-of-conduct

Thanks.

[Melvin Carvalho]

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.