TheTarPit

Ontologie dla laików aka poradnik sapera — odcinek #1

Rozważając praktyczne zastosowania Sieci Semantycznej nie da się uciec od problemu definiowania ontologii^[1], choćby i w OWL. A ponieważ zagadnienie to jest samo w sobie dosyć skomplikowane (choć nie niewykonalne jak widać np. po SchemaWeb) bardzo łatwo popełnić kilka smutnych w konsekwencjach błędów. Zamierzam w tym i kilku następnych wpisach zanalizować, a przynajmniej zapisać sobie ku pamięci, jakie błędy można popełnić przy definiowaniu ontologii, jeśli „zapomni się” zrzucić bagaż codziennego (przynajmniej dla mnie) myślenia kategoriami, które sprawdzają się w systemach informatycznych, ale zupełnie nie pasują do otwartego świata Semantic Web.

Pierwszym i właściwie najbardziej oczywistym źródłem problemów jest pojęcie klasy. Klasa to słowo w szeroko rozumianej informatyce tak wszędobylskie, że każdy rozumie je na swój sposób w zależności od tego, jakie ma doświadczenia. W kontekście Sieci Semantycznej najbardziej przeszkadzające są doświadczenia ze świata modelowania/programowania obiektowego (wspominałem już o tym).

Chyba najważniejszym problemem związanym z pojęciem klasy jest samo rozumienie jej definicji, czyli tego, co ta definicja mówi. Albo raczej czego nie mówi. Na przykład wyobraźmy sobie fragment ontologii stwierdzający, że faceci i kobiety to dwa rodzaje ludzi (język OWL, zapis w RDF/XML, tak mi chwilowo najwygodniej):

<owl:Class rdf:ID="Czlowiek">
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Mezczyzna" />
    <owl:Class rdf:about="#Kobieta" />
  </owl:unionOf>
</owl:Class>

Mamy tu definicję klasy Czlowiek jako „sumę klas” Mezczyzna i Kobieta. Dobrze? Intuicja wyniesiona z praktyki systemów obiektowych i baz danych podpowiada, że całkiem ok. Niestety z punktu widzenia ontologii nie jest dobrze. Jest całkiem źle.

Założenie świata otwartego funkcjonujące wszędzie gdzie zbliżamy się do Sieci Semantycznej, a w ontologiach w szczególności, powoduje, że klasy definiowane w OWL z definicji nakładają się. Sam fakt należenia zasobu/obiektu/indywiduum do jakiejś klasy nie wyklucza możliwości należenia równocześnie do innej. Do nieskończonej ilości innych (wspominałem o tym i to pewnie nie raz). Zatem definicja powyższa mówi tylko tyle, że zbiór instancji klasy Czlowiek jest równy sumie zbiorów instancji klas Mezczyzna i Kobieta. Nic ponadto. Innymi słowy: ktoś, kto jest człowiekiem, należy przynajmniej do jednego ze zbiorów mężczyzn i kobiet. Przynajmniej do jednego... a może i do obu.

Powyższa definicja klasy Czlowiek jest zatem zwyczajnie zła (w sensie biologicznym Update: ok, zgodnie z tym, co wytknął mi boleśnie dosłowny Shot, w sensie biologicznym jest akurat dobra. Ale oczekujemy, że decyzja dotycząca płci jest podejmowana w sposób jasno wskazujący jedną z opcji. I w uproszczonym świecie systemów informatycznych, który do zawiłości biologii może nigdy nie dorosnąć, pozostańmy przy tym, że płeć ma się jedną.). Rozwiązanie problemu jest jednak proste, a nawet jest ich kilka. Na przykład można uzupełnić definicje klas Mezczyzna i Kobieta o jawne wskazanie faktu, że jedno to nie drugie:

<owl:Class rdf:ID="Mezczyzna">
  <owl:disjointWith rdf:resource="#Kobieta"/>
</owl:Class>

<owl:Class rdf:ID="Kobieta">
  <owl:disjointWith rdf:resource="#Mezczyzna"/>
</owl:Class>

I tyle. Od tego momentu reasoner (czy kto tam będzie tę ontologię analizował) uzna obiekt należący równocześnie do klasy Mezczyzna i Kobieta za błędny. Ale dopiero od tego momentu, nie wcześniej. Niby drobny szczegół, a jak wiele zmienia...

Komentarze