Re: [whatwg] header for JSON-LD ???

[Roger Hågensen]

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.
http://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.



--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] header for JSON-LD ???

[Philipp Serafin]

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  schrieb am Mi., 26. Juli 2017 um 17:07 Uhr:

>
> [...]
>
> 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.
>

Re: [whatwg] header for JSON-LD ???

[Roger Hågensen]

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

Thanks.


Thank you.



--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] header for JSON-LD ???

[Mark Kaplun]

On Wed, Jul 26, 2017 at 5:52 PM, Philipp Serafin  wrote:

> Mark Kaplun  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.

Re: [whatwg] header for JSON-LD ???

[Philipp Serafin]

Mark Kaplun  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.

Re: [whatwg] header for JSON-LD ???

[Melvin Carvalho]

On 26 July 2017 at 15:43, Mark Kaplun  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.


> 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  >
> 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...
> >
> > On Wed, Jul 26, 2017 at 8:30 AM Mark Kaplun  wrote:
> >
> >> hmmm http://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.zucker...@gmail.com> wrote:
> >>
> >>> 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
> 

Re: [whatwg] header for JSON-LD ???

[Mark Kaplun]

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 
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...
>
> On Wed, Jul 26, 2017 at 8:30 AM Mark Kaplun  wrote:
>
>> hmmm http://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.zucker...@gmail.com> wrote:
>>
>>> 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 >> >
>>
>>
>>> 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 

Re: [whatwg] header for JSON-LD ???

[Melvin Carvalho]

On 26 July 2017 at 15:04, Jonathan Zuckerman  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


>
>
> On Wed, Jul 26, 2017 at 8:30 AM Mark Kaplun  wrote:
>
> > hmmm http://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.zucker...@gmail.com
> > > wrote:
> >
> >> 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  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  >
> >> wrote:
> >>
> >> > On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
> >> > > On 25 July 2017 at 17:32, Michael A. Peters  >
> >> > 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 

Re: [whatwg] header for JSON-LD ???

[Jonathan Zuckerman]

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...

On Wed, Jul 26, 2017 at 8:30 AM Mark Kaplun  wrote:

> hmmm http://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  > wrote:
>
>> 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 
>
>
>> 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 
>> wrote:
>>
>> > On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
>> > > On 25 July 2017 at 17:32, Michael A. Peters 
>> > 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 

Re: [whatwg] header for JSON-LD ???

[Mark Kaplun]

hmmm http://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 
wrote:

> 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 
> 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 
> wrote:
>
> > On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
> > > On 25 July 2017 at 17:32, Michael A. Peters 
> > 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 

Re: [whatwg] header for JSON-LD ???

[Jonathan Zuckerman]

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 
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 
wrote:

> On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
> > On 25 July 2017 at 17:32, Michael A. Peters 
> 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.
>

Re: [whatwg] header for JSON-LD ???

[Ian Hickson]

On Tue, Jul 25, 2017 at 2:21 PM Michael A. Peters 
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: https://whatwg.org/code-of-conduct

Thanks.

-- 

-- 
Ian Hickson



Re: [whatwg] header for JSON-LD ???

[Michael A. Peters]

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

On 25 July 2017 at 17:32, Michael A. Peters  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.

Re: [whatwg] header for JSON-LD ???

[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 <
qebui.nehebkau+wha...@gmail.com> wrote:

> On 25 July 2017 at 17:32, Michael A. Peters 
> 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.
>

Re: [whatwg] header for JSON-LD ???

[Michael A. Peters]

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.

Re: [whatwg] header for JSON-LD ???

[Qebui Nehebkau]

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.

Re: [whatwg] header for JSON-LD ???

[Michael A. Peters]

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.

Re: [whatwg] header for JSON-LD ???

[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.

On Mon, Jul 24, 2017 at 7:21 PM Michael A. Peters 
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 ;)

>
> On 07/24/2017 08:00 AM, Jonathan Zuckerman wrote:
> > 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 <
> mpet...@domblogger.net>
> > wrote:
> >
> >> 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, 

Re: [whatwg] header for JSON-LD ???

[Michael A. Peters]

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

On 24 July 2017 at 19:21, Michael A. Peters  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.

Re: [whatwg] header for JSON-LD ???

[Qebui Nehebkau]

On 24 July 2017 at 19:21, Michael A. Peters  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.

Re: [whatwg] header for JSON-LD ???

[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.


On 07/24/2017 08:00 AM, Jonathan Zuckerman wrote:

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 
wrote:


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

Re: [whatwg] header for JSON-LD ???

[Melvin Carvalho]

On 21 July 2017 at 23:21, Michael A. Peters  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.

Re: [whatwg] header for JSON-LD ???

[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" <
j.zucker...@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?

On Mon, Jul 24, 2017 at 11:30 AM Philipp Serafin  wrote:

> 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" <
> j.zucker...@gmail.com>:
>
> 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 
> wrote:
>
> > 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 

Re: [whatwg] header for JSON-LD ???

[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?

On Sun, Jul 23, 2017 at 8:13 PM Michael A. Peters 
wrote:

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

Re: [whatwg] header for JSON-LD ???

[Michael A. Peters]

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

Re: [whatwg] header for JSON-LD ???

[Michael A. Peters]

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

On 23 July 2017 at 14:12, Michael A. Peters  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.

Re: [whatwg] header for JSON-LD ???

[Qebui Nehebkau]

On 23 July 2017 at 14:12, Michael A. Peters  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.

Re: [whatwg] header for JSON-LD ???

[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.



On 07/22/2017 10:12 PM, Jeffrey Yasskin wrote:

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

Jeffrey

On Fri, Jul 21, 2017 at 2:21 PM, Michael A. Peters 
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?

Re: [whatwg] header for JSON-LD ???

[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

On 23 July 2017 at 06:12, Jeffrey Yasskin  wrote:

> 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-comme...@w3.org referenced from https://www.w3.org/TR/json-ld/?
> Or an issue against https://github.com/json-ld/json-ld.org?
>
> Jeffrey
>
> On Fri, Jul 21, 2017 at 2:21 PM, Michael A. Peters  >
> 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?
> >
>

Re: [whatwg] header for JSON-LD ???

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

Jeffrey

On Fri, Jul 21, 2017 at 2:21 PM, Michael A. Peters 
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?
>

[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?