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

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 <mpeters@domblogger.net>
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 <
> 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 Tuesday, 25 July 2017 17:45:44 UTC