Re: JSON Serialization?

Given our current context:
http://www.w3.org/TR/annotation-model/#json-ld-context

I would suggest as a start:

annotatedBy --> user
serializedBy --> generator  // CF ATOM terminology:
https://tools.ietf.org/html/rfc4287#section-4.2.4
annotatedAt --> date
serializedAt --> ???

It's already better than the CG's context, as we dropped the direct
translation already for FPWD.

Rob

On Mon, Jun 22, 2015 at 2:34 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
>
> Is there someone who could make a concrete proposal for revising the
JSON-LD keywords, specifically listing all the changes? We could then use
that as the basis for a brief discussion/agreement.
>
> Seems there is already rough agreement on the list as well as a rationale
for making the change (Thanks Randall for articulating this)
>
> regards, Frederick
>
> Frederick Hirsch
> Co-Chair, W3C Web Annotation WG
>
> www.fjhirsch.com
> @fjhirsch
>
> > On Jun 18, 2015, at 11:51 AM, Robert Sanderson <azaroth42@gmail.com>
wrote:
> >
> >
> > Yep, this is issue 12:
> >
> > https://github.com/w3c/web-annotation/issues/12
> >
> > Rob
> >
> > On Thu, Jun 18, 2015 at 8:42 AM, Chris Birk <cmbirk@gmail.com> wrote:
> > +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".
> >
> >
> >
> >
> >
> >
> > --
> > Rob Sanderson
> > Information Standards Advocate
> > Digital Library Systems and Services
> > Stanford, CA 94305
>
>
>
>
>



--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305