Bug 2352 - Underlesing trigga ved overflate-#
Summary: Underlesing trigga ved overflate-#
Status: ASSIGNED
Alias: None
Product: Grammar checkers
Classification: Unclassified
Component: Core infrastructure (show other bugs)
Version: unspecified
Hardware: All All
: P3 - Within a week normal
Assignee: Kevin Brubeck Unhammer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-09 20:20 CET by Sjur Nørstebø Moshagen
Modified: 2017-09-08 14:56 CEST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sjur Nørstebø Moshagen 2017-03-09 20:20:53 CET
Jf:

echo 'http://www.nb.no/nbsok/nb/ac3087f9a76b505c8f8adc7f6f823c6c.nbdigital?lang=no#47'\
| hfst-tokenise -g tools/preprocess/tokeniser-gramcheck-gt-desc.pmhfst 
"<http://www.nb.no/nbsok/nb/ac3087f9a76b505c8f8adc7f6f823c6c.nbdigital?lang=no#47>"
	"47" URL <W:0>
		"http://www.nb.no/nbsok/nb/ac3087f9a76b505c8f8adc7f6f823c6c.nbdigital?lang=no" <W:0>
:\n

Ein eksplisitt # i innstrengen bør ikkje føra til underlesingar, han er ein del av ordet.
Comment 1 Kevin Brubeck Unhammer 2017-03-09 20:44:26 CET
Hjelpes … korleis kan me skilja på dette? Går det an i lexc/twol å legga inn ein «escape» i lemmaet, slik at lemmaet blir 

http://www.nb.no/nbsok/nb/ac3087f9a76b505c8f8adc7f6f823c6c.nbdigital?lang=no\#47

?

(Eigentleg burde me jo hatt eit multichar-symbol til ordgrensar i staden for eit «alfabetisk» teikn (teikn som kan komma frå input), men det ville jo vore ein gigantisk operasjon å endra overalt.)
Comment 2 Sjur Nørstebø Moshagen 2017-03-09 22:21:31 CET
(In reply to Kevin Brubeck Unhammer from comment #1)
> (Eigentleg burde me jo hatt eit multichar-symbol til ordgrensar i staden for
> eit «alfabetisk» teikn (teikn som kan komma frå input), men det ville jo
> vore ein gigantisk operasjon å endra overalt.)

Er det ikkje det vi har i dag? Eg meiner - leksikaliserte, samansette ord blir _ikkje_ splitta på denne måten, berre dynamiske samansetjingar. Og dei har alltid +Cmp rett før #. Så kvifor blir det då vanskeleg med url-ar?

På den andre sida så er problemet mest kosmetisk. Blir det for mykje arbeid så trur eg nok vi kan leva med den analysen vi har no.
Comment 3 Kevin Brubeck Unhammer 2017-03-11 18:42:35 CET
(In reply to Sjur Nørstebø Moshagen from comment #2)
> (In reply to Kevin Brubeck Unhammer from comment #1)
> > (Eigentleg burde me jo hatt eit multichar-symbol til ordgrensar i staden for
> > eit «alfabetisk» teikn (teikn som kan komma frå input), men det ville jo
> > vore ein gigantisk operasjon å endra overalt.)
> 
> Er det ikkje det vi har i dag? Eg meiner - leksikaliserte, samansette ord
> blir _ikkje_ splitta på denne måten, berre dynamiske samansetjingar. Og dei
> har alltid +Cmp rett før #. Så kvifor blir det då vanskeleg med url-ar?
 
hfst-tokenize.cc har

  static string tag_separator = "+"; // + and # are hardcoded in cg-conv at least
  static string subreading_separator = "#";

– det er òg det som er konvensjonen frå cg-conv:

$ printf 'ab\ta+N#b+v\n'|cg-conv --in-fst --out-cg
"<ab>"
	"b" v
		"a" N


og ingen av dei veit (så langt) noko om +Cmp. Det kjennest litt feil å hardkoda ein tagg/taggsekvens i eit så generelt verktøy, viss me kan unngå det.

> På den andre sida så er problemet mest kosmetisk. Blir det for mykje arbeid
> så trur eg nok vi kan leva med den analysen vi har no.

Går det an å gjera # til \# (på analysesida) i lexc?
Comment 4 Sjur Nørstebø Moshagen 2017-09-08 12:59:31 CEST
(In reply to Kevin Brubeck Unhammer from comment #3)
> Går det an å gjera # til \# (på analysesida) i lexc?

Ja, det er mogleg, men krøkkete i tilfellet med URL-ar (men det er vel den ainaste staden der vi kan venta å finna # som ein del av ein streng?). Det er kanskje likevel det enklaste no.

Ei generell løysing (særleg dersom underlesingssymbolet blir konfigurerbart istf hardkoda som no) er å sjekka om innputtstrengen inneheld underlesingssymbolet, og i så fall gå gjennom analysestrengen symbolpar for symbolpar til ein kjem til det symbolparet, og deretter merka symbolparet i analysen slik at det _ikkje_ fører til underlesingsformattering. Men dette blir nok for mykje arbeid no.

Eg skal sjå om eg får til å laga '\#' i lexc.
Comment 5 Kevin Brubeck Unhammer 2017-09-08 14:55:29 CEST
(In reply to Sjur Nørstebø Moshagen from comment #4)
> (In reply to Kevin Brubeck Unhammer from comment #3)
> > Går det an å gjera # til \# (på analysesida) i lexc?
> 
> Ja, det er mogleg, men krøkkete i tilfellet med URL-ar (men det er vel den
> ainaste staden der vi kan venta å finna # som ein del av ein streng?). Det
> er kanskje likevel det enklaste no.
> 
> Ei generell løysing (særleg dersom underlesingssymbolet blir konfigurerbart
> istf hardkoda som no) er å sjekka om innputtstrengen inneheld
> underlesingssymbolet, og i så fall gå gjennom analysestrengen symbolpar for
> symbolpar til ein kjem til det symbolparet, og deretter merka symbolparet i
> analysen slik at det _ikkje_ fører til underlesingsformattering. Men dette
> blir nok for mykje arbeid no.

Det kan òg henda at det ikkje er mogleg – lista med symbolpar blir kasta vekk i PmatchAlphabet::locatefy før tokenize får tilgang på den informasjonen. Det tokenize ser i staden er to lister med «upara» symbol

        std::vector<std::string> input_symbol_strings;
        std::vector<std::string> output_symbol_strings;

Viss det finst ulikt antall ikkje-«printable» symbolar (einsidige flagg? epsilon?) før # i dei to listene, så vil listene ikkje lenger ha symbolpar på same posisjon. T.d.

a@U.kake.nam@#b:a#b
→
[(a,a),(@U.kake.nam@,x),(#,#),(b,b)]
→
([a,#,b]
,[a,x,#,b])

> Eg skal sjå om eg får til å laga '\#' i lexc.

Eit heilt anna symbol hadde vel òg fungert … 

-----

Eventuelt at me snur på det, og gjer # om til eit ekte Multichar_symbol der det fungerer som subreading-merke. Det er kanskje for mykje arbeid (og omstilling) å endra på teiknet i alle lexc-filene, men går det an å gjera det som ein del av kompilering?
Comment 6 Kevin Brubeck Unhammer 2017-09-08 14:56:40 CEST
(In reply to Kevin Brubeck Unhammer from comment #5)

> a@U.kake.nam@#b:a#b

wops, det skulle vera

a@U.kake.nam@#b:ax#b