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