OWL Język Ontologii Sieciowej
Przewodnik

Rekomendacja W3C 10 Luty 2004

Ta wersja:

http://www.w3.org/TR/2004/REC-owl-guide-20040210/

Ostatnia wersja:

http://www.w3.org/TR/owl-guide/

Poprzednia wersja:

http://www.w3.org/TR/2003/PR-owl-guide-20031215/

Edytorzy:

Michael K. Smith, Electronic Data Systems,
Chris Welty, IBM Research,
Deborah L. McGuinness, Stanford University,

Proszę o sprawdzenie erraty tego dokumentu, która może zawierać poprawki normatywne.

Zobacz również tłumaczenia.

Copyright © 2004 W3C^® (MIT, ERCIM , Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

Streszczenie

Ogólnoświatowa Sieć w swoim obecnym stanie przypomina bardzo niedokładną mapę geograficzną. Nasz wgląd w dokumenty i dostępne możliwości jest oparty na wyszukiwaniu przy użyciu słów-kluczy, nakłanianiu do sprytnego używania łączności dokumentów i używanych wzorców. Takiej ogromnej ilości danych nie da się opanować bez odpowiedniego narzędzia. Aby dokładniej je przeszukiwać, agenci obliczeniowi wymagają zrozumiałego przez maszyny opisu zawartości i zdolności dostępnych zasobów sieciowych. Te opisy muszą być dodatkiem do informacji zrozumiałych przez człowieka.

OWL Język Ontologii Sieciowej ma zapewnić język zapewniający możliwość opisu klas i związków między nimi, które są dziedziczone w dokumentach i aplikacjach.

Ten dokument demonstruje zastosowanie języka OWL do

1. zformalizowania domen poprzez zdefiniowanie klas i własności tych klas,
2. zdefiniowaniu indywiduów i związanych z nimi własności, oraz
3. wnioskowania o klasach i indywiduach w stopniu zezwalanym przez formalną semantykę języka OWL.

Sekcje są tak zorganizowane, aby przedstawić przyrostową definicję zestawu klas, własności i indywiduów, zaczynając od podstaw i przechodząc do bardziej złożonych składników języka.

Status tego dokumentu

Spis treści

• Streszczenie
• Status tego dokumentu
• Spis treści
• 1. Wstęp
  • 1.1. Rodzaje OWL-a
  • 1.2. Struktura dokumentu
• 2. Struktura ontologii
  • 2.1. Przestrzenie nazw
  • 2.2. Nagłówki ontologii
  • 2.3. Agregacja danych i prywatność
• 3. Podstawowe elementy
  • 3.1. Pojedyncze klasy i indywidua
    • 3.1.1. Pojedyncze nazwy klas
    • 3.1.2. Indywidua
    • 3.1.3. Wzorce do użycia
  • 3.2. Pojedyncze własności
    • 3.2.1. Definiowanie własności
    • 3.2.2. Własności i typy danych
    • 3.2.3. Własności indywiduów
  • 3.3. Charakterystyki własności
    • 3.3.1. TransitiveProperty
    • 3.3.2. SymmetricProperty
    • 3.3.3. FunctionalProperty
    • 3.3.4. inverseOf
    • 3.3.5. InverseFunctionalProperty
  • 3.4. Ograniczenia własności
    • 3.4.1. allValuesFrom, someValuesFrom
    • 3.4.2. Liczność
    • 3.4.3. hasValue
• 4. Mapowanie ontologii
  • 4.1. Równoważność między klasami i własnościami
  • 4.2. Tożsamość między indywiduami
  • 4.3. Różne indywidua
• 5. Klasy złożone
  • 5.1. Zbiór operatorów
  • 5.2. Klasy numerowane
  • 5.3. Klasy rozłączne
• 6. Kontrola wersji ontologii
• 7. Przykłady użycia
  • 7.1. Portal wina
  • 7.2. Bednarz wina
• Podziękowania
• Słownik OWL
• Indeks terminów i referencji
• Referencje
• Dodatek A: XML + RDF Basics
• Dodatek B: Historia
• Dodatek C: Zmiany w dzienniku od ostatniej zapowiedzi wydania

1. Wstęp

"Powiedz mi jakie wina powinienem kupić, aby podać z każdym daniem z poniższego menu. I, przy okazji, nie lubię wina typu Sauternes."

Dzisiaj byłoby trudno skonstruować agenta sieciowego zdolnego do przeprowadzenia wyszukiwania win w sieci, które odpowiadałoby na powyższe pytanie. Podobnie również, przypisanie agentowi programowemu zadania przygotowania spójnego planu podróży. (Więcej zastosowań zobacz dokument OWL wymagania.)

Aby potwierdzić tego typu obliczenia musimy pójść poza słowa-klucze i sprecyzować znaczenie zasobów opisanych w sieci. Tę dodatkową warstwę interpretacyjną zapewnia semantyka danych.

OWL Język Ontologii Sieciowej jest językiem do definiowania i tworzenia instancji ontologii sieciowej. Ontologia jest terminem zapożyczonym z filozofii, który odnosi się do nauki opisywania rodzajów podmiotów i jak są one ze sobą powiązane. Ontologia OWL-a może zawierać opisy klas, własności i ich instancji. Przy użyciu tej ontologii, formalna semantyka OWL-a precyzuje pochodzenie jej logicznych następstw, to znaczy faktów dosłownie nie obecnych w ontologii, ale dołączonych przez semantykę. Te dołączenia mogą być oparte na pojedynczym dokumencie lub wielokrotnie rozprowadzonych dokumentach, które byłyby połączone używaniem zdefiniowanych machanizmów OWL-a.

Ten dokument jest jednym z komponentów opisu OWL-a, Języka Ontologii Sieciowej, stworzonego przez W3C Grupę Roboczą Ontologii Sieciowej (WebOnt). Sekcja spis dokumentów w Przeglądzie ([Przegląd], 1.1) opisuje każdą część i jak pasują one do siebie.

Pytanie, które się pojawia kiedy opisujemy inny XML/standard Sieciowy to "Co daje mi XML czego nie ma XML Schema?" Są dwie odpowiedzi na to pytanie.

• Ontologia różni się od XML Schema, tym że jest to reprezentacja wiedzy, a nie format wiadomości. Większość przemysłu opierającego się na standardach Sieciowych składa się z kombinacji formatów wiadomości i specyfikacji protokołu. Tym formatom zostały nadane działania semantyczne, takie jak, "Na podstawie zlecenia na PurchaseOrder, przelej Amount dolarów z AccountFrom na AccountTo i wyślij Product." Ale specyfikacja nie przewiduje działania poza wyznaczonymi ramami, w tym przypadku obsługi transakcji. Na przykład, nie będziemy mieli mechanizmu wnioskującego, że skoro Product jest typu Chardonnay to musi to być również wino białe.
  
  
• Przewagą ontologii OWL-a będzie dostępność narzędzi, które będą mogły wnioskować na jej podstawie. Narzędzia zapewnią ogółne wsparcie, które nie jest specyficzne dla konkretnej domeny. Byłoby tak w przypadku gdyby został zaprojektowany system wnioskowania o konkretnym standardzie przemysłowym XML Schema. Zbudowanie poprawnego i użytecznego systemu wnioskowania nie jest takie proste. Skonstruowanie ontologii jest znacznie bardziej przystępne. Liczymy na to, że wiele grup zaaprobuje konstrukcję ontologii. Skorzystają oni na narzędziach opartych na formalnych własnościach języka OWL. Narzędziach, które dostarczą asortyment możliwości, których większość przedsiębiorstw nie mogłaby w prosty sposób skopiować.
  

1.1. Rodzaje OWL-a

Język OWL zapewnia trzy coraz bardziej wyraziste podjęzyki zaprojektowane do używania przez specyficzne środowiska programistów i użytkowników.

• OWL Lite wspiera użytkowników głównie potrzebujących hierarchii klasyfikacji i prostego ograniczenia cech. Na przykład, OWL Lite zapewnia ogólne ograniczenia, pozwalając jedynie na podstawowe wartości 0 lub 1. Powinno być łatwiej zapewnić wsparcie programowe dla OWL Lite niż dla bardziej rozbudowanych wersji, zapewniający szybki dostęp do tezaurusów i taksonomii.

• OWL DL wspiera tych użytkowników, którzy chcą maksymalnej ekspresyjności bez tracenia kompletności obliczeniowej (gwarancja wszystkich udostępnień możliwych do obliczenia) i zdolności decyzyjnych (wszystkie obliczenia będą skończone w skończonym czasie) w systemie wnioskowania. OWL DL zawiera wszystkie konstrukcje języka OWL z ograniczeniami, takimi jak rozdzielność typów (klasa nie może być również indywiduum lub własnością, własność nie może być również indywiduum lub klasą). OWL DL jest tak nazwany przez swoją zgodność z logiką opisową [Logika opisowa], badań, które zajmowały się szczególnym fragmentem zdolności decyzyjnych w logice rozkazów. OWL DL został zaprojektowany aby wspierać istniejącą część branży logiki opisowej i pożądane własności obliczeniowe dla systemu wnioskowania.

• OWL Full jest przeznaczony dla użytkowników chcących maksymalnej ekspresyjności i składniową wolność RDF-a bez gwarancji obliczeniowych. Na przykład, w OWL Full klasa może być równocześnie traktowana jako zbiór indywiduów i jako indywiduum z własnymi prawami. Następną znaczącą różnicą między OWL DL jest to, że owl:DatatypeProperty maże być oznaczony jako owl:InverseFunctionalProperty. OWL Full pozwala ontologii zwiększać znaczenie pre-definiowanego (RDF lub OWL) słownictwa. Mało prawdopodobne jest aby jakikolwiek program wnioskujący mógł obsłużyć każdy aspekt OWL Full.

Każdy z tych podjęzyków jest poszerzeniem swojego prostszego poprzednika, zarówno w tym co można poprawnie wyrazić, jak i ważnie wywnioskować. Następujące związki są poprawne, ich odwrotności nie.

• Każda poprawna ontologia OWL Lite jest poprawną ontologią OWL DL.
• Każda poprawna ontologia OWL DL jest poprawną ontologią OWL Full.
• Każde poprawne wnioskowanie OWL Lite jest poprawnym wnioskowaniem OWL DL.
• Każde poprawne wnioskowanie OWL DL jest poprawnym wnioskowaniem OWL Full.

Twórcy ontologii stosujący OWL powinni zastanowić się który rodzaj najbardziej odpowiada ich potrzebom. Wybór pomiędzy OWL Lite a OWL DL zależy od stopnia wymaganej przez użytkownika wyrazistości budowanych ograniczeń zapewnianych w OWL DL. Zwolennicy OWL Lite będą mieli pożądane własności obliczeniowe. Zwolennicy OWL DL, wykorzystując rozstrzygające podjęzyki, będą musieli radzić sobie z wyższą złożonością najgorszych przypadków. Wybór pomiędzy OWL DL i OWL Full zależy w głównej mierze od stopnia wykorzystania przez użytkowników meta-modelowanie urządzenia RDF Schema ( to znaczy, definiowanie klas w klasach ). Kiedy używamy OWL Full w porównaniu do OWL DL, pomoc we wnioskowaniu jest mniej przewidywalna. Więcej informacji dotyczących tego zagadnienia na OWL semantyka dokumentu.

Użytkownicy zamieniający RDF na OWL DL lub OWL Lite powinni zadbać o to aby oryginalne dokumenty RDF kompilowały się z ograniczeniami nałożonymi przez OWL DL i OWL Lite. Szczegóły tych ograniczeń są wyjaśnione w Dodatku E OWL Referencje.

Kiedy wprowadzamy konstrukcje, które są dostępne tylko w OWL DL lub OWL Full, oznaczamy je poprzez "[OWL DL]".

1.2. Struktura dokumentu

W celu zapewnienia zgodnego zestawu przykładów w całym przewodniku, stworzyliśmy ontologie wino i jedzenie. Są to ontologie OWL DL. Niektóre nasze dyskusje będą skupione na możliwościach OWL Full i będzie to zaznaczone. Ontologie wino i jedzenie są znaczącą modyfikacją elementu biblioteki ontologii DAML o długiej historii. Została ona stworzona przez McGuinness jako CLASSIC (klasyczna) logika opisowa przykład, rozszerzona do logiki opisowej samouczek, i rozszerzona do ontologii samouczek.

W tym dokumencie prezentujemy przykłady używając składni RDF/XML ([RDF], 5), zakładając że XML będzie znany większej liczbie osób. Normatywna wymiana składni to RDF/XML. Zauważmy, że OWL został zaprojektowany dla maksymalnej kompatybilności z RDF i RDF Schema. Te formaty XML i RDF są częścią standardu OWL-a.

Wszystkie przykłady prezentowane w tym dokumencie są wzięte z ontologii zawartych w wine.rdf i food.rdf, poza tymi oznaczonymi  ¬  w prawym dolnym rogu.

2. Struktura ontologii

OWL jest częścią działalności Sieci Semantycznej. Zakłada to, że zasoby sieciowe będą łatwiej dostępne dla automatycznych procesów poprzez dodanie informacji o zasobach opisujących lub zapewniających zawartość sieci. Jak sieć semantyczna jest nierozłącznie rozprzestrzeniana, OWL musi pozwalać aby informacje były gromadzone z rozprzestrzenionych źródeł. Jest to częściowo realizowane przez zezwalanie na korelację ontologii, dołączając informacje z innych ontologii.

W dodatku OWL zakłada otwarty świat. To znaczy, opisy zasobów nie są zawarte w pojedynczym pliku czy polu(miejscu, zakresie). Klasa c1 może być pierwotnie zdefiniowana w ontologii o1, ale może ona również zostać rozwinięta w innych ontologiach. Konsekwencje tych dodatkowych założeń o c1 są monotoniczne. Nowe informacje nie mogą odwołać poprzednich informacji. Nowa informacja może być sprzeczna ale fakty i udostępnienia mogą być tylko dodane, nigdy usunięte.

Możliwość takich sprzeczności jest czymś co twórca ontologii powinien wziąć pod uwagę. W wykrywaniu takich przypadków oczekiwana jest pomoc programowa.

Aby pisać ontologie, które mogą być jednoznacznie interpretowane i używane przez agentów programowych potrzebujemy składni i formalnej semantyki dla OWL-a. OWL jest rozszerzeniem słownika [RDF Semantyka] RDF. Semantyka OWL-a jest zdefiniowana w OWL Język Ontologii Sieciowej Semantyka i lista składni.

2.1. Przestrzenie nazw

Zanim możemy użyć zestawu określeń, potrzebujemy dokładnie sprecyzować jakiego specyficznego słownictwa będziemy używać. Standardowy początek ontologii zawiera zestaw XML-owych deklaracji przestrzeni nazw zawartych w otwierającym znaczniku rdf:RDF. To zapewnia sposób, aby jednoznacznie interpretować identyfikatory i zapewnia przejrzystość pozostałej części ontologii. Typowa ontologia OWL-a zaczyna się od deklaracji przestrzeni nazw podobną do poniższej. Oczywiście, URI zdefiniowanych ontologii z reguły nie będzie odnosić się do w3.org .

<rdf:RDF 
    xmlns     ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" 
    xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"       
    xml:base  ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"       
    xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#"    
    xmlns:owl ="http://www.w3.org/2002/07/owl#"
    xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:xsd ="http://www.w3.org/2001/XMLSchema#"> 

Dwie pierwsze deklaracje identyfikują przestrzeń nazw skojarzoną z tą ontologią. Pierwszy jest domyślną przestrzenią nazw, oznacza to że nieprefiksowane nazwy kwalifikatorów odnoszą się do bieżącej ontologii. Drugi identyfikuje przestrzeń nazw bieżącej ontologii z prefiksem vin:. Trzeci identyfikuje bazę URI dla tego dokumentu ( zobacz poniżej ). Czwarty identyfikuje przestrzeń nazw powiązanej ontologii jedzenie z prefiksem food:.

Piąta deklaracja przestrzeni nazw mówi, że w tym dokumencie elementy prefiksowane z owl: powinny być rozumiane jako odnoszące się do rzeczy zaczerpniętych z przestrzeni nazw zawartej w http://www.w3.org/2002/07/owl#. To jest konwencjonalna deklaracja OWL-a, używana do wprowadzenia słownictwa OWL-a.

OWL zależy od konstrukcji typów danych zdefiniowanych przez RDF, RDFS i XML Schema. W tym dokumencie prefiks rdf: odnosi się do rzeczy zaczerpniętych z przestrzeni nazw zawartej w http://www.w3.org/1999/02/22-rdf-syntax-ns#. Dwie następne deklaracje przestrzeni nazw zapewniają podobne stwierdzenia dotyczące RDF Schema (rdfs:) i typu danych XML Schema (xsd:).

Jako środek pomocniczy do przydługich napisów URL, często można zastosować zestaw użytecznych definicji podmiotów w typie deklaracji dokumentu (DOCTYPE), które wyprzedzają definicje ontologii. Nazwy definiowane przez deklaracje przestrzeni nazw mają znaczenie tylko jako część znacznika XML. Wartości atrybutów nie są wyczulone na przestrzeń nazw. Ale w OWL-u często odnosimy się do identyfikatorów ontologii używając wartości atrybutów. Mogą zostać zapisane w swojej pełnej formie, na przykład "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot". Alternatywnie, skróty mogą być definiowane przy użyciu definicji podmiotu, na przykład:

<!DOCTYPE rdf:RDF [
    <!ENTITY vin  "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" >
    <!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" > ]>

Po parze deklaracji podmiotów, możemy zapisać wartość "&vin;merlot" i zostanie ona rozwinięta do "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot".

Być może ważniejsze jest to, że deklaracje przestrzeni nazw rdf:RDF mogą zostać uproszczone, tak że zmiany w deklaracji podmiotów przeniosą się konsekwentnie na całą ontologię.

<rdf:RDF 
    xmlns     ="&vin;" 
    xmlns:vin ="&vin;" 
    xml:base  ="&vin;" 
    xmlns:food="&food;"
    xmlns:owl ="http://www.w3.org/2002/07/owl#"
    xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:xsd ="http://www.w3.org/2001/XMLSchema#"> 

2.2. Nagłówki ontologii

Kiedy przestrzenie nazw są ustalone, następnie załączamy zbiór twierdzeń o ontologii zgrupowanych pod znacznikiem owl:Ontology. Te znaczniki utrzymują podstawowe porządkowe zadania, takie jak komentarze, kontrolę wersji i dołączenie innych ontologii.

<owl:Ontology rdf:about=""> 
  <rdfs:comment>An example OWL ontology</rdfs:comment>

  <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/PR-owl-guide-20031215/wine"/> 
  <owl:imports rdf:resource="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food"/> 
  <rdfs:label>Wine Ontology</rdfs:label> 
  ...

Zauważ, że używamy '...' aby zaznaczyć że jest jeszcze dodatkowy tekst, który został skrócony na potrzeby tego przykładu.

Element owl:Ontology jest obszarem zbierającym znaczną część meta-danych dokumentu OWL-a. To jednak nie zapewnia, że dokument opisuje ontologię w tradycyjny sposób. W niektórych środowiskach, ontologie nie są o indywiduach, ale tylko o klasach i własnościach, które definiują domeny. Kiedy używamy OWL-a do opisania zbioru danych o instancji, może być potrzebny znacznik owl:Ontology, aby zapisać informacje o wersji i importować definicje od których zależy dokument. Zatem, w OWL-u określenie ontologia zostało poszerzone, aby zawierać instancje danych (zobacz powyżej).

Atrybut rdf:about zapewnia nazwę lub referencję ontologii. Gdzie wartością atrybutu jest "". Standardowy przypadek, nazwa ontologii jest podstawowy URI elementu owl:Ontology. Typowo jest to URI dokumentu zawierającego ontologię. Wyjątkiem od tego jest użycie xml:base, które może zmienić podstawowe URI elementu na coś innego niż URI bieżącego dokumentu.

rdfs:comment zapewnia potrzebną zdolność do komentowania ontologii.

owl:priorVersion jest standardowym znacznikiem przeznaczonym aby zapewnić punkt odniesienia dla systemu kontroli wersji pracującego z ontologią. Kontrola wersji ontologii jest omówiona dalej.

owl:imports zapewnia dołączanie mechanizmu stylu. owl:imports dołącza pojedynczy argument zidentyfikowany przez atrybut rdf:resource.

Importowanie innej ontologii sprowadza cały zbiór twierdzeń dostarczonych przez tą ontologię do bieżącej ontologii. Aby najlepiej wykorzystać importowaną ontologię normalnie użylibyśmy deklaracji przestrzeni nazw. Zauważmy różnice między tymi dwoma mechanizmami. Deklaracja przestrzeni nazw dostarcza wygodny sposób nawiązania do nazw zdefiniowanych w innych ontologiach OWL-a. Ogólnie, owl:imports zapewnia przewidzenie twojego zamiaru załączenia twierdzeń zamierzonej ontologii. Importowanie innej ontologii, O2, importuje również wszystkie ontologie importowane przez O2.

Zauważmy, że owl:imports może nie zawsze działać. Czego można się spodziewać pracując na Sieci Semantycznej, dostęp do zasobów rozprzestrzenionych w sieci nie zawsze może być możliwy. W takiej sytuacji narzędzia zadziałają zgodnie z wcześniejszą implementacją.

Zauważmy, że aby używać słownictwa OWL-a nie potrzebujemy importować ontologii owl.rdf. W zasadzie taki import nie jest polecany.

Jeden wspólny zbiór dodatkowych znaczników, który mógłby zostać tutaj (rozsądnie) dołączony to niektóre standardowe znaczniki meta-danych Dublin Core. Podzbiór po prostu dołącza typy lub ciągi jako wartości. Przykłady zawierają Tytuł, Autora, Opis, Wydawcę i Datę ( zobacz deklaracje RDF).

Własności, które używamy jako adnotacje powinny być deklarowane przy użyciu owl:AnnotationProperty. Na przykład

<owl:AnnotationProperty rdf:about="&dc;creator" />

OWL zapewnia kilka innych mechanizmów do powiązania bieżącej ontologii z ontologią importowaną (zobacz mapowanie ontologii).

Dołączamy również rdfs:label aby wspomóc etykiety w naturalnym języku w naszej ontologii.

Nagłówek definicji ontologii jest zamykany następującym znacznikiem.

</owl:Ontology>

Po nim następują faktyczne definicje, które tworzą ontologię i ostatecznie zamknięty przez

</rdf:RDF>

2.3. Agregacja danych i prywatność

Możliwości OWL-a do wyrażania ontologicznych informacji o instancjach pojawiających się w wielu dokumentach wspiera scalanie danych z wydzielonych źródeł w zasadniczy sposób. Odpowiednia semantyka zezwala na tworzenie wniosków na podstawie tych danych, które mogą dawać niespodziewane rezultaty. W szczególności, możliwość wyrażenia równoważności przy użyciu owl:sameAs, umożliwia stwierdzenie, że pozornie różne indywidua są w zasadzie takie same. Owl:InverseFunctionalProperty może również łączyć razem indywidua. Na przykład, jeśli własność taka jak "SpecjalnyNumerBezpieczeństwa" jest owl:InverseFunctionalProperty, wtedy dwa oddzielne indywidua mogą być identyczne, wnioskując na podstawie posiadania takiej samej wartości tej własności. Kiedy indywidua w tym sensie zostaną określane jako takie same, to informacje o nich zawarte w różnych źródłach mogą być scalone. Ta agregacja może być użyta do określania faktów, które nie są bezpośrednio reprezentowane przez żadne źródło.

Możliwość Sieci Semantycznych do łączenia informacji z wielu różnych źródeł jest pożądaną i mocną stroną (cechą) w wielu aplikacjach. Jednak zdolność scalania danych z wielu źródeł, połączona z wnioskowaniem OWL-a może być nadużywana. Użytkownicy OWL-a powinni zwracać uwagę na potencjalne problemy prywatności. Szczegółowe rozwiązania ochrony były rozważane marginalnie przez Grupę Roboczą. Kilka organizacji zwróciło się w tej sprawie z wieloma różnymi rozwiązaniami w zakresie bezpieczeństwa i preferencji. Zobacz, na przykład SAML i P3P.

3. Podstawowe elementy

Większość elementów ontologii OWL-a dotyczy klas, własności, instancji klas i związków między instancjami. Ta sekcja prezentuje niezbędne komponenty do przedstawienia tych elementów.

3.1. Pojedyncze klasy i indywidua

Wielu użytkowników ontologii będzie chciało wykorzystać możliwość wnioskowania o indywiduach. Aby móc to efektywnie robić, musimy mieć mechanizm opisu klas, do których należą indywidua, i własności, które dziedziczą przez członkostwo w klasie. Zawsze możemy przypisać specyficzne własności indywiduom, ale znaczna część skuteczności ontologii pochodzi z wnioskowania opartego na klasach.

Czasami chcemy podkreślić rozróżnienie między klasą jako obiektem i klasą jako zbiorem zawierającym elementy. Ten zbiór jednostek, należącymi do danej klasy, nazywamy rozszerzeniem tej klasy.

3.1.1. Pojedyncze nazwy klas
Class, rdfs:subClassOf

Podstawowym założeniem domeny powinno być współdziałanie z klasami, które są korzeniami różnych drzew taksonomii. Każde indywiduum w świecie OWL-a jest członkiem klasy owl:Thing. Zatem każda klasa definiowana przez użytkownika jest pośrednio podklasą owl:Thing. Specyficzne podstawowe klasy domeny są definiowane poprzez prostą deklaracją nazwy klasy. OWL również deklaruje pustą klasę, owl:Nothing.

Dla naszej prostej domeny win, tworzymy trzy klasy: Winery, Region, i ConsumableThing.

<owl:Class rdf:ID="Winery"/> 
<owl:Class rdf:ID="Region"/> 
<owl:Class rdf:ID="ConsumableThing"/> 

Zauważ, że tylko powiedzieliśmy o istnieniu klas, którym nadane zostały nazwy wskazane składnią 'rdf:ID='. Formalnie prawie nic o nich nie wiemy, oprócz tego że istnieją, pomijając użycie (znanych) angielskich określeń jako etykiet. Podczas gdy klasy istnieją, mogą nie mieć żadnych członków. Na tę chwilę, te klasy mogłyby się równie dobrze nazywać Thing1, Thing2 i Thing3.

Ważne, aby pamiętać, że definicje mogą być rozwijane i rozprzestrzeniane. W szczególności, będziemy mieli więcej do powiedzenia o Winery później.

Składnia rdf:ID="Region" jest użyta do wprowadzenia nazwy, jako części jej definicji. To jest atrybut rdf:ID ([RDF], 7.2.22), który jest jak podobny atrybut ID definiowany przez XML. W tym dokumencie do klasy Region można się teraz odwołać używając #Region, na przykład rdf:resource="#Region". Inne ontologie mogą się do niej odwołać używając jej pełnej formy, "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Region".

Inna forma odwołania używa składni rdf:about="#Region" do poszerzenia definicji zasobu. Takie użycie składni rdf:about="&ont;#x" zasadniczym elementem w tworzeniu łatwej do rozprzestrzenienia ontologii. Pozwala to na poszerzenie importowanych definicji x bez modyfikowania oryginalnego dokumentu i wspomaga rozwijalną konstrukcję większej ontologii.

Teraz możliwe jest odwoływanie się do klas zdefiniowanych w innych konstrukcjach OWL-a używając nadanych im identyfikatorów. Dla pierwszej klasy, w tym dokumencie, możemy użyć względnego identyfikatora #Winery. Inne dokumenty mogą również potrzebować odwołać się do tej klasy. Najrozsądniejszym sposobem, aby to zrobić, jest zapewnienie przestrzeni nazw i definicji podmiotu, które zawierają definiowany dokument jako źródło:

...
<!ENTITY vin  "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" >
<!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" >
...
<rdf:RDF xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
         xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" ... >
...

Mając te definicje możemy się odwołać do klasy win albo używając znacznika XML vin:Winery lub wartości atrybutu &vin;Winery. Bardziej formalnie, zawsze możemy się odwołać do zasobu używając jego pełnego URI, tutaj http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Winery.

Fundamentalnym konstruktorem taksonomii klasy jest rdfs:subClassOf. Wiąże on bardziej szczegółową klasę do bardziej ogólnej klasy. Jeśli X jest podklasą Y, wtedy każda instancja X jest również instancją Y. Relacja rdfs:subClassOf jest przechodnia. Jeśli X jest podklasą Y, a Y jest podklasą Z, to wtedy X jest podklasą Z.

<owl:Class rdf:ID="PotableLiquid"> 
  <rdfs:subClassOf rdf:resource="#ConsumableThing" />
  ...

</owl:Class> 

Definiujemy PotableLiquid (płyn nadający się do picia) jako podklasę ConsumableThing.

W świecie sieciowo opartych ontologii, obie te klasy mogą być zdefiniowane w oddzielnej ontologii. Zapewnia to podstawowe bloczki dla dużej różnorodności ontologii jedzenia i picia, co właśnie zrobiliśmy - są zdefiniowane w ontologii jedzenie, która jest importowana do ontologii wina. Ontologia jedzenie zawiera kilka klas, na przykład Food, EdibleThing, MealCourse, i Shellfish, które nie należą do faktów związanych z winem, ale muszą być z nim połączone jeśli chcemy wykorzystać przeprowadzone wnioskowanie. Jedzenie i wino muszą być wzajemnie zależne, abyśmy mogli identyfikować pary wino/jedzenie pasujące do siebie.

Definicja klasy ma dwie części: określenia nazwy lub referencji i listy ograniczeń. Każde z wyrażeń zawartych w definicji klasy dalej ogranicza instancje zdefiniowanej klasy. Instancje klasy są wynikiem ograniczeń. (Zobacz szczegóły owl:equivalentClass.) Do tej pory widzieliśmy przykłady zawierające pojedyncze ograniczenia, zmuszając nową klasę, aby była podklasą innej nazwanej klasy.

Obecnie możemy stworzyć prostą ( i niekompletną ) definicję kalsy Wine. Wine jest PotableLiquid. Definiujemy również Pasta jako EdibleThing.

<owl:Class rdf:ID="Wine"> 
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> 
  <rdfs:label xml:lang="en">wine</rdfs:label> 
  <rdfs:label xml:lang="fr">vin</rdfs:label> 
  ...  
</owl:Class> 


<owl:Class rdf:ID="Pasta">
  <rdfs:subClassOf rdf:resource="#EdibleThing" />
  ...
</owl:Class>

Zapis rdfs:label zapewnia opcjonalną nazwę klasy zrozumiałą przez człowieka. Interfejsy mogą to wykorzystywać do komunikacji z człowiekiem. Atrybut "lang" umożliwia wykorzystanie wielojęzykowego nazewnictwa. Etykieta jest jak komentarz i nie wnosi nic do logicznej interpretacji ontologii.

Nasza definicja wina jest dalej bardzo niekompletna. Nie wiemy nic o winach poza tym, że są rzeczami i płynami pitnymi. Mamy jednak wystarczająco informacji, aby tworzyć indywidua i o nich wnioskować.

3.1.2. Indywidua

Dodatkowo, prócz klas, chcemy móc opisywać jej członków. Normalnie myślimy o nich jako o indywiduach w naszym wszechświecie rzeczy. Minimalistyczne przedstawienie indywiduum odbywa się poprzez deklarację jej jako członka klasy.

<Region rdf:ID="CentralCoastRegion" /> 

Zauważ, że następująca deklaracja jest identyczna w znaczeniu jak powyższy przykład.

<owl:Thing rdf:ID="CentralCoastRegion" /> 

<owl:Thing rdf:about="#CentralCoastRegion"> 
   <rdf:type rdf:resource="#Region"/> 
</owl:Thing>

rdf:type jest własnością RDF, która wiąże indywiduum do klasy, której jest członkiem.

Trzeba tu wspomnieć o kilku rzeczach. Po pierwsze, zdecydowaliśmy że CentralCoastRegion ( określony obszar ) jest członkiem Region, klasy zawierającej wszystkie regiony geograficzne. Po drugie, nie jest wymagane w przykładzie, aby dwa elementy sąsiadowały ze sobą lub nawet znajdowały się w tym samym pliku ( jednak w takim przypadku nazwy musiałyby być rozszerzone o URI ). Projektujemy ontologie sieciowe w taki sposób, aby dały się rozprzestrzeniać. Mogą one być importowane i rozszerzane, tworząc pochodne ontologie.

Aby móc przedstawić własności w następnej sekcji, definiujemy jeszcze kilka klas. Definiujemy gałąź taksonomii Grape, z indywiduum oznaczającym winogrona typu Cabernet Sauvignon. Winogrona są zdefiniowane w ontologii jedzenie:

<owl:Class rdf:ID="Grape">
  ...
</owl:Class>

I wtedy w ontologii wina mamy:

<owl:Class rdf:ID="WineGrape">
  <rdfs:subClassOf rdf:resource="&food;Grape" />

</owl:Class>

<WineGrape rdf:ID="CabernetSauvignonGrape" />

Jak omawiane w następnej sekcji, CabernetSauvignonGrape jest indywiduum, ponieważ oznacza pojedynczy typ winogrona.

3.1.3. Wzorce do użycia

Pojawiają się istotne problemy w odniesieniu do rozróżnienia między klasą i indywiduum w OWL-u. Klasa jest po prostu nazwą i zbiorem własności, które opisują zbiór indywiduów. Indywidua są członkami tych zbiorów. Zatem klasy powinny współpracować z naturalnie pojawiającym się zbiorem rzeczy w omawianej domenie, i indywidua powinny współpracować z aktualnymi podmiotami, które mogą być zgrupowane w tych klasach.

W tworzeniu ontologii to rozróżnienie jest często rozmyte na dwa sposoby:

• Poziomy reprezentacji: W konkretnym kontekście, coś co jest oczywiste jako klasa może być uznane za instancję czegoś innego. Na przykład, w ontologii wina mamy pojęcie Grape, oznaczające zbiór wszystkich typów winogron. CabernetSauvingonGrape jest przykładem instancji tej klasy, jako że oznacza właśnie typ winogron zwany Cabernet Sauvignon. Jednak CabernetSauvignonGrape może zostać uznany za klasę, zbiór wszystkich faktycznych winogron Cabernet Sauvignon.
  
  
• Podklasa a instancja: Bardzo łatwo jest pomylić związek instancji ze związkiem podklasy. Na przykład, wydawać się może oczywiste określenie CabernetSauvignonGrape jako indywidua, która jest instancją Grape, w przeciwieństwie do podklasy Grape. Nie jest to taka oczywista decyzja. Klasa Grape oznacza zbiór wszystkich typów winogron, i dlatego każda podklasa Grape powinna oznaczać podzbiór tych typów. Zatem CabernetSauvignonGrape powinna być uważana za instancję Grape, a nie podklasę. To nie opisuje podzbioru typów winogron, to jest typem winogron.

Zauważ, że to samo tyczy się klasy Wine. Klasa Wine oznacza zbiór wszystkich typów wina, nie zaś faktyczny zbiór butelek, które ktoś może kupić. W alternatywnej ontologii, każda instancja Wine z bieżącej ontologii, mogłaby wyznaczać klasę zawierającą wszystkie butelki wina jednego typu. £atwo jest wyobrazić sobie system informacyjny, taki jak system inwentaryzacji sprzedawcy win, który uwzględnia pojedyncze(indywidualne) butelki wina. Aby było to możliwe w ontologia wina w jej obecnym stanie, wymagana jest możliwości traktowania klas jako instancji. Zauważmy, że OWL Full pozwala na to, możemy traktować instancję typów wina równocześnie jako klasę, której instancją są butelki wina.

Podobnie, wina produkowane przez winiarnie w konkretnym latach są uznawane za roczniki wina. Aby pokazać pojęcie rocznika, musimy określić jego miejsce w bieżącej ontologii. Instancja klasy Wine, jak omówiona powyżej, reprezentuje pojedynczy typ produkowanego wina przez pojedynczą winiarnię, na przykład FormanChardonnay.

Dodając, że wino wyprodukowane w roku 2000 jest uważane za rocznik sprawia trudność, ponieważ nie mamy możliwości reprezentowania podzbioru danego indywiduum wina. Rocznik nie jest nowym typem wina, jest specjalnym podzbiorem wina, który został wyprodukowany w 2000 roku. Opcją byłoby użycie OWL DL i traktowanie instancji wina jako klasy z podklasą ( podzbiorem ) oznaczającym rocznik. Inną opcją jest użycie obejścia i uznanie Vintage jako osobnej klasy, której instancje są związane z Winem, bo są z rocznika. Na przykład, FormanChardonnay2000 jest indywiduum Vintage z własnością vintageOf, której wartością jest Wine, FormanChardonnay. Poniżej definiujemy klasę Vintage.

Istotą tej dyskusji jest zauważenie, że rozwój ontologii powinien być w głównej mierze prowadzony przez potrzebę. Ta kwestia podkreśla również główną różnicę pomiędzy OWL Full i OWL DL. OWL Full pozwala na użycie klas jako instancji, a OWL DL nie. Ontologia wina została zaprojektowana pod OWL DL, co sprawia że indywiduum takie jak FormanChardonnay nie są równocześnie traktowane jako klasy.

3.2. Pojedyncze własności

świat klas i indywiduów byłby mało interesujący, gdybyśmy mogli definiować tylko taksonomie. Własności pozwalają nam zapewnić ogólne fakty o członkach klas i specyficzne fakty o indywiduach.

3.2.1. Definiowanie własności
ObjectProperty, DatatypeProperty, rdfs:subPropertyOf,
rdfs:domain, rdfs:range

Własność jest relacją binarną. Wyróżniamy dwa rodzaje własności:

• własności typu danych, relacja między instancjami klas i formalnym RDF, i typami danych XML Schema
• własności objektów, relacja między instancjami dwóch klas. Zauważ, że nazwa własności obiektu nie odnosi się do terminu z RDF-a rdf:object ([RDF], 5.3.4).

Kiedy definiujemy własność istnieje kilka sposobów aby ograniczyć relację. Możemy określić dziedzinę i zakres. Własność może być zdefiniowana jako sprecyzowanie ( podwłasność ) istniejącej własności. Bardziej złożone ograniczenia są możliwe i opisane później.

<owl:ObjectProperty rdf:ID="madeFromGrape"> 
  <rdfs:domain rdf:resource="#Wine"/>

  <rdfs:range rdf:resource="#WineGrape"/> 
</owl:ObjectProperty> 

<owl:ObjectProperty rdf:ID="course">
  <rdfs:domain rdf:resource="#Meal" />
  <rdfs:range rdf:resource="#MealCourse" />
</owl:ObjectProperty>

W OWL-u sekwencja elementów bez wyraźnego operatora reprezentuje bezwarunkowy łącznik. Własność madeFromGrape ma dziedzinę Wine i zakres WineGrape. To znaczy, łączy instancję klasy Wine z instancją klasy WineGrape. Wielokrotne dziedziny oznaczają, że dziedzina własności jest częścią wspólną identyfikowanych klas ( podobnie jest dla zakresu ).

Podobnie, własność course łączy Meal z MealCourse.

Zauważ, że używanie informacji o zakresie i dziedzinie w OWL-u jest inne niż typ informacji w języku programowania. Między innymi, typy są używane do sprawdzenia spójności języka programowania. W OWL-u zakres może być użyty aby wywnioskować typ. Na przykład, mamy:

<owl:Thing rdf:ID="LindemansBin65Chardonnay">

  <madeFromGrape rdf:resource="#ChardonnayGrape" />
</owl:Thing>                                              ¬ 

możemy wywnioskować, że LindemansBin65Chardonnay jest winem, ponieważ dziedziną madeFromGrape jest Wine.

Własności, jak klasy, mogą być zorganizowane w hierarchii.

<owl:Class rdf:ID="WineDescriptor" />

<owl:Class rdf:ID="WineColor">
  <rdfs:subClassOf rdf:resource="#WineDescriptor" />
  ...
</owl:Class>

<owl:ObjectProperty rdf:ID="hasWineDescriptor">
  <rdfs:domain rdf:resource="#Wine" />
  <rdfs:range  rdf:resource="#WineDescriptor" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasColor">
  <rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" />

  <rdfs:range rdf:resource="#WineColor" />
  ...
</owl:ObjectProperty>

Własności WineDescriptor wiążą wina do ich koloru i komponentów ich smaku, zawierających słodkość, gęstość i bukiet. hasColor jest podwłasnością własności hasWineDescriptor, z zakresem ograniczonym do WineColor. W tym przypadku związek rdfs:subPropertyOf oznacza, że cokolwiek z własnością hasColor z wartością X ma również własność hasWineDescriptor z wartością X.

Następnie prezentujemy własność locatedIn, która wiąże rzeczy do regionów w których są zlokalizowane.

<owl:ObjectProperty rdf:ID="locatedIn">

  ...
  <rdfs:domain rdf:resource="http://www.w3.org/2002/07/owl#Thing" />
  <rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>

Zwróć uwagę na to jak są zdefiniowane dziedzina i zakres locatedIn. Dziedzina zezwala wszystkiemu, aby było zlokalizowane w regionie, również samemu regionowi. Zestawienie przechodnie tej relacji zasadniczo tworzy sieć geograficznie powiązanych podregionów i rzeczy. Te rzeczy, które nie mają w sobie nic zlokalizowanego mogą być dowolnej klasy, podczas gdy te zawierające inne muszą być regionami.

Teraz możemy rozwinąć definicję Wine, aby uwzględniała, że wino jest zrobione z co najmniej jednego WineGrape. Jak z definicjami własności, definicje klas mają wiele podczęści, które są bezwarunkowo złączone.

<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>

  ...  
</owl:Class>

Wyróżnioną podklasę ograniczoną powyżej

    <owl:Restriction> 
      <owl:onProperty rdf:resource="#madeFromGrape"/>
      <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>

    </owl:Restriction> 

definiuje nienazwana klasa, która reprezentuje zbiór rzeczy z przynajmniej jedną własnością madeFromGrape. Nazywamy je anonimowymi klasami. Biorąc pod uwagę te ograniczenia w klasie Wine definicja gęstości(klarowności) stwierdza, że rzeczy które są winami są również członkami tych anonimowych klas. To znaczy, każde indywiduum wina musi brać udział w przynajmniej jednej relacji madeFromGrape.

Teraz możemy opisać klasę Vintage, omówioną wcześniej.

<owl:Class rdf:ID="Vintage"> 
  <rdfs:subClassOf>
    <owl:Restriction> 
      <owl:onProperty rdf:resource="#vintageOf"/>

      <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>                                              ¬ 

Własność vintageOf łączy Vintage z Wine.

<owl:ObjectProperty rdf:ID="vintageOf">
  <rdfs:domain rdf:resource="#Vintage" />

  <rdfs:range  rdf:resource="#Wine" />
</owl:ObjectProperty>                                     ¬ 

Wiążemy Vintage do roku wyprodukowania w następnej sekcji.

3.2.2. Własności i typy danych

Rozróżniamy własności w zależności od tego czy wiążą indywidua do indywiduów ( własności obiektu ), czy indywidua do typów danych ( własności typów danych ). Własności typów danych mogą być poza zakresem formalnego RDF-a lub prostymi typami definiowanymi zgodnie z typami danych XML Schema.

OWL używa większości wbudowanych typów danych XML Schema. Odwołania do tych typów danych są poprzez odwołania URI dla typów danych, http://www.w3.org/2001/XMLSchema. Następujące typy danych są rekomendowane do używania z OWL-em.

Powyższe typy danych, plus rdfs:Literal, formułują wbudowane typy danych OWL-a. Wszystkie wnioskowania OWL-a muszą wspierać xsd:integer i xsd:string tzp danych.

Inny wbudowany typ danych XML Schema może być użyty w OWL Full, ale z zastrzeżeniami opisanymi w OWL Semantyka i lista składni dokumencie.

<owl:Class rdf:ID="VintageYear" />

<owl:DatatypeProperty rdf:ID="yearValue">
  <rdfs:domain rdf:resource="#VintageYear" />    
  <rdfs:range  rdf:resource="&xsd;positiveInteger"/>
</owl:DatatypeProperty> 

Własność yearValue łączy VintageYear z dodatnimi wartościami całkowitymi. Poniżej pokazujemy własność hasVintageYear, która łączy Vintage z VintageYear.

Referencje OWL-a ([Referencje], 6.2) opisuje używanie owl:oneOf, rdf:List i rdf:rest do definiowania wyliczeniowych typów danych. Przykład pokazuje, jak skonstruować owl:DatatypeProperty i tennisGameScore, z zakresami równymi elementom listy z całkowitymi wartościami {0, 15, 30, 40}.

3.2.3. Własności indywiduów

Najpierw opisujemy indywidua Region i Winery, potem definiujemy nasze pierwsze wino, Cabernet Sauvignon.

<Region rdf:ID="SantaCruzMountainsRegion">
  <locatedIn rdf:resource="#CaliforniaRegion" />
</Region>

<Winery rdf:ID="SantaCruzMountainVineyard" />

<CabernetSauvignon
  rdf:ID="SantaCruzMountainVineyardCabernetSauvignon" >
  <locatedIn   rdf:resource="#SantaCruzMountainsRegion"/>  
  <hasMaker    rdf:resource="#SantaCruzMountainVineyard" />   

</CabernetSauvignon>  

To jest dalej niekompletne. Są inne aspekty bukietu wina, które są zdefiniowane w pełnej ontologii. Jednak kawałki zaczynają do siebie pasować tworząc całość. Moglibyśmy zacząć wnioskować o tym, którym pozycjom menu w naszej ontologii jedzenie mogłoby towarzyszyć to wino. Wiemy z powyższej definicji, że Santa Cruz Mountain Vineyard je wytwarza. Ponieważ jest to Cabernet Sauvignon (zobacz wine.rdf), wiemy że jest to czerwone wino wytrawne.

Własności typu danych mogą być dodane do indywiduów w podobny sposób. Poniżej opisujemy instancję VintageYear i wiążemy ją ze specyficzną wartością typu &xsd:positiveInteger.

<VintageYear rdf:ID="Year1998">
  <yearValue rdf:datatype="&xsd;positiveInteger">1998</yearValue>
</VintageYear> 

3.3. Charakterystyki własności

Kilka następnych sekcji opisuje mechanizmy używane do dalszej specyfikacji własności. Można określić charakterystyki, które zapewniają skuteczny mechanizm zaawansowanego wnioskowania o własności.

3.3.1. TransitiveProperty

Jeśli własność P jest określona jako przechodnia, wtedy dla każdego x, y i z:

P(x,y) and P(y,z) implies P(x,z)

Własność locatedIn jest przechodnia.

<owl:ObjectProperty rdf:ID="locatedIn">
  <rdf:type rdf:resource="&owl;TransitiveProperty" />
  <rdfs:domain rdf:resource="&owl;Thing" />

  <rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>

<Region rdf:ID="SantaCruzMountainsRegion">
  <locatedIn rdf:resource="#CaliforniaRegion" />
</Region>

<Region rdf:ID="CaliforniaRegion">
  <locatedIn rdf:resource="#USRegion" />

</Region>

SantaCruzMountainsRegion jest locatedIn w CaliforniaRegion, to musi również być locatedIn w USRegion, ponieważ locatedIn jest przechodnia.

3.3.2. SymmetricProperty

Jeśli własność P jest oznaczona jako symetryczna, wtedy dla każdego x i y:

P(x,y) iff P(y,x)

Własność adjacentRegion jest symetryczna, podczas gdy locatedIn nie jest. Mówiąc dokładniej, locatedIn nie była zamierzona aby być symetryczną. Nic w ontologii wina w jej obecnym stanie nie przeszkadza aby była ona symetryczna.

<owl:ObjectProperty rdf:ID="adjacentRegion">

  <rdf:type rdf:resource="&owl;SymmetricProperty" />
  <rdfs:domain rdf:resource="#Region" />
  <rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>

<Region rdf:ID="MendocinoRegion">
  <locatedIn rdf:resource="#CaliforniaRegion" />

  <adjacentRegion rdf:resource="#SonomaRegion" />
</Region>

MendocinoRegion jest przyległa do SonomaRegion i wzajemnie. MendocinoRegion jest zlokalizowana w CaliforniaRegion ale nie na odwrót.

3.3.3. FunctionalProperty

Jeśli własność P jest oznaczona jako funkcjonał, wtedy dla każdego x, y i z:

P(x,y) and P(x,z) implies y = z 

W naszej ontologii wina hasVintageYear jest funkcjonałem. Wino ma unikalny rocznik. To znaczy, dane indywiduum Vintage może być stowarzyszona z pojedynczym rokiem, używając własności hasVintageYear. Nie jest wymagane przez owl:FunctionalProperty aby wszystkie elementy dziedziny miały wartości. Zobacz dyskusję o liczności Vintage.

<owl:Class rdf:ID="VintageYear" />

<owl:ObjectProperty rdf:ID="hasVintageYear">
  <rdf:type rdf:resource="&owl;FunctionalProperty" />
  <rdfs:domain rdf:resource="#Vintage" />
  <rdfs:range  rdf:resource="#VintageYear" />

</owl:ObjectProperty>

3.3.4. inverseOf

Jeśli własność P1 jest oznaczona jako owl:inverseOf P2, wtedy dla każdego x i y:

P1(x,y) iff P2(y,x)

Zauważ, że składnia owl:inverseOf traktuje nazwę własności jako argument. A iff B oznacza (A implies B) i (B implies A).

<owl:ObjectProperty rdf:ID="hasMaker">

  <rdf:type rdf:resource="&owl;FunctionalProperty" />
</owl:ObjectProperty>
  
<owl:ObjectProperty rdf:ID="producesWine">
  <owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>

Wine ma twórców, którzy w definicji Wine są ograniczeniu do Winety. Wtedy każda Winery produkuje zbiór win, który identyfikuje ją jako twórcę.

3.3.5. InverseFunctionalProperty

Jeśli własność P jest oznaczona jako InverseFunctional, wtedy dla każdego x, y i z:

P(y,x) and P(z,x) implies y = z 

Zauważ, że producesWine w następnych sekcjach jest funkcjonałem odwrotnym. Powód, własność funkcjonału odwrotnego musi być funkcjonałem odwrotnym. Moglibyśmy zdefiniować hasMaker i producesWine w taki sposób, aby otrzymać identyczne efekty jak w poniższym przykładzie.

<owl:ObjectProperty rdf:ID="hasMaker" />
  
<owl:ObjectProperty rdf:ID="producesWine">
  <rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
  <owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>                                     ¬ 

Myśl o elementach zakresu w własności funkcjonału odwrotnego jak o definiowaniu unikalnego klucza w sensie bazy danych. owl:InverseFunctional definiuje, że elementy zakresu zapewnią unikalny identyfikator dla każdego elementu dziedziny.

W OWL Full możemy oznaczyć DatatypeProperty jako InverseFunctional, to pozwala nam identyfikować ciąg znaków jako unikalny klucz. W OWL DL formalnie są rozłączne z owl:Thing, dlatego też OWL DL nie pozwala aby InverseFunctional odnosił się do DatatypeProperty.

3.4. Ograniczenia własności

Dodatkowo oprócz przypisywania charakterystyk własności możliwe jest dalsze ograniczanie zakresu własności w określonym kontekście. Robimy to wykorzystując ograniczenia własności. Różne formy opisane poniżej mogą być użyte tylko w kontekście owl:Restriction. Element owl:onProperty oznacza ograniczoną własność.

3.4.1. allValuesFrom, someValuesFrom

Widzieliśmy już jeden sposób aby ograniczyć typy elementów, które tworzą własność. Mechanizmy danych są globalne, więc odnoszą się do wszystkich instancji danej własności. Następne dwa, allValuesFrom i someValuesFrom, są lokalne w swojej zdefiniowanej klasie.

Ograniczenie owl:allValuesFrom wymaga, aby dla każdej instancji klasy, która ma instancje określonej własności, wszystkie wartości własności były członkami klasy oznaczonej klauzulą owl:allValuesFrom.

<owl:Class rdf:ID="Wine">
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
  ...
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasMaker" />

      <owl:allValuesFrom rdf:resource="#Winery" />
    </owl:Restriction>
  </rdfs:subClassOf>
  ...
</owl:Class>

Twórcą Wine musi być Winery. Ograniczenie allValuesFrom jest na własności hasMaker tylko dla klasy Wine. Twórcy Cheese nie są związani przez to lokalne ograniczenie.

Z owl:someValuesFrom jest podobnie. Jeśli owl:allValuesFrom zastąpimy owl:someValuesFrom w powyższym przykładzie, znaczyłoby to, że co najmniej jedna hasMaker własność Wine musi wskazywać na indywiduum, którym jest Winery.

<owl:Class rdf:ID="Wine">
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasMaker" />

      <owl:someValuesFrom rdf:resource="#Winery" />
    </owl:Restriction>
  </rdfs:subClassOf>
  ...
</owl:Class>                                             ¬ 

Różnica pomiędzy dwoma formułami, jest różnicą między uniwersalnym i egzystencjalnym kwalifikatorem.

Pierwsza nie wymaga aby wino miało twórcę. Jeśli ma jednego lub więcej, wszyscy muszą być winnicami. Druga wymaga, aby był przynajmniej jeden twórca, który jest winnicą, ale mogą być również twórcy, którzy nie są winnicami.

3.4.2. Liczność

Widzieliśmy już przykłady licznych ograniczeń. Do tej pory były one twierdzeniami o minimalnej liczności. Bardziej bezpośrednia jest owl:cardinality, która pozwala na sprecyzowanie dokładnej liczby elementów w relacji. Na przykład, precyzujemy Vintage aby było klasą z dokładnie jednym VintageYear.

<owl:Class rdf:ID="Vintage"> 
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasVintageYear"/>  
      <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>

    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

Określiliśmy hasVintageYear jako własność funkcjonału, co oznacza to samo co powiedzenie, że każdy rocznik ma co najwyżej jeden rok produkcji. Zastosowanie tej własności do Vintage przy użyciu liczności ograniczeń wyraża coś mocniejszego, że każdy Vintage ma dokładnie jeden VintageYear.

Wyrażenia liczności z wartościami ograniczonymi do 0 lub 1 są częścią OWL Lite. To pozwala użytkownikowi na określenia jak 'przynajmniej jeden', 'nie więcej niż jeden' i 'dokładnie jeden'. Dodatnie całkowite wartości inne niż 0 i 1 są dozwolone w OWL DL. owl:maxCardinality może być użyte do określenia górnej granicy. owl:minCardinality może być użyte do określenia dolnej granicy. W połączeniu oba mogą być użyte do ograniczenia liczności własności do przedziału numerycznego.

3.4.3. hasValue [OWL DL]

hasValue pozwala nam określać klasy w oparciu o istnienie szczególnych wartości własności. W związku z tym, indywiduum będzie członkiem takiej klasy zawsze gdy przynajmniej jedna z jej wartości własności jest równa zasobowi hasValue.

<owl:Class rdf:ID="Burgundy">
  ...
  <rdfs:subClassOf>

    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasSugar" />
      <owl:hasValue rdf:resource="#Dry" />
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

Tutaj deklarujemy, że wszystkie wina Burgundy są wytrawne. To znaczy, ich własność hasSugar musi mieć przynajmniej jedną wartość, która jest równa Dry.

Jeśli chodzi o allValuesFrom i someValuesFrom, jest to lokalne ograniczenie. Zawiera hasSugar jako zastosowane do Burgundy.

4. Mapowanie ontologii

Aby ontologie miały największy wpływ muszą być szeroko rozpowszechnione. Aby zminimalizować wysiłek intelektualny potrzebny do stworzenia ontologii muszą się nadawać do powtórnego użycia. W najlepszym ze wszystkich możliwych przypadków muszą być złożone. Na przykład, mógłbyś zastsować ontologie daty z jednego źródła i fizyczną lokalizację ontologii z innego, i wtedy rozszerzyć pojęcie lokalizacji aby zawierało okres czasu podczas którego to się utrzymuje.

Ważne, aby zdać sobie sprawę z tego, że większość wysiłku w tworzeniu ontologii jest poświęcone połączeniu razem klas i własności w taki sposób, aby zmaksymalizować wydajność wnioskowania. Chcemy aby proste zapewnienie członkostwa w klasie miały szerokie i użyteczne zastosowanie. To jest najtrudniejsza część tworzenia ontologii. Jeśli możesz znaleźć istniejącą ontologię, która już jest poszerzona i udoskonalona w odpowiadający ci sposób, to zaadaptowanie jej jest sensownym krokiem.

Wyzwaniem będzie scalenie zbioru ontologii. Aby zachować spójność powstałej całości, na pewno będzie potrzebne odpowiednie narzędzie.

4.1. Równoważność między klasami i własnościami
equivalentClass, equivalentProperty

Aby związać ze sobą zbiór częściowych ontologii jako część kolejnej, często pożyteczne jest określenie, że konkretna klasa lub własność w jednej ontologii jest równoważna klasie lub własności w drugiej ontologii. Ta możliwość powinna być używana z rozwagą. Jeśli połączone ontologie są sprzeczne ( 'wszystkie A są B' do 'wszystkie A nie są B' ) wtedy nie będzie żadnego rozszerzenia ( indywiduów i relacji ), które zadowoli powstałą kombinację.

W ontologii jedzenie chcemy połączyć cechy wina w opisie dań spowrotem do ontologii wina. Jednym ze sposobów jest zdefiniowanie klasy w ontologii jedzenie (&food;Wine) i zadeklarowanie jej równoważności do istniejącej klasy wina w ontologii wina.

<owl:Class rdf:ID="Wine">
  <owl:equivalentClass rdf:resource="&vin;Wine"/>
</owl:Class>

Własność owl:equivalentClass jest używana do określenia, że dwie klasy mają dokładnie te same instancje. Zauważ, że w OWL DL klasy po prostu oznaczają zbiory indywiduów, i nie są same indywiduami. Jednak w OWL Full możemy użyć owl:sameAs pomiędzy dwoma klasami, aby określić że są one identyczne w każdym względzie.

Oczywiście powyższy przykład jest w pewnym sensie sztucznie stworzony, ponieważ zawsze możemy użyć &vin;Wine wszędzie tam gdzie użylibyśmy #Wine i uzyskać ten sam efekt bez konieczności redefiniowania. Bardziej prawdopodobne użycie jest w przypadku gdy operujemy na dwóch niezależnie rozwiniętych ontologiach, i zauważ że używają URI O1:foo i O2:bar aby odwołać się do tej samej klasy. owl:equivalentClass może być użyte do scalenia ich razem, aby wnioski z obu ontologii były połączone.

Już widzieliśmy, że wyrażenia klasy mogą być celem konstrukcji rdfs:subClassOf. Mogą być również celem owl:equivalentClass. Znowu, niepotrzebne jest sztuczne tworzenie nazwy dla każdego wyrażenia klasy i zapewnia mocne definiowalne możliwości oparte na satysfakcji własności.

<owl:Class rdf:ID="TexasThings"> 
  <owl:equivalentClass>
    <owl:Restriction>

      <owl:onProperty rdf:resource="#locatedIn" />
      <owl:someValuesFrom rdf:resource="#TexasRegion" />
    </owl:Restriction>
  </owl:equivalentClass>
</owl:Class>                                                ¬ 

TexasThings są dokładnie tymi rzeczami umiejscowionymi w regionie Teksas. Różnica pomiędzy użyciem tutaj owl:equivalentClass a użyciem rdfs:subClassOf jest różnicą pomiędzy warunkiem koniecznym a warunkiem koniecznym i wystarczającym. Przy subClassOf rzeczy zlokalizowane w Teksasie nie są koniecznie TexasThings. Ale używając owl:equivalentClass, jeśli coś jest zlokalizowane w Teksasie, wtedy musi być a klasie TexasThings.

Aby związać w podobny sposób własności używamy owl:equivalentProperty.

4.2. Tożsamość między indywiduami
sameAs

Ten mechanizm jest podobny do tego dla klas, ale deklaruje dwa indywidua jako identyczne. Przykładem by było:

<Wine rdf:ID="MikesFavoriteWine"> 
  <owl:sameAs rdf:resource="#StGenevieveTexasWhite" /> 
</Wine>                                                  ¬ 

Ten przykład nie jest zbyt dobry. Wszystko czego się dowiedzieliśmy to, że Mike lubi niedrogie, lokalne wino. Bardziej typowym użyciem sameAs byłoby zrównanie indywiduów zdefiniowanych w różnych dokumentach do siebie nawzajem, jako część zjednoczenia dwóch ontologii.

To zwraca uwagę na ważną rzecz. OWL nie ma założenia o unikalnej nazwie. Tylko dlatego, że dwie nazwy są różne nie oznacza to, że odnoszą się do różnych indywiduów.

W powyższym przykładzie, zapewniamy tożsamość pomiędzy dwiema różnymi nazwami. Ale dla tego rodzaju tożsamości możliwe jest również proste dedukowanie. Pamiętaj o konsekwencjach, które mogą pochodzić z własności funkcjonału. Mając hasMaker jako funkcjonał, następujący przykład nie jest koniecznie sprzeczny.

<owl:Thing rdf:about="#BancroftChardonnay">
  <hasMaker rdf:resource="#Bancroft" />
  <hasMaker rdf:resource="#Beringer" />
</owl:Thing>                                             ¬ 

Dopuki nie jest to sprzeczne z innymi informacjami w naszej ontologii, oznacza to że Bancroft = Beringer.

Zauważ że użycie sameAs do zrównania dwóch klas nie jest tym samym ci zrównanie ich przy użyciu equivalentClass; natomiast, to sprawia że klasy są interpretowane jako indywidua, przez co jest lepiej kategoryzaować ontologie jak OWL Full. W OWL Full sameAs może być użyte do zrównania wszystkiego: klasy i indywidua, własności i klasy, itp. i sprawia że oba argumenty są interpretowane jako indywidua.

4.3. Różne indywidua
differentFrom, AllDifferent

Ten mechanizm zapewnia odwrotny efekt niż sameAs.

<WineSugar rdf:ID="Dry" />

<WineSugar rdf:ID="Sweet">  
  <owl:differentFrom rdf:resource="#Dry"/>  

</WineSugar> 

<WineSugar rdf:ID="OffDry">
  <owl:differentFrom rdf:resource="#Dry"/> 
  <owl:differentFrom rdf:resource="#Sweet"/> 
</WineSugar>

To jest jeden za sposobów zapewnienia, aby te trzy wartości były wzajemnie różne. Będzie przypadek gdzie ważne będzie zapewnienie tak różnych tożsamości. Bez tych zapewnień moglibyśmy opisać wino, które byłoby zarówno Dry jak i Sweet. Ustaliliśmy, że własność hasSugar odnosząca się do wina ma nie więcej niż jedną wartość. Jeśli na chwile założymy, że wino może być zarówno Dry jak i Sweet, bez powyższego elementu differentFrom, to by oznaczało że Dry i Sweet są identyczne. Z powyższymi elementami zamiast tego dostalibyśmy sprzeczność.

Istnieje wygodniejszy mechanizm do definiowania zbioru wzajemnie różnych indywiduów. Następujący przykład zapewnia, że Red, White i Rose są parami różne.

<owl:AllDifferent>
  <owl:distinctMembers rdf:parseType="Collection">
    <vin:WineColor rdf:about="#Red" />
    <vin:WineColor rdf:about="#White" />

    <vin:WineColor rdf:about="#Rose" />
  </owl:distinctMembers>
</owl:AllDifferent>

Zauważ, że owl:distinctMembers może być użyte tylko w połączeniu z owl:AllDifferent.

W ontologii wina zapewniamy założenia owl:AllDifferent dla wszystkich WineDescriptor. Również ustaliliśmy, że wszystkie Winery są różne. Gdybyśmy chcieli dodać nową winnicę w jakiejś innej ontologii i zapewnić rozłączność ze wszystkimi zdefiniowanymi do tej pory, potrzebowalibyśmy wyciąć i wkleić oryginalne owl:AllDifferent zapewnienie i dodać nowego twórcę do listy. Nie ma prostszego sposobu na poszerzenie owl:AllDifferent zbioru w OWL DL. W OWL Full, użycie potrójnego RDF-a i konstrukcji rdf:List, możliwe są inne podejścia.

5. Klasy złożone [OWL DL]

OWL zapewnia dodatkowe konstrukcje do tworzenia klas. Te konstrukcje mogą być użyte do tworzenia tak zwanych wyrażeń klas. OWL wspiera podstawowy zbiór operacji, mianowicie sumę, iloczyn i dopełnienie zbiorów. Nazywają się one odpowiednio owl:unionOf, owl:intersectionOf i owl:complementOf. Dodatkowo klasy mogą być numerowane. Rozszerzenia klasy mogą być wyraźnie ustalone przez konstrukcje oneOf. I można zapewnić, aby rozszerzenie klasy było rozłączne.

Zauważ, że wyrażenia klas mogą być zagnieżdżone bez potrzeby tworzenia nazwy dla każdej pośredniej klasy. To pozwala na użycie zbioru operacji do budowy złożonych klas z anonimowych klas lub klas z ograniczonymi wartościami.

5.1. Zbiór operatorów
intersectionOf, unionOf, complementOf

Pamiętaj, że rozszerzenia klasy w OWL-u są zbiorem zawierającym indywidua, które są członkami klasy. OWL zapewnia środki do manipulowania rozszerzeniami klas przy użyciu podstawowego zbioru operatorów.

5.1.1. Iloczyn zbiorów [niektóre możliwości OWL DL]

Następujący przykład demonstruje użycie konstrukcji intersectionOf.

<owl:Class rdf:ID="WhiteWine">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Wine" />
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasColor" />
      <owl:hasValue rdf:resource="#White" />

    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

Klasy stworzone przy użyciu zbioru operacji są bardziej jak definicje niż cokolwiek co widzieliśmy do tej pory. Członkowie klas są całkowicie określeni przez zbiór operacji. Powyższa konstrukcja oznacza że WhiteWine jest dokładnie iloczynem klasy Wine i zbioru rzeczy, które są białego koloru. To znaczy, że jeśli coś jest białe i jest winem, wtedy jest instancją WhiteWine. Bez takiej definicji możemy wiedzieć, że białe wina są winami i są białe, ale nie na odwrót. Jest to ważne narzędzie do kategoryzacji indywiduów. ( Zauważ, że 'rdf:parseType="Collection"'jest wymaganym elementem składniowym. )

<owl:Class rdf:about="#Burgundy">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Wine" />
    <owl:Restriction>
      <owl:onProperty rdf:resource="#locatedIn" />
      <owl:hasValue rdf:resource="#BourgogneRegion" />

    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

Tutaj definiujemy Burgundy, aby zawierało dokładnie te wina, które mają przy najmniej jedną relację locatedIn do regionu Bourgogne. Moglibyśmy zadeklarować nową klasę ThingsFromBourgogneRegion i użyć jej jako klasy w konstrukcji owl:intersectionOf. Ponieważ nie mamy żadnej innej potrzeby dla ThingsFromBourgogneRegion, powyższa deklaracja jest krótsza, przejrzystsza i nie wymaga tworzenia sztucznej nazwy.

<owl:Class rdf:ID="WhiteBurgundy">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Burgundy" />

    <owl:Class rdf:about="#WhiteWine" />
  </owl:intersectionOf> 
</owl:Class>

Wreszcie, klasa WhiteBurgundy jest dokładnie iloczynem białych win i Burgundies. Burgundies w prawdzie rosną we francuskim regionie Bourgogne i są winami wytrawnymi. Odpowiednio wszystkie pojedyncze wina, które spełniają te kryteria są częścią rozszerzenia klasy WhiteBurgundy.

5.1.2. Suma zbiorów [OWL DL]

Poniższy przykład demonstruje użycie konstrukcji unionOf. Używa się jej dokładnie jak konstrukcji intersectionOf:

<owl:Class rdf:ID="Fruit">
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#SweetFruit" />
    <owl:Class rdf:about="#NonSweetFruit" />
  </owl:unionOf>
</owl:Class>

Klasa Fruit zawiera zarówno rozszerzenie SweetFruit jak i rozszerzenie NonSweetFruit.

Zauważ jak kompletnie różna jest konstrukcja typu sumy zbiorów od następującej.

<owl:Class rdf:ID="Fruit">
  <rdfs:subClassOf rdf:resource="#SweetFruit" />
  <rdfs:subClassOf rdf:resource="#NonSweetFruit" />
</owl:Class>                                             ¬ 

To mówi, że instancje Fruit są podzbiorem iloczynu słodkich i nie-słodkich owoców, który powinien być zbiorem pustym.

5.1.3. Dopełnienie [OWL DL]

Konstrukcja complementOf wybiera wszystkie indywidua z domeny rozprawy, które nie należą do konkretnej klasy. Zazwyczaj odnosi się to do bardzo dużego zbioru indywiduów:

  <owl:Class rdf:ID="ConsumableThing" />

  <owl:Class rdf:ID="NonConsumableThing">
    <owl:complementOf rdf:resource="#ConsumableThing" />
  </owl:Class>

Klasa NonConsumableThing zawiera jako swoich członków wszystkie indywidua, które nie należą do rozszerzenia ConsumableThing. Ten zbiór zawiera wszystkie Wines, Regions, itp. To jest formalny zbiór różnicy między owl:Thing i ConsumableThing. Zatem, typowy wzorzec użycia complementOf jest kombinacją z innym zbiorem operatorów:

<owl:Class rdf:ID="NonFrenchWine">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Wine"/>
    <owl:Class>
      <owl:complementOf>
        <owl:Restriction>

          <owl:onProperty rdf:resource="#locatedIn" />
          <owl:hasValue rdf:resource="#FrenchRegion" />
        </owl:Restriction>
      </owl:complementOf>
    </owl:Class>
  </owl:intersectionOf>

</owl:Class>                                             ¬ 

To definiuje klasę NonFrenchWine jako iloczyn Wine i zbioru wszystkich rzeczy nie zlokalizowanych we Francji.

5.2. Klasy numerowane
oneOf [OWL DL]

OWL zapewnia sposób do specyfikacji klasy przez bezpośrednią numerację jej członków. Robi się to używając konstrukcji oneOf. w znacznej mierze, ta definicja kompletnie specyfikuje rozszerzenie klasy, więc żadne inne indywidua nie mogą być zadeklarowane jako należące do klas.

Poniższy przykład definiuje klasę WineColor, której członami są indywidua White, Rose i Red.

<owl:Class rdf:ID="WineColor">
  <rdfs:subClassOf rdf:resource="#WineDescriptor"/>

  <owl:oneOf rdf:parseType="Collection">
    <owl:Thing rdf:about="#White"/>
    <owl:Thing rdf:about="#Rose"/>
    <owl:Thing rdf:about="#Red"/>
  </owl:oneOf>
</owl:Class>

Pierwszą rzeczą jaką należy zrozumieć jest to, że żadne inne indywidua nie mogą być ważnym WineColor skoro klasa została zdefiniowana jako numerowana.

Każdy element konstrukcji oneOf musi być ważnie zadeklarowanym indywiduum. Indywiduum musi należeć do jakiejś klasy. W powyższym przykładzie, do każdego indywiduum odwołujemy się poprzez nazwę. Używamy owl:Thing jako prostego banału do wprowadzenia referencji. Alternatywnie, moglibyśmy odwoływać się do elementów zbioru zgodnie z ich specyficznym typem, WineColor, przez:

<owl:Class rdf:ID="WineColor">
  <rdfs:subClassOf rdf:resource="#WineDescriptor"/>
  <owl:oneOf rdf:parseType="Collection">
    <WineColor rdf:about="#White" />
    <WineColor rdf:about="#Rose" />

    <WineColor rdf:about="#Red" />
  </owl:oneOf>
</owl:Class>

Inne, bardziej złożone opisy indywiduów są równie ważnymi elementami konstrukcji oneOf, na przykład:

<WineColor rdf:about="#White">
  <rdfs:label>White</rdfs:label>
</WineColor>                                             ¬ 

Dodatkowe przykłady użycia oneOf, zobacz Referencje.

5.3. Klasy rozłączne
disjointWith [OWL DL]

Rozłączność zbioru klas może być wyrażona przy użyciu konstrukcji owl:disjointWith. Gwarantuje to, że indywiduum będące członkiem jednej klasy nie może być równocześnie instancją innej określonej klasy.

<owl:Class rdf:ID="Pasta">
  <rdfs:subClassOf rdf:resource="#EdibleThing"/>
  <owl:disjointWith rdf:resource="#Meat"/>
  <owl:disjointWith rdf:resource="#Fowl"/>
  <owl:disjointWith rdf:resource="#Seafood"/>

  <owl:disjointWith rdf:resource="#Dessert"/>
  <owl:disjointWith rdf:resource="#Fruit"/>
</owl:Class>

Przykład Pasta demonstruje wielokrotnie rozłączne klasy. Zauważ, że to zapewnia tylko że Pasta jest rozłączna z wszystkimi innymi klasami. To nie zapewnia, na przykład, że Meat i Fruit są rozłączne. Aby zapewnić, że zbiór klas jest wzajemnie rozłączny owl:disjointWith musi być zapewnione dla każdej pary.

Powszechnym wymaganiem jest definiowanie klasy jako sumy zbioru wzajemnie rozłącznych podklas.

<owl:Class rdf:ID="SweetFruit">

  <rdfs:subClassOf rdf:resource="#EdibleThing" />
</owl:Class>

<owl:Class rdf:ID="NonSweetFruit">
  <rdfs:subClassOf rdf:resource="#EdibleThing" />
  <owl:disjointWith rdf:resource="#SweetFruit" />
</owl:Class>

<owl:Class rdf:ID="Fruit">
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#SweetFruit" />
    <owl:Class rdf:about="#NonSweetFruit" />
  </owl:unionOf>
</owl:Class>

Tutaj definiujemy Fruit aby był dokładnie sumą SweetFruit i NonSweetFruit. I wiemy że te podklasy dokładnie dzielą Fruit na dwie różne podklasy, ponieważ są one rozłączne. W miarę jak liczba wzajemnie rozłącznych klas rośnie, liczna zapewnień rozłączności rośnie proporcjonalnie do n². Jednak, W użytych przypadkach, które widzieliśmy, n jest typowo małe.

Gdy n jest duże, alternatywne podejście może być użyte, aby uniknąć kwadratowego wzrostu liczby zapewnień. Jedna taka metoda jest zilustrowana w OWL komplet testowy

Zilustrowane metody działają następująco. Opisujemy klasę rodzica, której elementy mają własności z licznością równą jeden. To znaczy, każda instancja musi mieć jedną i tylko jedną wartość dla tej własności. Wtedy, dla każdej podklasy tego rodzica wymagamy, aby jego instancje miały określoną unikalną wartość dla własności. W takim przypadku żadna z różnych podklas nie może mieć członków wspólnych.

6. Kontrola wersji ontologii

Ontologie są jak programy, będą zachowane i dlatego z czasem się zmieną. W elemencie owl:Ontology (omówionym powyżej), możliwe jest połączenie poprzednich wersji zdefiniowanych ontologii. Własność owl:priorVersion ma zapewnić to połączenie i może być użyta do śledzenia historii wersji ontologii.

<owl:Ontology rdf:about=""> 
  ...
  <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/CR-owl-guide-20030818/wine"/> 
  ...

</owl:Ontology>

Wskazana ontologia jest poprzednią wersją obecnie definiowanej.

Wersje ontologii nie muszą być ze sobą zgodne. Na przykład, poprzednia wersja ontologii może zawierać stwierdzenia, które są sprzeczne z bieżącą wersją. W elemencie owl:Ontology używamy znaczników owl:backwardCompatibleWith i owl:incompatibleWith do określenia kompatybilności lub jej braku z poprzednią wersją ontologii. Jeśli owl:backwardCompatibleWith nie jest zadeklarowane, wtedy kompatybilność nie powinna być zakładana. Dodatkowo, owl:versionInfo zapewnia punkt zaczepienia dla systemu kontroli wersji. W przeciwieństwie do poprzednich trzech znaczników, objekt owl:versionInfo jest formalny i znacznik może zostać użyty do komentowania klas i własności jako dodatek do ontologii.

Z wielu powodów, śledzenie wersji na całej rozdrobnionej ontologii nie jest wystarczające. Użytkownicy zachowawczy mogą chcieć zachować wersje informacji o klasach, własnościach i indywiduach - i również to może nie być wydajne. Przyrostowa natura wyrażeń klas w OWL-u oznacza, że jedna ontologia może dodać ograniczenia do ( nazwanej ) klasy zdefiniowanej w innej ontologii, i te dodatkowe ograniczenia same w sobie mogą wymagać wersji informacji.

OWL Full zapewnia siłę wyrazu do zrobienia każdego rodzaju założenia o klasie, to znaczy, że jest to instancja innej klasy lub, że to ( i nie jest instancją ) ma własność i wartość dla tej własności. Ta struktura może być użyta do zbudowania ontologii klas i własności dla śledzenia wersji informacji. OWL-owa przestrzeń nazw zawiera dwie pre-definiowane klasy, które mogą być użyte do tego celu: owl:DeprecatedClass i owl:DeprecatedProperty. Oznaczają one, że klasa lub własność najprawdopodobniej nie ulegnie zmianie do postaci niekompatybilnej w przyszłych wydaniach:

...
  <owl:DeprecatedClass rdf:ID="&vin;JugWine" />
  <owl:DeprecatedProperty rdf:ID="&vin;hasSeeds" />
...                                                            ¬ 

Ważne aby zauważyć, że owl:DeprecatedClass i owl:DeprecatedProperty nie mają dodatkowej semantyki i jest to zamierzone narzędzie twórców i użytkowników OWL-a, aby zapewnić ich zamierzone użycie.

7. Przykłady użycia

Kiedy pierwsza domena ontologii jest dostępna może być stworzona duża liczba aplikacji, które wykorzystują ontologię. W tej sekcji opisujemy niektóre przykłady użycia w domenie win.

7.1. Portal wina

Istnieje dzisiaj wiele stron, które nazywają się portalami wina. Google na przykład dostarcza 152,000 wyników dla frazy "portal wina". Jeden z pierwszych wyników to storna "Wine-Portal.com", zapewnia dostęp do większej liczby stron. Wiele ze stron podających się za portale wina jest w większości stronami informacyjnymi. Na przykład, pierwsza rekomendowana strona na wine-portal.com, nazywająca się 'korek w kuchni' (www.corkcuisine.com/), zapewnia informacje o doborze win i jedzenia, winach jako prezentach, itp.

Rozszerzając jakiekolwiek zagadnienie, każde znajduje zbiór stron zawierających informacje i czasami serwisy związane z tematem. Na przykład, 'akcesoria i prezenty' zawierają informacje o tym na co patrzeć, kiedy kupujemy określoną rzecz związaną z winem jak również znaczącą liczbę sprzedawców on-line. Inna popularna zakładka 'zakupy' ma podzakładkę 'zakup wina', z którego użytkownik może znaleźć on-line ( lub 'bazarowe' ) sklepu ( skategoryzowane krajami ). Te dwie strony są tylko dwoma z wielu dzisiejszych przykładów i są reprezentacją głównego poglądu portali wina zapewniających zbiór informacji i serwisy odnoszące się do określonej tematyki.

Kiedy patrzymy na te strony w szczególny sposób, nie do końca jesteśmy w stanie stwierdzić jak bardzo bazują one dzisiaj na ontologiach. Na przykład, przeglądanie źródła html-a nie pokazuje dowodów na użycie ontologii. Jednak, jasne jest, że strony mogłyby wykorzystywać niektóre dostępne ontologie wina.

Jedno proste użycie ontologii w portalach ułatwia organizację i przeglądanie. Powyższy wyciąg kategorii mógłby być generowany z kilku najpopularniejszych klas związanych z winem. Zapytania mogłyby wykorzystywać ontologie wina do odzyskiwania informacji związanych z winem. Jeśli ktoś wyszukiwałby terminu zawartego w ontologii, zapytanie mogłoby być rozszerzone o informacje podklas, aby znaleźć bardziej istotną odpowiedź. Portale mogły by automatycznie same się zaktualizować z ( kandydującymi ) informacjami w zakresie tematu. Z możliwością wnioskowania mogłyby nawet identyfikować prawdopodobne strony sprzedaży wina i negocjować aby zawrzeć je jako część portalu.

7.2. Bednarz wina

Stworzyliśmy bednarza wina w celach pokazowych. W naszym początkowym projekcie celem bednarza wina było polecenie win, które towarzyszyłyby określonym potrawom. Ta aplikacja wykorzystuje ontologię użytą jako baza dla tego przewodnika. Ta ontologia wina jest dostępna w bibliotece ontologii DAML i jest zatytułowana wina.

Spersonalizowany bednarz wina może zapewnić pewną liczbę usług dla człowieka.
Bednarz może polecić wino mających zbiór ograniczeń ( takich jak podawany posiłek ), znaleźć informacje o określonym winie lub określonej klasie win, wyszukać odpowiednich akcesoriów dla wina ( takich jak określony rodzaj szkła odpowiedni dla tego rodzaju wina, itp. )

Poniżej opisujemy przykład w prostym prototypie systemu, który został napisany kalo projekt studencki.

Zastanów się nad następującym scenariuszem:

Ktoś planuje bankiet i przynajmniej jeden z gości jest znawcą win. Gospodarz chciałby podać wino, które jest dobrze dobrane do potraw w menu. Gospodarz również chciałby wypaść na znawcę win podawanych na przyjęciu. Gospodarz również chciałby mieć odpowiednie akcesoria na bankiecie. Gospodarz zdecydował się na podanie specjalnego, opartego na pomidorach, sosu do makaronu, ze świeżym makaronem jako daniem głównym.

Aby podać wina odpowiednie do posiłku, gospodarz potrzebuje informacji zawierające pary pasujących do siebie win i jedzenia. Aby uchodzić za znawcę win, gospodarz skorzystałby mając dostęp do informacji i winie związanym z przyjęciem. Aby mieć odpowiednie akcesoria do wina, gospodarz potrzebowałby informacji o tym jakie akcesoria są znaczące w danej sytuacji ( i są w granicach możliwości cenowych gospodarza ).

Z założeń ontologii wina, mając opis posiłku, bednarz wina może zaproponować typ wina do podania z posiłkiem. Bednarz wina może zasugerować zinfandel jako różnorodny wybór dla posiłku. Dodatkowo, mając założenia ontologii, bednarz wina może zasugerować określony zinfandel, prawdopodobnie Marietta Zinfandel. Mają informację, że wino powinno być zinfandel, bednarz wina może poszukać miejsca aby kupić jakikolwiek wybrany zinfandel lub może poszukać określonego wina zinfandel, takiego jak Marietta. Mając założenia ontologii zawierające odpowiednie źródła dla zakupu wina ( prawdopodobnie przefiltrowane przez lokalizację gospodarza i lokalizację sprzedawcy win ), bednarz wina mógłby przejrzeć strony takie jak wine.com w poszukiwaniu 'zinfandels' i zwrócić listę zinfandel na sprzedaż na tej stronie. Bednarz wina mógłby spróbować znaleźć Marietta Zinfandel albo z samej winnicy lub od innych sprzedawców. Mógłby, na przykład, znaleźć ( przez Google lub przeszukanie strukturalne wybranych stron internetowych ) że winelibrary.com ma na sprzedaż Marietta Zinfandel rocznik 1999 za rabatową cenę $13.99. Bednarz wina mógłby użyć dodatkowego filtrowania informacji takich jak przedział cenowy zapewniany przez konsumenta lub jako sugestia bazująca na różnorodności.

Bednarz wina może teraz spróbować zapewnić informacje odnoszące się do zinfandel ogólnie lub Marietta Zinfandel w szczególności. Mógłby użyć założeń ontologii stron z winami aby znaleźć informacje o określonych winach. Na przykład, opis winiarni o ich ostatnich Zinfandel mógłby być użyty. Dodatkowo przegląd wiarygodnych źródeł takich jak Wine Spectator może być pomocny. Jeśli żaden przegląd Marietta Zinfandel nie jest dostępny na ulubionych przeglądanych stronach wina, może być pomocne przeszukanie powiązanych informacji, takich jak przegląd Zinfandel z tego samego regionu, w tym przypadku Zinfandel z Sonoma County, California.

Generalnie założone informacje mogą również być użyteczne. Gospodarz może również chcieć poczytać i być zainteresowany książkami na temat wina ogólnie lub zinfandels w szczególności. Na przykład, gospodarz może być zainteresowany książkami które Amazon.com ma na sprzedaż o zinfandel. Gospodarz może być również zainteresowany informacjami odnoszącymi się do win z tego samego regionu i dlatego może być zainteresowany Sonoma zinfandels. Bednarz wina może mieć typowe założone informacje dostępne, które są związane z jego główna dziedziną wiedzy. Na przykład, ten bednarz wina jest zainteresowany dopasowaniem wina do jedzenia, więc może mieć zarówno swobodne jak i nabyte informacje na ten temat, takie jak artykuł dobór jedzenia i wina.

Gospodarz obiadu może również nabyć odpowiednie akcesoria do wina przed bankietem. Wino jest podawane w lampkach do wina i różne rodzaje win są najlepiej podawane w różnych rodzajach lampek. Na przykład, jeśli gospodarz wybrał danie dla którego zinfandel jest odpowiedni, gospodarz może chciałby wiedzieć, że Riedel jest dobrze znanym wytwórcą wyrobów szklanych do wina. Gospodarz może również chcieć być w kontakcie z Wine Enthusiast ( dobrze znany dostawca towarów związanych z winem ) i zostać poinformowanym, że Wine Enthusiast ma lampki Riedel's Vinum Zinfandel na sprzedarz zestaw 4 sztuk za $63.95 ( z obniżką do $59.95 jeśli kupisz dwa zestawy po 4 lampki ). Gospodarz może również być zainteresowany tym, że Amazon.com ma pojedynczo dmuchane lampki Reidel's Sommelier Zinfandel dostępne za $49.99 ( i żąda ceny katalogowej $65.00 ). Amazon ma również to samo szkło Vinum na sprzedaż w zastawach po 6 ( zamiast po 4 jak na wine enthusiast ) za $79.99 ( i żąda ceny katalogowej $119.40 ). Bednarz wina mógłby zapewnić porównawczy wydruk wyrobów szklanych, które pasują do posiłku ( to znaczy, są odpowiednie do podania zinfandel ) i porównać cenowo lub innym kryterium wybranym z listy własności ontologii.

Gospodarz bankietu może rozważać inne akcesoria do wina. Z ontologii wiemy, że korkociągi są akcesoriami wina. Założenia ontologii mogą zawierać podklasę korkociągów lub taka informacja może być również znaleziona na konkretnych stronach internetowych. Wine Enthusiast ma zbiór korkociągów które polecają ( z opisem typu i zakresu cenowego ). Rozróżniają również korkociągi przez typ ( poziom, kelner, stacjonarny, obrót i pompa ) i gospodarz obiadu może chcieć uzyskać informacje o tych stylach.

Bednarz wina może być wyszkolony na wiele poziomów w zależności od założeń ontologii wiedzy o domenie i informacjach, serwisach internetowych. W tym przykładzie, wykorzystaliśmy tylko informacje dotyczące win, różnorodnych typów, kombinacji jedzenia i wina, niektórych akcesoriów do wina i związanych z nimi własności. Moglibyśmy oczywiście rozszerzyć to, aby zawierało więcej informacji i więcej ograniczeń nakładanych przez klienta.

Ewolucja przykładu tego bednarza wina jest dostępna.

Podziękowania

Ten dokument jest wynikiem rozległych dyskusji w Grupie Roboczej Ontologii Sieciowej jako całości . Grupa Robocza zawiera : Yasser alSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, Frederik Brysse, Stephen Buswell, Jeremy Carroll, Dan Connolly, Peter Crowther, Jonathan Dale, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman, Jérôme Euzenat, Tim Finin, Nicholas Gibbins, Sandro Hawke, Patrick Hayes, Jeff Heflin, Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane Hunter, Francesco Iannuzzelli, Rüdiger Klein, Natasha Kravtsova, Ora Lassila, Massimo Marchiori, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, Michael Sintek, Michael K. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, David Trastour, Frank van Harmelen, Bernard Vatant, Raphael Volz, Evan Wallace, Christopher Welty, Charles White, and John Yanosy.

Niektóre krytyczne uwagi na temat ograniczeń złożonych zostały napisane przez Raphael Volz, Forschungszentrum Informatik (FZI). Istotny wgląd dostarczył DAML+OIL Walkthru. Jeremy Carroll, Jerome Euzenat, Jeff Heflin, Kevin Page i Peter F. Patel-Schneider dostarczyli szerokie omówienia. Na WG Face to Face, 8 października 2002, Stephen Buswell, Ruediger Klein, Enrico Motta, i Evan Wallace dostarczyli szczegółowe omówienie ontologii co przyniosło istotne zmiany. Na WG Face to Face, 10 stycznia 2003, Jonathan Dale, Bernard Horan, Guus Schreiber, and Jeff Heflin dostarczyli szczegółowe omówienie Przewodnika, co przyniosło istotne zmiany. Publiczne omówienia dostarczyły liczne pomocne sugestie i poprawki.

Słownik OWL-a

Atrybut

jak w XML

Definicja klasy

nieformalny termin dla elementu owl:Class

Opis klasy

opisuje klase OWL-a, albo przez nazwę klasy, lub przez określenie rozszerzenia nienazwanej anonimowej klasy

Nazwa klasy

nieformalny termin dla atrybutu wartości owl:Class rdf:ID.

Klasa

jak w RDF

Komponent

dla części definicji, na przykład argumenty w iloczynie zbiorów w definicji klasy

Koncepcja

nieformalny termin dla abstrakcji "na świecie", które opisuje ontologie

Ograniczenie

nieformalny termin dla omówienia efektu restrykcji

Własności znaczących danych

alternatywny termin dla własności typów danych

Własności typów danych

własność OWL-a, która wiąże indywidua do wartości danych

Typy danych

Typ danych RDFS, prawie zawsze jeden z wbudowanych nie listowych typów danych XML Schema

Element

(1) jak w XML

(2) element zbioru

Podmiot

jak w XML

Importy zamknięć

informacje w dokumencie ontologii, plus informacje w importach zamknięć dokumentów ontologii, które są importowane przez dokument

Własności znaczących indywiduów

alternatywny termin dla własności objektu

Indywiduum

instancja klasy OWL-a, to znaczy źródło które należy do rozszerzenia klasy OWL-a

Instance Of

relacja między indywiduum a klasą

Instancja

członek rozszerzonej klasy OWL-a

Nazwa

jak w przestrzeni nazw XML

Nazwana klasa

klasa OWL-a z przypisanym identyfikatorem

Węzeł

jak w grafach RDF

Klasa OWL-a

klasa RDFS, która należy do rozszerzenia klasy owl:Class

Własności obiektu

własność OWL-a, która wiąże indywidua do innych indywiduów

Objekt

(1) objekt potrójnego RDF

(2) alternatywny termin dla indywiduum (używany z powodów historycznych )

Dokument ontologii

dokument sieciowy, który zawiera ontologie, generalnie wykazywany przez obecność elementu owl:Ontology w dokumencie

Ontologia

(1) zbiór informacji, generalnie zawierających informacje o klasach i własnościach

(2) informacje zawarte w dokumencie ontologii

Definicja własności

nieformalny termin dla elementu owl:ObjectProperty i\lub owl:DatatypeProperty elementu

Zasób

element domeny rozprawy RDF-a

Ograniczenia, globalne

zarezerwowane dla rozważań o domain i range własności

Ograniczenia, lokalne

[patrz powyżej]

Ograniczenia

najczęściej część rozszerzenia klasy, stwierdzenie wyrażające ograniczenia, lokalny z powodu braku innych ograniczeń

Zbiór

zbiór matematyczny

Wyrażenie

jak w grafach RDF

Typ

jak w RDF (rdf:type)

Referencja URI

jak w RDF

Nienazwana klasa

klasa OWL-a bez przypisanego identyfikatora, zazwyczaj część ograniczeń

Słownictwo

zbiór referencji URI

Indeks terminów i referencji

Indeks termminów

Przewodnik, Referencje i Semantyka

Referencje

OWL

[OWL Semantyka i lista składni]

OWL Web Ontology Language Semantics and Abstract Syntax , Peter F. Patel-Schneider, Patrick Hayes, and Ian Horrocks, Editors. Rekomendacja W3C, 10 Luty 2004,
http://www.w3.org/TR/2004/REC-owl-semantics-20040210/.
Najnowsza wersja dostępna na http://www.w3.org/TR/owl-semantics/.

[OWL Przegląd]

OWL Web Ontology Language Overview , Deborah L. McGuinness and Frank van Harmelen, Editors. Rekomendacja W3C, 10 Luty 2004,
http://www.w3.org/TR/2004/REC-owl-features-20040210/.
Najnowsza wersja dostępna na http://www.w3.org/TR/owl-features/.

[OWL Referencje]

OWL Web Ontology Language Reference , Mike Dean and Guus Schreiber, Editors. Rekomendacja W3C, 10 Luty 2004,
http://www.w3.org/TR/2004/REC-owl-ref-20040210/.
Najnowsza wersja dostępna na http://www.w3.org/TR/owl-ref/.

[OWL Wymagania]

OWL Web Ontology Language Use Cases and Requirements , Jeff Heflin, Editor. Rekomendacja W3C, 10 Luty 2004,
http://www.w3.org/TR/2004/REC-webont-req-20040210/.
Najnowsza wersja dostępna na http://www.w3.org/TR/webont-req/.

[OWL Przykłady testowe]

OWL Web Ontology Language Test Cases , Jeremy J. Carroll and Jos De Roo, Editors. Rekomendacja W3C, 10 Luty 2004,
http://www.w3.org/TR/2004/REC-owl-test-20040210/.
Najnowsza wersja dostępna na http://www.w3.org/TR/owl-test/.

Związane standardy W3C

[RDF]

Resource Description Framework (RDF) Model and Syntax Specification , Ora Lassila, Ralph R. Swick, Editors. World Wide Web Consortium Recommendation, 1999,
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.
Najnowsza wersja dostępna na http://www.w3.org/TR/REC-rdf-syntax/.

[RDFS]

RDF Vocabulary Description Language 1.0: RDF Schema , Dan Brickley and R.V. Guha, Editors. Rekomendacja W3C, 10 Luty 2004,
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ .
Najnowsza wersja dostępna na http://www.w3.org/TR/rdf-schema/.

[RDF Zarys]

Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne and Jeremy J. Carroll, Editors. Rekomendacja W3C, 10 Luty 2004,
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.
Najnowsza wersja dostępna na http://www.w3.org/TR/rdf-concepts/.

[RDF Semantyka]

RDF Semantics , Patrick Hayes, Editor. Rekomendacja W3C, 10 Luty 2004,
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/.
Najnowsza wersja dostępna na http://www.w3.org/TR/rdf-mt/.

[RDF Składnia]

RDF/XML Syntax Specification (Revised) , Dave Beckett, Editor. Rekomendacja W3C, 10 Luty 2004,
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/.
Najnowsza wersja dostępna na http://www.w3.org/TR/rdf-syntax-grammar.

[URI]

Uniform Resource Identifiers (URI): Generic Syntax , T. Berners-Lee, R. Fielding, and L. Masinter, IETF Draft Standard August, 1998 (RFC 2396).

[XML Base]

XML Base, Jonathan Marsh, Editor. Rekomendacja W3C, 27 Czerwca 2001,
http://www.w3.org/TR/2001/REC-xmlbase-20010627/.
Najnowsza wersja dostępna na http://www.w3.org/TR/xmlbase/.

[XML Przestrzenie nazw]

Namespaces in XML , Tim Bray, Dave Hollander, Andrew Layman, Editors. Rekomendacja W3C, Styczeń 1999,
http://www.w3.org/TR/1999/REC-xml-names-19990114/.
Najnowsza wersja dostępna na http://www.w3.org/TR/REC-xml-names.

[XML]

Extensible Markup Language (XML) 1.0 , Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Editors. Rekomendacja W3C, 10 Luty 1998,
http://www.w3.org/TR/1998/REC-xml-19980210.
Najnowsza wersja dostępna na http://www.w3.org/TR/REC-xml.

[XML Schema 1]

XML Schema Part 1: Structures, Henry S. Thompson, David Beech, Murray Maloney, and Noah Mendelsohn, Editors. Rekomendacja W3C, 2 Maja 2001,
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.
Najnowsza wersja dostępna na http://www.w3.org/TR/xmlschema-1/.

[XML Schema 2]

XML Schema Part 2: Datatypes, Paul V. Biron, Ashok Malhotra, Editors. Rekomendacja W3C, 2 Maja 2001,
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
Najnowsza wersja dostępna na http://www.w3.org/TR/xmlschema-2/.

Przykłady ontologii i aplikacje

[Integrating Applications]

Integrating Applications on the Semantic Web , James Hendler, Tim Berners-Lee, and Eric Miller. Journal of the Institute of Electrical Engineers of Japan, Vol 122(10), October, 2002, p. 676-680.

[VerticalNet]

Industrial Strength Ontology Management , Aseem Das, Wei Wu, and Deborah L. McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-09 2001. In the Proceedings of the International Semantic Web Working Symposium, Stanford, CA, July 2001.

[Wine Ontology From Daml.org]

http://www.daml.org/ontologies/76

[Wine Ontology / CLASSIC Tutorial]

Classic Knowledge Representation System Tutorial , Deborah L. McGuinness, Peter F. Patel-Schneider, Richmond H. Thomason, Merryll K. Abrahams, Lori Alperin Resnick, Violetta Cavalli-Sforza, and Cristina Conati. AT&T Bell Laboratories and University of Pittsburgh, 1994.

[Wine Ontology Tutorial]

Ontology Development 101: A Guide to Creating Your First Ontology, Natalya Fridman Noy and Deborah L. McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880, March 2001.

[Wine Ontology in CLASSIC]

Living with CLASSIC: When and How to Use a KL-ONE-Like Language , Ronald J. Brachman, Deborah L. McGuinness , Peter F. Patel-Schneider , Lori Alperin Resnick , and Alex Borgida. In Principles of Semantic Networks: Explorations in the representation of knowledge, John Sowa, Editor. Morgan-Kaufmann, San Mateo, California, 1991, pages 401--456.

Związane badania języka KR

[DAML+OIL]

DAML+OIL W3C Submission, Includes reference description, both model theoretic and axiomatic semantics, annotated walkthrough and examples.

Annotated DAML+OIL Ontology Markup , Dan Connolly, Frank van Harmelen, Ian Horrocks, Deborah McGuinness, Peter F. Patel-Schneider, Lynn Andrea Stein. December 2001.

[DAML-ONT]

DAML-ONT initial release at http://www.daml.org/2000/10/daml-ont.html.

[DAML-ONT KIF]

Partial DAML-ONT axiomatization at http://www.daml.org/2000/10/DAML-Ont-kif-axioms-001107.html.
Defined in KIF (http://logic.stanford.edu/kif/kif.html).

[Description Logics]

The Description Logic Handbook: Theory, Implementation and Application , Franz Baader, Diego Calvanese, Deborah L. McGuinness, Daniele Nardi, and Peter F. Patel-Schneider, Editors. Cambridge University Press, 2002.

[MCF]

Meta Content Framework Using XML , R.V. Guha and Tim Bray. Netscape Communications, 6 June 1997.

[Part Whole]

A Taxonomy of Part-Whole Relations. M. Winston, R. Chaffin & D. Herrmann. Cognitive Science, 11:417-444, 1987.

[XOL]

XOL: An XML-Based Ontology Exchange Language, Peter D. Karp, Vinay K. Chaudhri, and Jerome F. Thomere. Technical Report 559. AI Center, SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025, Jul 1999.

Podstawowe informacje i strony domowe

[Dublin Core]

Dublin Core Metadata at home page, http://dublincore.org/.

[Dublin Core XML]

Expressing Dublin Core in RDF/XML, Dave Beckett, Eric Brickley, and Dan Brickley.
Dublin Core Metadata Initiative. July 31, 2002,
http://dublincore.org/documents/2001/11/28/dcmes-xml/.

[KAON]

The Karlsruhe Ontology and Semantic Web Tool Suite at http://kaon.semanticweb.org.

[OIL]

OIL Home Page at http://oil.semanticweb.org/.

[Ontobroker]

The Ontobroker home page at http://ontobroker.aifb.uni-karlsruhe.de/index_ob.html.
Institute AIFB, University of Karlsruhe.

[Ontoknowledge]

Ontoknowledge Home Page at http://www.ontoknowledge.org/.

[RDF Home]

RDF: Resource Description Framework. Background information at http://www.w3.org/RDF/.

[SHOE]

Simple HTML Ontology Extensions (SHOE) home page at http://www.cs.umd.edu/projects/plus/SHOE/. University of Maryland.

[KR]

KR Home Page at http://kr.org/.

Dodatek A: Podstawy XML + RDF

Aby w pełni zrozumieć składnię i semantykę OWL-a powinieneś znać podstawy związane ze standardami W3C i IETF wypisanymi poniżej. Minimalny przewodnik do XML i RDF jest zamieszczony w dwóch pierwszych linkach.

• Dodatek do DAML+OIL Walkthru
  
  
• URI - Jednolity Identyfikator Zasobów
• XML - Rozszerzony Język Znaczników
• Przestrzenie nazw XML-a
• XML Schema
• RDF - Struktura Opisu Zasobów
• RDF Schema

Dodatek B: Historia

Struktura Opisu Zasobów (RDF) była pierwszym językiem określonym przez W3C do reprezentowania semantycznych informacji o swobodnych(arbitralnych) zasobach. RDF Schema (RDFS) jest kandydatem rekomendacji do rozszerzenia RDF-a do opisu słownictwa RDF-a. RDFS może być użyty do stworzenia ontologii, ale nie jest do tego najodpowiedniejszy, ponieważ ma mniejszą siłę wyrazu niż OWL.

Jak OWL, RDFS zawiera klasy i własności, jak również zakres i dziedzinę ograniczeń na własnościach. Zapewnia to dziedziczność hirearchii zarówno dla klas jak i własności. Od momentu jego publikacji użytkownicy zaczęli prosić o dodatkowe cechy, zawierające typy danych, numerowania i możliwość definiowania własności bardziej rygorystycznie.

Inne wysiłki w środowisku badawczym już testowały dokładnie tego typu cechy. Dla tych którzy pragną pogłębić te założenia, częściowa lista projektów i języków zawiera:

• DAML - DARPA Agent Markup Language
• DAML-ONT
• MCF - Meta Content Framework.
• Ontobroker
• On-To-Knowledge
• OIL - Ontology Inference Layer
• SHOE - Simple HTML Ontology Extensions
• XOL

Zamiast kontynuować z osobnymi językami dla Sieci Semantycznej, grupa badaczy, zawierająca wielu spośród głównych członków biorących udział w tworzeniu OIL i DAML-ONT, zebrała się w Joint US/EU ad hoc Agent Markup Language Committee, aby stworzyć nowy język ontologii sieciowej. Ten język DAML+OIL zbudowany na podstawie OIL i DAML-ONT został przedstawiony W3C jako proponowana podstawa dla OWL-a, i zastał następnie wybrany jako punkt wyjściowy dla OWL-a.

Dodatkowo do języków ontologii, wiele taksonomii i istniejących ontologii jest już w komercyjnym użyciu. W stronach e-handlu ułatwiają komunikację opartą na maszynach pomiędzy kupcem i sprzedawcą, umożliwiając pionową integrację sklepów i pozwalają opisom na ponowne użycie w innych rynkach. Przykłady stron, które faktycznie robią komercyjny użytek z ontologii zawiera:

• VerticalNet Vertical Net obecnie gości 59 branży gospodarki e-sklepów, które obejmują rozmaite przemysły takie jak produkcja, komunikacja, energia i służba zdrowia.

Wiele ontologii związanych z medycyną i lekami zostało stworzonych aby pomóc zarządzać przytłaczającą masą bieżących medycznych i biomedycznych badań, które mogą być trudne do powiązania razem w spójną całość. Jednym głównym zasobem jest Konsorcjum Ontologii Gen który definiuje ontologie dla

• Funkcji molekularnych,
• Procesów biologicznych, i
• Komponentów na poziomie komórkowym.

Ta strona ma również wskaźniki do ontologii dla

• atrybutów sekwencyjnych,
• atrybutów produkcji genu,
• substancji chemicznych,
• ścieżek,
• anatomii,
• patologii,
• fizycznych charakterystyk,
• atrybutów eksperymentalnych, i
• klasyfikacji.

Istnieją duże taksonomie w dzisiejszym użyciu, które były przygotowane do rozszerzenia w przestrzeni OWL-a. Na przykład, System Klasyfikacji Przemysłu Ameryki Północnej ( NAICS ) definiuję hierarchię ponad 1900 przedmiotów. NAICS jest również połączone z Systemem Klasyfikacji Standardowego Przemysłu Międzynarodowego ( ISIC, Poprawka 3 ), stworzonym i utrzymanym przez Narody Zjednoczone.

Dodatek C: Zmiany w dzienniku od zaproponowania rekomendacji, 15 Grudnia 2003

• Poprawienie literówki (allValuesFrom to someValuesFrom) w przykładzie TexasThings wsekcji 4.1.
• Dodanie zaczepienia dla owl:AnnotationProperty.
• W sekcji 3.1.1. dodano wyraźny prefiks ontologii przykładu składni 'o'.
• Dodano referencje do opisu użycia owl:oneOf w Referencje na końcu sekcji 5.2.
• Zrobiono liczne drobne poprawki zasugerowane przez wiadomości i publiczne komentarze.
• Zmodyfikowano cytowania dla zachowania zgodności z innymi dokumentami OWL-a.
• Poprawiono literówki związane z numerowaniem w referencji przestrzeni nazw.