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)

> >> 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...) 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
> >>
> >
> > That may indeed a way to go; we should discuss this in the protocol
> document. (Although we do not expect clients to understand Turtle, so the
> example should be adapted.)

This wasn't intended just for annotations, but for any place where we need to work with shapes (as in the discussion at public-lod [2]).

> Caveat: Accept-shape does not seem to be an existing HTTP header field,
> per[1]…
 
Well, sure. We'd have to register it.

> [1] http://www.iana.org/assignments/message-headers/message-headers.xml

[2] https://lists.w3.org/Archives/Public/public-lod/2015May/0034.html


Best,

Lars
> 
> 
> 
> > On 12 Jun 2015, at 17:18 , Ivan Herman <ivan@w3.org> wrote:
> >
> >>
> >> On 12 Jun 2015, at 17:15 , Svensson, Lars <L.Svensson@dnb.de> 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…
> >>
> >
> > Ivan
> >
> >> 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

> >
> >
> > ----
> > 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 Friday, 12 June 2015 15:31:21 UTC