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)

Hi Lars, Henry, all,

I think that, while interesting, we're very far afield of the original
topic now :)  In terms of the annotation model/protocol and its
relationship to LDP, the currently defined profile parameter of the media
type and associated registry seems sufficient to accommodate our use cases
once we identify, describe and register that profile.  If that's not the
case, please do let us know!

If there is interest in extending those capabilities beyond JSON-LD, I'm
very happy to be part of those conversations but I think we can let the
lists drop until such time as there's a direction.

Thanks!

Rob


On Mon, Jun 15, 2015 at 4:16 AM, Svensson, Lars <L.Svensson@dnb.de> wrote:

> On Saturday, June 13, 2015 9:00 AM, Henry Story wrote:
> [...]
> >> 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.
> >
> > That is fine for a very limited number of profiles. But if an
> application wanted
> > something more precise than the three default ones provided by JSON-LD
> then
> > registration of human readable documents is not yet very satisfactory -
> it does
> > not seem to me that any of those three profiles are sufficient for the
> Activiy
> > Streams 2 syntax for example ( but James M. Snell may be able to correct
> me
> > here ) http://www.w3.org/TR/activitystreams-core/ . If so then what is
> needed
> > is a machine readable profile document, that can be used by LDP servers
> to
> > produce the correct shape for the user, without code needing to be
> written for
> > each different type of document on the LDP server!
>
> I'm very much on the same page as Henry here. The only two media types
> registered with IANA as supporting profiles are JSON-LD and XHTML which
> means that the use of profiles with e.g. turtle is not possible (nor with
> N-triples or RDF/XML). Thinking of it, I come more and more to the
> conclusion that profiles/shapes/crystallisations is a topic for linked data
> in general, not only for LDP or annotations. I don't know which is the best
> WG to push this forward (if you think this _should_ be pushed forward). It
> could fit nicely into LDP-bis, though. What can I do to help getting this
> into the W3C process?
>
> Best,
>
> Lars
>
> > 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
>
>


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