Highlighted sentences to db

[bouke-nederstigt]

@yetti4 Dacht zelf dat een redelijk makkelijk oplossing was om elke zin in de tekst altijd document id mee te geven (bijv elke zin eigen divje / span geven ofzo). Vervolgens alle gehighlite sentence ids in hidden field zetten met jquery (serialize /json ofzo) en dan naar cakephp sturen als gebruiker op opslaan klikt

[karensg]

Ik denk dat de oplossing per zin geen lange termijn oplossing is, mochten we later overstappen naar HTML. Als lists owrden gehighlight, heb je al gelijk een probleem. Ik ben benieuwd wat de output is van de automatische summarizer en of dat ding met HTML om kan gaan.

[bouke-nederstigt]

Hoezo per zin geen lange termijn oplossing? Het hele project is wel redelijk gebouwd op het principe dat we alleen met hele zinnen werken? Verder is een lijst niet per se problematisch. Je moet gewoon goed onderbouwen wat je als hele zin beschouwt, een list item of de volledige lijst. Wat denk jij dan dat een goede oplossing is om de verbinding tussen jquery / db te maken

[MBrouns]

inderdaad is alles nu behoorlijk op hele zinnen gebouwd. In principe geen probleem want ik kan summarizer op zich zo bouwen dat ie een list als gehele zin beschouwd denk ik

[karensg]

Oke, eens. Dan hebben we twee mogelijkheden

1. We hebben algoritme nodig die zowel in php als in javascript de tekst splitst. Dan slaan we in DB alleen maar sequence van een zin ipv wat nu gebeurt: de hele zin.
2. In php splitten, opslaan in DB en met javascript text matchen.

Oplossing 1 lijkt mij robuster.

[MBrouns]

in java wordt de tekst nu ook al in zinnen gesplitst. misschien juist handig om het op 1 plek te houden want als er verschillen zitten in hoe de zinnen gesplit worden wordt t vast grandioze bende

[karensg]

Is wel extra troep in DB storten...

[MBrouns]

true. als we de splitter op basis van een degelijke regex maken moet het ook wel soort van universeel werken neem ik aan

[bouke-nederstigt]

Splitten van de hoofdtekst gebeurt nu al afdoende met behulp van de summarizer. Alle losse zinnen van een tekst zijn dus beschikbaar vanuit de db. Volgens mij zit op dit moment het probleem alleen in verbinden van highlights aan de juiste zin (frontend). Regex lijkt me juist niet wenselijk, want er zijn zeker scenario's mogelijk waarbij dezelfde zin meerdere malen in een tekst voor komt. Dat word nu wel ondervangen. Wat bedoel je trouwens met sequence van een zin?

[MBrouns]

ik bedoelde ook meer een regex om de zinnen te splitten, niet om ze te matchen

[bouke-nederstigt]

ah, is logischer inderdaad. Maar zie daar ook t nut niet echt van in aangezien het nu al in de summarizer gebeurt.

[karensg]

ik heb ze vanmiddag met regex gematched. Werkt voorlopig prima. Moet alsnog veranderd worden: Dus om deze issue af te maken, heb ik een van de volgende nodig:

• splitting algoritme die ik dan namaak in js
• alle zinnen in DB waarmee ik fulltext kan genereren

Beide hebben voor en nadelen

[bouke-nederstigt]

Op dit moment staan al alle zinnen in de database, namelijk in de sentences tabel. Als het goed is word daarmee all de fulltext gegenereerd, maar dat zal ik nu ff dubbelchecken.

[MBrouns]

ik stop volgens mij alleen de zinnen in de db die voorkomen in de summary

[karensg]

wat hij zegt ;)

[bouke-nederstigt]

Klopt inderdaad. Zat hier vanochtend nog naar te kijken omdat ik had bedacht dat de volledige tekst in de sentences tabel moet. En de samenvatting alleen in de user_sentences tabel. Heb er denk ik precies overheen gekeken dat blijkbaar niet alle zinnen in de sentences tabel worden gezet. Het is ook logischer om alle zinnen in de sentences tabel te zetten aangezien je anders voor de oorspronkelijke gegenereerde samenvatting bewaard terwijl die nergens voor nodig is. Alle zinnen opslaan lost ook het probleem van de volgorde op @MBrouns Nu kan inderdaad gewoon de volgorde met behulp van de ids van de sentences tabel worden bepaald.

Bouke Nederstigt

---

Oude Delft 223 2611HD Delft

MOB: (+31) 65 34 47 826

2014-03-17 16:15 GMT+01:00 Karens notifications@github.com:

wat hij zegt ;)

Reply to this email directly or view it on GitHubhttps://github.com/yetti4/crowd-summary/issues/9#issuecomment-37827130 .

[MBrouns]

ik vind t ook prima om de hele tekst op te slaan. Het leek me vanuit database oogpunt fijner om 90% minder data op te slaan maar dat zal wel los lopen. Laat maar weten of ik t moet aanpassen

[bouke-nederstigt]

Klopt. Maar de volledige tekst moet toch ergens worden opgeslagen. Denk dat het dan makkelijker is om dat in de database te doen dan het oorspronkelijke bestand te bewaren. Helemaal vanuit het oogpunt van pdf / word functionaliteit. Dan hoef je maar op 1 moment het oorspronkelijke bestandsformaat te processen. Dus wat mij betreft kan het aangepast worden.

[karensg]

en Fulltext kolom verwijderen dus. Top! Deze oplossing scheelt mij heel veel code ;)

[MBrouns]

prima! Ik zal het vanavond aanpassen en comitten.

[MBrouns]

zie #10