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

Henry,

see below

> On 16 Jun 2015, at 07:49 , Henry Story <henry.story@co-operating.systems> wrote:
> 
>> 
>> On 15 Jun 2015, at 23:43, Frederick Hirsch <w3c@fjhirsch.com> wrote:
>> 
>> Randall
>> 
>> I think you are correct about this goal, to enable deployment of annotation servers that use LDP that has been profiled. That is part of what we are doing with the Accept default.
>> 
>> If I remember :) this is the use case that Benjamin mentioned that got us started on all this.
>> 
>> regards, Frederick
>> 
>> Frederick Hirsch
>> Co-Chair, W3C Web Annotation WG
>> 
>> www.fjhirsch.com
>> @fjhirsch
>> 
>>> On Jun 15, 2015, at 11:40 AM, Randall Leeds <randall@bleeds.info> wrote:
>>> 
>>> It feels to me like we're talking about what an annotation client and a generic LDP server can do quite a bit.
>>> 
>>> Should we also consider the impact this has on interop between an annotation server that isn't a fully featured LDP server out of the box and some kind of generic LDP client?
>>> 
>>> I'm not sure that distinction is useful but it kept coming up for me as I read this thread.
> 
> There are two types of generic LDP clients
> 1) ones that never leave the domain of LDP server
> 2) ones that follow links acros the web from one domain to the other.
> 
> It is not easy to enforce 1), as LDP serves linked data and inevitably links may appear that link elsewhere.  But that is the only case where it would make sense to create clients that  use no Accept header with mime type, due to the client knowing how its server worked.
> 
> Any client of type 2) that follows links across the web, needs to have as many parsers available as possible in order to deal with all the types of data it can find on the web.
> My client for the moment uses
> 
>  "application/n-triples,application/ld+json;q=0.8,text/turtle;q=0.8"
> 
> But of course a client that can deal with RDFa too will offer the user more features.
> 
> I don't really see how a client with any linked data ambitions would ever make a request without specifying the parsers it has available.  Even more so if one group of LDP servers serves JSON-LD as a default and the other Turtle. But that is not a bad thing.
> 
> My feeling is that the server will serve as default whatever the customer prefers, to get him going. Then as they want to build real Linked Data apps, they'll come across this thread.

Let us not forget the origin of this discussion. We are not discussing generic clients with extensive 'linked data ambitions'. Annotation clients are not that kind of breed. Annotation clients are very localized to one documents, the links in an annotation structure are either used to identify specific portions of a document that is being annotated, or to refer to annotation bodies, ie, specific text/html/jpg/etc. documents. Of course there may be more complex scenarios, but the famous 80/20 cut means that we have to concentrate on the majority of our usage patterns.

As has been said in this thread many times, these issue and discussions are of course important and interesting, but go way beyond what the Annotation WG can and is chartered to handle.

Ivan



> 
>>> 
>>> 
>>> On Mon, Jun 15, 2015, 08:35 Henry Story <henry.story@co-operating.systems> wrote:
>>> 
>>>> 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


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