Re: Fwd: JSON Serialization?

Hey, folks–

I agree with everything Randall said, and I'll add this:

The RDF convention around predicates (e.g. hasX, isY, ZedBy) is intended 
to impart a natural-language flow when reading it, which I respect. In 
other languages and models, though, this violates expectations, and when 
used in real natural language, keyword (even RDF keywords) are used as 
different parts of speech, making it very awkward to talk about these 
attributes.

I'd very much like to revisit these keywords, as Randall suggests, and 
design a @context that maps them to whatever terms are needed under the 
hood.

Regards–
–Doug

On 6/18/15 2:01 AM, Randall Leeds wrote:
> See below for a response that I accidentally sent only to Ivan.
>
> ---------- Forwarded message ---------
> From: Randall Leeds <randall@bleeds.info <mailto:randall@bleeds.info>>
> Date: Wed, Jun 17, 2015 at 4:04 PM
> Subject: Re: JSON Serialization?
> To: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>
>
>
> On Wed, Jun 17, 2015 at 12:04 PM Ivan Herman <ivan@w3.org
> <mailto:ivan@w3.org>> wrote:
>
>
>      > On 17 Jun 2015, at 10:01 , Doug Schepers <schepers@w3.org
>     <mailto: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 <http://schema.org>:
>     schema.org <http://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".

Received on Thursday, 18 June 2015 06:47:23 UTC