Request/Deliver LaTeX output

[goodmami]

The REST servers have a latex value for some formats (e.g. mrs=latex, eds=latex, and dmrs=latex, although support varies among the LKB and Bottlenose servers). Can this LaTeX code be requested by the user and displayed somehow? It would probably require a second request from the server for the same input string. The LaTeX code could be displayed in a tooltip (via a button like we have for "PNG" and "SVG"), or open a new tab with the TeX code as the page contents.

[ned2]

Yeah this would be great to add. I see that bottlenose/pydelphin currently supports just DMRS, while the LKB backend supports EDS, DMRS, and MRS.

I think you're right, a second request will probably be required. Unless we were to opportunistically request latex on the initial call, however both servers currently only support a single format per visualisation type (for a given request), so that would be two calls -- meaning that we may as well wait until someone actually requests the latex for a given visualisation.

I will look into adding a latex button for individual visualisations that makes a request for the latex format for the corresponding input and result number that was selected.

I think this will mean that we'll need to start keeping track of the capabilities of different servers so we don't put latex buttons on results that will fail. Ideally would be good to have the server provide a list of capabilities, but for now I can just keep track on the delphin-viz side.

[fcbond]

G'day,

thanks. Looking at it this way, it would probably also be good to add it for the trees, where I am pretty sure the lkb provides LaTeX output and I probably want it enough to add it to pydelphin :-).

On Sat, Dec 17, 2016 at 11:31 AM, Ned Letcher notifications@github.com wrote:

Yeah this would be great to add. I see that bottlenose/pydelphin currently supports just DMRS, while the LKB backend supports EDS, DMRS, and MRS.

I think you're right, a second request will probably be required. Unless we were to opportunistically request latex on the initial call, however both servers currently only support a single format per visualisation type (for a given request), so that would be two calls -- meaning that we may as well wait until someone actually requests the latex for a given visualisation.

I will look into adding a latex button for individual visualisations that makes a request for the latex format for the corresponding input and result number that was selected.

I think this will mean that we'll need to start keeping track of the capabilities of different servers so we don't put latex buttons on results that will fail. Ideally would be good to have the server provide a list of capabilities, but for now I can just keep track on the delphin-viz side.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/delph-in/delphin-viz/issues/1#issuecomment-267737519, or mute the thread https://github.com/notifications/unsubscribe-auth/ABD8xjv2MCpBAdDYdX8iHb8OUQIHTD1jks5rI0mdgaJpZM4Kn3Lm .

-- Francis Bond http://www3.ntu.edu.sg/home/fcbond/ Division of Linguistics and Multilingual Studies Nanyang Technological University

[ned2]

Yep that would be useful too for sure. Even thought the LKB itself likely supports latex output for the derivation trees, I don't think Stephan's API implementation currently supports it, as the below link just returns EDS JSON, presumably the default. So we'll have to ask him to hook that up for support on LKB server.

http://erg.delph-in.net/rest/0.9/parse?derivation=latex&input=Abrams+knew+that+it+rained.&results=5

[goodmami]

Some things:

• the LKB server supports LaTeX for MRS and EDS, but not DMRS. So our servers are currently exactly complementary here.

• while the servers may support returning LaTeX during a parse request, I think they should provide a convert URL (in addition to parse) so we don't need to parse the whole thing over again. Then again, if one server implements this and not the other, it'd be even more reason to maintain a list of server capabilities.

• I'd also like to see trees have a LaTeX option.

[ned2]

@goodmami, can you elaborate on how the convert URL might work? What kind of input do you think it would take?

[goodmami]

@ned2 I imagine it would be something like:

.../bottlenose/erg/convert?from=simplemrs&to=mrs-latex

It would need to be a POST request, so the (e.g. MRS) data would go in the message body, not the URL. It needs to be a POST request because MRSs would quickly use up the practical maximum limit for URLs, and because GET messages cannot include message bodies (or at least the bodies couldn't be used for anything). We don't really have to follow those rules, but I try to follow standards and conventions if there's no big reason not to.

Also note that the from=simplemrs and to=mrs-latex use different strings for the format names than the parse endpoint does. We could try to keep them consistent by breaking them up: from=mrs&from-format=simple or something; or alternatively we could embed that info in the POST body:

{
    "from": {"mrs": "simple"},
    "to": {"mrs": "latex"},
    "data": "[ TOP: h0 ... ]"
}

I'm open to ideas, here.

[ned2]

@goodmami from the perspective of an end consumer, that all makes a lot of sense and I would be on board with either of those approaches. I guess I was more unsure about how this would work with respect to getting the MRS back to the servers and serialisation etc, it sounded like it could be a bit of work on the server side, but I haven't really being paying attention to what the current state of all that is with respect to pydelphin. Not really sure if I have many principled suggestions. Stephan is more likely to have strong feelings about these considerations than I, I suspect.

[ned2]

In the meantime, I've done a bit of holiday coding and gone ahead and implemented saving as latex on visualisations. This is now live on the demo.

Since the latex format is only available on specific visualisations depending on the server you served to do the parsing, we also needed a way of tracking all this. So I went ahead and refactored that way we track the different resources. the file resources.js now lists all the different grammars available to the demo along with various metadata as well as the capabilities of the two different server types that a grammar can have. I'm open to any and all of this changing, but figured I'd offer this as an opening bid. Also, I wasn't sure what to call Stephan's implementation so it's just lkb for the moment.

In the meantime, @fbond, latex is available for DMRS on pydelphin hosted grammars (UiO server is down at the moment, so that's it) and as soon as pydelphin supports other formats it should just be a matter of adding this capability in resources.js. That's the idea anyway.

[fcbond]

On Tue, Dec 27, 2016 at 2:06 AM, Ned Letcher notifications@github.com wrote:

In the meantime, I've done a bit of holiday coding and gone ahead and implemented saving as latex on visualisations.

It's like a Christmas present for us all :-).

Since the 'latex' format is only available on specific visualisations depending on the server you served to do the parsing, we also needed a way of tracking all this. So I went ahead and refactored that way we track the different resources. the file resources.js now lists all the different grammars available to the demo along with various metadata as well as the capabilities of the two different server types that a grammar can have. I'm open to any and all of this changing, but figured I'd offer this as an opening bid. Also, I wasn't sure what to call Stephan's implementation so it's just lkb for the moment.

That seems a reasonable thing to do. Now we need to update the LaTeX output on the UW servers.

In the meantime, @fbond https://github.com/fbond, latex is available for DMRS on pydelphin hosted grammars (UiO server is down at the moment, so that's it) and as soon as pydelphin supports other formats it should just be a matter of adding this capability in resources.js. That's the idea anyway.

Great.

-- Francis Bond http://www3.ntu.edu.sg/home/fcbond/ Division of Linguistics and Multilingual Studies Nanyang Technological University

[goodmami]

Cool, thanks Ned.

@ned2 wrote: the file resources.js now lists all the different grammars available to the demo along with various metadata as well as the capabilities of the two different server types that a grammar can have. I'm open to any and all of this changing, but figured I'd offer this as an opening bid.

This seems like a fine solution to me. Stephan wanted an HTTP endpoint capabilities that returned such information for a server, but AFAIK he hasn't implemented it yet, and I wasn't a big fan of that anyway. There are other RESTy ways of making APIs explorable (e.g. the HATEOAS pattern, or the OPTIONS HTTP verb, or other things), but I think implementing one of the many automatic API discovery methods would lead to more headaches than manually updating resources.js when a new version of the server is pushed.

(BTW, Bottlenose is also capable of eds=json, although the EDS produced by pyDelphin aren't quite the same as those from the LKB (nor are those from Bec's C++ code, for that matter))

Also, could you use standard language codes in resources.js? Like Mandarin -> cmn, Japanese -> jpn (check here: https://en.wikipedia.org/wiki/List_of_ISO_639-3_codes)

Also, I wasn't sure what to call Stephan's implementation so it's just lkb for the moment.

It's part of the LKB codebase, so that seems appropriate.

@fcbond wrote: Now we need to update the LaTeX output on the UW servers.

Let me know when you're done tweaking the LaTeX output in pyDelphin, and I can push the changes.

[ned2]

Also, could you use standard language codes in resources.js? Like Mandarin -> cmn, Japanese -> jpn (check here: https://en.wikipedia.org/wiki/List_of_ISO_639-3_codes)

Oops, meant to fill them in properly, but forgot amidst my flurry of coding. Just fixed.

[ned2]

Closed via 37ee77d

[fcbond]

I have long been a fan of ISO-639-3, but have been convinced by John McCrae to move to BCP 47 (which is the standard for linked data, and also allows you to specify region and script). This makes it easy to distinguish cmn-hans from cmn-hant, which is actually useful for us.

More info on BCP 47 here: https://en.wikipedia.org/wiki/IETF_language_tag

This page for checking tags is very useful: http://r12a.github.io/apps/subtags/

Maybe we should use them here? eng -> en; deu -> de; jpn -> jp; cmn -> cmn-hans; hau -> ha; ind -> id

On Tue, Dec 27, 2016 at 5:05 PM, Ned Letcher notifications@github.com wrote:

Also, could you use standard language codes in resources.js? Like Mandarin -> cmn, Japanese -> jpn (check here: https://en.wikipedia.org/wiki/ List_of_ISO_639-3_codes)

Oops, meant to fill them in properly, but forgot amidst my flurry of coding. Just fixed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/delph-in/delphin-viz/issues/1#issuecomment-269406390, or mute the thread https://github.com/notifications/unsubscribe-auth/ABD8xgL8OthcxE5KI2FAGFyrJoZuRibWks5rMbXtgaJpZM4Kn3Lm .

-- Francis Bond http://www3.ntu.edu.sg/home/fcbond/ Division of Linguistics and Multilingual Studies Nanyang Technological University