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

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:04:44 UTC