Re: JSON-LD serialization and linked data support

+1 to Tim and James.



On Thu, Aug 13, 2015 at 8:43 AM, Timothy Cole <t-cole3@illinois.edu> wrote:

> James's experience on this resonates with me and I'll remain skeptical
> until I see some examples that a custom JSON-OA serialization, assuming it
> retains the precision, full expressiveness and extensibility of our Data
> Model and supports all articulated MUST, SHOULD and MAY requirements /
> options, will look significantly more natural to JSON developers than a
> JSON-LD serialization with a well-thought out @context. I really think Greg
> et al. did an amazing job with the JSON-LD spec. When it comes to
> customizing JSON-LD to a specific data model, the @context approach is
> powerful. Even though it may be worth a try, I'm not convinced we're going
> to do enough better to justify minting our own custom OA RDF serialization
> in JSON.
>
> But we'll see. Lengthy discussions about balancing the trade-offs between
> uptake, interoperability and completeness are inherent to this kind of work.
>
> -Tim Cole
>
> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Thursday, August 13, 2015 10:07 AM
> To: Ivan Herman <ivan@w3.org>
> Cc: Frederick Hirsch <w3c@fjhirsch.com>; W3C Public Annotation List <
> public-annotation@w3.org>; Tim Cole <t-cole3@illinois.edu>; Rob Sanderson
> <azaroth@stanford.edu>
> Subject: Re: JSON-LD serialization and linked data support
>
> If I can interject a few thoughts from the sidelines... I faced a similar
> decision with regards to Activity Streams 2.0 -- only I came at it from the
> opposite point of view. That is, we had a pure JSON syntax to start and
> moved to a Vocabulary model with a JSON-LD syntax.
> One of the key goals of this move, however, has been to make sure that
> developers who wish to ignore the JSON-LD processing model can do so if
> they wish -- albeit at a cost of some features.
>
> The short version of the story is that Activity Streams 2.0 builds on
> JSON-LD but requires only a subset of what JSON-LD provides. For instance,
> the data format *requires* JSON-LD compact form serialization, it requires
> use of a normative JSON-LD @context definition that ensures consistent
> serialization, it strongly recommends that certain JSON-LD features are
> avoided, and -- perhaps most importantly -- does not require that
> developers implement the full RDF world view in order to make sense of the
> data.
>
> A similar approach can be applied here. By defining a normative JSON-LD
> @context and requiring compact serialization using that @context, and by
> limiting the JSON-LD specific features you depend on, you can place
> practical limits on those various JSON-LD idiosyncrasies that everyone
> loves to hate.
>
> - James
>
> On Thu, Aug 13, 2015 at 6:16 AM, Ivan Herman <ivan@w3.org> wrote:
> > Frederick, I put Tim and Rob into the Cc list just to make it clear that
> this is not a direct answer to this mail but, rather, the three mails in
> this thread ([1,2]), and also Rob's separate mail[3].
> >
> > (Apologies if parts of what I write is obvious to some of the people
> > on the group. It may not be for others…)
> >
> > The annotation model is *not* in JSON-LD. Nor is it in Turtle, for that
> matter. It is in RDF. RDF is defined in terms of abstract concepts (IRI-s
> as identifiers, literals, blank nodes, triples, etc.) defined in the RDF1.1
> Concept document[4]; that document is *serialization agnostic*. (<digress>
> it has been one of the biggest mistake ever in the history of RDF that the
> concept and a particular serialization in XML, ie, RDF/XML, have been
> conflated in the story line. This has done more harm to RDF than anything
> else!</digress>). There are quite a number of serialization syntaxes
> (Turtle, JSON-LD, RDFa, N-Triples, RDF/XML, there is even a simple JSON
> serialization, though not as a Rec).
> >
> > I believe that, at this point, nobody (including Paolo) is considering
> moving away from the model. It is a model in RDF and, so far, it has served
> us well. In other words, we are firmly in the domain of Linked Data. We
> should get this issue off the table.
> >
> > RDF can be serialized. We use already two of those in our document:
> Turtle and JSON-LD. Other people may use other serialization for OA: RDFa
> or, (God forbid!) RDF/XML. The model is oblivious to that and we cannot
> even forbid that to happen.
> >
> > In my *personal* opinion, Semantic Web people would use Turtle, which
> > is a simple, straightforward representation of the model. But it is an
> > alien syntax to most, so we decided to push JSON to the fore. To
> > achieve that, we are looking at a particular *serialization* of RDF,
> > which is JSON-LD. We are hoping that this works for us, including
> > those among us who do not care about RDF. But JSON-LD has its
> > idiosyncrasies that some may live with, but others do not. It has the
> > advantage of being a generic RDF serialization, but it also has the
> > disadvantage of being a generic RDF serialization:-)
> >
> > 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. What a JSON-LD processor does is to map a generic JSON-LD
> file to the abstract RDF model; well, we can define a processor that does
> the same *to a very restricted JSON syntax* that is defined for the
> annotation model only. 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.
> >
> > In fact, this is not so far off from what Rob proposed in [1]:
> >
> > [[[
> > * Define the model to fully encapsulate all of the requirements without
> taking into consideration any serialization or convenience.
> > * The on-the-wire bits are the JSON-LD serialization of that model. We
> can discuss later whether we need to require a specific crystalization or
> whether we can just say JSON-LD.
> > * We provide implementations that take that serialization and further
> compact it into whatever structure is most useful, but those are
> non-normative. They're code that we can write to make developers' lives
> easier.
> > ]]]
> >
> > But, I think:
> >
> > * Per point 1: we have the model, and we should not change it
> > * Per point 2: we can, actually, use JSON-OA as a the on-the-wire bits
> > as a serialization of that model (yeah, I know, this is a bit touchy
> > with the definition of LDP, let us see whether we can solve that)
> > * Per point 3: JSON-OA *may* be the normative serialization and we
> > ditch JSON-LD altogether
> >
> > This approach may or may not work. Tim may be right that the proper
> modeling of the problem area would lead us to a certain level of
> complication anyway, and the whole thing may not lead to a real
> simplification compared to JSON-LD. In which case we declare this a dead
> end and we may be stuck with JSON-LD. But let us not pretend that by trying
> to that we create more interoperability problems (we don't, because there
> is a plethora of RDF serializations out there already) or that we drop
> Linked Data approach from our model (we don't because we touch only a
> particular serialization of the model).
> >
> > Ivan
> >
> > P.S. a different remark: yes, JSON-LD is included in schema.org, ie,
> > Google think it is ready and easy for… webmasters! Not developers in
> > general…
> >
> >
> > [1]
> > http://www.w3.org/mid/CABevsUFyszpujiZq2qGd-wUQVvzzBgHY6K9sAKcatyjdj16
> > PUA@mail.gmail.com [2]
> > http://www.w3.org/mid/009201d0d585$696b9810$3c42c830$@illinois.edu
> > [3]
> > http://www.w3.org/mid/CABevsUGMeisPtx3xgxv1Dy52nmnUuoaRwWfi2Q10X5QJhr-
> > 0JA@mail.gmail.com [4] http://www.w3.org/TR/rdf11-concepts/
> >
> >
> >> On 13 Aug 2015, at 24:15 , Frederick Hirsch <w3c@fjhirsch.com> wrote:
> >>
> >> On today's call the topic of serializations came up and a question
> >> seemed to be raised over whether JSON-LD should be used (perhaps I
> >> heard incorrectly)
> >>
> >> There are some strong reasons to continue to require JSON-LD as a
> mandatory serialization, the abstract argument being the value of linked
> data on the back end.
> >>
> >> A specific concrete example of the value of linked data in combination
> with annotations might be "CATCH: Common Annotation, Tagging, and Citation
> at Harvard"
> >>
> >> [[
> >>
> >> It is designed to interoperate with third-party annotation tools to
> >> aggregate and associate contextualized annotation metadata from
> >> various pedagogical and research tools with reference to persistent
> >> digital media in repositories, such as the Harvard Library DRS. - See
> >> more at:
> >> https://osc.hul.harvard.edu/liblab/projects/catch-common-annotation-t
> >> agging-and-citation-harvard#sthash.fr7L4qa3.dpuf
> >>
> >> ]]
> >>
> >> Do we have other concrete examples of how the linked data aspect of the
> Open Annotation model adds value to annotations? Pointers would be welcome.
> >>
> >> I'm concerned about specifying multiple serializations as we have to be
> more careful of interoperability in this case, specifically is
> round-tripping without information loss despite the serialization a
> potential issue? More serializations also mean more testing.
> >>
> >> In a related thought, is directly embedding JSON-LD in HTML (
> http://www.w3.org/TR/json-ld/#embedding-json-ld-in-html-documents ) a
> viable option? What is the status of browser support for this? If it is
> supported (or is in progress) what is the case for HTML serialization as an
> alternative? Would it be more productive to focus on generic support for
> JSON-LD in browsers rather than a specific annotation serialization?
> >>
> >> The fundamental issue I heard us discuss is that even with all our
> efforts to simplify the JSON-LD serialization, there will remain some
> aspects that do not appear 'natural' to JSON developers.  The next question
> I have is whether these aspects can be managed with suitable libraries etc.
> >>
> >> Thanks
> >>
> >> regards, Frederick
> >>
> >> Frederick Hirsch
> >>
> >> www.fjhirsch.com
> >> @fjhirsch
> >>
> >>
> >
> >
> > ----
> > Ivan Herman, W3C
> > Digital Publishing Activity Lead
> > Home: http://www.w3.org/People/Ivan/
> > mobile: +31-641044153
> > ORCID ID: http://orcid.org/0000-0003-0782-2704
> >
> >
> >
> >
>
>
>


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