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 12:58 PM, Gregg Kellogg wrote:
>> 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.

It sounds like the negative of not being developer friendly would 
overshadow the benefits of canonicalization.

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

Thanks for the input.  I was assuming that the RDF canonicalization 
(a/k/a normalization) work would also define a canonical form of 
JSON-LD, since that work was previously hosted in the JSON-LD group, but 
I guess not.

Thanks,
David Booth

>
> 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 Saturday, 13 June 2015 04:20:17 UTC