What kind of redesiging and refactoring of the code is needed if the widget is used outside the YSO?

[miguelvaara]

Notes if the widget will be used on the vocabularies other than YSO:

• Not every vocabulary or ontology uses classes
• How coherently are paths (URL/URIs) used in the other vocabularies or ontologies, outside the YSO? The proper URLs are important particularly from the point of view of real time searches in the input fields while filling up the form.
• Should the configuration of the URLs be set up in the Skosmos config.ttl or in the widget's own configuration?

[kouralex]

The important bits related to the points above:

• Yes, vocabulary/ontology structure may differ a bit. The relevant documentation is here: https://github.com/NatLibFi/Skosmos/wiki/Data-Model
• Paths for concepts follow the standard /vocid/UI_lang/page/URI or /vocid/UI_lang/page/?uri=URI, where latter is the required form in case the URI does not belong to the main concept scheme or if the path includes some illegal URL characters. Skosmos readily delivers the full URI of the requested concept on the page in JavaScript (as a global variable) that can be used.
• URLs do not need configuration. However, there may be need for understanding the vocabulary structure (from the point of view of widget) in case the widget does something fancy. What can be adjusted for a vocabulary is stated here: https://github.com/NatLibFi/Skosmos/wiki/Configuration. All that information does not get passed on to JavaScript as of Skosmos 2.11. However, it may be possible to open issues for required properties Skosmos and, ultimately, have them at JavaScript execution time.

[miguelvaara]

Related #47

[miguelvaara]

Ensimmäinen case tämän asian edistämiseksi voisi olla SLM (https://finto.fi/slm/fi/)

[miguelvaara]

Nyt tehty:

• Testimielessä on kehitetty ja koodattu ehdotuswidgetiä tutkiaksemme sen käyttöä erikoisontologioissa.
• Paikallisten, omalla koneella olevien sanastojen lisäksi testitapaukset devillä olivat: LIIKO https://dev.finto.fi/liiko/fi/ SEKO https://dev.finto.fi/seko/fi/

Testeissä on selvinnyt seuraavaa:

Ehdotuswidgetin käyttö erikoisontologioissa on mahdollista (alunperin siis suunniteltu vain ysolle)

Yleisesti käytettävän version toteuttamisen helppous tai vaikeus (lue: suunnittelun ja koodaamisen määrä) riippuu lähinnä toivotusta aikataulusta. Ihan päivässä tai parissa toteutusta ei voi loppuun asti viedä.

Sanastokohtaisen, räätälöidyn toteutuksen helppous tai vaikeus riippuu,

a) erikoisontologian ominaispiirteistä b) toiveista ja odotuksista toimintojen suhteen c) halutusta aikataulusta

Koska kyseessä on plugin/widget/lisäosa/liitännäinen, suunnittelunäkökulma on ollut plug-and-play-ajatuksen toteutuminen mahdollisimman pitkälle niin, että widgetin käyttöönotto taustajärjestelmässä (Skosmos/Finto) vaatisi minimimäärän konfigurointia tai sanastokohtaisia säätöjä + etteivät muutokset Skosmoksessa mahdollisesti rikkoisi widgetiä. Widgetin tulisi olla Skosmoksesta/Fintosta riippuvainen lähinnä vain data osalta, mutta täyttä teknistä riippumattomuutta ei voi silti saavuttaa.

Plug-and-play-ajatuksen toteutuminen vähenee sitä mukaa, kun halutaan toimintojen osalta lisää sanastokohtaisia erityistoiveita.

Widgetin yleiskäyttöisessä testiversiossa tällä hetkellä,

• ei valita käsitteen tyyppiä (konsepti/maantieteellinen), vaan kaikki ehdotukset ovat tyyppiä "käsite"
• ei ole valittavissa ryhmiä (käytetään lähinnä ysossa)
• olemassa oleva käsite tarkistetaan Finton rajapinnan avulla vain erikoisontologiasta, ei ysosta, yso-paikoista tai ysestä
• lomakkeessa validointi mukailee muuttunutta tilannetta pakollisten/sallittujen syötteiden osalta
• GitHub-issueen (ehdotukseen) tulee sanastokohtainen sanaston nimen osoittava tägi.

Ehdotusten erikoissanastokohtaiseen GitHub-repoon ohjaamisen tutkimisen jäi hieman kesken, mutta ylimääräisten/turhien konfiguraatioiden välttämiseksi, todennäköisesti paras tapa toteuttaa omaan repoonsa ohjautuminen on seuraava:

• Widget "lukee" sanaston tunnuksen Skosmoksen tarjoaman datasta, kuten monissa muissakin toiminnoissa tällä hetkellä tehdään.
• Em. sanastotieto kuljetetaan aiemmin GitHub-käyttöä varten kehitetylle proxylle url-parametrinä.
• Ehdotusdatan GitHubiin lähettävässä proxyssä luetaan "getillä" sanastotunnus.
• Proxyssä saadun sanastotunnuksen perusteella proxy valitsee sanastokohtaisen käytettävän GitHub-rajapinnan endpointin ja käyttää repolle osoitettua tokenia autentikointiin ja mahdollistaa autorisoinnin (downside: vaatii erillisen konfiguraatiotiedoston).

Testiversiolle tehdyissä käyttäjätesteissä ei ilmennyt erityisiä ongelmia toiminnallisuuksien osalta, visuaalisia "kauneusvirheitä" ei edes pyritty estämään.

Seuraavaksi:

• Vielä mahdollisuus käyttäjäpalautteeseen yleismuotoiseen toteutukseen liittyen.
• Ensimmäinen suunnittelupalaveri(* (vaatimusmäärittelyn laadinnan aloitus) liittyen parannuksiin, uusiin ominaisuuksiin ja sanastokohtaisiin, räätälöityihin toiveisiin ja rajoitteisiin.
• Nyt koodatun testikoodin järkevöittäminen, toisteisuuden minimointi ja sofistikoituneempi yleistoteutus (tällä hetkellä vain muutoskohdat osoittavaa testikoodia), jotta ensimmäisessä vaiheessa toteutettava erikoisontologioiden yleiskäyttöinen, ei-räätälöity widget mahdollistaisi mahdollisimman hyvin jatkokehittämisen.

Myöhemmin:

• suunnittelupalaverissa(* sovittujen uusien ominaisuuksien toteutustapojen tutkiminen testikoodin avulla
• raportti testikoodaamisen tuloksista
• palaveri siitä, miten räätälöityjen/uusien ominaisuuksien toteuttamisen suhteen edetään.

[jarmosaarikko]

Viilattavaa, ei visuaalisia vaan jotenkin toiminnallisia epäjohdonmukaisuuksia - pitikö näitä kommentoida nyt?

• uutta käsitettä ehdotettaessa widget tarkistaa nyt prefLabelit ja näyttää jos termi on jo sanastossa, mutta altLabeleissa tämä ei toimi eli widgetti näyttäisi hyväksyvän ne uutena terminä. esim. LIIKO: alikulkukäytävät vs. alikulut
• kun ehdotan yläkäsitettä ja kirjoitan "käytävä" -- widgetti tarjoaa kolme vaihtoehtoa, josta kaksi on "käytävät" -- ovatko ne sama käsite vai eri käsitteitä? Miksi kaksi kertaa?
• Jos kirjoitan RT-kohdassa "ajokor" -- tarjotaan kolme "ajokortit" -käsitettä.

[miguelvaara]

• AltLabelien suhteen tarkistuksia ei ole toteutettu alun alkaenkaan. Niitä ei siis ole myöskään YSOn käyttässä widgetissä.
• Toinen ehdotetuista käytävät-käsitteistä on YSOn käsite ja toinen on LIIKOn käsite (meron). Kieltämättä olisi paljon informatiivisempaa, jos kunkin kohdalla näkyisi tarkenne, että mistä sanastosta ehdotus tulee. Hyvä kehitysidea! :-)
• Kolme ajokortit-käsitettä rinnakkaistermeissä johtuu siitä, että yksi käsite tulee YSO-tarkistuksesta, yksi LIIKOsta itsetään ja yksi LIIKOon sisällytetystä YSOsta. Ongelma on analogiassa yllä kuvatun kanssa. Mahtavaa testausta @jarmosaarikko :+1:, juuri tämän takia testijaksoja tarvitaan