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)

> On 12 Jun 2015, at 20:52 , Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> In fact, we are already explicitly defining a profile and it does have a (draft) name:   http://www.w3.org/ns/oa#jsonLdProfile
> This is noted in annotation-protocol section 3.3.2:  http://w3c.github.io/web-annotation/protocol/wd/#retrieve-a-known-annotation
> (Though as a very much in-flux ED, I have not fleshed out the related IANA considerations)
> 
> There's no need to define a new header (Accept-Shape) or a new media type, as the JSON-LD media type by design has a profile attribute.  And there is a registry for such profiles, defined by RFC 7284.  (https://tools.ietf.org/html/rfc7284)   Its initial contents include flattened, expanded and compacted JSON-LD shapes.
> 
> Please see my question about this on the JSON-LD list: https://lists.w3.org/Archives/Public/public-linked-json/2014Jan/0060.html and Markus's response.
> 

Ah. I did not remember this

> Hope that helps :)

Yes, it does. For annotation servers, where the data structure is, in fact, very simple, this may very well be all what we need; ie, the Annotation WG should not engage into a generic solution for JSON-LD.

Thanks Rob

Ivan

> 
> Rob
> 
> 
> On Fri, Jun 12, 2015 at 7:55 AM, Ivan Herman <ivan@w3.org> 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
> 
> >
> > Alexandre
> >
> > 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
> 
> 
> 
> 
> 
> 
> 
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305


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