{"id":70780,"date":"2024-05-16T19:51:19","date_gmt":"2024-05-16T10:51:19","guid":{"rendered":"https:\/\/monolith.law\/no\/?p=70780"},"modified":"2024-08-09T00:34:34","modified_gmt":"2024-08-08T15:34:34","slug":"system-flaw-measure-after-acceptance","status":"publish","type":"post","link":"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance","title":{"rendered":"Tiltak ved oppdagelse av systemfeil etter godkjenning"},"content":{"rendered":"\n<p>Systemutvikling inneb\u00e6rer generelt at implementeringen av programmet f\u00f8lger innholdet som ble bestemt i kravdefinisjonsfasen. Til slutt bekrefter b\u00e5de brukeren og leverand\u00f8ren om resultatet samsvarer med spesifikasjonene, og prosjektet avsluttes n\u00e5r det er godkjent.<\/p>\n\n\n\n<p>Men i virkeligheten kan det oppst\u00e5 feil eller problemer som ikke ble oppdaget under testfasen eller ved godkjenning, og disse kan komme frem i driftsfasen. Hva kan man juridisk sett kreve n\u00e5r man f\u00f8rst har akseptert leveransen?<br><\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Det_er_ikke_overraskende_at_det_fortsatt_finnes_feil_etter_godkjenning_og_testfaser\" title=\"Det er ikke overraskende at det fortsatt finnes feil etter godkjenning og testfaser\">Det er ikke overraskende at det fortsatt finnes feil etter godkjenning og testfaser<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Det_er_vanlig_a_anse_gjelden_som_oppfylt\" title=\"Det er vanlig \u00e5 anse gjelden som oppfylt\">Det er vanlig \u00e5 anse gjelden som oppfylt<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Veien_til_a_forfolge_ansvar_basert_pa_mangelsansvar\" title=\"Veien til \u00e5 forf\u00f8lge ansvar basert p\u00e5 mangelsansvar\">Veien til \u00e5 forf\u00f8lge ansvar basert p\u00e5 mangelsansvar<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Forst_bekreft_alvorlighetsgraden_av_feil_eller_mangler\" title=\"F\u00f8rst, bekreft alvorlighetsgraden av feil eller mangler\">F\u00f8rst, bekreft alvorlighetsgraden av feil eller mangler<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Deretter_klargjor_hva_som_skal_kreves_fra_leverandoren\" title=\"Deretter, klargj\u00f8r hva som skal kreves fra leverand\u00f8ren\">Deretter, klargj\u00f8r hva som skal kreves fra leverand\u00f8ren<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Andre_Viktige_Punkter\" title=\"Andre Viktige Punkter\">Andre Viktige Punkter<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Vaer_oppmerksom_pa_metoder_ved_juridiske_handlinger_som_oppsigelse_av_kontrakt\" title=\"V\u00e6r oppmerksom p\u00e5 metoder ved juridiske handlinger som oppsigelse av kontrakt\">V\u00e6r oppmerksom p\u00e5 metoder ved juridiske handlinger som oppsigelse av kontrakt<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Forhandle_fremfor_a_ga_til_rettssak\" title=\"Forhandle fremfor \u00e5 g\u00e5 til rettssak\">Forhandle fremfor \u00e5 g\u00e5 til rettssak<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Skille_mellom_feil_og_mangler_og_mangel_pa_funksjonalitet\" title=\"Skille mellom feil og mangler, og mangel p\u00e5 funksjonalitet\">Skille mellom feil og mangler, og mangel p\u00e5 funksjonalitet<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/monolith.law\/no\/it\/system-flaw-measure-after-acceptance\/#Oppsummering\" title=\"Oppsummering\">Oppsummering<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Det_er_ikke_overraskende_at_det_fortsatt_finnes_feil_etter_godkjenning_og_testfaser\"><\/span>Det er ikke overraskende at det fortsatt finnes feil etter godkjenning og testfaser<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Fra et teknisk perspektiv er det ikke uvanlig at ulike feil og problemer oppdages etter at leverand\u00f8rens testfaser er fullf\u00f8rt og brukeren har godkjent systemet. Under godkjenningsprosessen utf\u00f8rer brukeren vanligvis en sjekk av inn- og utdata som kan bekreftes fra skjermen. Men IT-systemer har ofte en kompleks og detaljert struktur bak skjermens utseende, inkludert databaser og programmer som styrer ulike beregninger og kontroller. Derfor er det begrensninger p\u00e5 hva som kan unders\u00f8kes gjennom skjermbaserte inn- og utdata-sjekker fra brukerens perspektiv. Det er derfor ikke realistisk \u00e5 forvente at alle potensielle problemer som kan oppst\u00e5 i driftsfasen, kan oppdages gjennom slike sjekker.<\/p>\n\n\n\n<p>De samme forholdene gjelder ogs\u00e5 fra leverand\u00f8rens perspektiv. For eksempel er testfasen der man sjekker om det er feil eller problemer i de implementerte programmene. Men det er ikke alltid mulig \u00e5 oppdage alle potensielle feil og problemer i testfasen. Etter at det utviklede systemet begynner \u00e5 bli brukt i full skala, kan det oppst\u00e5 uventede operasjoner fra brukerne, store mengder data kan bli registrert, eller flere brukere kan f\u00e5 tilgang samtidig. \u00c5 lage et system som fortsatt fungerer uten problemer under slike forhold krever egentlig h\u00f8y teknisk kompetanse.<\/p>\n\n\n\n<p>Man b\u00f8r forst\u00e5 at det ikke er realistisk \u00e5 oppdage alle feil og problemer i godkjennings- og testfasene, og at ulike problemer kan oppst\u00e5 etter at systemet tas i bruk.<br><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Det_er_vanlig_a_anse_gjelden_som_oppfylt\"><\/span>Det er vanlig \u00e5 anse gjelden som oppfylt<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith-law.jp\/wp-content\/uploads\/2019\/09\/shutterstock_326816432-1024x977.jpg\" alt=\"\" class=\"wp-image-4911\" \/><figcaption class=\"wp-element-caption\">Det er ofte vanskelig \u00e5 holde leverand\u00f8ren ansvarlig for feil som oppst\u00e5r etter at programmet er tatt i bruk.<\/figcaption><\/figure>\n\n\n\n<p>S\u00e5 hvordan b\u00f8r man h\u00e5ndtere slike problemer n\u00e5r de faktisk oppst\u00e5r? La oss organisere dette i henhold til juridiske prosedyrer.<\/p>\n\n\n\n<p>F\u00f8rst og fremst, hvis ulike feil og mangler oppdages etter levering, vil brukeren vanligvis \u00f8nske \u00e5 holde leverand\u00f8ren ansvarlig. Men hvis leveransen allerede er fullf\u00f8rt og godkjent, er det ofte vanskelig \u00e5 forf\u00f8lge ansvar basert p\u00e5 kontraktsbrudd.<\/p>\n\n\n\n<p>Kontrakter for systemutvikling reguleres vanligvis av bestemmelsene i den japanske sivilretten om oppdragsavtaler, med mindre det er spesielle avtaler. Vi forklarer detaljene om oppdragsavtaler i f\u00f8lgende artikkel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/system-development-contact-agreement\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/system-development-contact-agreement[ja]<\/a><\/p>\n\n\n\n<p>I en oppdragsavtale er &#8220;fullf\u00f8ring av arbeidet&#8221; en forutsetning for oppfyllelse av gjelden. Vi forklarer hva &#8220;fullf\u00f8ring av arbeidet&#8221; konkret betyr i f\u00f8lgende artikkel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/completion-of-work-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/completion-of-work-in-system-development[ja]<\/a><\/p>\n\n\n\n<p>Her forklarer vi at i tidligere rettssaker har &#8220;fullf\u00f8ring av arbeidet&#8221; i en oppdragsavtale, i konteksten av systemutvikling, blitt tolket som fullf\u00f8ring av alle utviklingsfaser. Vi forklarer ogs\u00e5 at problemer som oppst\u00e5r etter fullf\u00f8ring av utviklingsfasene, som feil og mangler, faller inn under ansvaret for mangler i oppdragsavtalen.<\/p>\n\n\n\n<p>For \u00e5 oppsummere, hvis leveransen er mottatt og godkjent, anses gjelden som oppfylt. Deretter blir sp\u00f8rsm\u00e5let om det er mulig \u00e5 forf\u00f8lge ansvar for mangler, det vil si ansvaret for mangler i oppdragsavtalen, vanligvis det sentrale sp\u00f8rsm\u00e5let.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Veien_til_a_forfolge_ansvar_basert_pa_mangelsansvar\"><\/span>Veien til \u00e5 forf\u00f8lge ansvar basert p\u00e5 mangelsansvar<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>S\u00e5, hva b\u00f8r man vurdere og i hvilken rekkef\u00f8lge n\u00e5r man krever tiltak fra leverand\u00f8ren basert p\u00e5 mangelsansvar? La oss se n\u00e6rmere p\u00e5 dette nedenfor.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Forst_bekreft_alvorlighetsgraden_av_feil_eller_mangler\"><\/span>F\u00f8rst, bekreft alvorlighetsgraden av feil eller mangler<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>N\u00e5r feil eller mangler oppdages i etterkant og man \u00f8nsker \u00e5 kreve noen form for kompensasjon under lovens &#8220;mangel&#8221;, blir alvorlighetsgraden av feilen eller mangelen et sentralt sp\u00f8rsm\u00e5l. Problemet med lovens mangel kan deles inn i tre kategorier:<\/p>\n\n\n\n<ol>\n<li>Selv om det kan kalles en feil eller mangel, er det bare en mindre feil og kan ikke betraktes som en lovlig &#8220;mangel&#8221;.<\/li>\n\n\n\n<li>Det kvalifiserer som en lovlig &#8220;mangel&#8221;, men det er fortsatt mulig \u00e5 oppn\u00e5 kontraktens form\u00e5l.<\/li>\n\n\n\n<li>Det kvalifiserer som en lovlig &#8220;mangel&#8221;, og det er ikke mulig \u00e5 oppn\u00e5 kontraktens form\u00e5l.<\/li>\n<\/ol>\n\n\n\n<p>Grensen mellom 1 og 2 avgj\u00f8r om man kan forf\u00f8lge ansvar basert p\u00e5 mangelsansvar, mens grensen mellom 2 og 3 avgj\u00f8r om man kan heve kontrakten basert p\u00e5 mangelsansvar.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Artikkel 634<\/p>\n\n\n\n<p>1. N\u00e5r det er en <u>mangel<\/u> i arbeidsobjektet, kan bestilleren kreve at entrepren\u00f8ren utbedrer <u>mangelen<\/u> innen en rimelig frist. Dette gjelder imidlertid ikke hvis mangelen er ubetydelig og utbedringen vil medf\u00f8re uforholdsmessige kostnader.<\/p>\n\n\n\n<p>2. Bestilleren kan kreve <u>erstatning<\/u> i stedet for, eller sammen med, utbedring av mangelen. I dette tilfellet gjelder bestemmelsene i artikkel 533 tilsvarende.<\/p>\n\n\n\n<p>Artikkel 635<\/p>\n\n\n\n<p>N\u00e5r det er en mangel i arbeidsobjektet, og det derfor er <u>umulig \u00e5 oppn\u00e5 kontraktens form\u00e5l<\/u>, kan bestilleren heve kontrakten. Dette gjelder imidlertid ikke for bygninger eller andre konstruksjoner p\u00e5 land.<\/p>\n<\/blockquote>\n\n\n\n<p>For en detaljert forklaring av disse trinnvise forskjellene i &#8220;mangel&#8221;, se artikkelen nedenfor.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/defect-warranty-liability\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/defect-warranty-liability[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Deretter_klargjor_hva_som_skal_kreves_fra_leverandoren\"><\/span>Deretter, klargj\u00f8r hva som skal kreves fra leverand\u00f8ren<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Det er ogs\u00e5 n\u00f8dvendig \u00e5 tydeliggj\u00f8re hva som skal kreves fra motparten. Hvis man \u00f8nsker \u00e5 heve kontrakten, er det ikke nok \u00e5 bevise at det er en mangel; det m\u00e5 ogs\u00e5 bevises at mangelen gj\u00f8r det &#8220;umulig \u00e5 oppn\u00e5 kontraktens form\u00e5l&#8221;. Ved vurdering av &#8220;form\u00e5let&#8221; er m\u00f8tereferater fra oppstarten av systemutviklingsprosjektet og spesifikasjonsdokumenter viktige ledetr\u00e5der. Siden feil og mangler kan oppdages etter at prosjektet er godkjent, b\u00f8r man s\u00f8rge for \u00e5 oppbevare alle relevante dokumenter ogs\u00e5 etter prosjektets avslutning.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/the-minutes-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/the-minutes-in-system-development[ja]<\/a><\/p>\n\n\n\n<p>Foruten heving, kan man ogs\u00e5 kreve erstatning eller utbedring av mangelen som en del av mangelsansvaret.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Andre_Viktige_Punkter\"><\/span>Andre Viktige Punkter<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith-law.jp\/wp-content\/uploads\/2019\/09\/shutterstock_1299988513-1024x684.jpg\" alt=\"\" class=\"wp-image-4913\" \/><figcaption class=\"wp-element-caption\">Det er viktig \u00e5 ha oversikt over dokumenth\u00e5ndtering og juridiske prosedyrer frem til prosjektets fullf\u00f8ring.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Vaer_oppmerksom_pa_metoder_ved_juridiske_handlinger_som_oppsigelse_av_kontrakt\"><\/span>V\u00e6r oppmerksom p\u00e5 metoder ved juridiske handlinger som oppsigelse av kontrakt<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Hvis du skal si opp en kontrakt p\u00e5 grunn av mangelsansvar, b\u00f8r du ogs\u00e5 tilegne deg kunnskap om de juridiske prosedyrene for oppsigelse. Vi har forklart detaljene om effekten av kontraktsoppsigelse, hvordan man gir en gyldig erkl\u00e6ring, og hvordan man gir varsel for \u00e5 unng\u00e5 fremtidige konflikter i artikkelen nedenfor.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/cancellation-of-contracts-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/cancellation-of-contracts-in-system-development[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Forhandle_fremfor_a_ga_til_rettssak\"><\/span>Forhandle fremfor \u00e5 g\u00e5 til rettssak<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Disse juridiske prinsippene er ikke bare relevante i tilfelle en rettssak. Rettslige tvister er sv\u00e6rt belastende for begge parter. Derfor b\u00f8r man heller bruke denne kunnskapen i forhandlingsfasen f\u00f8r en eventuell rettssak. Vi har forklart betydningen av juridisk kunnskap i forhandlinger utenfor rettssalen i artikkelen nedenfor.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/disputes-related-to-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/disputes-related-to-system-development[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Skille_mellom_feil_og_mangler_og_mangel_pa_funksjonalitet\"><\/span>Skille mellom feil og mangler, og mangel p\u00e5 funksjonalitet<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Diskusjonen er forskjellig n\u00e5r det gjelder feil og mangler i implementerte funksjoner og spesifikasjoner, sammenlignet med tilfeller der n\u00f8dvendige funksjoner mangler helt. Hvis n\u00f8dvendige funksjoner ikke er til stede, kan det hende at &#8220;fullf\u00f8ring av arbeidet&#8221; i henhold til oppdragskontrakten ikke blir anerkjent, og at oppfyllelse av forpliktelsene ikke blir godkjent.<\/p>\n\n\n\n<p>Selv om n\u00f8dvendige funksjoner og spesifikasjoner mangler, kan det v\u00e6re upassende \u00e5 anse dette som en del av kontrakten hvis brukeren ikke har gitt tilstrekkelig informasjon i kravdefinisjonsfasen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Oppsummering\"><\/span>Oppsummering<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Problemer som oppst\u00e5r i l\u00f8pet av et prosjekt kan avdekkes b\u00e5de under prosjektets gang og i driftsfasen etter prosjektets avslutning. Selv om alle faser av prosjektet fullf\u00f8res uten problemer, kan man ikke alltid f\u00f8le seg trygg. Denne egenskapen ved systemutviklingsprosjekter er spesielt tydelig i den japanske &#8220;ansvar for skjulte feil&#8221;-ordningen. Det er viktig \u00e5 sikre grundig dokumenth\u00e5ndtering som tar hensyn til tiden etter prosjektets avslutning, samt \u00e5 ha en god forst\u00e5else av denne prosessen.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Systemutvikling inneb\u00e6rer generelt at implementeringen av programmet f\u00f8lger innholdet som ble bestemt i kravdefinisjonsfasen. Til slutt bekrefter b\u00e5de brukeren og leverand\u00f8ren om resultatet samsvarer  [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":71992,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70780"}],"collection":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/comments?post=70780"}],"version-history":[{"count":3,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70780\/revisions"}],"predecessor-version":[{"id":72791,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70780\/revisions\/72791"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/71992"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=70780"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=70780"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=70780"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}