- From: Henry Story <henry.story@co-operating.systems>
- Date: Mon, 15 Jun 2015 17:34:46 +0200
- To: Doug Schepers <schepers@w3.org>
- Cc: Robert Sanderson <azaroth42@gmail.com>, Arnaud LeHors <lehors@us.ibm.com>, David Wood <david@3roundstones.com>, Mark Baker <distobj@acm.org>, W3C Public Annotation List <public-annotation@w3.org>, "public-ldp@w3.org" <public-ldp@w3.org>, Frederick Hirsch <w3c@fjhirsch.com>
> On 13 Jun 2015, at 19:36, Doug Schepers <schepers@w3.org> wrote: > > Hey, folks– > > If everyone else is satisfied that we can override a SHOULD in LDP with a MUST in Annotation Protocol, that's good enough for me. > > > I proposed an erratum on LDP simply because it seemed the easiest way to resolve the issue (for the LDP spec); errata don't have to be errors, they can also be issued because ongoing implementation experience differs from the Rec; if it turns out we get more LDP servers defaulting to JSON-LD than turtle, the spec would more accurately reflect interop if it we to change that statement. Errata can introduce changes that affect conformance [1], if warranted by the ecosystem. > > If there are major substantive changes needed for LDP, then probably a v2 is needed, which would require the re-formation of a chartered WG; otherwise, a 2nd edition can be made, which can be done by the W3C Team. > > But all this is administrivia that will only be relevant if we decide in the future that we need to update LDP. For now, it seems that we have consensus that we can require JSON-LD as the default return format for Annotation Protocol without causing a conflict with LDP. The only thing I'd say to this is that 1. the idea of having a Annotation server different from an LDP server is a bit weird, because annotation is clearly a subset of what can be done with LDP. It would be weird in that someone doing Annotations could then not use an LDP server out of the box. 2. Serving JSON-LD by default is only satisfactory to JSON folks in the very special case of the annotation representations served by the Annotation group. In any other case ( such as Activity Streams 2.0, serving JSON-LD by default won't be satisfactory to them). To really satisfy the JSON folks, we need an automatic way for them to specify the right form/profile/crystalisation of the documents produced, so that LDP servers can automatically generate them by following its nose ( of the URL in the profile=... of the mime type for example ), so that generic LDP servers can do the right thing . The action to take there is really to find the JSON-LD folks and see if they are up to specifying such a format, which could then be required by LDP-next. At the minimum it seems that the LDP group could here produce a short requirement that such a feature would be very helpful. This does not seem to be something the LDP next group can specify, but it would be very helpful to have. > > > [1] http://www.w3.org/2014/Process-20140801/#rec-modify > > Regards– > –Doug > > On 6/12/15 2:34 PM, Robert Sanderson wrote: >> >> I would be in favor of having JSON-LD as the default be a requested >> change to discuss early in the LDP-Next work. I (personally) don't >> think it blocks the WAWG protocol work, as we have only minimal >> implementation experience to date and sufficient overlap between WAWG >> and LDPWG to have engaged and productive discussions, such as currently >> :) As noted, the two are not incompatible. >> >> I agree with Arnaud that it's not a technical error -- it's completely >> implementable and in some circles it would be the appropriate choice. >> >> I would propose that Doug's additional question be discussed separately, >> initially in the WAWG list and then once there is clarity there, having >> further joint discussions. >> >> Rob >> >> >> On Fri, Jun 12, 2015 at 11:13 AM, Arnaud Le Hors <lehors@us.ibm.com >> <mailto:lehors@us.ibm.com>> wrote: >> >> I'm sorry but I just don't see how this can be painted as an errata >> and and this would change compliance. We may regret that JSON-LD >> isn't the default instead of Turtle but that's how it is and it's >> not an error. >> >> When we started with LDP and adopted Turtle as the default over >> RDF/XML this was seen as a hugely progressive move. At the time >> there was no JSON-LD to talk about. As JSON-LD surfaced and become >> more popular we progressively added in as much support as we could >> for JSON-LD but by the time people felt it should be the default it >> was just way too late to make the change. >> >> That's just how it is. >> -- >> Arnaud Le Hors - Senior Technical Staff Member, Open Web >> Technologies - IBM Software Group >> >> >> David Wood <david@3roundstones.com <mailto:david@3roundstones.com>> >> wrote on 06/11/2015 01:07:40 PM: >> >> > From: David Wood <david@3roundstones.com >> <mailto:david@3roundstones.com>> >> > To: Frederick Hirsch <w3c@fjhirsch.com <mailto:w3c@fjhirsch.com>> >> > Cc: Mark Baker <distobj@acm.org <mailto:distobj@acm.org>>, W3C >> Public Annotation List >> > <public-annotation@w3.org <mailto:public-annotation@w3.org>>, >> "public-ldp@w3.org <mailto:public-ldp@w3.org>" <public-ldp@w3.org >> <mailto:public-ldp@w3.org>> >> > Date: 06/11/2015 01:08 PM >> > Subject: Re: CfC: Resolution Annotation Protocol to make JSON-LD >> > default returned if no HTTP Accept request header (deadline 24 >> June 2015) >> >> > >> > Hi Frederick, >> > >> > That works for me. >> > >> > Regards, >> > Dave >> > -- >> > http://about.me/david_wood >> > >> > >> > >> > > On Jun 11, 2015, at 15:44, Frederick Hirsch <w3c@fjhirsch.com >> <mailto:w3c@fjhirsch.com>> wrote: >> > > >> > > I take this as support for filing an errata item on LDP to make >> > the default SHOULD be JSON-LD when no Accept specified. >> > > >> > > regards, Frederick >> > > >> > > Frederick Hirsch >> > > Co-Chair, W3C Web Annotation WG >> > > >> > > www.fjhirsch.com <http://www.fjhirsch.com> >> > > @fjhirsch >> > > >> > >> On Jun 11, 2015, at 1:58 PM, David Wood >> <david@3roundstones.com <mailto:david@3roundstones.com>> wrote: >> > >> >> > >> Mark (Hi, Mark!) is correct; interrelated specs invariably become >> > a morass. If you want to prove it, try to trace through HTTP, URI, >> > etc, to figure out which characters are allowed in an HTTP URL. >> > Kudos to anyone who can do it in within a single day. >> > >> >> > >> Of course we should be as clean as possible. Just don’t insist >> > upon perfection. >> > >> >> > >> Regards, >> > >> Dave >> > >> -- >> > >> http://about.me/david_wood >> > >> >> > >> >> > >> >> > >>> On Jun 11, 2015, at 01:14, Mark Baker <distobj@acm.org >> <mailto:distobj@acm.org>> wrote: >> > >>> >> > >>> This reminds me of that time when we had to revise HTTP to >> > support GIF89a in addition to HTML. And then the CSS update, oy! >> > Don't get me started on JPG! >> > >>> >> > >>> No, of course that never actually happened, because that >> would be silly :P >> > >> >> > > >> > >> > >> >> >> >> >> -- >> Rob Sanderson >> Information Standards Advocate >> Digital Library Systems and Services >> Stanford, CA 94305
Received on Monday, 15 June 2015 15:35:23 UTC