[whatwg] header for JSON-LD ???
melvincarvalho at gmail.com
Wed Jul 26 06:42:56 PDT 2017
On 26 July 2017 at 15:04, Jonathan Zuckerman <j.zuckerman at gmail.com> 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
> 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 <mark at marksw.com> 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,
> > it is also a meh to develop software that will need to parse the content
> > add it as you might break the structure required for the proper
> > of CSS and JS. You can have all kinds of "macros" for that, but the
> > 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.zuckerman at 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
> >> 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
> >> 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.
> >> you explain why you are such a fan of JSON-LD? I'm open minded, I'm
> >> 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 <https://search.google.com/
> >> 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
> >> 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
> >> 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 <mpeters at domblogger.net
> >> wrote:
> >> > On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
> >> > > On 25 July 2017 at 17:32, Michael A. Peters <mpeters at domblogger.net
> >> > 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
> >> > bloat
> >> > >> of traffic.
> >> > >>
> >> > >
> >> > > Oh, then I think you misunderstood his statement. As I read it,
> >> > 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
> >> > > 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
> >> > the JSON-LD data before rendering a page.
> >> >
> >> > Just like the accept header for WebP, an accept header for JSON-LD
> >> > solve this problem. Bots and non-bot users agents that want it send
> >> > 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.
> >> >
More information about the whatwg