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

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

Received on Monday, 24 July 2017 15:01:37 UTC