Re: Turtle Trouble (was: Re: [protocol] Patch formats)

On Mon, Jun 8, 2015 at 1:01 PM, Ivan Herman <ivan@w3.org> wrote:

>
> > On 08 Jun 2015, at 16:21 , Benjamin Young <bigbluehat@hypothes.is>
> wrote:
> >
> > This email's been in my head for awhile (too long probably) and this
> patch thread tipped it to the point of my fingers typing what's in my
> brain. :) So here goes...
> >
> > First (and foremost, maybe), I actually really like Turtle. :)
> >
> > However....it requires a way of thinking that the prevailing systems
> (non-graph databases, browsers, JS runtimes, etc) don't currently think in.
> >
> > We've addressed that in the data model by preferring / promoting the
> JSON-LD representation in examples--while still providing the Turtle
> representation for those that support it.
> >
> > Where things fall down for me (at least) are with the protocol
> specification--which, being based on LDP (which is otherwise quite
> fabulous) comes with the requirement that:
> > http://www.w3.org/TR/ldp/#h4_ldprs-HTTP_GET
> > > ...MUST respond with a Turtle representation...when the request
> includes an Accept header specifying text/turtle
> > > ...SHOULD respond with a text/turtle...whenever the Accept request
> header is absent.
> > > ...MUST respond with a application/ld+json representation...when the
> request includes an Accept header specifying application/ld+json
> >
> > What this means practically (afaik) is that an Annotation API server
> MUST be able to transform their stored info into both Turtle and JSON-LD
> (regardless of which was sent in).
> >
> > There aren't (that I've found) terribly many Turtle-to-JSON-LD
> transformation libraries. I've used this one (recently relicensed to Apache
> License 2.0) with varied success:
> > https://github.com/warpr/turtle-to-jsonld
>
> I will ask around. I think if we allow for non-Javascript converters, too,
> then there are more. I know there is a JSON-LD module to RDFLib, so it is
> fairly easy to write a Python program to convert from one format to the
> other. Gregg Kellogg has a similar tool for Ruby. I think both are fairly
> good; the JSON-LD part was written by people from the JSON-LD group itself.
> I may get more info (from Gregg)
>
> (Note that I am mostly offline tomorrow, so the info may come on Wednesday
> only)
>

Thanks, Ivan!

Sorry if I misrepresented the "coverage area" of the tooling. The focus on
JS was mostly browser-driven--which is where I currently expect most
annotation clients live. Server-side stuff is more amenable of course. :)

Thanks in advance for the links. It will be a useful list to reference
whatever else we decide.

Cheers!
Benjamin


>
> ivan
>
> >
> > However, that (plus it's dependencies) provides a transformation to a
> JSON-LD format that may actually not be what one wants in the end, and then
> requires yet-more transformation and more understanding of the "meta model"
> by the API server (and/or database) to move between the formats.
> >
> > Here's where this hits the PATCH format options....
> >
> > On Sat, Jun 6, 2015 at 12:57 AM, Ivan Herman <ivan@w3.org> wrote:
> >
> > > On 05 Jun 2015, at 20:51 , Robert Sanderson <azaroth42@gmail.com>
> wrote:
> > >
> > >
> > > In reading back through the discussion at the face to face about the
> protocol draft, it was noted that there are many possible patch formats,
> including LDPatch, JSON Patch, Sparql Update, diff and so on.  All would be
> possible to use, and some easier in different circumstances.
> > >
> > > Do we want to:
> > >
> > > a)  Specify one as a requirement (MUST) and let the others be usable
> (MAY)
> > > b)  Not specify any as a requirement and just remain silent on which
> one to use.
> > >
> > > If B is the preference, then we would need to decide how the server
> advertises which of the PATCH formats it implements so that clients can
> determine how (if at all) they can interact.
> > >
> > > My preference is A, and to pick LDPatch (by reference) as part of the
> LDP stable of specifications, but what do people think?
> >
> > My preference is also A, although the issue of advertising may still be
> relevant. ('may'. We may decide not to address this issue.)
> >
> > If the database or API server you are building supports a graph-based
> "meta model" then supporting the transformation between Turtle and JSON-LD
> or LDPatch or anything else triple-based is "just some more code." :)
> >
> > However, if your database does not (most databases don't...even if they
> "speak" JSON), then handling LDPatch is an even farther reach than
> supporting Turtle.
> >
> > Here's an LDPatch example for those who are curious:
> > http://www.w3.org/TR/ldpatch/#full-example
> >
> >
> >  > Benjamin suggested at the F2F a preference for JSON Patch, for
> example.
> >
> > Good memory, Rob! :)
> >
> > The preference is completely along these lines:
> >  - most available tooling supports JSON
> >  - "understanding" the `-LD` bit of JSON-LD is at some level "optional"
> (at least for storage, basic parsing, and transportation)
> >  - if a PATCH format is chosen, it should be equally "dumb" (in the best
> possible way) ;)
> >
> > Because:
> >  - if developers can deal with annotations as JSON (+/- the `-LD`
> knowhow), they can start using annotation data now with very little
> additional effort added to their stack
> >  - if developers *want* to use PATCH, having the option of a patch
> format equally as "dump" (just dealing with keys and values, not triples),
> means (again) that they can start with (nearly) what they already know and
> have.
> >
> > Here's the list of examples from the JSON Patch (RFC 6902) spec:
> > http://tools.ietf.org/html/rfc6902#appendix-A
> >
> >
> > I do not have a strong feeling on whether it is json patch or ldpatch,
> not really familiar with the details and certainly no experience. I. I have
> a slight preference to JSON, however; as far as I can see, LDPatch is based
> on a turtle syntax, and we did make a decision to put JSON-LD forward as
> our primary syntax in the model (in view of our constituency). In this
> respect JSON patch seems to be more in line with the rest.
> >
> > I suppose it comes down to "cutting with the grain" of what's already in
> place--with the option to "be smarter" if you know how to be. :)
> >
> > I'm all for having Turtle as an *option* and (if I have that) also
> having LDPatch as an *option.*
> >
> > However, if these become mandatory, I fear we're cutting off a large
> part of the potential integration, implementation, and consuming developers.
> >
> > I'd love to see annotation data as widely used as feeds were "back in
> the day."
> >
> > I think it's possible, but (at least right now) I think that means
> keeping the "smarter" graph stuff as optional bits and not required
> defaults--as they are in LDP.
> >
> > Ideally, we find a way to spec our Annotation API that is at once
> "simple" and also LDP compatible.
> >
> > Is that feasible?
> >
> > Did any of this make sense? :)
> >
> > Thanks for listening regardless. ;)
> >
> > Cheers,
> > Benjamin
> > --
> > Developer Advocate
> > http://hypothes.is/
> >
> >
> > (Maybe there is an Abis possibility: require JSON and LDPatch? Or is
> that too much?)
> >
> > Ivan
> >
> > >
> > > Thanks!
> > >
> > > Rob
> > >
> > > --
> > > Rob Sanderson
> > > Information Standards Advocate
> > > Digital Library Systems and Services
> > > Stanford, CA 94305
> >
> >
> > ----
> > 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
>
>
>
>
>