- From: David Booth <david@dbooth.org>
- Date: Fri, 12 Jun 2015 10:21:18 -0400
- To: Henry Story <henry.story@co-operating.systems>, W3C Public Annotation List <public-annotation@w3.org>, public-ldp <public-ldp@w3.org>
- CC: Ivan Herman <ivan@w3.org>, Frederick Hirsch <w3c@fjhirsch.com>
On 06/12/2015 06: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. How about canonical JSON-LD? http://json-ld.github.io/normalization/spec/ David Booth >> 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:21:47 UTC