[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.zuckerman at gmail.com>:

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

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

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

On Mon, Jul 24, 2017 at 11:30 AM Philipp Serafin <phil127 at gmail.com> 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.zuckerman at 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 <mpeters at 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, 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 ;)
> >
>
>