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)

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.

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

Received on Friday, 12 June 2015 14:47:24 UTC