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