Comparison to Gluon
Niklas Lindström
First off, thanks for JSON-LD, it is an impressive work!
A while ago, I designed a JSON format for RDF called Gluon [1]. Of all
the other JSON formats, I believe JSON-LD is one of the closer to the
gist of that design. I have no interest in itself to pursue Gluon if
there's more backing of another format, so I wonder how much more
evolution you believe JSON-LD will undergo before finalization?
Some principles I've had in Gluon are:
* Profile mappings should be compact, uniform and reusable. They
should enable "pure" JSON, as it looks in e.g. Linked Data API JSON
[2].
* Avoid "microsyntax", i.e. use JSON object literals for compound
datatypes (like typed literals and literals with language).
* Avoid symbols as much as possible. Right now, Gluon uses "$uri",
"$datatype" etc., but I'll likely change this to underscores (e.g.
"_uri" or "_about" (the latter as in [2])).
* Any microparsing (of CURIE:s) is done only when converting from/to
RDF triples, where such a step should be easy.
* The raw mode is somewhat unimportant in practise. I believe that a
full RDF-format in JSON isn't really what's needed. If you have an RDF
store, parsing *at least* N3 should be the way to go. This is about
making RDF look like JSON for "casual use".
* Remapping this "very simple JSON" to RDF is a good thing.
Ideal goals are also:
* Profiles should be complete enough to work as a declarative
mechanism for "RDF to Object" mappers, similar to my Oort mapper,
Sparta, RDFAlchemy and many others. I believe Gluon profiles have that
(with single/multiple, refererence (and symbol), datatype and
localization features).
* Standardization... There are a plethora of JSON formats for RDF,
with a wide array of intended targets. Somehow we must work to
consolidate this work (lest newcomers be overwhelmed by the
fragmentation and leave in despair)...
My main concerns today, which keeps me from supporting JSON-LD
wholeheartedly, are:
1. It is a bit complex. There are many variations, and it might not be
clear for a novice what the relation to RDF really is, and which use
cases the format is intended for. In comparison, Gluon has two
"modes", raw and compact, with the latter being the most interesting
one. (Since I believe that full RDF usage should be done with an RDF
API, ideally though with a sugared mapper (describer...).)
2. Lots of symbols. I dislike the need for "microsyntax" in a format
intended for simple use. The use of "<..>" for URI:s, and the language
and datatype literal notations strike me as cumbersome. Also, the "#"
and "@" feel a bit too idiomatic. I'd much prefer more structure, with
english symbols like "prefix" and "_about".
3. I do like the profile idea, which seems to be very much like in
Gluon. Though in Gluon, I use CURIE:s to declare shorthand properties
(and symbols), instead of using the prefix mechanism for both prefixes
and URI to token mappings. In Gluon profiles, the "define" stuff allow
for a lot of compactness beyond datatyping.
(I'm also confused by the JSON-LD example using "homepage":
"xsd:anyURI" -- I'd expect the resulting RDF value to become a literal
typed with xsd:anyURI -- *not* a reference.)
With that said, I applaud you for a good overall design, well
formulated principles, the writing of a complete spec, setting up a
site and list for this, etc. Gluon is just some scribbles in a wiki.
;)
I have also noticed Nathan's work on a JSON format as well [3]. It
seems to be quite close to Gluon (less microsyntax, and also using
URI:s as keys (like the "linked" object in Gluon)).
I would not mind "deprecating" Gluon in favour of this, if these
concerns were to appeal to you. (And if these things converge (and
time permitting), I'd love to adapt my python implementation, and do
at least one in java.)
Best regards,
Niklas
[1]: http://purl.org/oort/wiki/Gluon
[2]: http://code.google.com/p/linked-data-api/wiki/API_Formatting_Graphs#JSON_Formatting
[3]: http://webr3.org/apps/specs/jsn3/
Manu Sporny
> First off, thanks for JSON-LD, it is an impressive work!
Thanks Niklas... the same to you re: Gluon. I hope that we can find some
way of merging the best parts of each. :)
> A while ago, I designed a JSON format for RDF called Gluon [1]. Of all
> the other JSON formats, I believe JSON-LD is one of the closer to the
> gist of that design. I have no interest in itself to pursue Gluon if
> there's more backing of another format, so I wonder how much more
> evolution you believe JSON-LD will undergo before finalization?
We plan to feed JSON-LD into the W3C for the next RDF Working Group,
which will start early next year. We believe that many of the JSON-LD
concepts will be discussed and perhaps even standardized in the RDF
Working Group. So, JSON-LD could still evolve a bit, but the changes as
of late have been less and less drastic.
> Some principles I've had in Gluon are:
>
> * Profile mappings should be compact, uniform and reusable. They
> should enable "pure" JSON, as it looks in e.g. Linked Data API JSON
> [2].
I believe this is covered by the JSON-LD API:
http://json-ld.org/spec/ED/20101128/#the-json-ld-api
and JSON-LD Vocabulary Profiles:
http://json-ld.org/spec/ED/20101128/#vocabulary-profiles
However, I'm not sure that's true... what do you think?
> * Avoid "microsyntax", i.e. use JSON object literals for compound
> datatypes (like typed literals and literals with language).
Yeah, this is one of those trade-offs that was heavily debated in the
early XML/SVG days and now again in JSON-LD. The findings in the XML/SVG
groups was that microsyntaxes aren't always bad and the use of them
should be inspired by the problem you're trying to solve. In this
particular case, we want JSON-LD to be a simple list of key-value pairs
- easy to author by hand, if needed. If we make the values things that
look like this:
"foaf:name" : { "value" : "John Doe", "language" : "en" }
We make it more difficult to:
* Hand-author JSON-LD (which we do regularly)
* Access the data in an orthogonal way (sometimes you use .value, other
times you just do .name, etc.)
* Add complexity to the data structures, making them more deeply nested.
So, given those technical issues, what are your arguments against
micro-syntaxes in this specific use case?
> * Avoid symbols as much as possible. Right now, Gluon uses "$uri",
> "$datatype" etc., but I'll likely change this to underscores (e.g.
> "_uri" or "_about" (the latter as in [2])).
We use symbols for several reasons:
- They are simple to remember
- Most people don't use symbols to index their objects
- We try to make sure that there is some cohesion between N3, TURTLE
and JSON-LD.
If we use words, people need to remember those words. "How do I specify
a type again? Was it $datatype? Or was it $type?".
Similarly, re-using the same symbols that are used in TURTLE, like '@'
or '^^' means that it's easier for those coming from TURTLE to
understand JSON-LD. For others, it'll mean that if they ever have to
learn TURTLE, it'll be easier for them to transition.
> * Any microparsing (of CURIE:s) is done only when converting from/to
> RDF triples, where such a step should be easy.
I think JSON-LD does this.
> * The raw mode is somewhat unimportant in practise. I believe that a
> full RDF-format in JSON isn't really what's needed. If you have an RDF
> store, parsing *at least* N3 should be the way to go. This is about
> making RDF look like JSON for "casual use".
I don't quite understand this point, could you elaborate?
> * Remapping this "very simple JSON" to RDF is a good thing.
Yes, agreed.
> Ideal goals are also:
>
> * Profiles should be complete enough to work as a declarative
> mechanism for "RDF to Object" mappers, similar to my Oort mapper,
> Sparta, RDFAlchemy and many others. I believe Gluon profiles have that
> (with single/multiple, refererence (and symbol), datatype and
> localization features).
Agreed, sort-of. I don't know if it's the Profiles job to state how RDF
should be mapped to JSON. I do think that there should be /some/ mapping
mechanism. The RDFa API does this via PropertyGroups. The JSON-LD API
lets the developer specify how to map the data to a JavaScript object:
http://json-ld.org/spec/ED/20101128/#methods-1
The one thing we're missing is how to do localization - that is, specify
that a particular item should be in a certain language automatically. We
may or may not add that support... still undecided on that. JSON-LD does
support automatic typing and type coercion:
http://json-ld.org/spec/ED/20101128/#type-coercion
> * Standardization... There are a plethora of JSON formats for RDF,
> with a wide array of intended targets. Somehow we must work to
> consolidate this work (lest newcomers be overwhelmed by the
> fragmentation and leave in despair)...
Agree, wholeheartedly. :)
> My main concerns today, which keeps me from supporting JSON-LD
> wholeheartedly, are:
>
> 1. It is a bit complex. There are many variations, and it might not be
> clear for a novice what the relation to RDF really is, and which use
> cases the format is intended for. In comparison, Gluon has two
> "modes", raw and compact, with the latter being the most interesting
> one. (Since I believe that full RDF usage should be done with an RDF
> API, ideally though with a sugared mapper (describer...).)
So, I think we agree on the API portion being necessary to make it easy
to map from an RDF graph to JSON-LD and back. I don't agree that we
should just give up on making it easy to hand-author JSON-LD. In fact,
we've been hand-authoring JSON-LD, using associative arrays, in our
internal systems and it's been working out nicely.
> 2. Lots of symbols. I dislike the need for "microsyntax" in a format
> intended for simple use. The use of "<..>" for URI:s, and the language
> and datatype literal notations strike me as cumbersome.
You don't need to use microsyntax for URIs and datatypes - you can
always use type coercion.
However, also keep in mind that people use microsyntaxes heavily in
wikis, sometimes many different microsyntaxes and those people seem to
do just fine - look at Wikipedia, or (insert your favorite wiki format
here).
While these microsyntaxes may strike you as cumbersome, you just
outlined the only ones people would need to know: <>, :, @, and ^^.
I also note that you use ':' for CURIEs in Gluon. You also use '@' to
specify language in Gluon. Gluon starts keywords with $. So, aren't
these microsyntaxes too?
> Also, the "#"
> and "@" feel a bit too idiomatic. I'd much prefer more structure, with
> english symbols like "prefix" and "_about".
They may be too idiomatic - not enough people have protested yet to get
us to change it. I do think that using words, while good for the points
you illustrate, ultimately is confusing as people need to remember all
the keywords. The less keywords, the better... and if we can get most of
the heavy lifting done using symbols, all the better if the symbols have
an easy to remember mnemonic.
'#' - hashmap - maps prefixes to string values
'@' - at symbol - the subject can be found at the following URL
'a' - this is a XYZ
and so on. Most of the rest of the symbology is borrowed from N3/TURTLE.
> 3. I do like the profile idea, which seems to be very much like in
> Gluon. Though in Gluon, I use CURIE:s to declare shorthand properties
> (and symbols), instead of using the prefix mechanism for both prefixes
> and URI to token mappings. In Gluon profiles, the "define" stuff allow
> for a lot of compactness beyond datatyping.
Yes, the two approaches are similar. Perhaps this is an area that we
should explore more. We settled on using the prefix mechanism for both
prefixes and URI to token mappings largely because Mark Birbeck has made
a very convincing case for doing this over the past several years - it's
dead simple.
We kept type coercion separate via "#types" and may keep localization
separate as well.
> (I'm also confused by the JSON-LD example using "homepage":
> "xsd:anyURI" -- I'd expect the resulting RDF value to become a literal
> typed with xsd:anyURI -- *not* a reference.)
It's a special case - perhaps we need a special vocabulary term that
means "convert the value into an IRI reference". The downside of
xsd:anyURI is that you wouldn't ever be able to type coerce something
into xsd:anyURI. Perhaps it should be:
"homepage": "IRI"
What do you think?
> With that said, I applaud you for a good overall design, well
> formulated principles, the writing of a complete spec, setting up a
> site and list for this, etc. Gluon is just some scribbles in a wiki.
> ;)
Still Gluon is very interesting... will have to have more of a think
about it. I do like the thinking you've done on "define:" and you make
good points above. The decisions you've made for Gluon and the ones that
we've made for JSON-LD have trade-offs. Perhaps those trade-offs are
mitigated by other software further up the stack.
I think one key difference between Gluon and JSON-LD is that we want
JSON-LD to be easy to author in a programming environment. We directly
manipulate JSON-LD markup in C++ and will eventually do so in JavaScript
- without any helper libraries.
There is also the notion of backwards-compatibility with existing JSON -
we call it the Zero Edits goal of JSON-LD. That is, we want to bring all
of the current JSON-LD data on the Web into the RDF world, and doing so
shouldn't require people to change their current JSON objects.
> I have also noticed Nathan's work on a JSON format as well [3]. It
> seems to be quite close to Gluon (less microsyntax, and also using
> URI:s as keys (like the "linked" object in Gluon)).
Yes, Nathan and I talk quite a bit about this area - ideas
cross-pollinate (if you notice some of the section headings and syntax
between the JSN3 spec came from the earlier JSON-LD specs). The JSON-LD
spec got its idea of "[[ lists ]]" from Nathan's work. Although we've
both done a shoddy job of crediting each other in the specs :).
Nathan's also built a fantastic JavaScript library called JS3, if you
haven't seen it yet, check it out:
It contains some really great examples of how to easily work with RDF
data in JavaScript.
> I would not mind "deprecating" Gluon in favour of this, if these
> concerns were to appeal to you. (And if these things converge (and
> time permitting), I'd love to adapt my python implementation, and do
> at least one in java.)
Your concerns certainly do appeal to a subset of us. Some of these
decisions on JSON-LD came about after much hand-wringing and
implementation headaches. I think that the biggest difference between
Gluon and JSON-LD are: microsyntaxes, the zero-edits-goal and
ease-of-hand-authoring.
We should keep discussing how we can address your concerns, as I don't
think that Gluon and JSON-LD are as different as they may seem at first.
What do you think?
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Linked Data in JSON
http://digitalbazaar.com/2010/10/30/json-ld/