Zrealizował: Michał Lesiak (4RI)
W projekcie miał zostać stworzony wzorzec XSLT, który zamieni składnię XTTML na składnię SWRL XML, przy czym XML dla SWRL jest kombinacją OWL Web Ontology Language XML z RuleML XML.
Ostatecznie został stworzony translator w prologu, gdyż XSLT okazał się nie wystarczającym narzędziem.
Możliwa jest również zamiana XTTML na RDF dla SWRL, przy czym można tego dokonać korzystając ze wzorca owlxml2rdf.xsl, który należałoby rozbudować.
Semantic Web Rule Language (SWRL) jest propozycją języka, który bazuje na kombinacji OWL DL i OWL Lite, czyli podjęzyków OWL Web Ontology Language z pojedynczymi/binarnymi datalogami języka RuleML. Propozycja rozszerza zbiór aksjomatów OWL tak, by zawierał reguły podobne do reguł Horna. Reguły te mogą więc być łączone z bazą wiedzy OWL.
Reguły są przedstawiane w formie implikacji: poprzednik („body”) i następnik („head”), z których każdy może składać się z zera lub więcej atomów. Implikacja w przypadku pustego poprzednika jest traktowana jako zawsze prawdziwa, a w przypadku pustego następnika jest traktowana jako zawsze fałszywa. Wiele atomów jest traktowanych jako koniunkcja. Reguła z koniunkcją atomów w następniku jest równoważna koniunkcjom reguł, w których następnikami są pojedyncze atomy.
Składnia XML dla SWRL jest kombinacją OWL Web Ontology Language XML z RuleML XML.
Definiuje przestrzenie nazw swrlx i swrlb, importuje przestrzeń nazw ruleml i owl.
Używane przestrzenie nazw:
Skrót | Przestrzeń nazw |
swrlx | http://www.w3.org/2003/11/swrlx |
swrlb | http://www.w3.org/2003/11/swrlb |
ruleml | http://www.w3.org/2003/11/ruleml |
owl | http://www.w3.org/2003/05/owl-xml |
xsd | http://www.w3.org/2001/XMLSchema |
W związku z czym został zaproponowany bardziej czytelny XML: SWRL presentation: SWRLp
<swrlx:Ontology swrlx:name = xsd:anyURI > Content: (owlx:VersionInfo | owlx:PriorVersion | owlx:BackwardCompatibleWith | owlx:IncompatibleWith | owlx:Imports | owlx:Annotation | owlx:Class[axiom] | owlx:EnumeratedClass(D,F) | owlx:SubClassOf(D,F) | owlx:EquivalentClasses | owlx:DisjointClasses(D,F) | owlx:DatatypeProperty | owlx:ObjectProperty | owlx:SubPropertyOf | owlx:EquivalentProperties | owlx:Individual[axiom] | owlx:SameIndividual | owlx:DifferentIndividuals | ruleml:imp[axiom] | ruleml:var[axiom])* </swrlx:Ontology>
Główny element „Ontology” w stosunku do składni prezentacji OWL XML został rozszerzony o aksjomaty „imp” („implication” - reguła implikacyjna) oraz „var” („variable” - deklaracja zmiennej)
<ruleml:var>xsd:string</ruleml:var>
Definiuje istnienie zmiennej. Zapożyczono z przestrzeni nazw RuleML.
<ruleml:imp> Content: ( _rlab?, owlx:Annotation*, _body, _head ) </ruleml:imp>
<ruleml:imp> Content: ( _rlab?, owlx:Annotation*, _body, _head ) </ruleml:imp>
<ruleml:_body> Content: ( swrlx:atom* ) </ruleml:_body>
<ruleml:_head> Content: ( swrlx:atom* ) </ruleml:_head>
Mogą być pojedynczymi predykatami (klasami), binarnymi predykatami (właściwościami), równościami lub nierównościami.
W SWRL występuje ciąg aksjomatów (axioms) i faktów, gdzie aksjomaty to reguły i klasy obiektów. SWRL przewiduje tylko proste obliczenia matematyczne (builtIn), ale poprawność syntaktyczna nie jest sprawdzana. Np. operacja „builtIn(op:numeric-add ?x 5)” (czyli: x + 5 zamiast np. 6 = x + 5) jest poprawna i zwraca wartość fałszu. SWRL bazuje na opisie i właściwościach klas obiektów. To zdecydowanie odmienne podejście niż w przypadku XTT powoduje problemy w translacji między tymi językami.
1. Możliwość stosowania tylko predykatów binarnych w SWRL (w XTT brak ograniczenia),
2. Brak możliwości zagnieżdżania obliczeń matematycznych w SWRL,
3. Brak możliwości korzystania z predykatów zdefiniowanych zewnętrznie,
4. SWRL nie obsługuje negacji ani alternatywy.
Translacja, której wynikiem byłby XML SWRL taki, że interpreter SWRL dokonywałby działań (operacji) analogicznych do interpretera XTT.
Napisanie takich reguł translacji XTT → SWRL przy pomocy XSLT jest bardzo trudne, o ile nie niemożliwe (XSLT jest nieodpowiednim do tego narzędziem, należałoby napisać własny translator).
W tym podejściu rozwiązania problemów przedstawiałyby się nastepująco:
ad 1. Rozwiązaniem jest stworzenie sztucznej relacji, która wiąże ze soba kolejne argumenty. Przykład zastosowania sztucznej relacji 'reifiedRelation'
ad 2. Rozwiązaniem jest stworzenie serii zmiennych pomocniczych, które przechowywałyby wyniki obliczeń kolejno w sobie zagnieżdżonych operacji.
ad 3. Brak istniejącego rozwiązania.
ad 4. Rozwiązaniem problemu alternatywy jest stworzenie tylu reguł, ile jest alternatyw. Każda reguła w poprzedniku posiadałaby inną alternatywę, w następniku znajdowałaby się natomiast ta sama dla wszystkich operacja (Zbiór operacji).
Translacja, której wynikiem byłby XML SWRL taki, że interpreter SWRL stwierdziłby poprawność XML, ale nie byłby w stanie wykonać działań (operacji) analogicznie do tego jak zrobiłby to interpreter XTT.
Translacja powodowałaby przedstawienie obliczeń i operacji w postaci klas i obiektów.
Najbardziej właściwa dla SWRLa wydaje się propozycja przedstawiania zmiennych/operacji/funkcji jako klas, posiadających odpowiednie własności: wartość (własność: „value”), operacja (własność zależna od operacji).
Przykładem operacji jest np. sumowanie, właściwość obiektu „add” byłaby obiektem, która posiadałaby własność liczby (DataPropertyValue) lub przechowywałaby konieczne do wykonania obliczenia w postaci obiektu (ObjectPropertyValue) - kolejne zagnieżdżenie z kolejnymi własnościami „value” lub operacjami.