Re: Fwd: JSON Serialization?

+1 as well ( especially revisiting the keywords ).  




I agree that the end value isn’t high for most producers from my perspective, but including that information in the HTTP return header should alleviate any issues there.








- Chris @cmbirk

(317) 418-9384

On Thu, Jun 18, 2015 at 2:47 AM, Doug Schepers <schepers@w3.org> wrote:

> 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".