W3C home > Mailing lists > Public > public-ldp@w3.org > June 2015

RE: JSON-LD & N3 - Re: CfC: Resolution Annotation Protocol to make JSON-LD default returned if no HTTP Accept request header (deadline 24 June 2015)

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Mon, 15 Jun 2015 11:04:23 +0000
To: Gregg Kellogg <gregg@greggkellogg.net>, David Booth <david@dbooth.org>
Cc: Ivan Herman <ivan@w3.org>, Alexandre Bertails <alexandre@bertails.org>, Doug Schepers <schepers@w3.org>, Henry Story <henry.story@co-operating.systems>, W3C Public Annotation List <public-annotation@w3.org>, public-ldp <public-ldp@w3.org>, Frederick Hirsch <w3c@fjhirsch.com>
Message-ID: <24637769D123E644A105A0AF0E1F92EF010D027331@dnbf-ex1.AD.DDB.DE>
On Friday, June 12, 2015 6:58 PM, Gregg Kellogg wrote:
 
> > On Jun 12, 2015, at 9:04 AM, David Booth <david@dbooth.org> wrote:
> >
> >
> >
> > On 06/12/2015 11:15 AM, Svensson, Lars wrote:
> >> Iván,
> >>
> >> On Friday, June 12, 2015 4:55 PM, Ivan Herman wrote:
> >>
> >>>
> >>>> On 12 Jun 2015, at 16:46 , Alexandre Bertails
> >>>> <alexandre@bertails.org>
> >>> wrote:
> >>>>
> >>>> Well, I think Henry made an important point re: stable tree
> >>>> structure. At my previous job, we ditched JSON-LD entirely
> >>>> because we found working with frames was really not practical.
> >>>>
> >>>> If the group wants to go with JSON-LD, I would strongly recommend
> >>>> the group to investigate David's suggestion: using canonical
> >>>> JSON-LD. I have not used it myself and I have no idea if it is
> >>>> supported in all libraries, though.
> >>>
> >>> I think our case is different and simpler. The Annotation Data
> >>> model gives a clear structure for the form of JSON objects that are
> >>> used. It is derived from RDF, and *can* be used in RDF, but most of
> >>> the users will just look at this as a specific JSON dialect. In
> >>> effect, without a name, we define a JSON-LD profile…
> >>
> >> Then perhaps we should make that profile definition explicit and put
> >> it into a larger framework that allows us to negotiate profiles (or
> >> crystallisations or shapes or whatever you prefer to call it...)
> >
> > I am late coming into this discussion, so please forgive me if I've
> misunderstood something.
> >
> > Wouldn't it be better to require *canonical* JSON-LD, rather then having
> each group define its own idiosyncratic shape of JSON?   If each group defines
> its own required serialization of JSON then in essence it is defining a domain-
> specific JSON syntax, then wouldn't that lead to "babelization", just like in the
> XML world?
> > http://www.w3.org/2002/Talks/1218-semweb-dbooth/slide43-0.html

> >
> > It seems to me that if canonical JSON-LD were used then each group would
> be specifying a required *subset* of canonical JSON-LD that is appropriate for
> that group, and that would at least make the syntactic structure more uniform,
> even if the different groups require different properties.
> 
> There is no definition of “canonical” JSON-LD IIRC; the closest thing would be
> flattened JSON-LD [1], which removes all hierarchical structure from a
> document, which doesn’t seem to me to be particularly developer friendly. This
> can be requested using the profile link relation with
> http://www.w3.org/ns/json-ld#flattened.


Hmm. In the JSON ns document [1] there is no such thing as "flattened". There is "expanded-flattened" [2] and "compacted-flattened" [3]. I note, however, that at [4]the JSON-LD spec referrers to flattened [5], too, so I guess that there is something missing here. I'm not knowledgeable enough about JSON-LD to say where, though...

[1] http://www.w3.org/ns/json-ld

[2] http://www.w3.org/ns/json-ld#expanded-flattened

[3] http://www.w3.org/ns/json-ld#compacted-flattened

[4] http://www.w3.org/TR/json-ld-syntax/#flattened-document-form

[5] http://www.w3.org/ns/json-ld#flattened


Cheers,

Lars
> 
> > David
> >
> >> the
> >> way we negotiate content types or languages. Something along the
> >> lines of:
> >>
> >> Request: GET /some/resource HTTP/1.1 Accept: application/ld+json;
> >> q=0.9, text/turtle; q=0.8 Accept-shape: annotation; q=0.9, *; q=0.1
> >>
> >> Response: HTTP/1.1 200 OK Content-type: text/turtle Shape:
> >> annotation
> >>
> >> Best,
> >>
> >> Lars
> >>
> >>>> On Fri, Jun 12, 2015 at 7:22 AM, Doug Schepers <schepers@w3.org>
> >>>> wrote:
> >>>>> Hi, Henry–
> >>>>>
> >>>>> If someone wants to specify a MIME type in the Accept header to
> >>>>> get back turtle, N3, HTML, or any other format that they know
> >>>>> (or hope) the server can produce, there's no problem with that.
> >>>>> They should be able to do that, though the Annotation protocol
> >>>>> spec wouldn't require any other format than JSON-LD be
> >>>>> supported.
> >>>>>
> >>>>> We're simply talking about the default format that's returned
> >>>>> if there is no Accept header; for our use case, the WG has
> >>>>> consensus that JSON-LD is the format that all servers must
> >>>>> support, and thus that must be the default.
> >>>>>
> >>>>>
> >>>>> There doesn't seem or need to be any drama about this; so far,
> >>>>> everyone
> >>> else
> >>>>> has agreed, and I hope that you also agree that so long as a
> >>>>> server is allowed (not prohibited) to serve other formats,
> >>>>> everyone's use case is satisfied.
> >>>>>
> >>>>> In the case where a server only supports JSON-LD, the client
> >>>>> could transform it into the desired format, right? (Though
> >>>>> perhaps not completely consistently, IIUI.)
> >>>>>
> >>>>> Regards– –Doug
> >>>>>
> >>>>>
> >>>>> On 6/12/15 6:33 AM, Henry Story wrote:
> >>>>>>
> >>>>>>
> >>>>>>> On 12 Jun 2015, at 12:31, Henry Story
> >>>>>>> <henry.story@co-operating.systems> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On 12 Jun 2015, at 10:45, Ivan Herman <ivan@w3.org>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Henry,
> >>>>>>>>
> >>>>>>>> I do not think N3 is an option for our constituency.
> >>>>>>>> Also, providing and accept header is not an obvious
> >>>>>>>> operation for a lambda javascript programmer, and we can
> >>>>>>>> bet that people will forget to do it even if it is
> >>>>>>>> straightforward for a very seasoned developer.
> >>>>>>>>
> >>>>>>>> I would not call this a storm, certainly not in a tea
> >>>>>>>> cup, but for the purposes of the annotation protocol
> >>>>>>>> (which is the only issue the annotation WG is
> >>>>>>>> considering) it is important to specify that the default
> >>>>>>>> language for expressing annotations over the wire relies
> >>>>>>>> on the serialization format that is the closest to the
> >>>>>>>> Javascript programs running in the client, ie, JSON-LD.
> >>>>>>>
> >>>>>>>
> >>>>>>> Does JSON-LD not have the same problem RDF/XML had? In that
> >>>>>>> it looks like JSON, but if you really want to use it
> >>>>>>> correctly you need RDF tools. ( At least on the client
> >>>>>>> getting those RDF tools is easier, for sure as JS is so
> >>>>>>> wide spread and efficient enough now).
> >>>>>>>
> >>>>>>> Let me expand: in order for a JSON person to use the
> >>>>>>> JSON-LD without hitch the JSON-LD needs to be crystalised
> >>>>>>> [1] correctly. That is it has to have a certain determinate
> >>>>>>> tree structure. But then what is important is for the
> >>>>>>> client to request the tree structure it really wants, or
> >>>>>>> else the tree structure could well be different on each
> >>>>>>> request, or at least on each different server. And so the
> >>>>>>> developer who may have written up his code for one LDP
> >>>>>>> server may find that his code does not work on another one.
> >>>>>>> As a result he will be completely at a loss as to why all
> >>>>>>> of this is meant to enhance inter-operability and will call
> >>>>>>> out bullshit. This is I think part of the reason for the
> >>>>>>> RDF/XML wars.
> >>>>>>>
> >>>>>>> In order for the client to get a stable tree structure that
> >>>>>>> he can use we need to have a profile for the document
> >>>>>>> structure. Now clearly it is not possible in LDP to
> >>>>>>> determine a profile for every single type of graph in
> >>>>>>> advance. These will need to be specified by the client in
> >>>>>>> some way using a mime type, probably something like this
> >>>>>>>
> >>>>>>> Accept:
> >>>>>>>
> >>>>>>> application/ld+json;profile=http://www.w3.org/TR/activitystreams-

> >>>
> >>>>>>>
> > core/profile
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>> But since we also don't want LDP servers to have to have to
> >>>>> write code for each crystalisation, what needs to be determined
> >>>>> is an automatic method
> >>> for
> >>>>> an LDP server to find a crystalisation constraints from the
> >>>>> profile uri in order to try to server that correctly to the
> >>>>> user.
> >>>>>>>
> >>>>>>>
> >>>>>>> But as far as I know this has not yet been specified. I
> >>>>>>> asked on the public-lod about this last month as we would
> >>>>>>> need something like this for Social-Web-WG.
> >>>>>>
> >>>>>>
> >>>>>> Forgot to point to the discussion:
> >>>>>> https://lists.w3.org/Archives/Public/public-lod/2015May/0110.html

> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> > In any case it seems that users will need to learn to use mime
> >>>>>>> types to get going. Which does not seem to be such a
> >>>>>>> difficult thing to learn.
> >>>>>>>
> >>>>>>> Henry
> >>>>>>>
> >>>>>>>
> >>>>>>> [1]
> >>>>>>> https://blogs.oracle.com/bblfish/entry/crystalizing_rdf

> >>>>>>>
> >>>>>>>>
> >>>>>>>> Ivan
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On 12 Jun 2015, at 09:59 , Henry Story
> >>>>>>>>> <henry.story@co-operating.systems> wrote:
> >>>>>>>>>
> >>>>>>>>> Seems a bit like a storm in a tea-cup. What is so
> >>>>>>>>> difficult for clients to provide an accept header?
> >>>>>>>>>
> >>>>>>>>> What is more important is that JSON-LD is closer to N3
> >>>>>>>>> than Turtle: ie it makes it easy to speak about
> >>>>>>>>> quotations of other graphs. ( which are feasable in
> >>>>>>>>> Turtle and RDF/XML, if one were to introduce simple
> >>>>>>>>> data types such as rdf:Turtle eg
> >>>>>>>>>
> >>>>>>>>> <#laura> believes "<http://hero.org/#SuperMan> a
> >>>>>>>>> <http://hero.org/#FlyingBeing>"^^rdf:Turtle
> >>>>>>>>>
> >>>>>>>>> But because this type of quotation on graphs works with
> >>>>>>>>> strings it is not possible to use the prefixes outside
> >>>>>>>>> the literal and so things become tedious to write. N3
> >>>>>>>>> allows one to say the same more elegantly
> >>>>>>>>>
> >>>>>>>>> <#laura> believes { <#SuperMan> a <#FlyingBeing> } .
> >>>>>>>>>
> >>>>>>>>> It is of course much easier to read this and express
> >>>>>>>>> this in N3 than in JSON-LD.
> >>>>>>>>>
> >>>>>>>>> But the real point behing JSON-LD & N3 move is that it
> >>>>>>>>> is easier to start answering questions here about how
> >>>>>>>>> should a LDPC quote the contents of the ldp:contains
> >>>>>>>>> resources. In both of these notations it is possible to
> >>>>>>>>> solve this problem without creating reasoning errors.
> >>>>>>>>> And this clearly means that some questions can be
> >>>>>>>>> answered in LDP-next that were difficult to answer
> >>>>>>>>> previously.
> >>>>>>>>>
> >>>>>>>>> Henry
> >>>>>>>>>
> >>>>>>>>>> On 10 Jun 2015, at 22:47, Frederick Hirsch
> >>>>>>>>>> <w3c@fjhirsch.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> During today's Annotation WG teleconference we
> >>>>>>>>>> discussed and agreed on the following Resolution
> >>>>>>>>>> [1]:
> >>>>>>>>>>
> >>>>>>>>>> RESOLUTION: Annotation Protocol spec will override
> >>>>>>>>>> LDP 4.3.2.2 LDP servers SHOULD respond with a
> >>>>>>>>>> text/turtle representation of the requested LDP-RS
> >>>>>>>>>> whenever the Accept request header is absent with
> >>>>>>>>>> "MUST respond with JSON-LD"
> >>>>>>>>>>
> >>>>>>>>>> In essence we are profiling the LDP specification [2]
> >>>>>>>>>> in the Web Annotation Protocol specification [3]  to
> >>>>>>>>>> have a 'MUST JSON-LD' instead of a 'SHOULD turtle' in
> >>>>>>>>>> the case no Accept request header is specified [2].
> >>>>>>>>>>
> >>>>>>>>>> The reason is to simplify the default requirements
> >>>>>>>>>> for server-side implementation in the case of
> >>>>>>>>>> annotations to enable adoption as well as to be
> >>>>>>>>>> consistent in the preference of JSON-LD.
> >>>>>>>>>>
> >>>>>>>>>> We will make the specification language precise as
> >>>>>>>>>> part of adding it to the Web Annotation Protocol
> >>>>>>>>>> specification.
> >>>>>>>>>>
> >>>>>>>>>> This is a Call for Consensus (CfC) to ensure wide
> >>>>>>>>>> agreement with this approach. If you have any
> >>>>>>>>>> significant concern with this approach, please
> >>>>>>>>>> indicate on the public annotation list before 24 June
> >>>>>>>>>> (2 weeks). Silence will be considered agreement. (a
> >>>>>>>>>> +1 to indicate support will also be useful if you
> >>>>>>>>>> were not on the call). Please note however that we
> >>>>>>>>>> had consensus on a well-attended call.
> >>>>>>>>>>
> >>>>>>>>>> This message is intentionally cross-posted to the
> >>>>>>>>>> public Web Annotation and  LDP WG lists.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>> regards, Frederick
> >>>>>>>>>>
> >>>>>>>>>> Frederick Hirsch Co-Chair, W3C Web Annotation WG
> >>>>>>>>>>
> >>>>>>>>>> www.fjhirsch.com @fjhirsch
> >>>>>>>>>>
> >>>>>>>>>> [1] Draft minutes (may be cleaned up later)
> >>>>>>>>>>
> >>>>>>>>>> http://www.w3.org/2015/06/10-annotation-minutes.html#item07

> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> > [2] http://www.w3.org/TR/ldp/#ldprs

> >>>>>>>>>>
> >>>>>>>>>> [[ 4.3.2.2 LDP servers should respond with a
> >>>>>>>>>> text/turtle representation of the requested LDP-RS
> >>>>>>>>>> whenever the Accept request header is absent
> >>>>>>>>>> [turtle]. ]]
> >>>>>>>>>>
> >>>>>>>>>> [3] http://w3c.github.io/web-annotation/protocol/wd/

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

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

> >>>
> >>>
> >>>
> >>
> >

Received on Monday, 15 June 2015 11:04:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:40 UTC