Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Kyle P. Johnson
    @kylepjohnson
    @manu-chroma I made an image of the server you were working on and turned it off. I can restart it if that helps you
    Manvendra Singh
    @manu-chroma
    @kylepjohnson I'll ask for it if I require in the future :smile:
    I thought you were using the same server setup currently and facing problems with that
    Kyle P. Johnson
    @kylepjohnson
    In case you guys didn't see, here are the new Perseus repos that are available for conversion: https://github.com/cltk/capitains_corpora_converter/issues/7#issuecomment-227059186
    I want to start using these, though surely there'll be some work to serve in the frontend
    @lukehollis I am beginning to think of a plan to host these converted files, however I don't want to do jump the gun. Should we table plans for this until after your upcoming demo?
    Luke Hollis
    @lukehollis
    Oh sure, that sounds good! Though I don't want to hold off just on account of that--we can move things around as necessary before then or even demo a local copy of the applications with screenshare
    Kyle P. Johnson
    @kylepjohnson
    OK, I suppose I can make them and you them as you're ready. I'll work on it this week
    Rob Jenson
    @ferthalangur
    Hi guys ... right now the server was only configured to proxy either to 8080 or to 5000. Now that the DNS records are in place, we can make api.cltk.org proxy to Gunicorn on port 5000 for the API and archive.cltk.org proxy to Meteor on port 8080 for the FrontEnd.
    I see that they are there now. Thank you!
    Rob Jenson
    @ferthalangur
    I have a mess at the Historical Society today (hacked webserver plus a date with the Evil Verizon) so I might not be around for a bit.
    Luke Hollis
    @lukehollis
    Given @suheb's recent updates to the cltk_frontend repo and how we've already entered into pretty complex contracts between the API and frontend app, I think unless anyone's against it we should start versioning our API in the cltk_api.
    I think the small amount of additional complexity here would outweigh the longer term benefits.
    Would setting Accept headers be an alright solution for this? Can create an issue on the cltk_api repo. Looks like this is pretty easy in Flask: http://flask.pocoo.org/snippets/45/
    Manvendra Singh
    @manu-chroma
    Hey, it's been long. I was back to working on cltk/cltk_api#24
    Long amounts of gap in discussion have left me a little confused on how to proceed with this.
    This is what I've understood and have in mind for now.
    Expose GET /core/ner/<string:sentence> endpoint
    And feed the input string to the following endpoint and pipe the output to wikipedia search module.
    @lukehollis @kylepjohnson Thoughts ?
    Also, sorry for the delay in getting back to addressing the issues.
    Manvendra Singh
    @manu-chroma
    One more idea, rather than picking up any particular result from wikipedia search, can we display top k results and user decide what is most relevant for them ?
    Seems like a better approach to reduce ambiguity and increase accuracy.
    Luke Hollis
    @lukehollis
    Thanks, @manu-chroma! Top results is an interesting idea.. I know we're going to have a fair amount of ambiguity even for common entities like Jupiter--I'm of two minds about this because top entries would be most useful for others potentially using our API but for the frontend, I think we really just need a thumbnail and two-three sentence description to one place. Honestly, I can't think of how to do that now other than a fair amount of manual massaging of the data after we run it the first time.
    I suppose then it might make sense for the API to return top results and the frontend to just take the top result--and if it's wrong, we can follow up afterward and correct it.
    Does that seem like a reasonable solution? Thanks again for following up on this.
    Manvendra Singh
    @manu-chroma
    Yeah, I think it does.
    I can start working with exposing GET /core/ner/<string:sentence>
    What do you think ?
    Luke Hollis
    @lukehollis
    That sounds great! This'll be super useful for pulling together the frontend and I imagine people will really appreciate it in the api as well.
    Manvendra Singh
    @manu-chroma
    Hey, a little doubt here
    Should ner be in the metadata folder or should I create another core folder for the same ?
    Luke Hollis
    @lukehollis
    Ah, good question--I think that since we have a lot of the other core CLTK package functions exposed in the metadata directory, we can keep using that for now. As the project grows, it might make sense as you mention to make one directly specifically for CTLK core package functionality.
    Manvendra Singh
    @manu-chroma
    Sure :smile:
    And sounds good!
    Luke Hollis
    @lukehollis
    Cool, and thanks again! :)
    Manvendra Singh
    @manu-chroma
    @kylepjohnson @lukehollis In case of NER for Latin, should I take the string and pass it directly to NER method or first use JVReplacer and then go for the NER ? Or should this be given as an option to the user of the API ?
    Kyle P. Johnson
    @kylepjohnson
    You could add an optional query string, like &jvreplce=True. If the language is Latin and it makes sense for the algorithm, then the replacement is done
    Know how to do that? Thanks, that's a smart question
    Manvendra Singh
    @manu-chroma
    I think better approach would be a POST request here
    Here's what I had in mine
    POST request /ner/
    {'string': 'Gallia est omnis divisa in partes tres',
    'lang': 'latin',
    'jvreplce': 'True'}
    if 'jvreplce' is not given in the json, it will fallback to deafult
    and yes, I think I can do this bit
    Thoughts ?
    Kyle P. Johnson
    @kylepjohnson
    Yeah I like that too. It's cleaner, for sure
    Luke Hollis
    @lukehollis
    Seems good to me. Long-term, GETs with the query string @kylepjohnson mentioned might be a little better because GETs can be cached
    Manvendra Singh
    @manu-chroma
    blob
    I'm afraid only ASCII characters are supported in GET requests
    Luke Hollis
    @lukehollis
    ah, lame! well, it appears we'll have to do some amount of encoding for the URL in the future anyhow, but as I mentioned, POSTs seems like a good solution for now to me at least
    thanks for checking into that, @manu-chroma!
    Kyle P. Johnson
    @kylepjohnson
    for cases of True/False flags in a get, this could work with a GET
    However id like to know it's being used in a large number of Latin options before adding this