
Publishing JSON-LD for Developers - anthonyhughes
https://datalanguage.com/news/publishing-json-ld-for-developers
======
TheAceOfHearts
Try leading with an explanation of why developers should care about JSON-LD.
Its value is not obvious to me.

According to the Wikipedia article [0] this is used by Google Knowledge Graph,
but there's no other examples. Are there open source RDF processors? What are
they used for?

Previously I've used json-schema for documenting, validating, and testing a
REST API. The tooling wasn't very good, but it worked alright. As I understand
it, JSON-LD wouldn't help at all with this.

The fact that JSON-LD is a W3C standard while json-schema isn't doesn't
constitute an argument against it. Standards regularly show up and die without
ever gaining adoption. Maybe instead of a vacuous remark on JSON-LD offering
more than json-schema with respect to linked data you could actually muster
some concrete example which highlight these alleged benefits?

I'm not an expert on this subject, but isn't it worrying that third-party
links can change or go down without notice? Ideally if I'm hosting a context
I'll want to replicate my whole dependency graph and provide a mirror in order
to reduce dependencies on external systems. However, just because I want to
host my own mirror doesn't mean I want it to be treated as a different kind of
entity. It seems like something such as content-addressable storage [1] could
be relevant here.

[0] [https://en.wikipedia.org/wiki/JSON-
LD](https://en.wikipedia.org/wiki/JSON-LD)

[1] [https://en.wikipedia.org/wiki/Content-
addressable_storage](https://en.wikipedia.org/wiki/Content-
addressable_storage)

~~~
jshen
The main benefit in my eyes is data integration. If you have multiple systems
with data, and you want to merge the data together into a unified whole for
some reason then RDF/JSON-LD make it easy and mostly automatic.

For example: 1\. How do you distinguish IDs from one system with those of
another? RDF solves this. 2\. How do you distinguish property names across
systems? RDF solves this. 3\. What if a entity originates in system A which
you don’t control but you want to add a property to it in your system? RDF
solves this.

JSON-LD is simply one way to serialize RDF data that makes look like what you
would typically expect from an API that returns JSON. I.e. it’s developer
friendly

In addition to the above, RDF is also an extraordinarily flexible/schemaless
data model if you store your data as triples rather than as documents. There
is definitely a steep learning curve to linked data, and I’ve had a hard time
explaining it’s value over the years, but I think it’s worth the time to
learn, understand, and leverage.

All of these benefits exist before you get into things like ontologies, which
allows you to add additional value on top of what I outlined above.

~~~
vfaronov
Outstanding explanation. I would like to emphasize one point:

> _If you have multiple systems with data, and you want to merge the data
> together into a unified whole for some reason_

This isn’t just about “big data” or “data warehousing” or such OLAPy concerns.
It’s really about the bread and butter of modern information systems.

“Get some ID from service A, use it to query service B.” Does that sound
familiar? That’s data integration for you. That’s what RDF / Linked Data is
about.

------
titanix2
I'm working on language ressources and graphs and in my opinion, RDF is so
flawed you shouldn't even bother with it. I will address the topic during a
conference in June (email me -- info in my profile -- for follow up or to get
my articles if you're interested by the topic). JSON-LD is trying to make RDF
sexier (more exactly said, RDF try to pimp itself by using JSON-LD) but as it
is just RDF with a new serialization syntax, it share every of its issues.

Main issues are:

\- a literal node (strings which carry the useful information for an human)
cannot be the source of an edge, so you end up creating "resources" nodes and
pushing content as leaf of the graph. Access to its is thus done with a lot of
indirections.

\- no annotations, which mean you cannot represent simple graph construct such
as a weighted edge.

\- blank nodes, needed to join more than two piece of data which, are
anonymous so they are difficult to reuse. That's sad because a graph is
supposed to make data link each other. Coupled with issue 1, it mean most
linguistic resources graphs are actually closer to trees than real graphs.

\- reliance on the web infrastructure (IRI, DNS, web servers, ...) which is a
big dependency with a lot of gotchas and not fitted for every uses cases (self
contained data for example)

\- performances is abyssal. I tried one of the dictionary build on RDF, and
some query took up to 40 seconds (!) to return no result. Even bloated web
dictionaries perform under 2 seconds.

Also, the second sentence of the article is totally false. I read the history
of JSON-LD by one of its main author [1], and it does not originated in the
RDF community. It originated elsewhere, and then there was RDF people included
in the loop.

[1] [http://manu.sporny.org/2014/json-ld-
origins-2/](http://manu.sporny.org/2014/json-ld-origins-2/)

~~~
Boulth
Is there a reasonable alternative? I've worked with RDF and LD and can agree
with most of your points but would like to see if there is something better on
the horizon.

~~~
titanix2
Currently no. I am concerned with making dictionaries better (especially
mobile applications), so I don't have a general purpose solution but I propose
something for that use case. I basically started from scratch and came up with
a very simple type system which aggregates a few values (name, id, type, ...).
This type system is not hierarchical so no inheritance; you could implement it
with a few classes in a OO language.

Also, nodes can host complex structure but do not expose it to the graph
(edges are made only between nodes) and edge can be of n-arity. The system is
regular enough to implement simple and complex lexicographic constructs easily
as well as to use the graph in an actual application.

Issue with RDF et al if that before you start even working on your real data,
you have to come up with an ontology, that is to describe the world in
categories, which is not easy. Another problem is that a lot of projects want
to define standards that works with everything. That's not realistic. So I
took an approach where you can learn from your domain by working directly on
your data, make something useful with it, and then expand it you need it.
KISS.

~~~
rjsw
There are plenty of ontologies already defined that someone could use. I'm
currently involved in work to map STEP [1] onto RDF/OWL/SKOS and it seems to
be working out well.

I know that some of my collegues are using JSON-LD as the interchange format
for this kind of thing.

[1]
[https://en.wikipedia.org/wiki/ISO_10303](https://en.wikipedia.org/wiki/ISO_10303)

~~~
titanix2
It totally depends on what you are doing. You need to take in account if using
an ontology will solve any problem at hand. Also you may have an ontological
system not build in RDF. At least in what I'm doing, RDF is creating more
problems than it solves. Finally there is all the political layer that may go
against publishing your data in an open and (web) accessible format and then
you need another solution anyway.

~~~
lolive
To counter the argument of opening data to the outside world, LinkedOpenData
has been studied _inside_ companies. I.e opening only inside the walled
garden. And guess what? It failed. Simply because companies are not organized
so data can "travel" flawlessly. Companies are organized as silos. With
boundaries & (implicit) contracts between people, teams, hierarchies. Of
course, everyone knows the information is somewhere here or there, but
eventually it is a real hard job to get it for real.

------
yoklov
For an argument against using JSON-LD, see [https://hsivonen.fi/no-json-
ns/](https://hsivonen.fi/no-json-ns/)

~~~
vfaronov
This article does not have a valid argument against _using_ JSON-LD.

It may be read as an argument against making namespaces a ubiquitous part of
JSON, in the same way as they are ubiquitous in XML (even though not part of
the base XML spec). It’s a valid argument against getting to the point where
namespaces pop up in every JSON tutorial, and every JSON serializer takes a
namespace map, and every user of JSON has to deal with them.

But JSON-LD (as RDF) uses namespaces to solve a particular problem (merging
data from disparate sources). Solutions involve costs, that’s normal. You
might weigh this cost against the expected payoff and decide it’s not worth it
for you — but the article doesn’t do that.

------
neurotrace
As someone completely out of the loop on this one but deeply entrenched in
modern web development, I have some questions.

1\. What benefit does this format give that other schema systems do not?

2\. The `@context` just seems like a way of defining variables. As best as I
can tell, the use case leads to one only using each of these "variables" once.
What's the benefit?

3\. What benefit does RDF in any format provide to the average web developer?

Sorry if these questions are asinine. It's just that the article bemoans the
fact that this hasn't hit mainstream web development yet, to my mind, does
nothing to encourage its use.

~~~
titanix2
> 3\. What benefit does RDF in any format provide to the average web
> developer?

Probably (almost) none, otherwise in its 20 years of existence it would have
been used somewhere. Heck, even Semantic Web scholars actually don't use it
for their own personal websites...

~~~
jshen
It provides a lot of benefits, see my other comment on this thread for a few
specific benefits.

~~~
titanix2
I read your post and you rose valid points.

I think one problem though is that RDF is a solution searching for a problem
to solve. It's clear it was designed from some abstract space instead to be a
solution evolving from real use cases. And that's why most people have a hard
time understand it, and even more putting it in practice.

For example, even basic RDF concepts such as a resource are hard to grasp. You
have an IRI, great, but should it be dereferenceable? If yes, what it expected
to be returned: a document in various formats or more RDF triples? If not (URN
case), what to do with it? All these problematics are not addressed in the
spec itself but must be understood before even starting to implement a hello
world.

There is interesting projects such as DBpedia. Another problem of RDF is
social and pertains to its advocates: trying to impose the technology
everywhere without taking in account the audience needs nor the limitations of
the technology itself is not going to work great. See the suggestions made
during this workshop to improve the technology:
[https://www.w3.org/2009/12/rdf-ws/](https://www.w3.org/2009/12/rdf-ws/) In 9
years (half of its live), nothing was addressed.

~~~
jshen
I think it solves a real problem. I work at a large company, with many data
silos. I’ve had to hire armies of interns to match in merge data over the
years because it wasn’t possible to automate the merging of data from
different databases.

I agree with your other points though, people have a hard time understanding
it, and the community hasn’t really shown the value. My hobby project is an
effort to show the value, but it’s not ready to share yet.

And yes, there’s a lot of confusion things (URI vs URL, dereference or not)
that the community hasn’t done a good job articulating a happy path. There’s
another you didn’t mention, there’s an impedance mismatch between triples and
resources. One is property oriented, and the other entity oriented, and they
dont’ always play nice together.

~~~
titanix2
Of course I don't know every issues but sure I forgot some. Difficulty of
making reification for example. Anyway, I will be glad to hear about your
project when it's published.

------
otakucode
Blah. Some people just won't be happy until JSON turns into the debacle XML
turned into. It's a special kind of brain problem to see a simple
straightforward thing and to only consider how one might bolt on arbitrary
complexity.

~~~
rspeer
You must have misunderstood something. JSON is a data format. JSON-LD is a use
of that data format.

Your complaint is as if you looked at the Sublime Text configuration file,
which is in JSON, and said "I liked JSON better when you didn't have to
configure anything".

JSON-LD isn't designed to replace JSON, it's designed to replace all the
awkward formats for RDF.

------
rspeer
I recently wrote about the use of JSON-LD in ConceptNet:
[http://blog.conceptnet.io/posts/2018/conceptnet-and-json-
ld/](http://blog.conceptnet.io/posts/2018/conceptnet-and-json-ld/)

Seeing some knee-jerk negativity in other replies, I should emphasize: nobody
is under any obligation to use JSON-LD just because you use JSON! It's not an
upgrade to JSON, it's an upgrade to RDF.

------
harlanji
Please forgive me if off topic. I feel EDN deserves some love. Unsure if it’s
lack of awareness or what. Defrecord with type hints is enough for most
projects, esp. the data models. The collection types are complete and there
are also comments, namespaces, and tags. The grammar is also short, simple and
easy.

Spec: [https://github.com/edn-
format/edn/blob/master/README.md](https://github.com/edn-
format/edn/blob/master/README.md)

Grammar:
[https://github.com/antlr/grammars-v4/blob/master/clojure/Clo...](https://github.com/antlr/grammars-v4/blob/master/clojure/Clojure.g4)
(EDN is a subset of Clojure).

Sorry if this is too fanboy, I just need to assume people aren’t aware when I
see this big pile of mud that is JSON.

~~~
igravious
No worries, it is _slightly_ off-topic though :) JSON-LD is a JSON format for
the serialization of linked data, not a general data interchange format like
JSON itself. Presumably an EDN fanboy could come up with EDN-LD without too
much trouble if they so desired. I linked this elsewhere but here are nine
other RDF serialization formats that you could model EDN-LD on:
[https://help.poolparty.biz/doc/developer-guide/general-
infor...](https://help.poolparty.biz/doc/developer-guide/general-information-
on-the-poolparty-api/rdf-serialization-formats) if it ever comes into being.

------
talltimtom
Only slightly related bit does anyone have a good current take on how to get
going on using RDF for something of value? I recently got interested through a
colleague showing off his pet rdf setup, but the more I read the more I am
just confused with the platora of dead/abandoned and renamed projects,
different standards and tons of different shorter versions like this one. It
really feels like everything on the topic is written both by and for people
who have been active in the space continually since 2005, so for someone new
it’s difficult to see where to start and what to avoid.

~~~
jerf
RDF is a zombie format. It isn't entirely "dead" but after some wildly
ambitious promises, it hasn't lived up to any of them, and it seems only a few
"true believers" are still working with it. This being a world of seven
billion people, a few "true believers" can still be a few thousand people, but
it's just not a technology I can say is vibrant, alive, or worth spending much
time with. The core problem is that it solves the easy problems, and not even
terribly well (I more-or-less endorse titanix2's comment elsewhere in the
thread), while leaving the hard problems mostly untouched. The excitement it
generated 10-15 years ago mostly comes from confusing solving the easy problem
for the hard problem. Everything that I've personally ever seen used RDF has
ripped it back out again at some point. Whether that's the fate in store for
the current users named in the article I can't say, but it certainly wouldn't
be a bad guess.

If the space intrigues you, I would suggest starting with a graph database
instead.

~~~
lolive
All the questions that the Semantic Web asked itself are reemerging with
GraphQL. (exposing the DB schema, querying over the web, returning results
based on a structure). The JS script kiddies are just scratching the surface
today, but they will eventually have exactly the same questions. (data
delivery, data reuse, data semantics, data exposure). They still worship plain
JSON. But they will (have to) evolve. The Semantic Web has solved all those
questions already, but in the most obscure manner.

PS: and yes, a graph database is a good start to open your mind.

------
dogweather
I've been developing a strongly-typed Ruby library for generating JSON-LD that
might be interesting or useful: [https://github.com/public-law/schema-dot-
org](https://github.com/public-law/schema-dot-org)

~~~
igravious
Awesome, I love messing with Ruby and semantic web stuff. Thanks for posting
this. Could you explain more? How do you implement the strongly-typed feature?
How does it interoperate with the Ruby-RDF library? [https://github.com/ruby-
rdf](https://github.com/ruby-rdf)

~~~
dogweather
Here's a quick example. Put this in a Rails template:

    
    
      <%= WebSite.new(
            name: 'Texas Public Law',
            url:  'https://texas.public.law',
          )%>
    

...and you'll see this in the HTML:

    
    
      <script type="application/ld+json">
      {
        "@context": "http://schema.org",
        "@type": "WebSite",
        "name": "Texas Public Law",
        "url": "https://texas.public.law"
      }
      </script>
    

This DRY's up my code - I just encode the right way of forming JSON-LD and the
correct objects and attributes in one place, the library. (That JSON-LD is
from my live site, [https://texas.public.law](https://texas.public.law))

Details:

First I created a small library which wraps Rails ActiveModel Validations so
they can be used in any Ruby object. And I supply a new validator,
TypeValidator.

[https://github.com/public-law/validated_object](https://github.com/public-
law/validated_object)

With this building block, I can create classes for each Schema type I care
about. And they strictly enforce their attributes:

    
    
      class Organization < SchemaType
        attr_accessor founding_date
        validates founding_date, type: Date
      end
    

That's a little redundant, but to a Rails developer, it's immediately clear
what's going on. The full Organization code: [https://github.com/public-
law/schema-dot-org/blob/master/lib...](https://github.com/public-law/schema-
dot-org/blob/master/lib/schema_dot_org/organization.rb)

I'm not using Ruby-RDF at all. I looked into the current Ruby meta-data and
strong typing work, and found it all too complex for my simpler use case:

I'm creating websites, and I want to embed correct JSON-LD-formatted
schema.org in a rock-solid way: (1) Correct syntax, and (2) correct semantics.
I've got the information as Rails models and objects, and I need to convert
this to HTML/JSON-LD.

So all of these objects, like Organization above, recursively creates proper
markup in response to #to_s:

    
    
      <%= @an_organization %>
    

...instantiated from that class above, will result in this in the generated
HTML page:

    
    
      <script type="application/ld+json">
      {
        "@context": "http://schema.org",
        "@type": "Organization",
    

etc.

[https://github.com/public-law/schema-dot-
org#usage](https://github.com/public-law/schema-dot-org#usage)

~~~
igravious
Thanks for the in-depth explanation. Sounds really great. I'll add it to my
Ruby RDF toolkit.

What do you think of Spira [https://github.com/ruby-
rdf/spira](https://github.com/ruby-rdf/spira) , does it complement what you
are doing in any way?

~~~
dogweather
That's pretty cool! But yeah, I don't have any RDF data sources. I parse lots
of plain text and PDFs, and import some databases directly.

And for generating the website metadata, that info is coming from the Rails
models.

------
athenot
I guess I don't understand the purpose. If a high degree of formalization,
typing and namespacing is required, why not use full-blown XML with namespaces
and schemas?

~~~
lolive
Everyone is slowly reinventing SOAP :) (Note that RDF can modelize graphs
natively, has native support of types, IDs and labels, and has a javascript
parsing library, a bit more powerful than JSON.parse()).

------
goofballlogic
Awesome stuff. I'm working with JSON-LD in both C# and JavaScript and loving
the freedom that the linked data concepts (constraints) bring to developing
APIs.

