Fwd: JSON Serialization?

See below for a response that I accidentally sent only to Ivan.

---------- Forwarded message ---------
From: Randall Leeds <randall@bleeds.info>
Date: Wed, Jun 17, 2015 at 4:04 PM
Subject: Re: JSON Serialization?
To: Ivan Herman <ivan@w3.org>


On Wed, Jun 17, 2015 at 12:04 PM Ivan Herman <ivan@w3.org> wrote:

>
> > On 17 Jun 2015, at 10:01 , Doug Schepers <schepers@w3.org> wrote:
> >
>
> A sticking point came up around JSON-LD; I explained to them (and I hope
> I'm correct) that the data model is very lightweight, and that JSON-LD is
> not a big burden on top of JSON, because you don't need to include the
> context inline, so it's just a matter of using the same attribute names and
> structures.
>
> That is correct. If a client really wants, it has the possibility to a
> reference to @context in the HTTP return header. Pretty much invisible for
> anyone who does not need it.
>
> >
> > Even with the relatively small additional overhead, they were skeptical
> there is any benefit to JSON-LD over plain JSON; with a simple, small,
> well-defined vocabulary, they didn't see why it shouldn't simply be
> stand-alone. I wasn't great at selling the notion of "reasoning", since
> they aren't using the Linked Data/SemWeb backend toolchains that would
> enable that; maybe somebody else could explain it more compellingly?
>
> My 2 cents:
>
> In my experience, reasoning as an argument does not really fly. In fact,
> only a few RDF systems do any kind of reasoning in the first place, and it
> does not scale over a certain size anyway (although those sizes are
> irrelevant for annotations).
>
> What JSON-LD buys us (at least in my view) is its strong connection to
> Linked Data. Ie, the annotation data can be combined, if necessary, with
> data like the ones represented by dbpedia (ie, the whole of Wikipedia:-)
> or, these days, with WikiData which is gradually becoming the underpinning
> of Wikipedia. DBpedia, though not prominent, is not the only example of
> course, there are tons of others. To take another example, it can use the
> same terms as the ones used in web sites for schema.org: schema.org is,
> in reality, RDF, encoded in either microdata or RDFa Lite.
>
> Ie: if the annotation data is used in strict isolation from the rest of
> the world, then JSON-LD does not buy anything. But if a system wants to
> bind this data to the outside world, it is a different ballgame. (Ie, the
> important bit is 'LD', not RDF)
>

Agree with all of this. Thanks, Ivan.

I still think the value proposition to producers isn't particularly strong,
though. Intermediate consumers that want to link together data from
disparate sources derive value, but the original producers it's less clear.


>
> >
> > They also didn't react especially well to some of the attribute names,
> like annotatedBy, annotatedAt, serializedBy, serializedAt, which didn't
> seem intuitive or descriptive, or to the value prefixes (like "oa:"). I
> couldn't really explain why some attributes start with @, and some not.
> (Though on further reading, maybe the @ represents a JSON-LD keyword [1]?)
>
> Finding the good attribute names that would satisfy everybody needs a
> white table and lots of drinks (if you are in Amsterdam, you may want
> something else, too). Seriously: can anyone imagine any attribute name that
> would be agreeable to everybody? I doubt. (Sorry to be sarcastic.)
>
>
I disagree. I think simple attribute names are really easy to agree on.
Most people, when really challenged on it, don't want to bikeshed
everything forever, in my opinion.

However, I've never seen JSON in the wild that is anything like what we
have in our context document.

As a developer, I would never choose "hasTarget" over "target". The "has"
is implied by the nesting. When working in JSON we don't see independent
triples, we see framed wholes. The domain model and the framing obviates
these prepositions.

Often, for simple vocabularies, it's sufficient to use the type of the
object range of the relationship as the key because there's only one
meaningful relationship between the subject and that type of object.

I've worked with JSON in dozens of domains and I never see anything like
what we have.


> Seriously: this is not a JSON-LD issue. We can choose any names we want
> and we can agree on, that can be mapped on the data model terms through
> @context at our heart's content.
>
> As for '@': afaik, they are, sort of, keywords. More exactly: '@id' is,
> because it assigns an identification to a resource. AFAIK, one can use any
> attribute to 'type' (mapped through the context), the usage of '@type' is
> just a convention.
>

Most keywords can be aliased, so this is not a problem:
http://www.w3.org/TR/json-ld/#aliasing-keywords

I would suggest our default context use "id" or "uri" or anything like
this. When every single other key lacks a "@" (in absence of a context
document, or with it sent in a header link) "@id" looks mighty strange and
is not something I would expect anyone to do otherwise.

I am aware of a number of JSON APIs that use a prefixing scheme, such as
"@" or "_", to separate metadata and data, but that doesn't apply here.
It's all properties or relations of the subject. None of this is, for
instance, protocal or storage "metadata" "around" the, e.g., annotation.


>
> >
> > I wondered if maybe there might be a path forward, by just defining a
> simplified JSON syntax that maps directly to the JSON-LD, but without the
> "data-typing" and URIs?
> >
> > I know that might seem like a really bad idea, because multiple syntaxes
> makes interop harder. I don't have a good answer for that.
> >
> > Can someone help me frame a description or an argument why this isn't a
> good idea?
> >
> > On the surface of it, it does have the advantage that it would be
> simpler to understand (and mildly simpler to produce). Would there be any
> other advantages?
> >
>

I think we should take another pass at our default context with an eye
toward memorable, compact keys and a default aliasing for "@id".