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 Jun 12, 2015, at 9:04 AM, David Booth <david@dbooth.org> wrote:
> 
> 
> 
> On 06/12/2015 11:15 AM, Svensson, Lars wrote:
>> Iván,
>> 
>> On Friday, June 12, 2015 4:55 PM, Ivan Herman 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…
>> 
>> Then perhaps we should make that profile definition explicit and put
>> it into a larger framework that allows us to negotiate profiles (or
>> crystallisations or shapes or whatever you prefer to call it...)
> 
> I am late coming into this discussion, so please forgive me if I've misunderstood something.
> 
> Wouldn't it be better to require *canonical* JSON-LD, rather then having each group define its own idiosyncratic shape of JSON?   If each group defines its own required serialization of JSON then in essence it is defining a domain-specific JSON syntax, then wouldn't that lead to "babelization", just like in the XML world?
> http://www.w3.org/2002/Talks/1218-semweb-dbooth/slide43-0.html
> 
> It seems to me that if canonical JSON-LD were used then each group would be specifying a required *subset* of canonical JSON-LD that is appropriate for that group, and that would at least make the syntactic structure more uniform, even if the different groups require different properties.

There is no definition of “canonical” JSON-LD IIRC; the closest thing would be flattened JSON-LD [1], which removes all hierarchical structure from a document, which doesn’t seem to me to be particularly developer friendly. This can be requested using the profile link relation with http://www.w3.org/ns/json-ld#flattened.

JSON-LD Framing is the spec which is intended to create a shape appropriate for client consumption. It remains unfinished, but is widely implemented and used; a test suite exists as part of the JSON-LD test suite. Some time some group will choose to take this forward to REC, and inadequacies should be addressed (such as reverse property framing)

Note that the Normalization spec [2] is generic RDF Dataset Normalization, not specific to JSON-LD, and a serialization would likely be in N-Quads, although it could potentially be in any form. It’s mostly useful for isomorphism and signatures, though.

Gregg

[1] http://www.w3.org/TR/json-ld/#flattened-document-form
[2] http://json-ld.github.io/normalization/spec/

> David
> 
>> the
>> way we negotiate content types or languages. Something along the
>> lines of:
>> 
>> Request: GET /some/resource HTTP/1.1 Accept: application/ld+json;
>> q=0.9, text/turtle; q=0.8 Accept-shape: annotation; q=0.9, *; q=0.1
>> 
>> Response: HTTP/1.1 200 OK Content-type: text/turtle Shape:
>> annotation
>> 
>> Best,
>> 
>> Lars
>> 
>>>> 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
>>> 
>>> 
>>> 
>> 
>

Received on Friday, 12 June 2015 16:58:34 UTC