TheTarPit

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

Kontynuując notatki na temat tworzenia ontologii OWL...

Hierarchie klas i właściwości to zdecydowanie za mało by mógł powstać sensowny opis jakiejkolwiek nie trywialnej dziedziny pojęciowej. Siła języków definiowania ontologii jest możliwość definiowania pojęć na podstawie ich cech charakterystycznych lub ograniczeń jakie muszą spełniać. Dlatego OWL jest w tym zakresie bardzo mocno rozbudowany. A jak uczy doświadczenie, każdy rozbudowany mechanizm stwarza multum możliwości jego błędnego użycia.

Chyba najbardziej popularnym sposobem definiowania nowych klas pojęć jest uściślanie — „X to jest taki Y, który ma cechę Z”. Przy czym „cecha Z” określana jest najczęściej jako specyficzna wartość konkretnej właściwości. Na przykład: „Polak to taki człek, który ma obywatelstwo polskie”. W zapisie OWL może to wyglądać np. tak:

<owl:Class rdf:ID="Polak">
  <rdfs:subClassOf rdf:resource="#Czlowiek"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#obywatelstwo"/>
      <owl:someValuesFrom rdf:resource="#Polskie"/>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

Ograniczenie owl:Restriction z predykatem owl:someValuesFrom oznacza, że przynajmniej jedna wartość właściwości wskazanej przez owl:onProperty musi być podanej klasy. Powyższe można przeczytać: „Polak to taki Czlowiek, który między innymi posiada właściwość obywatelstwo o wartości Polskie”. Brzmi OK.

Inny przykład: pizza Hawajska (wg Pizza Hut):

<owl:Class rdf:ID="Hawajska">
  <rdfs:subClassOf rdf:resource="#Pizza"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#dodatek"/>
      <owl:someValuesFrom rdf:resource="#SosPomidorowy"/>
    </owl:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#dodatek"/>
      <owl:someValuesFrom rdf:resource="#Mozzarella"/>
    </owl:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#dodatek"/>
      <owl:someValuesFrom rdf:resource="#Szynka"/>
    </owl:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#dodatek"/>
      <owl:someValuesFrom rdf:resource="#Ananas"/>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

Jak widać klasa zbudowana przez analogię do poprzedniej definicji. Czy dalej OK?

Niestety tym razem ta definicja jest zupełnie zła. W przypadku klasy Polak słowa „między innymi” wprowadzone przez owl:someValuesFrom są ważne — można mieć wiele obywatelstw. Natomiast pizza po dodaniu czegokolwiek przestaje reprezentować konkretną pozycję menu. Co z tego, że zostały dodane wszystkie wymienione dodatki, skoro nie mamy żadnej pewności co do pozostałych elementów. Aby zachować pewność, że menu nie zostanie spaprane, trzeba dodać ograniczenie, które to uniemożliwi — tzw. „closure restriction”. W naszym przypadku należy dopisać:

  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#dodatek"/>
      <owl:allValuesFrom>
        <owl:Class>
          <owl:oneOf rdf:parseType="Collection">
            <owl:Thing rdf:about="#SosPomidorowy"/>
            <owl:Thing rdf:about="#Mozzarella"/>
            <owl:Thing rdf:about="#Szynka"/>
            <owl:Thing rdf:about="#Ananas"/>
          </owl:oneOf>
        </owl:Class>
      </owl:allValuesFrom>
    </owl:Restriction>
  </rdfs:subClassOf>

A zatem uzupełniona definicja wygląda tak: Hawajska to taka Pizza, która:

• posiada jako dodatek SosPomidorowy,
• posiada jako dodatek Mozzarella,
• posiada jako dodatek Szynka,
• posiada jako dodatek Ananas,
• każdy jej dodatek należy do zbioru {SosPomidorowy, Mozzarella, Szynka, Ananas}.

Nic więcej i nic mniej. Menu uratowane ;-)

Komentarze

Brak komentarzy do tego wpisu.