Re: JSON-LD serialization and linked data support

On Thu, Aug 13, 2015 at 7:42 PM, Frederick Hirsch <> wrote:

> Tim's questions seem a good place to continue the discussion, can somebody
> concerned with the use of JSON-LD answer these questions?

Agreed. I'd like to narrow in on "troublesome" use cases (multi-bodies,
etc) where the current JSON-LD serialization seems cumbersome.

It'd also be super to see "usage code" written against some examples. Ssee
my other email for that ask:

The "roles" array proposed by Tim (+1'd by Rob & Paulo) is not untenable,
but it does pose a higher bar to jump for "stuff that should be simple"
like "give me all the comments" or "give me all the edits."

Code wins. As they say. :)

> I would hate to see the WG spin into a long discussion and JSON-OA work
> effort only to discover that we are close to what James was suggesting,
> which is to scope  our usage of JSON-LD to what it is practical for our use
> (which I thought we had done)

+1 to this concern. I'm not apposed to us crafting alternate formats per
se, but at the end of the day...those already exist (see...the Web). What's
needed is the interoperable layer in which "all" of these "snowflake" JSON
formats can be encoded into something that's *meaningful* ("Things vs.
Strings" etc).

In the end, these "internal representation formats" either exist or will be
made by developers. It'd happen even if we crafted a JSON-OA format.

JSON-LD at least gives us extension points, lets folks cram in whatever
they like (which JSON-LD parsers at the very least can ignore), and mostly
ignore the semantic sausage making going on behind the scenes.

And yeah, Google's pushing JSON-LD pretty hard...and not just on the Web:

Here's a flight confirmation:

JSON-LD is the default.

> To be honest, I'm not sure why @ signs are frightening, aren't developers
> used to various syntax items in languages etc

Yeah. They're not scary. They're namespace'd. If I don't know what they
are, I'll just make sure I copy and paste them correctly. ;)

It's not dissimilar to CouchDB (and others) using underscore prefixed keys
for it's "namespace" such as `_id`, `_rev`, etc. You know those have
meaning to the system you're talking to--and to only use them
appropriately. If you're concerned, you read the docs. :)

For the most part, for us, it'll be a single `@context` at the top.

> and won't this all be hidden from end-users (and even most developers with
> libraries)?

Mostly likely.

I'd like to see us circle back to the multiple bodies issue and explore
(more broadly) what the options are--including things like putting doing
that at all as an "extra geeky" appendix. ;) If it comes to that. :)

Tim's done a fabulous job of collecting the options currently on the table:

I'd encourage anyone with additional options, variations, or even "found
JSON" (where something like this is already being done), to *please* add
those options to that wiki page, so we can zero in on a solid, singular
issue to tackle--which we can all come at from our personal vantage points
(as I hope we shall!).

Thanks to everyone for being here! Please hang tight. :) We'll get through
this for sure. :)

Onward, annotators!
Developer Advocate

> regards, Frederick
> Frederick Hirsch
> Co-Chair, W3C Web Annotation WG
> @fjhirsch
> > On Aug 13, 2015, at 2:09 PM, Timothy Cole <> wrote:
> >
> > Setting aside for a moment how best to express the individual roles of
> bodies and targets in a multi-Body/Target Annotation, what are the
> shortcomings of how we serialize the rest of our data model in JSON-LD?
> >
> > ·         We have improved our @context document such that we know we
> can get rid of the '@' symbol on keys almost entirely if we want.
> > ·         We have unresolved questions (raised I think by Ivan?) about
> when type is MUST, SHOULD, and MAY appear.  Can we discuss this issue? If
> we pare down how often type is required, are we okay? Alternatively, given
> how frequently it appears, would people be more comfortable with a
> different key than 'type'? (I have no idea what might work better, but
> thought I should ask.)
> > ·         Is there significant discomfort with having to do "body" : {
> "id" : "" } rather than just "body" : "
>" ?  If so, we could perhaps revisit the tradeoff
> of adding hasTextBody instead of relying solely on hasBody.
> >
> > What else about JSON-LD examples in the current Data Model are
> developers on the list finding unnatural? Is there anything in
> serializations of our current data model other than @context that requires
> JSON-LD tools?
> >
> > If JSON-LD serialization of the rest of the data model is generally in
> good shape now that we know more about how to use @context, then I would
> suggest we can find an approach to the body/target role issue that does not
> require a whole new JSON serialization.  (Attractive as it is from a
> RDF-based data modeling perspective, I for one am willing to accept that
> the Role Assignment approach is probably not it.)
> >
> > But maybe the JSON-LD serialization of our current Data Model has more
> problems than have been surfaced on the list to date?
> >
> > -Tim Cole
> >
> >
> > From: Robert Sanderson []
> > Sent: Thursday, August 13, 2015 12:22 PM
> > To: Ivan Herman <>
> > Cc: Frederick Hirsch <>; W3C Public Annotation List <
>>; Tim Cole <>
> > Subject: Re: JSON-LD serialization and linked data support
> >
> >
> >
> > On Thu, Aug 13, 2015 at 9:08 AM, Ivan Herman <> wrote:
> >>
> >> > Here comes Paolo's proposal (at least the way I understand it): let
> us *replace* the JSON-LD serialization with a dedicated JSON serialization
> of our model. Ie, we drop the -LD *from the syntax* (but that does not mean
> dropping Linked Data) and we may replace it with -OA to yield something
> like JSON-OA.
> >> >
> >> > There is no real interoperability issue: we drop JSON-LD, and we
> require JSON-OA to be the interchange format; for Linked Data aware systems
> there is a processor that maps this the internal representation of RDF,
> whereas non-Linked Data aware systems can use that particular JSON dialect
> only.
> >
> >
> > I'm sorry Ivan, maybe I'm completely misunderstanding you, but I can't
> reconcile "we require JSON-OA [which is not an RDF serialization] to be the
> interchange format" with "Annotation systems are able to export their data
> into RDF at their heart's content."
> >
> > So our special syntax would be required, and all other syntaxes
> optional? And you think that anyone would implement these optional, by
> definition more complex, syntaxes, that are not required and not used to
> transfer information between annotation clients and servers?
> >
> > Rob
> >
> >> > In fact, this is not so far off from what Rob proposed in [1]:
> >> >
> >> > I think it's the complete opposite, actually. You are proposing to
> have an abstract model with no practical interoperability with linked data
> systems,
> >>
> >> No I am not.
> >>
> >> > the core of which is a new JSON format,
> >>
> >> No I am not. The core is the model, with a specific serialization
> thereof.
> >>
> >> > that any linked data system needs to revert back to something it can
> deal with via special code.
> >>
> >> No I am not. Annotation systems are able to export their data into RDF
> at their heart's content.
> >
> >
> >
> >
> > --
> > Rob Sanderson
> > Information Standards Advocate
> > Digital Library Systems and Services
> > Stanford, CA 94305

Received on Friday, 14 August 2015 01:43:11 UTC