Shared vocabularies
(
)
Schema.org startet som et samarbeid mellom søkemotorene Google, Yahoo og Bing, og er senere utvidet med bl.a. Yandex. Bakgrunnen var at de enkelte søkemotorene var i ferd med å lage sine egne begrepsapparat for spesielle «ting» som søkemotorene kunne kjenne igjen. Litt fritt etter hukommelsen tilbød f.eks. Google at de som drev en restaurant kunne legge inn spesielle data på sine hjemmesider, bl.a. åpningstider og link til andres vurderinger, som kunne brukes som strukturerte data av Google. Gjennom Schema.org var ambisjonen å lage et felles vokabular slik at de som lager nettsider slapp å legge inn omtrent likelydende kode, beregnet på de tre søkemotorene, altså en form for begrepsharmonisering. Siden oppstarten har det felles vokabularet vokst betraktelig, og det er også gått mer i retning av å basere seg på W3Cs teknologier for «lenkede data», bl.a. RDFa og JSON-LD (opprinnelig var «microdata» det primære formatet). Her er et knippe klasser/typer som er beskrevet i vokabularet: · Creative works: CreativeWork, Book, Movie, MusicRecording, Recipe, TVSeries ... · Embedded non-text objects: AudioObject, ImageObject, VideoObject · Event · Health and medical types: notes on the health and medical types under MedicalEntity. · Organization · Person · Place, LocalBusiness, Restaurant .. Det interessante med Schema.org er at det fremstår som et relativt vellykket forsøk på å lage «referansemodeller»/core vocabulary, med lave kostnader: - Vokabularene publiseres på statiske nettsider, http://schema.org - Nye versjoner utvikles i github, der en finner både vokabularer under arbeid og programvare for generere innholdet på http://schema.org – både vokabularet og eksempelene på bruk av det. Se: https://github.com/schemaorg/schemaorg - Det er W3C som organiserer arbeidet med å utvikle vokabularene, gjennom sin «Web Schema TF» (som har et mer generelt oppdrag, men nå er det Schema.org som tar mesteparten av oppmerksomheten). Se deres mandat: http://www.w3.org/2001/sw/interest/webschema.html - Det er et lite (bittelite!) «redaktørkorps», slik jeg forstår det – i all hovedsak Dan Brickley - Men mange fagmiljø «bringer til bordet» det de har gjort i andre sammenhenger, og dermed vokser det ganske fort Jeg synes det er ekstra interessant, jfr temaet om eventuelle tiltak knyttet til tjenestekataloger og tjenestebeskrivelser på møtet i dag, at Schema.org også beveger seg inn på et vokabular for å beskrive API. Opprinnelig var det bare «menneskelesbar» informasjon som fikk vokabular, for å gjøre søkeresultatene bedre. Men i fjor la de til typen «Actions» som gir et vokabular for å beskrive maskin-til-maskin-interaksjon. Se http://schema.org/docs/actions.html Se f.eks. Example: Product purchase API call with –output Eksempelet illustrerer: - standardiseringen av API-vokabular à for å sende en web-service-forespørsel om å kjøpe noe, bruk «BuyAction». - «meldingsmodellen» for hva tjenesten returnerer som svar – beskrevet i JSON-LD med bruk av Schema.org-vokabular for «Order» { "@type": "Product", "url": "http://example.com/products/ipod", "potentialAction": { "@type": "BuyAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://example.com/products/ipod/buy", "encodingType": "application/ld+json", "contentType": "application/ld+json" }, "result": { "@type": "Order", "url-output": "required", "confirmationNumber-output": "required", "orderNumber-output": "required", "orderStatus-output": "required" } } } “Alle” er enige om at REST-tjenester er veien å gå for integrasjon mellom maskiner, men i det siste er det blitt stadig mer fokus på at «alle» lager sine REST-tjenester på forskjellige måter, og at mye av gevinsten forsvinner. Et mål med REST – hvis det gjøres riktig – er kunne sette opp integrasjoner uten å ty til dokumentasjon «out of bound»; ut fra et «startpunkt» til et API, skal du via det samme API-et kunne få informasjon om alle funksjoner i API-et og hvordan det brukes, inkludert meldingsmodeller der hvor du skal sende inn eller få returnert data. Men det blir lettere hvis man blir enige om … nettopp! … begrepsbruken J Derfor har det dukket opp «rammeverk» og standarder for REST-tjenester, inkludert det som Altinn bruker (Odata og Hal, se https://www.altinn.no/api/help/ ). Men de går ikke så langt som til å lage et vokabular for hva slags aksjoner man faktisk kan ta (kjøpe, selge, abonnere, etc). Jeg tror det kan ligge et stort potensiale i det Schema.org gjør her, og det viser også hvor verdifull det er med knytning er mellom et godt grenesnitt og publiserte datamodeller og vokabular. Vel, det var det Oslo kommune hadde å by på i dag. Føltes godt å få nevnt det når det omsider hadde boblet opp fra underbevisstheten og frem til pannelappen. Blir _ikke_ fornærmet om dere ikke finner noen mulighet til å «ta det videre». Den største verdien av å bruke det tror jeg er at det kan vise relevansen av informasjonsforvaltningen for flere av «do-erne», de som til sist sitter og etablerer integrasjoner, og sliter med at alle API-er snakker forskjellige språk, at integrasjonene må skrives om hver gang noen endrer API-et sitt osv. Det er denne gruppen jeg tror vi nå må overbevise. Nå har informasjonsforvaltning en «heiagjeng» i veikart og SKATE og de som sliter med manglende orden i eget hus, men det er ikke de samme som skal løse prosjektenes utfordringer fra dag til dag. Helsing, Steinar