Metody Inżynierii Wiedzy OWL2RL/RIF Projekt translatora z HML na

Metody Inżynierii Wiedzy
OWL2RL/RIF
Projekt translatora z HML na OWL2RL/RIF
Piotr Olech, AiR IV rok
Spis Treści:
1.
2.
3.
4.
5.
6.
7.
8.
Język OWL 2 RL.
Język RIF.
Reguły w OWL 2 RL.
Język HML/HMR.
Propozycja tłumaczenia.
Struktury nieprzetłumaczalne.
Wnioski.
Translator (.xsl)
1. Język OWL 2 RL.
OWL (ang. Web Ontology Language) to język służący do reprezentacji i przetwarzania danych w
sieci www. Stanowi on rozszerzenie RDF (ang. Resource Description Framework). Służy do
budowy tzw. semantycznej sieci - dane opisywane sa w postaci ontologii. Podstawowa składnia
OWL zawiera szereg aksjomatów i faktów. Istnieją trzy odmiany języka OWL:
•
OWL Lite;
•
OWL DL (rozszerzenie OWL Lite);
•
OWL Full (rozszerzenie OWL DL).
OWL2 jest rodziną języków reprezentacji wiedzy, zatwierdzone przez W3C w październiku 2009.
Podjęzyki OWL2 są nieco okrojone w stosunku do macierzystego, (za W3C). Główne podjęzyki
OWL2 to:
•
OWL 2 EL (użyteczny w aplikacjach używających ontologii do objęcia dużej ilości
właściwości i/lub klas;
•
OWL 2 QL (dedykowany aplikacjom korzystającym z dużej liczby instancji, i gdzie
najważniejszym zadaniem jest odpowiedź na pytanie);
•
OWL 2 RL (dedykowany aplikacjom korzystającym ze zbilansowanej ilości zarówno klas
jak i instancji, bez poświęcania wydajności)
Więcej o OWL2RL: http://www.w3.org/TR/owl2-profiles/#OWL_2_RL
2. Język RIF.
RIF (the Rule Interchange Format) jest wciąż rozwijanym językiem, posiadającym wiele modułów.
Jego podstawowy RIF-Core odpowiada językowi klauzul Horna bez symboli funkcyjnych
(zwanych Datalogami) wraz ze standardową semantyką aksjomatyczną (ang. without function
symbols (often called 'Datalog') with a standard first-order semantics).
Po zapoznaniu się z dokumentacją języka RIF, rodzaje składni tego języka można podzielić na:
• Presentation syntax – Używana w formalnych definicjach, szczególnie dla semantyki.
• XML syntax - Jest to tzw. XML serialization składni prezentacji. Kluczowe cechy tej składni
wywodzą się ze składni prezentacji, lecz niektóre aspekty związane z wymianą reguł nie
mają swoich odpowiedników w presentation syntax.
3. Reguły w OWL 2 RL.
W regułach w OWL2RL trójka T(s, p, o) reprezenstuje odpowiednio podmiot s, predykat p i obiekt
o. Zmienne poprzedzone sa znakiem zapytania. Reguły mające puste „if” należy rozumieć jako
zawsze stosowalne.
IF
THEN
T(s1,p1,o1)
T(sr1,pr1,or1 )
…
…
T(sn,pn,on)
T(srm,prm,orm)
Regułę tę można w ogólnej postaci zapisać w RIF jako:
Group (
Forall ?v11 ... ?v1o (
sr1[pr1->or1] :- And( s1[p1->o1] ... sn[pn->on] ))
...
Forall ?vm1 ... ?vmo (
srm[prm->orm] :- And( s1[p1->o1] ... sn[pn->on] ))
)
Tłumaczenie reguł z OWL2RL na RIF można znaleźć na: http://www.w3.org/TR/rif-owlrl/#Analysis_of_OWL_2_RL_rules
4. Język HML/HMR.
HML (Hekate Markup Language ) – język stworzony na potrzeby projektu HekatE.. Stworzony
został na potrzeby interpretacji reguł HekatE. Posiada wersję tzw. „Human – Readable” - HMR.
Reguły r HMR mają następującą postać:
xrule %STRING1%/%NUMBER%: %LIST1% ==> %LIST2% **> %LIST3% : %STRING2%.
Gdzie:
•
%STRING1% - nazwa schemtu, którego dotyczy reguła
•
%NUMBER% - Id reguły wewnątrz schematu
•
%LIST1% - lista z warunkami do reguły
•
%LIST2% - lista decyzji wywoływanych. gdy reguła jest proawdziwa
•
%LIST3% - Akcje wywoływane, gdy reguła jest prawdziwa
•
%STRING2% - parametr, który zawiera dane do przypadku, gdy tryb wnioskowania
ustawiony jest na token - drive.
5. Propozycja tłumaczenia.
Przykładowy kod i tłumaczenie na OWL 2 RL / RIF w HMR:
xrule dt/1:
[day in [mon,tue,wed,thu,fri]]
==>
[today set workday]
**>
[tell_console,['Today is a workday']]
:th.
OWL2RL:
IF
THEN
T(?day, owl:oneOf, ?x) LIST[?x, mon, tue, wed, thu, fri]
Akcje i parametry do Tokena sa nieprzetłuamczalne.
T(?day, rdf:type, workday)
RIF:
L(mon, tue, wed, thu, fri)
for(?day in L) {
{$
?day[rdf:type->workday] )
$}
}
Podstawową regułą w HML (lub też w ekwiwalentnym „Human-readable” HMR) jest
przynależność do listy i porównywanie stanu z wzorcem. Pod tym katem, ciężko jest przetłumaczyć
to na OWL2RL, ponieważ
• W OWL2RL opisuję się ontologię jako zbiór klas i ich instancji i pod tym kątem
przeprowadza działania
• W HMR opis interesujących nas rzeczy przestawia się jako jedynie gotowe instancje, które
mogą być zebrane w listę
Innymi słowy, translacja HMR ⇒ OWL2RL jest teoretycznie możliwa, lecz istnieje ryzyko
utracenia interesujących nas infromacji (lub też przekłamań) poprzez przedstawienie ich w nieco
innej postaci.
Pokazany powyżej przykład z dniami tygodnia i tygodniem pracy jest tego dobrym przykładem:
• W HMR sprawdza się, czy zmienna Today jest elementem listy workday; Today nie jest
instancją jednego z elemntów listy, może mieć co najwyżej taką samą wartość
• Tłumaczenie na OWL2RL nie jest dobrym przykładem pomimo, że deklaracja rdf:type
odnosi się w miarę ekwiwalentny spoób (dzień typu dzień pracy)
• Predykat oneOf może budzić wątpliwości, gdyż może być on używany również do
określenia, czy obiekt jest instancją danej klasy.
Porównywanie jednej zmiennej do drugiej w OWL2RL można zapisać dość prosto, na przykład
reguła
xrule day1:
[today eq sunday]
==>
[today set freeDay].
może zostać zapisana w OWL2RL jako:
T(?day, owl:sameAs, sunday) :- T(?day, owl:members, freeDay)
Tutaj dochodzimy do punktu, w którym należy rozróżnić rdf:type od owl:members.
• w rdf:type deklarujemy, że coś jest typem czegoś, bez przynależności do jakiegoś
konkretnego zbioru (listy)
• w owl:members nie deklarujemy, żę obiekt ma jakąś konkretną własność (typ), jest jedynie
elementem jakiegoś zbioru(listy)
6. Struktury nieprzetłumaczalne.
W OWL2RL istnieją mechanizmy pozwalające na powiązanie zależnościami wielu
obiektów, jak również na wnioskowanie z wielu reguł. Jednak zasadniczą różnicą pomiędzy
OWL2RL a HML jest to, że ten pierwszy odnosi się bardziej do abstrakcyjnej struktury „klas” i
„obiektów”. Tu ważna jest dokładna klasyfikacja, a właściwości i reguły odnoszą się bardziej do
abstrakcyjnych obiektów, a nie ich instancji. W HML natomiast opisywane są rzeczywiste instancje
obiektów, które można przetłumaczyć na język abstrakcyjny, jednak istnieją struktury, które ciężko
lub wcale nie można przetłumaczyć, na przykład:
•
Typ symboliczny w HML - można go uznać za zwykłą listę bądź strukturę. W OWL2RL
istnieje wiele typów, nie definiują one jednak bezpośrednio list. Rozwiązania, które były
analizowane to użycie zależności owl:oneOf która mówi, że dany podmiot jest jednym z
wymienionych orzeczeń. Orzeczenia te można zebrać w listę poleceniem LIST. Druga opcja
jest bardzo podobna i mniej skomplikowana składniowo - przykład: DayOfTheWeek :=
'mon' | 'tue" | 'wed' | 'thu' | 'fri' | 'sat' | 'sun' . Tę strukturę można uznać za podobną do listy.
•
Wspomniane już wcześniej definiowanie, że coś jest typem czegoś w HML. Prosty przykład
– procesor Intel typ i7. rdf:type Określa, że Intel jest obiektem klasy i7, co nie zawsze jest
prawdą (bo np. istnieją procesory i3). owl:members natomiast mówi, że coś jest jednym z
elementów danej struktury, co też nie jest do końca merytorycznie poprawne. Tego typu
tłumaczenia były najczęstszymi powodami problemów.
7. Wnioski.
Język HML ma węższe zastosowanie niż OWL2RL, jednak bardziej precyzyjne. OWL2RL
to dobry język do opisu dużych ontologii i zależności, jednak podczas tłumaczenia HML na
OWL2RL natrafiłem na dużo problemów związanych z mnogością własności i relacji, które były
odpowiednie dla jednej struktury w HML, jak również z HMLowymi strukturami
nieprzetłumaczalnymi na OWL2RL, na grupowanie reguł w tablice.
8. Translator (.xsl).
Cały translator do probrania na stronie projektu. Poniżej kilka fragmentów wraz z przykłądowym
tłumaczeniem (HekatE case Thermostat). Jako format wynikowy wybrałem formę funkcjonalną
OWL2RL (nie składnię XMLową) ze względu na dużo większy zasób wiedzy w internecie
pozwalający na naukę tej właśnie składni.
HML
OWL2RL (XSLT)
<type id="tpe_4" name="integer" base="numeric"
length="9" scale="0">
<desc>integer</desc>
<domain>
<value from="-999999999" to="999999999"/>
</domain>
</type>
ClassAssertion( a:tpe_4 xsd:int )
DataPropertyAssertion( a:hasName a:tpe_4 a:integer )
<type id="tpe_8" name="months" base="symbolic">
<desc>All months of the year</desc>
<domain ordered="yes">
<value is="January" num="1"/>
<value is="February" num="2"/>
<value is="March" num="3"/>
<value is="April" num="4"/>
<value is="May" num="5"/>
<value is="June" num="6"/>
<value is="July" num="7"/>
<value is="August" num="8"/>
<value is="September" num="9"/>
<value is="October" num="10"/>
<value is="November" num="11"/>
<value is="December" num="12"/>
</domain>
</type>
ClassAssertion( a:tpe_8 xsd:String )
DataPropertyAssertion( a:hasName a:tpe_8 a:months )
tpe_8 := 'January' | 'February' | 'March' | 'April' | 'May' |
'June' | 'July' | 'August' | 'September' | 'October' |
'November' | 'December'
<attr id="att_8" type="tpe_2" name="day" abbrev="day"
class="simple" comm="in">
<desc>The current day</desc>
</attr>
ClassAssertion( a:att_8 a:isAttribute )
ObjectPropertyAssertion( a:hasType a:att_8 a:tpe_2 )
ObjectPropertyAssertion( a:hasName a:att_8 a:day )
ObjectPropertyAssertion( a:hasAbbrev a:att_8 a:day )
ClassAssertion( a:att_8 a:simple )
ObjectPropertyAssertion( a:hasComm a:att_8 a:in )
<rule id="rul_3">
<condition>
<relation name="in">
<attref ref="att_9"/>
<set>
<value is="January"/>
<value is="February"/>
<value is="December"/>
</set>
</relation>
</condition>
<decision>
<trans>
<attref ref="att_6"/>
<set>
<value is="Summer"/>
</set>
</trans>
</decision>
<link><tabref ref="tab_5"/>
</link>
</rule>
ClassAssertion( a:rul_3 a:isRule )
ObjectPropertyAssertion( a:hasName a:rul_3)
T( ?att_9 owl:oneOf ?x)
LIST[?x, January, February, December, ]
:T( ?att_6 a:hasValue ?Summer)