Sehke speci draft

Versioon 4

Tanel Tammet, Kalle Tomingas

18 märts 2009

Sissejuhatus

Versioon 4 on koostatud pärast versioon 3-le saabunud tagasisidet ja küsimusi. Detailiseeritud/täiendatud on muuhulgas järgmised osad:

• klassi ja omaduse suhted
• klassifikaatorite esitamine
• versioneerimine
• klasside hierarhia kuvamise täiendamine
• owl reeglite lisamine wiki lehtedele
• mitmekeelsus
• omaniksuhted
• eksport
• wsdl kasutamine

Käesolev spetsifikatsioon täpsustab semantic mediawiki tarkvarasüsteemi kasutamist, mitte aga WSMO süsteemi, veebiteenuste sünteesi või muuid väliseid süsteeme. Semantika kasutamine nendes süsteemides lisatakse spetsifikatsioonile edaspidistes etappides.

Spetsifikatsiooni alguses on toodud suhteliselt põhjalik selgitus semantika, rdfi/owli, semantic mediawiki võimaluste kohta: eesmärgiks tekitada lugejate seas ühesugune arusaam aluspõhimõtetest.

SEHKE eesmärgid: mis ja milleks semantika

Sehke süsteemi peamine eesmärk on hõlbustada eeskätt veebiteenuste, edaspidi ka muude tarkvarakomponentide (andmebaasiskeemid jms) semantilist ehk tähenduse kirjeldamist.

Veebiteenused on analoogilised funktsioonide väljakutsumisega: teenusele antakse N parameetrit ja saadakse vastus.

Semantilised kirjeldused veebiteenustele on analoogilised harilikele andmetüüpidele, olles nö täiendavad tüübid: igal veebiteenuse parameetril oleks nii tava-andmetüüp kui semantiline tüüp, kusjuures kumbki kannab endas erinevat informatsiooni.

Semantika ehk tähendus

Sõnal “semantika” endal ei ole lihtsat ja universaarset tähendust, ei tavakeeles ega teaduslikes erialakeeltes. “Semantika” tähendus üldiselt on filosoofiline küsimus, tähenduse filosoofiaga tegelemine ei ole - arusaadavalt - antud projekti skoobis.

SEHKE projektis konkreetselt ja veebiteenuste/programmide/andmebaaside semantilise annoteerimise juures on “semantilisel annotatsioonil” kaks peamist tähendust, mis mõlemid on projekti jaoks olulised:

• Tähendus tavamõttes: kogu seoste, intuitsioonide, assotsiatsioonide hulk inimese peas. Eri inimestel ja eri ajahetkedel on sõnadel erinevad tähendused.

Tavamõttes tähendust kirjeldavad SEHKE projektis annoteerivate sõnade juures olevad inimloetavad seletused, näiteks:

Füüsiline isik

Reaalne inimene. Kodakondsus, vanus jms võib olla mistahes. Erinev juriidilisest isikust: viimane tähistab ametlikult registreeritud organisatsiooni.

Ilma selliste seletusteta ei ole annoteerivate sõnade tähendus kasutajatele mõistetav. Annoteeriva sõna enda kuju (näiteks, “Füüsiline isik” sõna “x12223” asemel) on samuti mõeldud esmase inimloetava selgitusena.

Inimloetavad seletused on analoogilised kommentaaridele programmide ja andmebaasiskeemide juures.

Inimloetavad seletused ei ole mõeldud programmide poolt töötlemiseks: programmid ei tee neist seletustest mingeid järeldusi: neid seletusi lihtsalt ignoreeritakse.

• Tähendus formaalses mõttes: loogikareeglitega antud seosed annoteerivate sõnade vahel.

Näiteks:

Iga X jaoks kehtib: kui X on “füüsiline isik”, siis X on “isik”.

Viimane lause oleks standardses loogikakeele süntaksis niisugune:

Forall X. “füüsiline isik”(X) => isik(X).

Iga X, Y ja Z jaoks kehtib: kui X on Y “isa” ja Y on Z “isa” siis X on Z “vanaisa”.

mis oleks standardses loogikakeele süntaksis niisugune:

Forall X, Y. isa(X,Y) & isa(Y,Z) => vanaisa(X,Z).

Reeglite mõte on võimalus reeglite abil olemasolevatest faktidest automaatselt uusi fakte tuletada.

Sõnade konkreetne kuju (“isa”, “Isa”, “father”, “z1112” vms) ei oma formaalse tähenduse jaoks mingit tähtsust: ainus, mis loeb, on reeglitega esitatud seosed sõnade vahel.

Selleks, et formaalset tähendust arvutiga töödelda/kasutada, peavad:

• reeglid olema konkreetses, arvutiga töödeldavas keeles
• arvutiprogramm peab sisaldama/kasutama neid reegleid rakendada oskavat järeldus- või päringumootorit.

Teoreetiliselt on loogikareeglitega võimalik esitada ükskõik kui keerulisi seoseid ja ükskõik kui palju. Reaalselt ei suuda järeldus- ja päringumootorid väga suure hulga keeruliste reeglitega efektiivselt opereerida. Hoopiski ei suuda inim-kasutajad formaliseerida ja sõnastada niipalju reegleid, et mõiste formaalne tähendus jõuaks lähedale mõiste tähendusele tavamõttes.

Sehke projekti jaoks tuleb arvestada, et mõistete tavatähenduse loetavalt kirjapanek kasutajate poolt on süsteemi kasutatavuse ja mõttekuse jaoks kriitiline. Formaalsed tähendused kannavad SEHKE projektis kolme rolli:

• Abistavad kasutajatel mõistete süsteemi korrastada ja seal navigeerida.
• Võimaldavad luua erirakendusi veebiteenuste verifitseerimiseks ja automaatseks sünteesiks.
• Võimaldavad teostada semantikavarade automaatset kvaliteedikontrolli (vastuolude puudumine jms).

Veebiteenus, funktsioon, andmebaas

Veebiteenuseid kasutatakse tüüpiliselt selleks, et teha http protokolli kaudu, xml formaadis esitatud andmetega andmebaasipäringuid ja saada tulemuseks andmebaasist päritud andmed, mis on samuti xml formaadis esitatud.

Veebiteenuse URL-le xml-teksti postitamise järel käivitatakse programm, mis seda veebiteenust realiseerib. Programm sisaldab omakorda funktsioone, mis tüüpiliselt teevad kontrolle, andmebaasipäringuid ja vormistavad tulemusi.

Veebiteenus on analoogiline tavaprogrammeerimise funktsioonile, lihtsalt teda kutsutakse välja üle http protokolli ning andmed on esitatud xml kujul.

Ahel veebiteenus-funktsioon-andmebaas on semantika mõttes oluline, kuna veebiteenuse parameetrite ja tulemuse sisuline tähendus on otseselt seotud teda realiseeriva andmebaasipäringu andmete sisulise tähendusega andmebaasis.

Veebiteenuste parameetrite ja tulemuste tähenduse kirjeldamist oleks perspektiivis mõttekas teha sünkroonis andmebaasiskeemi väljade tähenduse kirjeldamisega.

Sestap tuleb eeldada, et SEHKE eesmärk hõlbustada veebiteenuste kirjeldamist peab olema võetud laiemalt, lisaeesmärgina hõlbustada andmebaasiskeemide väljade ja teenust realiseerivate funktsioonide parameetrite/tulemuste tähenduse kirjeldamist.

Tava-andmetüübid kui mitte-semantilised kirjeldused

Ahela veebiteenus-funktsioon-andmebaas kõigi osade parameetritel/tulemustel/väljadel on reeglina juba tüübid olemas: string, täisarv, ujukomaarv, struktuur etteantud väljadest, massiiv lihtsamatest tüüpidest vms. Vale tüüpi argumendi andmisel annab funktsioon või veebiteenus reeglina vea.

Võtame näitena funktsiooni, mis saab argumendiks isikukoodi ja annab tulemuseks aadressi (või selle puudumisel tühja stringi). Tavaprogrammeerimisel näeks funktsiooni prototüüp välja näiteks nii:

String aadress(integer ik);

mis ütleb, et sisendparameeter ik on lihtsalt integer (täisarv) ning funktsiooni vastus on string (tekst). Mingeid täiendavaid piiranguid või selgitusi need andmetüübid endas ei kanna.

Veebiteenuste wsdl-kirjeldused on analoogilised funktsiooni prototüübiga, sisaldades muuhulgas samuti parameetrite ja tulemuste andmetüüpe. Üks osa WSDL-failist loetleb WSDL-failis kirjeldatud operatsioonide tüüpe, andes neile nimed (allpool “ik” ja “aadress”) ning kirjeldades iga tüüpi. Äsjase näite jaoks sobiks tüüpide osaks näiteks järgmine, mis kirjeldab tüübid nimedega “ik” ja “aadress”, mida omakorda hiljem kasutatakse sisendparameetri ja tulemuse kirjeldamiseks:

<wsdl:types>
  <xs:element name="ik" type="xs:integer"></xs:element>
   <xs:element name="aadress" type="xs:string"></xs:element>
</wsdl:types>

Andmetüüpidel võivad olla piirangud ja alamtüübid, näiteks:

• xml schema xs:positiveInteger tüüp ütleb, et tegemist peab olema positiivse täisarvuga
• xml schema xs:int ütleb, et tegu on positiivse või negatiivse 32-bitise täisarvuga

Oluline tähelepanek tava-andmetüüpide kohta: andmetüübid ei kirjelda parameetrite ja tulemuste sisulist tähendust. Eeltoodud funktsiooni tüübid “integer” ja “string” ei ütle, et sisendargument on nimelt isikukood ja väljundstring on nimelt aadress.

Tava-andmetüüpide põhimõtted ei võimaldata taolist tähendus-informatsiooni reaalselt kodeerida ja esitada.

Semantilised annotatsioonid ehk tähenduse kirjeldamine

Nagu varasemas selgitatud, tuleks semantilise annotatsioone käsitleda kui tava-tüübisüsteemile täiendavat tüübisüsteemi. Igal teenuse/funktsiooni parameetril/tulemusel ja andmebaasiväljal oleks lisaks tava-andmetüübile ka tema sisulist tähendust kirjeldav annotatsioon.

Parameetri ehk andmevälja semantiline annotatsioon näeb välja kui harilik andmetüüp: tegu on lihtsalt mingi sõnaga, mis iseenesest ei pea selgelt nähtavat tähendust kandma.

Eelmine WSDL-näide võiks semantiliselt annoteerituna välja näha niimoodi:

<wsdl:types>
  <xs:element name="ik" type="xs:integer" sawsdl:modelReference="”isikukood"”>
  </xs:element>
   <xs:element name="aadress" type="xs:string" sawsdl:modelReference="aadress”">
   </xs:element>
</wsdl:types>

kus atribuudi sawsdl:modelReference väärtus ongi sõna, mis kirjeldab antud parameetri tähenduse sisu.

Konkreetselt sawsdl:modelReference on atribuudiks seepärast, et SEHKE projektis kasutame WSDL annoteerimiseks nimelt sawsdl keelt, kus lihtsalt eeldatakse, et semantilised annotatsioonid antakse nimetatud parameetriga.

Reaalselt ei kasutata WSDL annotatsioonides (ja enamuses teistes semantilistes annotatsioonides) siiski mitte lihtsalt sõnu nagu “isikukood” ja “aadress”, vaid pikemaid, URL-i kujul nimeruumiga varustatud unikaalseid sõnu-idenftikaatoreid nagu “http://www.sehke.ee/isikukood” ja “http://www.sehke.ee/aadress”.

<wsdl:types>
  <xs:element name="ik"  type="xs:integer"      
        sawsdl:modelReference="http://www.sehke.ee/isikukood"”>
   </xs:element>
   <xs:element name="aadress"  type="xs:string"      
        sawsdl:modelReference="http://www.sehke.ee/aadress”">          
   </xs:element>
</wsdl:types>

Taoliste annotatsioonide lisamine objekidele tähendab, et me ütleme, et nimetatud objekt on vastavat tüüpi asi. Iseneesest ei anna see teadmine mitte midagi kasulikku ei arendajale ega tarkvarale: kasu tekib juhul, kui:

• Kirjeldava sõna kohta on lihtsalt võimalik leida inimloetavaid selgitusi tema tähenduse kohta.
• Kirjeldav sõna on reeglitega seotud teiste sõnadega, mis võimaldab tarkvaral automaatselt järeldada uusi fakte kirjeldatud objekti kohta.

Tasub tähele panna, et peale veebiteenuse/funktsiooni parameetrite ja tulemuse on põhimõtteliselt võimalik kirjeldada ka teenust/funktsiooni ennast, st, mida ja kuidas ta tegelikult rehkendab. Taolist kirjeldust on küll tihtipeale raskem anda, kui sisendargumentide/tulemuste tähendusi.

Semantikakeeled Rdf, Rdfs, OWL ja semantic mediawiki

Eelnevas rõhutasime, et formaalset tähendust kannavad sõnadevahelised reeglid, ning nende arvutiga töötlemiseks/kasutamiseks

• peavad reeglid olema konkreetses, arvutiga töödeldavas keeles
• arvutiprogramm peab sisaldama/kasutama neid reegleid rakendada oskavad järeldus- või päringumootorit.

Formaalsed reeglikeeled erinevad üksteisest nii:

• sisuliselt: klassikaline/intuitsionistlik/modaalne predikaatarvutus, default loogika jne jne
• kui süntaksi mõttes: iga keele jaoks on kasutusel palju erinevaid süntakseid (erinevad prefiks-, infiks-, xml süntaksid jne jne)

Semantilise veebi sfääris on põhilisteks keelteks hetkel järgmised kolm hierarhiliselt üksteist sisaldavat keelt: RDF, RDFS ja OWL. RDFS on RDF-i pealisehitus ning OWL on omakorda RDFSi pealisehitus.

RDF

Ametliku RDF õpetuse leiab lehelt http://www.w3.org/TR/rdf-primer/. Sisuliselt on tegemist puhtalt andmete esitamise keelega analoogiliselt SQLi skeemile, mingeid reegleid RDF keeles esitada ei saa.

RDF keele idee on esitada andmeid võimalikult lihtsate (ja seega üldiste põhimõtete) järgi: kõik andmed esitatakse ühes kolme välja tabelis. Väljad on:

• Subjekt: selle asja id, mida kirjeldatakse. (SQL-s vastab tabeli id-väljale)
• Predikaat: omadus ehk välja nimi (SQL-s vastab tabel/väljanimi kombinatsioonile)
• Objekt: omaduse ehk välja väärtus (SQL-s vastab välja sisule).

Näiteks:

Subjekt	Predikaat	Objekt
http://www.isik.ee/12	nimi	Jaan
http://www.isik.ee/12	isikukood	36504120211
http://www.isik.ee/12	telefon	+3724432323
http://www.isik.ee/13	nimi	Mihkel

Objekt ehk omaduse väärtus peab lisaks sisaldama informatsiooni väärtuse tüübi kohta: string, integer, URI (globaalselt unikaalne ID) vms. Ühel predikaadil ehk omadusel võivad olla väga erinevat tüüpi väärtused. Ühel subjektil ehk id-l võib olla palju sama predikaadi ehk omaduse väärtusi. Olulise kitsendusena võivad nii subjekt kui predikaat olla ainult globaalselt unikaalsed ID-d (URI-d, mida enamasti esitatatakse URL-dena, nagu http://www.sehke.ee/isikukood). Objekt ehk omaduse väärtus võib olla nii harilik andmetüüp kui ka URI.

RDFi jaoks eksisteerib hulk erinevaid süntakseid. RDF-i XML süntaksi näide, kus kirjeldatakse subjekti id-ga http://www.w3.org/People/EM/contact#me, esitades tema omaduste type, fullName, mailbox, personalTitle väärtusi Person, Eric Miller, mailto:em@w3.org, Dr.

  <contact:Person rdf:about="http://www.w3.org/People/EM/contact#me">
    <contact:fullName>Eric Miller</contact:fullName>
    <contact:mailbox rdf:resource="mailto:em@w3.org"/>
    <contact:personalTitle>Dr.</contact:personalTitle> 
  </contact:Person>

 

Näites pidevalt korduv contact: tekstijupp on mõistete nimeruumi lühend. Nimeruumid defineeritakse tüüpiliselt RDF faili päises, vastavalt XML-I nimeruumide põhimõtetele.

RDFS

Ametlik RDF-i õpetus lehel http://www.w3.org/TR/rdf-primer/ sisaldab – teises pooles – ka RDFS-I õpetust. RDFS on RDF-I laiendav lihtne reeglikeel. RDFS võimalda öelda ainult järgmisi lihtsaid reegleid:

• Subjekt on mingit klassi. Klassi mõiste on RDFsi sisse ehitatud: rdfs:Class. Klassid on näiteks isik, auto jne.
• Klass on mingi teise klassi alamklass. Alamklassi mõiste on RDFSi sisse ehitatud:

rdfs:subClassOf . Seejuures sisaldab RDFS automaatselt tüüpide taksononoomia ehk hierarhia reeglit:

• • kui X on klassis T, ja klass T on omakorda klassi R alamklass, siis X on samuti klassis R.
• Subjekt on ise omadus (mitte klass). Omadused on näiteks nimi, vanus jne. Omaduse mõiste on juba RDF-I sisse ehitatud: rdf:Property.
• Omadus on mingi teise omaduse alamomadus. Alamomaduse mõiste on RDFSi sisse ehitatud: rdfs:subPropertyOf. Seejuures sisaldab RDFS automaatselt omaduse taksononoomia ehk hierarhia reeglit:
  • kui X-l on omadus T, ja omadus T on omakorda omaduse R alamomadus, siis Xl on samuti omadus R.
• Kui subjektil on omadus P, siis subjekt on klassis T.
• Kui objekt on mingi omaduse P väärtuseks, siis objekt on klassis T

Selleks, et öelda, et mingi sõna on kasutatav klassina, tuleb salvestada kolmik, kus objektiks on sisseehitatud erisõna rdfs:Class

Näiteks:

• ex:fyysiline_isik rdf:type rdfs:Class

Arusaadavalt ei ole mõttekas öelda näiteks konkreetsete isikute kohta, et nad on klassid. Samas, kui mingi sõna tüübiks on antud klass, siis see ei kitsenda tema kasutamist mitte kuidagi. Ka klassi tüüpi sõnadel võivad olla antud mistahes omadused.

Selleks, et öelda, et klass on teise klassi alamlass, tuleb salvestada kolmik, kus predikaadiks on sisseehitatud erisõna rdfs: subClassOf

Näiteks:

• ex:fyysiline_isik rdfs:subClassOf ex:isik

Selleks, et öelda, et subjekt on omadus, tuleb salvestada kolmik, kus objektiks on sisseehitatud erisõna rdf:property, näiteks:

• ex:nimi rdf:type rdf:property

Selleks, et öelda, et subjekt on omadus, mis on teise omaduse alamomadus, tuleb salvestada kolmik, kus predikaadiks on sisseehitatud erisõna rdfs:subPropertyOf, näiteks:

• ex:eesnimi rdfs:subPropertyOf rdf:nimi

Selleks, et öelda, et mingi predikaadi subjekt on alati teatud klassi, tuleb salvestada kolmik, kus predikaadiks on sisseehitatud erisõna rdfs:domain, näiteks:

• ex:author rdfs:domain ex:Book

Selleks, et öelda, et mingi predikaadi objekt on alati teatud klassi, tuleb salvestada kolmik, kus predikaadiks on sisseehitatud erisõna rdfs:range, näiteks:

• ex:author rdfs:range ex:isik

OWL

Ametliku kokkuvõtva OWL-I õpetuse leiab lehelt http://www.w3.org/TR/owl-guide/. Koondi OWL-I sissehitatud erimõistetest leiab lehelt http://www.w3.org/TR/owl-features/. Hoiatus: erinevalt varemviidatud RDF(S)I õpetusest ei ole nimetatud tekstid kuigi mugavad lugeda. OWL on RDFS-i laiendus, kus on võimalik väljendada mistahes reegleid. OWL on mittelahenduv ja sama väljendusvõimsusega kui esimest järku predikaatarvutus.

Seejuures näeb OWL-i süntaks välja oluliselt teistsugune, kui traditsiooniline esimest järku predikaatarvutus. OWL-i reeglid esitatakse enamasti XML süntaksis, kuid neid reegleid saan soovi korral esitada, nagu ka RDFS reegleid, RDF-i kolmikute komplektina, kasutades hulka sisseehitatud erisõnu.

Traditsioonilisi loogikatehteid, kvantoreid jne OWL-s eksplitsiitselt ei kasutata: nad on sisuliselt peidetud sisseehitatud (analoogiliste) erisõnade tähenduse definitsioonidesse.

OWL on jaotatud omakorda mitmeks alamtasemeks, kus alamtasemed on väiksema väljendusvõimsusega, kui esimest järku predikaatarvutus. Piiratud alamtasemete mõte on selles, et võimaldada lahenduvust ja järelduste tegemist kiiremini, kui täielikus OWL-s.

Toome W3C materjalide seast OWL keeles esitatud reeglite näite, mis ütleb meile tavamõttes, et

• vein on joodavate vedelike alamklass (seda saaks esitada ka rdfs keeles)
• vein on tehtud viinamarjadest
• veinil on alati mingi asukoht/piirkond

 
<owl:Class rdf:ID="Wine"> 
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> 
  <rdfs:subClassOf>
    <owl:Restriction> 
      <owl:onProperty rdf:resource="#madeFromGrape"/>
      <owl:minCardinality 
        rdf:datatype="&xsd;NonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction> 
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#locatedIn"/> 
      <owl:minCardinality 
        rdf:datatype="&xsd;NonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

Andmete esitamine puhtas mediawikis

Harilik (mittesemantiline) mediawiki on mõeldud sõnadele inimkeelse, tavatähendusliku semantika andmiseks: igale sõnale vastab selle sõna URL-lt avatav inimloetav artikkel. Mediawiki pakub mugavaid võimalusi artiklite redigeerimiseks, nende versioonihalduseks jne. Mingeid formaalseid semantikavahendeid mediawiki ei paku.

Samas ei keela mediawiki kasutaja soovil mingi erikeele tarvitamist programmiliselt töödeldavate andmete esitamiseks mediawiki artiklites. Kui selliselt talitada, siis mediawiki ise mingit erituge nende andmete töötlemiseks või esitamiseks ei anna, küll aga saaksid seda teha välised programmid ja/või mediawikile spetsiaalselt loodud täiendused.

Andmete esitamine semantic mediawikis

Semantic mediawiki on hariliku mediawiki laiendus, mis on eeskätt mõeldud nimelt selleks, et

• pakkuda kasutajatele lihtne ja mugav erikeel programmiliselt töödeldavate andmete hoidmiseks mediawikis.
• pakkuda kasutajale mediawikis kasutatav eri-päringukeel andmete otsinguks ja tulemuste formattimiseks mediawiki lehtedel.

Semantic mediawiki põhi-funktsionaalsus on järgmise süntaksi ja selliselt esitatud andmete programmilise töötlemise pakkumine:

Selles artiklis kirjeldatud isiku nimi on [[nimi::Jaan]] ja tema telefon on [[telefon::6204432]].

Taoliselt esitatud andmed salvestatakse RDF põhimõtete järgi, kus kirjeldatava subjekti id on lehe url, kus artikkel on. Kui ülaltoodud tekst on lehel http://www.sehke.ee/jaantamm siis oleks teksti RDF-tähenduseks kaks kolmikut:

• http://www.sehke.ee/jaantamm nimi Jaan
• http://www.sehke.ee/jaantamm telefon 6204432

Tasub tähele panna, et süntaks on valitud äärmiselt sarnane harilikule mediawiki süntaksile, millega esitatakse linke mediawiki enda lehtedele (näiteks lehtedele isik ja telefon)

Selles artiklis kirjeldatud [[isik|isiku]] nimi on Jaan ja tema [[telefon]] on 6204432.

Semantic mediawiki pakub kasutajale lisaks RDFS-le klasside süsteemi realisatsiooni traditsioonilise mediawiki Category mõiste kaudu.

Kui lisada konkreetse isiku lehele tekst [[Category:isik]], siis salvestatakse see info automaatselt kui RDFS-I mõttes lehe klass:

• http://www.sehke.ee/jaantamm rdf:type Category:isik

Kui lisada kategooria-tüüpi lehele (näiteks Category:fyysiline_isik) tekst [[Category:isik]], siis salvestatakse see info automaatselt kui RDFS-I mõttes lehe alamklass:

• http://www.sehke.ee/Category:fyysiline_isik rdfs:subclassOf Category:isik

Seda subclassOf omadust kasutab semantic mediawiki edaspidi vaikimisi koos RDFSi taksonoomiareegliga kõigis päringutes ja kuvamistes. Muuhulgas kuvatakse iga kategooria tüüpi lehe lõppu kõigi tema alamkategooriate tähestikuline loetelu.

Kategooria-lehtede pealkirjad algavad mediawikis alati sõnaga Category:, näiteks Category:isik. Analoogiliselt võimaldab semantic mediawiki esitada alamomadusi (rdfs:subPropertyOf), ning neid alamomadusi kasutab semantic mediawiki samamoodi koos taksonoomiareegliga kõigis pärimistes ja kuvamistes.

Keerukamaid reegleid, sh OWL-I reegleid, semantic mediawiki ei mõista ega päringutes/kuvamistes ei kasuta. Samas ei keela miski sisestamast semantic mediawikisse kuitahes keerulisi OWL-I reegleid, kasutatades selleks kas oma valitud markereid ja xml süntaksit või sama semantic mediawiki süntaksit, kus OWL-I reeglid esitatakse kui RDF-I kolmikute komplektid, mida saab semantic mediawikis edukalt teha (see ongi semantic mediawiki põhifunktsionaalsus).

OWL-I tüüpi reeglite kirjutamisel semantic mediawiki lehtedele tuleb lihtsalt arvestada, et semantic mediawiki enda päringu- ja kuvamismehhanismid neid reegleid ei mõista ega kasuta. Reeglite lisamise mõte oleks eeskätt selles, et võimaldada mediawikist eksporditud lehti töödelda välistel süsteemidel, mis suudaksid nimetatud reegleid kasutada. Reeglid ise on semantic mediawiki jaoks kas suvalised xml tesktijupid või rdf stiilis andmed, seega neid eksporditakse/imporditakse samadel alustel, kui mistahes muid tekstijuppe/andmeid.

Väga olulise funktsionaalsusena pakub semantic mediawiki päringute tegemist ja dünaamiliste päringute paigutamist otse mediawiki lehtedele, koos küllalt paindlike võimalustega päringutulemusi kuvada. Näide päringust, mille võib panna mistahes lehele ja mis annab tulemuseks vaikimisi formaadis loeteluna kõik lehed, mille tüüp on ‘isik’:

{{#ask: [[type::isik]]}}

SEHKE mõistete esitamine mediawikis, tähendus Rdfs/OWL mõttes

Küsimus: kategoorialehed või harilikud lehed

Eelkirjeldatud ülesanded ja võimalused toovad meid küsimuse juurde, kuidas konkreetselt semantic mediawikis esitada SEHKES vajaminevaid mõisteid.

Eeskätt on SEHKE mõisted vajalikud veebiteenuste ja funktsioonide parameetrite/tulemuste ja andmebaasiväljade semantika kirjeldamiseks, mitte aga konkreetsete objektide kohta käiva informatsiooni salvestamiseks.

Seega ei ole semantic mediawiki standardnäited nagu konkreetsete linnade rahvaarvu salvestamine/otsimine jne sobivad SEHKE näideteks.

SEHKE mõisted on eeskätt klassid, teatud juhtudel ka omadused. Varemtoodud näidetes esitatud “fyysiline_isik” ja “isik” on kahtlemata klassid.

Klasside esitamiseks soovitati semantic mediawiki esimestes versioonides kasutada Category: prefiksiga lehti. Neile lehtedele genereeritakse automaatselt kõik antud klassi alamklassid tähestiku järjekorras.

Samas on Category: prefiksiga lehtede kasutamisele mitu vastuväidet:

• Uuemad semantic mediawiki variandid pakuvad Category: prefiksiga lehtedele mitu (osalist) alternatiivi ja toovad väljad mõned tehnilised probleemid Category: prefiksiga lehtede puhul.
• Category: prefiksiga lehtedel on põhipealkirjas alati Category: (eestikeelses versioonis Kategooria:), samuti tuleb neid igale poole alati kirjutada prefiksiga Category: (ka eestikeelses versioonis Category:), mis on kasutuse mõttes häiriv: kõik SEHKE mõisted oleks igalpool pealkirjadesprefiksiga Kategooria: ja teksti sees Category:
• Kategoorialehtede allosas automaatselt esitatav alamkategooriate tähestikloetelu ei ole kergesti formateeritav/ümberkujundatav.

Eeltoodust lähtuvalt soovitame kasutada harilike SEHKE mõistete esitamiseks harilikke mediawiki lehti, mitte Category: prefiksiga lehti. See valik toob kaasa kaks kaotust, millest kumbki on kompenseeritav:

• Lehtede alläärtesse ei ilmu automaatselt nende alamklasside loetelu. Selle asemel saab lehtedele paigutada dünaamilise otsingu, mis esitab alamklasse isegi sobivamal kujul.
• Semantic mediawiki oma päringud ei saa enam kasutada subclassOf seoste hierarhiat. Selle asemel:
  • Päringutesse on võimalik sisse kirjutada piiratud sügavusega hierarhiakasutus: näiteks, öelda päringus, et vaata klassi otseseid ülemklasse ja nende ülemklasside otseseid ülemklasse (sel juhul siis kaks taset). Samamoodi saab teha päringuid kolme, nelja jne taseme jaoks. Ei saa teha päringuid piiramatu arvu tasemete jaoks.
  • Arvestame, et SEHKE eesmärgid ei vaja semantic mediawiki enda lehtedele keerukate päringute paigutamist, kus nimetatud hierarhia-kasutust vaja oleks. Keerukaid päringuid ja järeldusi teevad süsteemi arhitektuuri järgi hoopis välised süsteemid, kasutades semantic mediawikist eksporditud andmeid.

Nimeruumid ja prefiksid

Mis on wikis olevate mõistete nimeruumiks?

• Mõiste nimeruumiks on tema SEHKE URL-I algus. Näiteks lehel mediawiki viidaga [[Isik]] võib olla URL kujul URI http://www.sehke.ee/Isik kus nimeruumiks on http://www.sehke.ee. Mediawiki enda seest ei viidata lehtedele koos mediawiki nimeruumiga, vaid hariliku siseviidana, näiteks [[Pank:Isik]].

Nimeruumi esitamise/kodeerimise konkreetseks viisiks on http://www.w3.org/TR/swbp-vocab-pub/#recipe5 lehel toodud retsept nr 5. Selle retsepti järgi ei kasutata nimeruumi ja mõiste vahel trelle # vaid slashi /. Näide:

• Soovitav esitus: http://www.sehke.ee/nimeruum/Isik
• Mittesoovitav esitus: http://www.sehke.ee/nimeruum#Isik

• Kui mingi mõiste on juba kasutuses ning tekib soov esitada sama mõiste hoopis teises tähenduses, tuleb SEHKES lisada uue mõiste nimele valdkonna või ontoloogia lühinimi, näiteks “Meditsiin” mille järel on koolon. Kui oletada, et mõistel “isik” on meditsiinis hoopis teine tähendus, kui muudes valdkondades, siis oleks meditsiini-eri-isiku mõiste nimi SEHKES “[[Meditsiin:isik]]”. http://www.sehke.ee/Meditsiin:isik

Mõistete valdkondade ja ontoloogiate vahel jaotamist kirjeldatakse järgmises alampeatükis.

• Selliste lühi-nimekujude jaoks luuakse omaette leht, mille omaduste hulgas oleks antud nimeruum kui omaduse väärtus. Näiteks Meditsiini-valdkonna või ontoloogia lehel peab olema toodud info [[nimeruum::http://www.sehke.ee/Meditsiin]]

• Luuakse ülevaateleht ‘Nimeruumid’, millel esitatakse päringuga kõik eelmise punkti ja järgnevas esitatud punktide alusel toodud lühi-nimeruumid.

Küsimus erimõistete prefiksitest: kui kasutada näiteks rdf nimeruumi mõistet “type” ja rdfs nimeruumi mõistet “subclassOf”, siis kas esitada nad nimeruumiga ja kui, siis kuidas?

Arvestada tuleb jällegi, et mediawikis esitatavad mõisted on kõik automaatselt sellesama mediawiki installatsiooni nimeruumiga (näiteks http:/www.sehke.ee) , kuid seda automaatset nimeruumi ei kirjutata ega esitata wiki tekstis (kirjutatakse/kuvatakse lihtsalt ‘isik’, mitte ‘http:/www.sehke.ee/isik’)

Soovitame järgmist:

• Esitada rdf ja rdfs sisseehitatud mõisted kui kõige harilikumad ilma spetsiaalse nimeruumita mõisted: ekspordi ja kasutuse mõttes eeldame, et mõistetel type, subclassOf jms on vaikimisi rdf ja rdfs nimeruumid. Selleks tuleb ekspordis/impordis teha vastavad teisendused.
• Muude nimeruumide puhul kasutada mõiste prefiksina nimeruumi lühikuju (näiteks xsd, owl) mille järel oleks koolon (näiteks xsd:integer, owl:intesectionOf). See tähendab, et
  • vastava mõiste nimeruum koosneb justkui automaatsest nimeruumist (näiteks http:/www.sehke.ee) pluss lisa-nimeruumist nagu owl:
  • semantika kasutuse ja import-ekspordi mõttes tehakse nimeruumi teisendus:
    • http:/www.sehke.ee/owl:intesectionOf asemele pannakse http://www.w3.org/2002/07/owl# intesectionOf
• Nagu eelnevalt kirjutatud, luuakse selliste lühi-nimekujude jaoks luuakse omaette leht, mille omaduste hulgas oleks antud nimeruum kui omaduse väärtus. Näiteks owl jaoks luuakse leht owl, ning tuua lehel muuhulgas info [[nimeruum::http://www. http://www.w3.org/2002/07/owl#]]. Samuti luuakse ülevaateleht nimeruumid, millel esitatakse päringuga kõik eelmisel lehel toodud lühi-nimeruumid.

Valdkonnad ja ontoloogiad

Järgmised üldküsimused puudutavad mõistete kategoriseerimist: lehe valdkonna ja ontoloogia esitamist ning nimeruume

• Lehe valdkonna all mõistame organisatoorset või sisulist hulka lehti, millesse antud leht kuulub. Valdkonnad on näiteks avalik haldus, majandus, kultuur jne. Iga valdkond on niisiis lihtsalt hulk lehtedest, mis sinna valdkonda kuuluvad. Üks leht võib kuuluda mitmesse valdkonda. Valdkonda esitab SEHKES harilik sehke mõiste, kuhu kergema loetavuse eesmärgil on lisatud kooloniga prefiks Valdkond: (näiteks “Valdkond:Majadus”, “Valdkond:Kultuur”), mis on lihtsalt toodud hulga lehtede valdkonna-omaduse väärtuseks ja millel on omakorda type valdkond.

• Lehe ontoloogia all mõistame analoogiliselt valdkonnaga jällegi lihtsalt hulka lehti/reegleid, millesse antud leht kuulub. Ontoloogia on enamasti kellegi isiku või organisatsiooni poolt loodud. Ontoloogiad võivad olla loodud SEHKEST väljapool. Jällegi, üks leht võib kuuluda mitmesse ontoloogiasse. Ontoloogiat esitab SEHKES harilik sehke mõiste, kuhu kergema loetavuse mõttes on lisatud kooloniga prefiks Ontoloogia: (näiteks “Ontoloogia:FOAF”), mis on lihtsalt toodud hulga lehtede ontoloogia-omaduse väärtuseks ja millel on omakorda type ontoloogia.

Klassifikaatorid

Klassifikaatorite moodustamine toimub analoogiliselt ontoloogiate ja valdkondade moodustamisega: osad mõisted deklareeritakse klassifikaatoriks ning nende ees kasutatakse sisemist kooloniga nimeruumi Klassifikaator: (näiteks Klassifikaator:sugu). Klassifikaator jaotatakse versioonideks. Mõisted, mis on omakorda selle klassifikaatori-versiooni mõiste tüüpi (näiteks sisaldavad lehel teksti [[type::Klassifikaator:sugu_v1]] on klassifikaatori elemendid.

Klassifikaatorite süsteemi kirjeldav klassihierarhia oleks järgmine:

Klassifikaator (ik: Classification) on klass, mida kasutatakse üldmõistena klassifikatsioonisüsteemi grupeerimiseks ja nimetamiseks. Analoogiline ontoloogiale. Võib olla lineaarne ühetasemeline nimekiri või hierarhiline taksonoomia. Klassifikaatori omadused: nimi, lühendnimi, kirjeldus, valdkond (see ei pruugi üks-ühele kokkulangeda Sehke enda valdkondadega? mõned Statistikaameti näited: geograafia, tervishoid, ametid, majandus, transport, tooted/teenused, tegevusalad,...), haldaja (organisatsioon), kontaktisik(ud), kehtestamisaeg, kehtivus, õiguslik alus (viide seadusele või standardile), seosed teiste klassifikaatoritega (asendab, seotud...), struktuur (lubatud hierarhia tasemed ja nende nimed), seosed ontoloogia mõistete, andmebaasi ja veebiteenuste kirjeldustega?

Iga SEHKE leht tüübiga Klassifikaator peab sisaldama ask: päringut, mis näitab nimekirja klassifikaatori versioonidest (viimaste type:'Klassifikaatori versioon'). Kehtiv versioon peaks olema eristatav. Klassifikaatorid võivad praktilises elus grupeeruda ka nn perekondadeks e klassifikaatorite gruppideks. Teatud juhtudel võib klassifikaator sisaldada alamklassifikaatoreid, kuid esialgu me seda funktsionaalsust ette ei näe.

Klassifikaatori versioon (ik: Classification Version) on klass, mida kasutatakse konkreetse klassifikaatori versioonina, millel on kindel kehtestamisaeg ja kehtivus. Nimi on enamasti kombineeritud Klassifikatori nimest ja versiooni nimest või numbrist (see on ilmselt mõistlik ja vajalik, et tagada unikaalne nimi wiki klassifikaatori nimeruumis). Kasutusel võivad olla ka klassifiaatori variandid, mis on ühe versiooni korraga kehtivad (erinevaks otstarbeks) variandid . Klassifikaatori versiooni ülemklass on klassifikaator.

Iga SEHKE leht tüübiga 'Klassifikaatori versioon' sisaldab ask: päringut, mis näitab nimekirja alamklassidest (type:'Klassifikaatori element'). 'Klassifikaatori elemendid' võivad moodustada muutuva sügavusega hierarhiaid, mille hierarhiline esitus tuleb ette näha (vähemalt 5-tasemelise hierarhia leiab klassifikaatorist EHAK).

Klassifikaatori element (ik: Classification Item) on klassifikaatori versiooni liige ehk element, mis võib olla ka nimeline hierarhia tase. Klassifikaatori elemendil on unikaalne kood, nimi ja kirjeldus. Klassifikaatori elemendil võib olla oma tüüp ja tüübi kood (näit: EHAK, http://metaweb.stat.ee/view_xml.htm?id=2441119&siteLanguage=ee). Klassifikaatori elemendi ülemklass on klassifikaatori versioon.

Iga klassifikaatori element realiseeritakse wiki lehe abil. Lehe nimi on klassifikaatori elemendi nimi, mitte tema kood. Tuleb lahendada unikaalse nime konstrueerimise küsimus, sest klassifikaatori eri versioonides korduvad harilikult ühed samas nimed ja koodid. Samuti võib üks kood ühes klassifikatsioonis tähendada üht ning teises teist asja.

Igale elemendile oma lehe tegemine võimaldab vajadusel klassifikaatori erinevate versioonide või eri klassifikaatorite elemente omavahel seostada (näit Eesti majanduse tegevusalade (EMTAK) klassifikaatori ja rahvusvahelise NAICS klassifikaatori vastavuse esitamine). Nimi tuleks konstrueerida 'Klassifikaatori versiooni' lühinimest (v numbrist) ning 'Klassifikaatori elemendi' koodist või nimest (näit: "EMTAK 2008:61101" või "EMTAK 2008:Telefoniteenus", http://metaweb.stat.ee/view_xml.htm?id=2254259&selectedRow=2392701&siteLanguage=ee).

Klassifikaatori elemendi lehel tuuakse elemendi kood omadusega "kood", näiteks [[kood::kood_tekstina]].

Seosed klassifikaatori (või klassifikaatori elementide), ontoloogia mõistete ja veebiteenuste vahel oleks lahendatud vastavatel lehtedel defineeritud omaduste (wiki viidete) kaudu.

Näited statistikaameti hallatavatest klassifikaatorist leiab siit: http://metaweb.stat.ee/classificator_publish_list.htm?siteLanguage=ee

PS! ISO11179 ja Unesce Neuchatel on standardid, mis räägivad klassifikatsiooni mudelitest detailsemalt.

(http://standards.iso.org/ittf/PubliclyAvailableStandards/c035345_ISO_IEC_11179-2_2005(E).zip, http://www.unece.org/... )

Mõisted: klassid, omadused, tüübid

Eelnevas soovitasime käsitleda SEHKE mõisteid kui OWL klasse ning esitada neid harilike semantic mediawiki lehtedena, mitte spetsiaalsete Category: prefiksiga lehtedena.

Vaatleme siin peatükis “klassi” ja “omaduse” erinevusi ja suhteid. Traditsioonilises loogikas tehakse enamasti selget vahet erineva hulga argumentidega predikaatide vahel. RDFS ja OWL kontekstis aga sellist vahet ei ole: üks mõiste võib esinede nii ühe- kui kahekohalise predikaadi rollis. Näiteks:

• klass on harilikus loogikas ühekohaline predikaat. Klasside abil saab näiteks ehitada taksonoomiat, kasutades reegleid nagu:

• iga X jaoks kehtib: fyysiline_isik(X) => isik(X).

owl-I mõttes on klass eeskätt subjektide kategoriseerimise vahend.

Vaatame näitena mõistet “isa”. Ütlemaks, et mingi objekt on isa klassist, tuleb esitada järgmine rdfs kolmik:

• ex: keegi_isik rdf:type ex:isa

Klassikalises predikaatloogikas näeks “isa” klassi kasutus välja nii:

• holds(type,ex:keegi_isik,ex:isa)

• omadus on harilikus loogikas kahe- või enamakohaline predikaat. Näide lihtsast reeglist:

• Iga X jaoks kehtib: omabisikukoodi(X,Y) => fyysiline_isik(X).

owl-i mõttes on omadus eeskätt subjektidele konkreetsete väärtuste andmise vahend, mis vastab kahekohalistele predikaatidele ja andmebaaside tabel/väli paaridele.

Ütlemaks, et mingi objekt on teise objekti isa, tuleb esitada järgmine rdfs kolmik:

• ex: isik1 ex:isa ex: isik2

Klassikalises predikaatloogikas näeks “isa” omaduse kasutus välja nii:

• holds(ex:isa,ex:isik1,ex:isik2)

Muuhulgas oleks klassikalises loogikas mõtestatud näiteks järgmine reegel:

• forall X exists Y. holds(ex:isa,X,Y) => holds(type,X,ex:isa).

Semantic mediawiki süntaks [[isikukood::3611212121]] ütleb konkreetselt, et antud lehel on omadus isikukood väärtusega 3611212121.

Samas on võimalik kasutada omadust “isikukood” ka ühekohalise predikaadi ehk klassina, mispuhul ta väljendab asjaolu, et tema argumendiks olev tekst on nimelt isikukood.

SEHKE kontekstis on mõisted eeskätt klassid (näiteks “inimene”, “juriidiline isik” jne), kuid osa klasse on sama-aegselt ka omadused. Näitena võtame mõisted

• “isikukood” , mis on reeglina osade isikute omadus, mille väärtuseks on 11-kohaline numbritest tekst.
• “sugu”, mida saab kasutada omadusena, millel on eeldatavalt kaks võimalikku väärtust: mees ja naine.

OWL keel lubab kasutada sama mõistet nii klassi kui omadusena, seda ei luba aga OWL keele alamhulk OWL-DL. Muuhulgas lubab Protege kasutada sama mõiste-teksti nii klassi kui omadusena, kuid hoiatab samal ajal, et peab neid kaheks erinevaks objektiks.

Lähtume põhimõttest, et mõiste on vaikimisi ehk üldjuhul klass. Kui mõiste on omadus, siis on kasutajal kaks erinevat lubatud varianti tema esitamiseks:

• Kasutada mõistet spetsiaalse sise-nimeruumiga Omadus, näiteks "Omadus:sugu". Kui mõistet on vaja samal ajal esitada valdkonda kuulumise sise-nimeruumiga, siis kasutame ahelat "Valdkond:Omadus:sugu". Sel juhul (st kui nime osaks on "Omadus:") eksporditakse mõiste omadusena.
• Kasutada mõistet n.ö. harilikul viisil, ilma "Omadus:" sise-nimeruumita. Sel juhul eeldatakse, et mõiste on samas ka klass ning omaduse jaoks on lehel vaja näidata, et tegu on (muuhulgas) omadusega, ning mõiste tuleb eksportida kahel eri viisil: klassi ja omadusena.

Owl/rdf eksporditavas tekstis peaks kõigi klasside (lehekülgede) omadused (Data Property või Object Property) olema esitatud kas Object Property-na (kui on vaja et omaduse väärtused on seotud mingi klassiga):

    <owl:ObjectProperty rdf:about="#Isikukood">
        <rdfs:comment>see on omadus isikukood</rdfs:comment>
        <rdfs:domain rdf:resource="#Eraisik"/>
    </owl:ObjectProperty>

või Data Property-na (kui omaduse väärtused on lõplikud väärtused):

    <owl:DatatypeProperty rdf:about="#Isikukood">
        <rdfs:comment>See on omadus (Data Property)  Isikukood</rdfs:comment>
        <owl:dataPropertyDomain rdf:resource="#Eraisik"/>
    </owl:DatatypeProperty>

Semantic mediawiki võimaldab omaduste väärtuste puhul anda (teatud piiratud valikust, nagu String, Number, Page) nende tüüpe. Näiteks, kui lehel on toodud informatsioon

[[population::3,396,990]]

Ja population lehel (mõiste, mis on omadus) on tüübiks number, siis 3,396,990 ei esitata lehena.

Kuna SEHKE eesmärk ei ole mitte tava-andmete esitamine, vaid eeskätt semantiliste mõistete ehk klasside kirjeldamine, ei ole esialgu näha vajadust selliste tüübikirjelduste järel. SEHKE kontekstis eeldame, et omaduste väärtused ise on jällegi klassid, neil on omad lehed ja lehtedel on nende klasside kirjeldused, nii inimloetava tekstina kui masintöödeldavate reeglitena.

Analoogiline olukord on seotud klassifikaatoritega. Näiteks mõistet “sugu” ja väärtusi “mees” ja “ naine” kirjeldab SEHKE tähenduse järgi, mitte kui konkreetseid stringe, mida veebiteenus vastata võib. Teisisõnu, veebiteenus võib näiteks vastata isiku soo päringule alati stringiga “mees” või stringiga “naine”. Asjaolu, et ainult kaks nimetatud vastus-stringi on korrektsed, ei ole SEHKE kirjelduste teemaks: sellise täpsustuse peab andma WSDL-s toodud tava-andmetüübikirjeldus, mida SEHKE-s ei hallata.

SEHKE, vastupidi, peaks esitama informatsiooni, et “sugu” klass on muuhulgas omadus, millel on kaks võimalikku, üksteist välistavat väärtust “mees” ja “naine”.

Selliseks võimalike väärtuste kuvamiseks on semantic mediawikis spetsiaalne omadus “allows value”, mille kasutamine “sugu” lehel näeks välja järgmine:

[[allowsvalue::mees]],[[allowsvalue::naine]]

Selle “allowsvalue” omaduse kasutamist me ei soovita.

OWL-i mõttes vastab selline osundus reeglile, et “sugu” omaduse väärtus peab olema teatud klassist, millel ainult kaks liiget: mõiste mees ja mõiste naine. SEHKE kontekstis soovitame selleks väärtuste klassiks kasutada reeglina sama klassi, mis omadus ise.

Konkreetselt tähendaks see, et: nii “mees” kui “naine” lehel näidatakse, et tegu on “sugu” alamklassiga.

Owli mõttes antakse piirang meie näite jaoks reegliga

<owl:Class rdf:ID="sugu">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="sugu" />
      <owl:allValuesFrom rdf:resource="sugu" />
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>   

Sellise reegli seostamine SEHKE mõistega on otstarbekas väliste süsteemide jaoks, mitte SEHKE siseseselt. SEHKE siseselt piisab eelmainitud süntaksist

[[allows value::mees]],[[allows value::naine]]

(või tema alternatiivist mõne muu omaduse nimega “allows value” asemel). Sehke väliseks reegli lisamiseks soovitame igale klassifikaator-lehel esitada omadus

[[type:klassifikaator]]

koos võimalikke väärtusi esitava päringuga.

Ning selle omaduse leidmisel mõiste juures lisada eksporditavale tekstile automaatselt ülaltoodud owl reegel.

Mõistete identsus ja välised ontoloogiad

Mõistete lisandudes SEHKE-sse võib ilmneda, et kaks mõistet eri valdkondades on sisuliselt identsed. Eeldatavalt on nende mõistete kirjeldused ja seotud reeglid veidi erinevad. Juba defineeritud mõisteid üldjuhul kustutada ei või, sest nad on tõenäoliselt juba kasutusel teiste mõistete definitsioonides või veebiteenuste kirjeldustes.

Sellise olukorra tekkides on kaks alternatiivi:

• Soovitav variant: mediawiki redirect-i kasutamine

Vaja teha kaks sammu:

(a) Valida üks kahest identsest mõistest nö põhimõisteks ja täiendada tema kirjeldust teise mõiste oluliste kirjelduste ja reeglitega (näiteks, kui mõisted on eri valdkondades, siis tuleks põhimõistele lisada info, et ta on ka teises valdkonnas).

(b) Panna teisele (mitte-põhimõiste) mediawiki mõttes suunamine ehk redirect:

: #REDIRECT [[põhimõiste]]

mispeale nimetatud lehele minnes satub kasutaja põhimõiste lehele. Andmete ekspordil eksporditakse ka mitte-põhimõiste lehed.

• Alternatiivne variant: võrduse näitamine lehel eraldi owl:equivalentClass omadusega, ilma redirecti kasutamata.

See variant on mõttekas juhul, kui ei õnnestu valida ühte kahest mõistest põhimõisteks, kuhu teine (teised) mõisted redirectiga viitaks. Variandi miinuseks on asjaolu, et semantic mediawiki sisemised otsimehhanismid ei oska selliselt toodud võrdust kuidagi kasutada. Küll aga saavad seda kasutada välised süsteemid.

Sel juhul tuleb panna mõlemi mõiste lehele owl-keelne informatsioon, et mõiste on identne teise mõistega.

Info näeb välja selline:

[[owl: equivalentClass::teine_mõiste]]

Mõistelehtedele, mis on mõne teisega võrdsed, tuleks paigutada vastav info, esitades võrdsete mõistete loetelu alguse päringuga

{{#ask: [[owl: equivalentClass::{{PAGENAME}}]]}}

Nimetatud päring ei ole seotud ekvivalentsireeglitega, seega ei kuva ta koguhulka võrdsetest mõistetest. Viimase saamiseks tuleb teha kas piisavalt sügav päring või leppida vajadusega klikkida järgmistele võrdsetele mõistetele jõudmiseks eelmiste linkidele.

Väliste ontoloogiate ja väliste mõistete importimiseks ja seostamiseks semantic mediawikis endas kirjeldatud mõistetega (millele vastavad lehed) pakub semantic mediawiki spetsiaalse mehhanismi, vt lehelt http://semantic-mediawiki.org/wiki/Help:Import_vocabulary Näiteks välisest ”foaf” ontoloogiast pärit mõiste “knows” seostamine semantic mediawiki oma mõistega tuleb viimase lehele kirjutada info selliselt:

[[imported from::foaf:knows]]

Sel juhul kasutab semantic mediawiki oma mõiste ekspordil foaf-I vastavat URI.

Peamised andmeesituspõhimõtted SEHKE jaoks

Klassid/mõisted wiki lehtedel

Iga harilik mediawiki leht vastab SEHKES üldjuhul rdfs klassile. SEHKE kontekstis nimetame klasse mõisteteks.

Leht peaks olema pealkirjastatud üldjuhul ilma prefiksita, eestikeelse sõna/fraasiga ainsuse nimetavas käändes, näiteks “Isik” või “Füüsiline isik”: esimene täht suur, ülejäänud väikesed.

Lehe globaalne unikaalne id (URI) on tema konkreetne URL, näiteks http://www.sehke.ee/Isik.

Lehe algusosas peab olema toodud inimlugejale mõeldud mõiste seletus eesti keeles, soovitavalt koos viidetega teistele antud lehega seotud lehtedele, näiteks füüsilise isiku lehel:

• Reaalne inimene. [[Kodakondsus]], [[vanus]] jms võib olla mistahes. Erinev [[juriidiline isik|juriidilisest isikust]]<nowiki>: viimane tähistab ametlikult registreeritud <nowiki>[[organisatsioon|organisatsiooni]].

Järgnevalt peaks leht sisaldama formaalseid seoseid teiste lehtedega, antud semantic mediawiki süntaksis ja eeldatavalt kandes rdf/rdfs/owl keelset tähendust.

Näiteks füüsilise isiku lehel oleks tekst:

• Selle mõiste ülemmõisted on: [[subclassOf::Isik]]

Taoliselt toodud omaduse väärtus on semantic mediawiki jaoks vaikimisi samas wikis olev leht. Äsjases näites on väärtuseks siis mõiste “Isik” leht samas wikis. Üldreeglina peakski mõistete juures olevate omaduste väärtuste jaoks olema lehed loodud.

Lehele on võimalik lisada ka OWLi reegleid, kasutades seejuures sama rdf-tähendusega omadus-väärtus süntaksit, mis äsjastes näidetes. Seejuures saab valida mitme esitusviisi vahel:

• Lihtsamatel juhtudel: esitada OWL reegel lihtsa rdf kolmikuna.

Näiteks, kui soovime lehel “Füüsiline isik” öelda, et füüsiline isik ei ole kunagi juriidiline isik, siis OWL-I teksti

	<owl:Class rdf:ID="Füüsiline isik"> 
	  <owl:disjointWith rdf:resource="#Juriidiline isik"/>
	</owl:Class>

sobilik esitus on [[owl:disjointWith::Juriidiline isik]]

• Keerukamate juhtude esimene (soovitav) variant: esitada owl reeglid otse xml keeles tekstina spetsiaalse markertagi <rdf> vahel: need reeglid eksporditakse ning neid saab välise rakendusega kasutada

E:sitame näitena mõiste poissmees definitsiooni kui mõistete “mees” ja “mitteabielus” ühisosa:

• Poissmehe reegel: <rdf>

 <owl:intersectionOf rdf:parseType="Collection">
                        <owl:Class rdf:about="#mees"/>
                        <owl:Class rdf:about="#mitteabielus"/>
               </owl: intersectionOf>
    

   </rdf>

• Keerukamate juhtude teine (vähem soovitav) variant: kodeerides avaldise abilehtede abil rdf kolmikuteks, vt suuniseid lehel http://www.w3.org/TR/2008/WD-owl2-mapping-to-rdf-20081202/

Esitame näitena mõiste poissmees definitsiooni kui mõistete “mees” ja “mitteabielus” ühisosa:

• Poissmees on [[owl:intersectionOf::_poissmees1]]
• … ja lehel _poissmees1 on tekst …. [[first::mees]] ja [[rest::_poissmees2]]
• … ja lehel _poissmees2 on tekst …. [[first::mitteabielus]]

Valdkond ja ontoloogia

Lehe valdkond ja ontoloogia ja osutatakse kui lehe omadused, näiteks:

• Selle lehe valdkond on [[valdkond::Majandus]] ja ontoloogia [[owl_ontology::FOAF]].

Kui leht ise esitab valdkonda või ontoloogiat, on tal vastav tüüp, näiteks

• Selle lehe tüüp on [[type::valdkond]]
• Selle lehe tüüp on [[type::ontoloogia]].

Lehe lõpuks peaks olema toodud

• päring, mis kuvab antud lehe kui klassi otsesed alamklassid ja otsesed ülemklassid. Hierarhias kaugemale liikumiseks peab kasutaja neile otsestele alam/ülemklassidele klikkima.
• klikitav viide spetsiaalsele lehele, mis kuvab kogu alamklasside ja ülemklasside puu antud lehe jaoks. Teisisõnu, kogu puud ei kujutata igal lehel, vaid ainult spetsiaalsele puu-kuvamise lehele minekul.

Alamklasside päring näeb spetsiaalset formaati täpsustamata välja niisugune:

{{#ask: [[type::{{PAGENAME}}]]}}

Näites antud Sehke speci draft on template, mille asemele semantic mediawiki paigutab automaatselt lehe nime. Näiteks Isik lehel annab see päring tulemuseks kõik lehed, mille otsene (hieararhiat arvestamata) type väärtus on Isik:

{{#ask: [[type::Isik]]}}

Päringu tulemuse väljanägemist saab formaadiparameetreid andes paindlikult muuta.

Versioonid

Lehe muutmisel/uue info lisamisel tekivad küsimused, kuidas hoitakse alles vanu versioone, kas neid saab taastada, kes tegi muutusi, kas saab sama-aegselt kasutada uut ja vana versiooni.

Versioonide halduseks näeme ette kahte erinevat mehhanismi.

• Põhivariant: lehe vana versiooni ei kasutata sama-aegselt uue lehega, küll saab lehte taastada ja näha muudatuste ajalugu koos muutjatega. Selleks kasutame mediawiki standardset ajaloo-halduse mehhanismi, mis on kättesaadav iga lehe mediawiki tabil “ajalugu”.

• Alternatiivne variant: peab saama sama-aegselt kasutada nii vana kui uut lehte. Sel juhul talitame nii:

• • Teeme olemasolevast lehest nimega X koopia, anname talle numbri, alustades 1, ja koopia nimele lisame sufiksiks alakriipsuga seotud numbri, näiteks X_1.
  • Põhilehe (nimega X) uuendame.
  • Koopialehele X_1 paneme uuele lehele viitava omaduse [[mainversion::X]], soovi korral täiendavalt ka viite varasemale versioonile [[oldversion::X_N]] kus N on väiksem number.
  • Põhilehele paneme versioonide päringu: Varasemad versioonid: {{#ask: [[mainversion::{{PAGENAME}}]]}}

Erinevad keeled ja tõlkimine

Võib tekkida olukordi, kus sama mõistet/lehte soovitakse esitada mitmes keeles. Sehke põhikeel on eesti keel. Muudes keeltes info esitamise korral mõiste X jaoks tuleb koostada uus leht mõiste X jaoks, kusjuures:

• Mõiste/lehe nimi on juba muukeelne: X asemel Y.
• Kõik omadused lehelt X tuleb lihtsalt kopeerida lehele Y.
• Lehele Y tuleb lisada keelt spetsifitseeriv omadus "language", näiteks [[language::English]] ja originaalkeeles esitatud lehega ekvivalentsi näitav omadus "owlEquivalentClass", näiteks [[owlEquivalentClass::Muusika]].

Lehe omanik

Lehe omanik on eeskätt administratiivne, mitte semantikakategooria.

Lehe omaniku all mõistame isikut, kes on lehe algselt SEHKE-sse ehitanud või kes vastutab antud lehe haldamise eest. Igal lehel ei pruugi olla aktiivset konkreetset omanikku. Võib juhtuda, et lehe algselt SEHKE-sse lisanud isik enam ei kasuta SEHKEt ning antud leht kuulub lihtsalt teatud valdkonna pädevusse, mille eest vastutab valdkonda haldav grupp inimesi.

Lehe muutuste ajaloo koos konkreetsete kasutajanimedega leiab alati lehe "Ajalugu" tabilt: see on standardne Mediawiki funktsionaalsus. Lehe halduse organisatoorne külg peakski eeskätt lähtuma lehe ajaloost. Muutuste tegemisel/küsimuste kerkimisel tuleb lehe ajaloost vaadata tema algset lisajat ja viimaseid muutjaid ning vajadusel nendega kontakteeruda.

Semantilise omanik-omaduse lisamist lehele ei pea me otstarbekaks: kuigi tehniliselt oleks see lihtne, ei kajastaks ta lehega toimuvat sama hästi, kui lehe mediawiki ajaloo tab ning tekitaks kasutajatele täiendavaid küsimusi ja probleeme.

Meenutame, et semantilise omadusena on lehel juba olemas valdkonda kuulumise omadus. Administratiivne vastutus peakski toimuma eeskätt valdkondade mehhanismi järgi (valdkonna eest vastutab grupp inimesi), ning muutuste jälgimine/isiklik vastutus mediawiki "Ajalugu" tabi abil.

Mediawiki eksport ja mõtestatud OWL teksti saamise protsess

Põhipunktid:

• Toor-ekspordiks kasutatakse wikisse SEHKE jaoks programmeeritud ekspordiprogrammi, mis annab iga lehe jaoks OWL teksti xml formaadis.
• Impordiks kasutatakse samuti wikisse SEHKE jaoks programmeeritud impordiprogrammi, mis võimaldab importida OWL teksti xml formaadis.
• Eksporditakse ja imporditakse ka Wikis olev harilik inimloetav tekst, mitte ainult defineeritud omadused.
• Valdkondade ja ontoloogiate lehtedele pannakse terve valdkonna/ontoloogia ekspordi nupp/link.

Eristamaks wikis olevat harilikku inimloetavat teksti omaduste jaoks kasutatavast tekstist, kasutame põhimõtet, et kogu lehel olev tekst kuni esimese reani, milles esineb mõni omadus semantic mediawiki kujul [[omadus::väärtus]], eksporditakse (ja vastupidisel juhul imporditakse) <rdfs:comment>...</rdfs:comment> tagide vahel.

Võtame konkreetse näitena lehe "Popmuusika", mille lähtekood wikis on

Tutvustav jutt, see laheb eksporti, rdfs commenti sisse
see ka...h

SubClassOf: [[SubClassOf::Muusika]]
Tempo: [[Tempo::Kiirus]]

<rdf>
<owl:disjointWith rdf:resource="Kirjandus"/>
<owl:disjointWith rdf:resource="Kokandus"/>
</rdf>

{{#ask:[[SubClassOf::{{PAGENAME}}]]}}

Selle lehe eksportimine annab tulemuseks

<owl:Ontology rdf:ID="SEHKE">
	</owl:Ontology>
<!DOCTYPE rdf:RDF [
<!ENTITY owl "http://www.w3.org/2002/07/owl#">
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
]>
<rdf:RDF
xmlns:owl2xml='http://www.w3.org/2006/12/owl2-xml#'
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:xsd='http://www.w3.org/2001/XMLSchema#'
xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#'
xmlns:owl='http://www.w3.org/2002/07/owl#'
xml:base='http://www.sehke.ee'
xmlns='http://www.sehke.ee'>
 
<owl:Class rdf:ID="Popmuusika">
<rdfs:comment  xml:lang="en">Tutvustav jutt, see laheb eksporti, rdfs commenti sisse
see ka...
</rdfs:comment>
<rdfs:subClassOf rdf:resource="Muusika"/>
<Tempo rdf:resource="Kiirus"></Tempo>
<owl:disjointWith rdf:resource="#Kirjandus"/>
<owl:disjointWith rdf:resource="#Kokandus"/>  
</owl:Class>

WSDL mediawikis

WSDL failide xml-teksti hoitakse RIHA serveris. SEHKE süsteemis luuakse iga annoteeritava/kirjeldatava WSDL-i jaoks leht, millelt viidatakse xml-tekstile RIHA serveris.

WSDL-dele vastavate lehtede jaoks lähtutakse järgmisest:

• Lehe nimi on teenuse lühinimi prefiksiga WSDL:
• Lehel on toodud omadus [[type:WSDL]], mille järgi neid lehti välja otsitakse.
• Leht algab inimloetavate kommentaaride ja selgitustega.
• Lehel võib olla toodud veebiteenuse arvutamise formaalne spetsifikatsioon, mida saab kasutada automaatsel verifitseerimisel ja/või kompleksteenuste sünteesi. Täpsem info sellise spetsifikatsiooni esitamise kohta lisatakse järgmistes etappides.
• Seejärel tuuakse - soovitavalt - loetelu WSDL-s kasutatavaid SEHKE mõisteid klikitavana.
• WSDL tekst esitatakse viitena “wsdlurl” omadusega selliselt: WSDL teksti leiab [[wsdlurl::http://….tegelik wsdl teksti url …]]