Pojęcia zdefiniowane w ontologii FOAF

Zgodnie z ideą tworzenia lekkich ontologii, FOAF koncentruje się na podstawowych pojęciach pozwalających opisać nasz profil użytkownika w systemach społecznościowych (i nie tylko). FOAF został zdefiniowany w 2002 roku i od tamtej pory jego podstawowe pojęcia nie zmieniły się znacząco; doszło jednak kilka nowych właściwości odpowiadające zmianom w kierunku Web 2.0 jakim podlegała Sieć.

Do podstawowych pojęć zdefiniowanych przez FOAF należą:

• klasa foaf:Person, która definiuje użytkownika, którego profil społeczny opisujemy.
• klasa foaf:Agent, będąca nad klasą foaf:Person, umożliwia stworzenie profilu nie tylko dla osób, ale również dla usług, agentów, itp.
• foaf:knows jest właściwością za pomocą której budujemy skierowany graf powiązań pomiędzy użytkownikami, czyli sieć społeczną. Sam foaf:knows nie wyraża ani stopnia ani rodzaju znajomości: może oznaczać od "widziałem tę osobę w telewizji" do "jesteśmy najlepszymi kumplami na świecie"; systemy bazujące na FOAF mają możliwość rozszerzenia słownika o właściwości o bardziej konkretnych znaczeniach.
• właściwość foaf:mbox umożliwia zdefiniowanie adresu email użytkownika; podajemy go w postaci [mbox:moj.adres@poczta.pl]; foaf:mbox jest zdefiniowana jako właściwość odwrotnie funkcyjna (ang. IFP - inverse functional property), co umożliwia identyfikowanie i łączenie wielu profili FOAF należących do tej samej osoby. Ponieważ, nie zawsze chcemy ujawniać nasz adres email, szczególnie jeżeli dany dokument FOAF (czyli dokument RDF z danymi FOAF) jest ogólnie dostępny, możemy skorzystać z właściwości foaf:mbox_sha1sum, w której zapisujemy wynik funkcji SHA1SUM na naszym adresie email (w formacie mbox:*); ta właściwość jest również zdefiniowana jako IFP.
• FOAF umożliwia również na podanie naszego imienia (foaf:firstName, foaf:givenname) i nazwiska (foaf:surname, foaf:family_name), lub poprostu łącznie naszego imienia i nazwiska (foaf:name). Jeżeli chcemy określić nasze ksywki to korzystamy z właściwości foaf:nick; tworzymy po jednym zdaniu RDF dla każdej ksywki (zobacz przykład poniżej)
• ostatnią bardzo popularną właściwością jest foaf:depiction za pomocą, której możemy wskazać lokalizację naszego zdjęcia.

FOAF definiuje również całą gamę innych klas jak foaf:Project, foaf:Organization, foaf:Group, foaf:Document, i właściwości jak np.: foaf:weblog, foaf:geekcode, foaf:schoolHomepage, itp. Zachęcam do lektury specyfikacji FOAFa gdzie wszystko jest dość spójnie opisane. Ciekawostką jest właściwość foaf:myersBriggs za pomocą określamy naszą osobowość; więcej informacji na temat Myers Briggs (MBTI) personality classification znajdziecie pod http://www.personalitypage.com/four-temps.html.

Systemy i usługi bazujące na FOAF

Ontologia FOAF jest bardzo popularna, i wiele osób tworzy i publikuje swoje FOAFy. Najlepszym miejscem, żeby rozpocząć zabawę z FOAFem jest serwis FOAF-o-matic. Jego pierwsza wersja jest dostępna pod adresem http://www.ldodds.com/foaf/foaf-a-matic, ja jednak polecam najnowszą wersję, stworzoną w ramach projektu OKKAM, dostępna pod adresem: http://www.foaf-o-matic.org/.

Oto przykładowy dokument FOAF wygenerowany za pomocą usługi FOAF-o-matic:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:foaf="http://xmlns.com/foaf/0.1/"
	xmlns:admin="http://webns.net/mvcb/">
	<foaf:PersonalProfileDocument rdf:about="">
		<foaf:maker rdf:resource="#me" />
		<foaf:primaryTopic rdf:resource="#me" />
		<admin:generatorAgent rdf:resource="http://www.ldodds.com/foaf/foaf-a-matic" />
		<admin:errorReportsTo rdf:resource="mailto:leigh@ldodds.com" />
	</foaf:PersonalProfileDocument>
	<foaf:Person rdf:ID="me">
		<foaf:title>Dr</foaf:title>
		<foaf:name>Sebastian Kruk</foaf:name>
		<foaf:givenname>Sebastian</foaf:givenname>
		<foaf:family_name>Kruk</foaf:family_name>
		<foaf:nick>skruk</foaf:nick>
		<foaf:mbox_sha1sum>959ef7bc9db1f3038f1301fe7c53654fa4f85d3f</foaf:mbox_sha1sum>
		<foaf:homepage rdf:resource="http://www.sebastiankruk.com/" />
		<foaf:depiction
			rdf:resource="http://www.knowledgehives.com/images/stories/skruk_200808.jpg" />
		<foaf:workplaceHomepage rdf:resource="http://www.knowledgehives.com/" />
		<foaf:schoolHomepage rdf:resource="http://www.semanticschool.com/" />
		<foaf:knows>
			<foaf:Person>
				<foaf:name>Stefan Decker</foaf:name>
				<foaf:mbox_sha1sum>1bc1f862b688a45b7e0c8d4a8467c23177c53fad</foaf:mbox_sha1sum>
			</foaf:Person>
		</foaf:knows>
		<foaf:knows>
			<foaf:Person>
				<foaf:name>Dan Brickley</foaf:name>
				<foaf:mbox_sha1sum>6e80d02de4cb3376605a34976e31188bb16180d0</foaf:mbox_sha1sum>
				<rdfs:seeAlso rdf:resource="http://danbri.org/foaf.rdf" />
			</foaf:Person>
		</foaf:knows>
	</foaf:Person>
</rdf:RDF>

Kolejną ciekawą usługą jest FOAF Explorer, który umożliwia przeglądanie sieci znajomości zapisanych w dokumentach FOAF. Na przykład, jeżeli chcecie rozpocząć przeglądanie od mojego profilu wystarczy, że udacie się pod ten adres.

W projektach open source, które wspiera nasza firma, Knowledge Hives, korzystamy z komponentu FOAFRealm, który wykorzystuje ontologię FOAF do zarządzanie społecznymi profilami użytkowników w systemie. Projekt FOAFRealm powstał jako przykład działania (ang. proof of concept) usługi zarządzania użytkownikami opartego o FOAF, prezentowanej na FOAF Workshop, który odbył się w 2004 roku w Galway.

Do FOAF wrócimy jeszcze prezentując inne ontologie zależne od niej, np. SIOC (Semantycznie Połączone Społeczoności Online) oraz DOAC (Opis Kariery) oraz rozszerzenie FOAF-SSL umożliwiające tworzenie rozproszonej sieci uwierzytelniającej.

OWL Lite rozszerza zestaw pojęć zdefiniowany przez RDF Schema o mechanizmy umożliwiające na bardziej precyzyjne definiowanie znaczenia właściwości i klas:

• podobieństwa elementów zdefiniowanych w ontologii:
  • aby określić, że dwie klasy lub właściwości są sobie równe korzystamy (odpowiednio) z equivalentClass i equivalentProperty. Równość w przypadku klas oznacza, że instancje należące do jednej należą jednocześnie do drugiej. Podobnie zdefiniowane równości właściwości oznacza, że połączenie dwóch instancji jedną z właściwości podpowiada, że są one połączone jednocześnie drugą z równych sobie właściwości. Poniższy przykład w pseudo-RDF prezentuje równoznaczność klas:

    [semschool:Grzejnik] [rdf:type] [rdfs:Class].
    [semschool:Kaloryfer] [rdf:type] [rdfs:Class].
    [semschool:Grzejnik] [owl:equivalentClass] [semschool:Kaloryfer].

  • aby określić, że dwie instancje są sobie równe (takie same) lub zupełnie różne, korzystamy (odpowiednio) z sameAs i differentFrom.

    [semschool:Fiat126p] [rdf:type] [semschool:Samochod].
    [semschool:Maluch] [rdf:type] [semschool:Samochod].
    [semschool:Linea] [rdf:type] [semschool:Samochod].
    [semschool:Fiat126p] [semschool:sameAs] [semschool:Maluch].
    [semschool:Linea] [semschool:differentFrom] [semschool:Maluch].

  • możemy też za pomocą pojedynczego opisu określić, że wszystkie instancje w danym zestawie są wzajemnie różne, korzystając z pojęć AllDifferent i distinctMembers. Poniższy przykład w zapisie RDF/XML prezentuje użycie pojęcia AllDifferent i distinctMembers:

    <owl:AllDifferent>
      <owl:distinctMembers rdf:parseType="Collection">
        <semschool:Samochod rdf:about="#Maluch" />
        <semschool:Samochod rdf:about="#Linea" />
        <semschool:Samochod rdf:about="#Sedici" />
      </owl:distinctMembers>
    </owl:AllDifferent>

• typy właściwości:
  • OWL Lite umożliwia zdefiniowanie wzajemnie odwrotnych właściwości za pomocą pojęcia inverseOf, np.:

    [semschool:produkuje] [rdf:type] [rdf:Property].
    [semschool:jestProdukowany] [rdf:type] [rdf:Property].
    [semschool:produkuje] [owl:inverseOf] [semschool:jestProdukowany].

  • OWL Lite umożliwia również zdefiniowane typu właściwości:
    • DatatypeProperty - obiekty w zdaniu, w którym są zdefiniowane dane właściwości, są literałami a nie obiektami
    • TransitiveProperty - dana właściwość jest przechodnia, tzn. z tego że [A] [powiązane] [B]. i [B] [powiazane] [C] wynika [A] [powiązane] [C]
    • SymetricProperty - dana właściwość jest symetryczna, tzn. z tego, że [A] [powiązane] [B] wynika [B] [powiązane] [C].
    • FunctionalProperty - dla danego podmiotu w zdaniu z tą właściwością, może istnieć tylko jeden obiekt (wartość).
    • InverseFunctionalProperty - oznacza, że dla danego obiektu w zdaniu z tą właściwością, może istnieć tylko jeden podmiot. Jest to niesamowicie ważna właściwość, gdyż jej zidentyfikowanie w ontologii umożliwia wnioskowanie, że dwa zasoby o róznych URI, są w rzeczywistości tym samym zasobem.
• ograniczenia na wykorzystanie właściwości przez instancje:
  • możemy zdefiniować, że wszystkie obiekty powiązane daną właściwością są określonego typu, np.:

    <owl:Class rdf:ID="Samochod">
      ...
      <rdfs:subClassOf>
        <owl:Restriction>
          <owl:onProperty rdf:resource="#maProducenta" />
          <owl:allValuesFrom rdf:resource="#FabrykaSamochodow" />
        </owl:Restriction>
      </rdfs:subClassOf>
      ...
    </owl:Class>

  • możemy zdefiniować, że conajmniej jeden z obiektów powiązanych daną właściwością jest określonego typu, np.:

    <owl:Class rdf:ID="Samochod">
      ...
      <rdfs:subClassOf>
        <owl:Restriction>
          <owl:onProperty rdf:resource="#dostawcaCzesci" />
          <owl:someValuesFrom rdf:resource="#FabrykaOpon" />
        </owl:Restriction>
      </rdfs:subClassOf>
      ...
    </owl:Class>

  • możemy również określić oczekiwaną ilość właściwości, lub zdefiniować minimalne lub maksymalne ograniczenie na ilość właściwości dla danego podmiotu; do tego celu korzystamy (odpowiednio) z pojęć: cardinality, minCardinality, maxCardinality.
• definiowanie przecięć zbiorów klas i właściwości - korzystamy z pojęcia intersectionOf, jak w poniższym przykładzie:

  <owl:Class rdf:ID="BialySamochod">
    <owl:intersectionOf rdf:parseType="Collection">
      <owl:Class rdf:about="#Samochod" />
      <owl:Restriction>
        <owl:onProperty rdf:resource="#maKolor" />
        <owl:hasValue rdf:resource="#Bialy" />
      </owl:Restriction>
    </owl:intersectionOf>
  </owl:Class>

Kiedy prezentowaliśmy różne specyfikacje tworzące semantyczny tort, wspomnieliśmy o ontologiach i języku OWL, umożliwiającym ich opis w sposób bardziej dokładny niż umożliwia to RDF Schema.  Ponieważ OWL jest dużo bardziej skomplikowanym standardem niż RDF Schema jego omówieniu poświęcimy kilka najbliższych artykułów.

Na wstępie, omówimy czym jest, a właściwie czym są, specyfikacje OWL. Na zakończenie cyklu omówimy zmiany i rozszerzenia sugerowane w tworzonym obecnie standardzie OWL-2.

Specyfikacja języka OWL zyskała status rekomendacji W3C w roku 2004. OWL został opracowany przez grupę naukowców pod kierownictwem Guus Schreiber, Franka van Harmelena, Jamesa Hendlera i Deborah'y McGuinness. OWL powstał w wyniku ewolucji z wcześniejszych standardów opisu ontologii, w tym szczególnie DAML+OIL.

Podobnie jak w przypadku RDF Schema, w OWL mamy do czynienia z klasami obiektów, interpretowanymi jako zestawy indywiduów (ang. individual), właściwościami (ang. property assertions) i aksjomatami (ang. axioms) określającymi zależności pomiędzy nimi. OWL znacząco rozszerza możliwości opisu ontologii w porównaniu do RDF Schema, definiując dodatkowe słownictwo (ang. vocabulary) opisu klas i właściwości, m.in.:

• typy relacji pomiędzy klasami, np.: rozłączność (ang. disjointness),
• ilość oczekiwanych relacji (ang. cardinality),
• równoważność (ang. equality),
• dodatkowe typy właściwości, np.: właściwość odwrotnie funkcyjna (ang. inverse functional property, IPF),
• cechy właściwości, np. symetryczność czy przechodniość.

OWL umożliwia definiowanie czterech typów pojęć:

• klasy zasobów dziedziczące po owl:Thing,
• właściwości, czyli binarne relacje pomiędzy zasobami i literałami,
• instancje będące indywiduami należącymi (tworzącymi zbiór) danej klasy,
• operacje (typu suma, przecięcie, różnica) na zbiorach indywiduów, czyli klasach.

Ponieważ wzrost możliwości wyrażania cech ontologii prowadzi do wzrostu złożoności obliczeniowej procesu wnioskowania, zdefiniowane zostały trzy typy specyfikacji OWL (patrz rysunek): OWL Lite, OWL DL (ang. Description Logic) i OWL Full.

Następujące zależności są spełnione pomiędzy ontologiami i wnioskami zdefiniowanymi w różnych wersjach OWL:

• Każda poprawna ontologia OWL Lite jest również poprawną ontologią OWL DL.
• Każda poprawna ontologia OWL DL jest również poprawną ontologią OWL Full.
• Każdy poprawny wniosek w OWL Lite jest również poprawnym wnioskiem w OWL DL.
• Każdy poprawny wniosek w OWL DL jest również poprawnym wnioskiem w OWL Full.

W kolejnych artykułach omówimy każdą z wersji OWL, zaczynając od OWL Lite.

Na zakończenie, powróćmy do akronimów, poprawnej pisowni i sów. Wbrew temu co myślicie - akronim nazwy standardu opisu ontologii internetowych, czyli Web Ontology Language, to właśnie OWL. Jeżeli czytaliście "Kubusia Puchatka" po angielsku, to zapewne pamiętacie poniższy fragment:

Owl took Christopher Robin’s notice from Rabbit and looked at it nervously. He could spell his own name WOL, and he could spell Tuesday so that you knew it wasn’t Wednesday, and he could read quite comfortably when you weren’t looking over his shoulder and saying "Well?" all the time...

Każdy serwis Web 3.0 potrzebuje dwóch elementów: semantyki i społeczności. Zanim większość Internetu będzie dostępna w postaci grafu

powiązanych semantycznie zasobów i usług sieciowych, musimy przedsięwziąć wszelkie kroki, aby opublikować jak najwięcej istniejących danych w postaci semantyki. Warto zacząć od opublikowania istniejących słowników, tak aby inne zasoby i usługi sieciowe mogły z nich korzystać.

W jednym z poprzednich artykułów opisaliśmy standard SKOS, który umożliwia opis słowników w formacie RDF. W tym artykule przedstawimy projekt Open Vocabulary umożliwiający dostęp do słowników w formacie SKOS. Projekt ten dostarcza bibliotekę programistyczną w języku Java oraz usługę sieciową typu REST.

Projekt Open Vocabulary składa się z trzech modułów:

• Reprezentacji ogólnodostępnych i otwartych słowników w formacie SKOS/RDF.
• API w języku Java i standardzie REST umożliwiające dostęp, wyszukiwanie i przeglądanie słowników.
• Portal umożliwiający przeglądanie i przeszukiwanie słowników.

Słowniki w SKOS/RDF

Obecnie projekt OpenVocabulary.info udostępnia następujące słowniki:

• Taksonomie:
  • Polska Klasyfikacja Tematyczna (PKT)
  • Association for Computing Machinery (ACM)
  • Dewey Decimal Classification (DDC)
  • Library of Congress (LOC)
  • Universal Decimal Classification (UDC)
  • Open Directory Project Taxonomy (DMoz)
  • Polskie pojęcia zdefiniowane w Open Directory Project (DMoz - PL)
• Tezaurusy:
  • WordNet 2.0 Thesaurus - oryginalny słownik WordNet w wersji RDF/OWL rozszerzony o właściwości zdefiniowane w standardzie SKOS
  • OpenThesaurus (PL) - wersja SKOS/RDF polskiego tezaurusa wykorzystywanego w pakiecie OpenOffice

Reprezentacje SKOS/RDF dla wszystkich taksonomii (za wyjątkiem DMoz) zostały wygenerowane na postaci definicji dostępnej w postaci prostego pliku tekstowego. Taksonomie DMoz zostały wygenerowane na podstawie źródła w postaci zbliżonej do formatu RDF i rozszerzonej o właściwości zdefiniowane w standardzie SKOS. Podobnie, wersja RDF/OWL tezaurusa WordNet została rozszerzona o relacje zdefiniowane w SKOS.
Natomiast wersja SKOS/RDF polskiego słownika OpenThezaurus została stworzona od podstaw po przetworzeniu źródłowego dokumentu OpenThesaurus.

API Javy i API RESTowe

Projekt OpenVocabulary dostarcza bibliotekę Java, która umożliwia skorzystanie ze słowników, szczególnie w na platformie JEE. Biblioteka ta dostarcza:

• API Javy do zarządzania taksonomiami, tezaurusami i tagami przechowywanymi w repozytorium RDF (wykorzystywana jest biblioteka RDF2Go i baza Sesame 2)
• Dostęp do pełnotekstowego indeksu (korzystając z biblioteki Lucene) poprawiającego wyszukiwanie i dostęp do pojęć ze słowników projektu Open Vocabulary.
• API RESTowe, które umożliwia usługom sieciowym dostęp do repozytorium i pojęć słowników Open Vocabulary w formacie HTML, RDF i JSON.

REST API zostało przygotowane w oparciu o wytyczne promowane przez inicjatywę Linked Data initiative, o których napiszemy niedługo. Dodatkowymi usługami dostarczanymi przez Open Vocabulary są:

• Przegląd (ang. lookup) - dostarczane przez usługę w schemacie /vocabularis/lookup?uri= umożliwia dostęp do informacji o pojęciach ze słowników przechowywanych w bazie RDF, jednak zdefiniowanych w innej przestrzeni nazw niż ta w której dostępne są usługi biblioteki OpenVocabulary; przykładem takiego słownika może być WordNet.
• Wyszukiwanie (ang. search) - dostarczane przez usługę w schemacie /vocabularies/search?q=[&threshold=&size=] umożliwia wyszukiwanie w pełnotekstowym indeksie słowników, z możliwością określenia minimalnego progu (ang. threshold) podobieństwa oraz maksymalnej ilości wyników wyszukiwania.

Portal do przeglądania i przeszukiwania słowników

W ramach projektu Open Vocabulary zainstalowany został referencyjny portal http://www.openvocabulary.info/, który:

• umożliwia dostęp do pojęć ze wspieranych słowników w postaci HTML, RDF i JSON,
• dostarcza przeglądu możliwości API Javy, włącznie z dostępem do indeksu pełnotekstowego,
• dla zarejestrowanych użytkowników - umożliwia pobranie archiwów zawierających słowniki w formacie RDF oraz ich indeksy pełnotekstowe dla biblioteki Lucene.

[na podstawie: Linking Public Vocabularies – openvocabulary.info]

Zapewne wielu z Was, którzy znają programowanie obiektowe, z hasłem "dziedziczenie" rozumie następujący scenariusz:

Mamy kilka klas, z których każda definiuje pewne metody i właściwości. Jeżeli dwie klasy dziedziczą po sobie to właściwości i metody dostępne w klasie nadrzędnej są również dostępne w klasie, która dziedziczy po niej.

Zgadza się. To jest właśnie programowanie obiektowe. A teraz możecie spokojnie zapomnieć o tej teorii kiedy myślicie o ontologiach i RDF Schema.

1. W RDF Schema (oraz innych językach opisu ontologii, np. OWL) możemy definiować hierarchię dziedziczenia nie tylko klas ale również i właściwości. Pamiętacie jak pisałem wcześniej, że w RDF Schema właściwości mają takie same znaczenie jak klasy (ang. first-class citizens) ? Oto kolejny przykład na potwierdzenie tej tezy.
2. Dziedziczenie właściwości zdefiniowanych w RDF Schema jest odwrotne do tego jak ma to miejsce w programowaniu obiektowym.

Ilu z Was pomyślało sobie właśnie, że to jakieś kompletne bzdury ?

Ale niestety, tak właśnie jest. I im szybciej zapamiętacie te dwie reguły, tym mniej problemów z korzystaniem z dobrodziejstw Sieci Semantycznej, będziecie mieli w przyszłości.

Czas na dokładne wyjaśnienia. Do zdefiniowania zależności dziedziczenia pomiędzy klasami lub właściwościami używamy predykatów (odpowiednio) [rdfs:subClassOf] i [rdfs:subPropertyOf].

[semschool:Człowiek] [rdf:type] [rdfs:Class].
[semschool:Kierowca] [rdf:type] [rdfs:Class].
[semschool:Pojazd] [rdf:type] [rdfs:Class].
[semschool:Samochód] [rdf:type] [rdfs:Class].
[semschool:poruszać_się] [rdf:type] [rdf:Property].
[semschool:kierować] [rdf:type] [rdf:Property].

[semschool:poruszać_się] [rdfs:domain] [semschool:Człowiek].
[semschool:poruszać_się] [rdfs:range] [semschool:Pojazd].
[semschool:kierować] [rdfs:domain] [semschool:Kierowca].
[semschool:kierować] [rdfs:range] [semschool:Samochód].

[semschool:Kierowca] [rdfs:subClassOf] [semschool:Człowiek].
[semschool:kierować] [rdfs:subPropertyOf] [semschool:poruszać_się].

W powyższym przykładzie zdefiniowaliśmy cztery klasy i dwie właściwości, oraz zależności pomiędzy nimi: [Kierowca] dziedziczy po [Człowieku], właściwość [kierować] po właściwości [poruszać_się].

Co w ten sposób powiedzieliśmy maszynie?

1. Każdy zasób, który jest typu [Kierowca] jest również typu [Człowiek].
2. Każda para zasobów spełniająca właściwość [kierować] spełnia również właściwość [poruszać_się].

Jak na razie nic strasznego prawda? Ale ...

1. Jeżeli nie mielibyśmy zdefiniowanego dziedziczenia pomiędzy klasami, to właściwość [poruszać_się] nie byłaby zdefiniowana dla klasy [Kierowca]. Pamiętajmy, że nie oznacza to, że nie możemy z niej skorzystać dla zasobu który jest typu [Kierowca], stanie się on tylko jednocześnie zasobem typu [Człowiek].
2. Jeżeli dane byłoby tylko dziedziczenie pomiędzy klasami, to właściwość [poruszać_się] byłaby dostępna dla zasobów typu [Człowiek].
3. Jeżeli nie będzie zdefiniowanego dziedziczenia pomiędzy właściwościami, to np. wszystkie zasoby typu [Kierowca] będą również zasobami typu [Człowiek], ... i nic poza tym, tzn. nie będzie to oznaczało, że właściwość [poruszać_się] będzie dziedziczona, ale podobnie jak poprzednio, nie oznacza to, że nie będzie dostępna!

Skomplikowane? Być może, ale tylko dlatego, że używamy niepoprawnej terminologii, wywodzącej się z programowania obiektowego, a nie z logiki. To powoduje, że myślimy w niepoprawny sposób o wiedzy zapisanej w RDF Schema.

Spróbujmy jeszcze raz:

1. Jeżeli zdefiniujemy jedynie dziedziczenie właściwości, to maszyna przeprowadzi następujące rozumowanie:
   • Z  [A] [kieruje] [B] wynika: [A] jest [Kierowcą], [B] jest [Samochodem], oraz [A] [porusza_się] [B].
2. Jeżeli zdefiniujemy jedynie dziedziczenie klas, to maszyna przeprowadzi następujące rozumowanie:
   • Z  [A] [kieruje] [B] wynika: [A] jest [Kierowcą], [B] jest [Samochodem].
   • Z powyższego wynika również, że [A] jest [Człowiekiem], [B] jest [Pojazdem].

Mam nadzieję, że powyższe zdania wydały się już bardziej przyjazne. Warto więc zapamiętać, że RDF Schema nie służy do definiowania schematów znanych nam z np. programowania obiektowego, i nie należy ostrożnie podchodzić do wyciągania wniosków z informacji w niej zapisanych.

Na zakończenie cytat ze specyfikacji RDF Schema, który zapowiada czym będziemy zajmowali się w następnych odcinkach:

Note: The basic facilities provided by rdfs:domain and rdfs:range do not provide any direct way to indicate property restrictions that are local to a class. Although it is possible to combine use rdfs:domain and rdfs:range with sub-property hierarchies, direct support for such declarations are provided by richer Web Ontology languages such as OWL.

Image via Wikipedia

Jednym ze sposobów na przedstawienie wizji rozwoju Web 3.0, a dokładniej Sieci Semantycznej, jest analiza tzw. semantycznego tortu (ang. Semantic Web Layer Cake), który przedstawia stos technologii i standardów potrzebnych do stworzenia w pełni funkcjonalnej Sieci Semantycznej. Jedna z jego pierwszych wersji (prezentowana w 2002 roku przez TBL) była następująca:

Semantyczny tort (rok 2002) źródło: http://www.w3.org/2002/Talks/04-sweb/slide12-0.html

Podstawą Sieci Semantycznej są dwie technologie, dzięki którym możliwe jest wskazanie dowolnej treści i obiektu (nie tylko w Internecie) oraz opisanie ich w dowolnym języku; są to odpowiednio URI (Uniform Resource Identifier) i Unicode. Adres URI jest podobny do adresu URL (Uniform Resource Locator), z którym mamy codziennie do czynienia w Internecie; różni go jednak to iż umożliwia (przynajmniej teoretycznie) na wskazanie nawet przedmiotów w świecie rzeczywistym, a zatem również ich opisanie i połączenie z dokumentami w Internecie. Unicode umożliwia zapis znaków ze wszystkich znanych obecnie alfabetów.

Kolejna warstwa to bardzo popularny obecnie standard XML i związane z nim przestrzenie nazw (ang. namespaces). W XMLu można zapisać informacje tak, aby maszyna mogła je przetworzyć (ale nie zrozumieć!). W jednym z przyszłych artykułów postaramy się wyjaśnić dlaczego wprowadzenie warstwy XML do "semantycznego tortu" nie było najlepszym pomysłem.

Warstwę wyżej zdefiniowany jest standard nieodłącznie związany z Siecią Semantyczna: RDF (Resource Description Framework). W odróżnieniu od XMLa umożliwia on na zapis grafu (skierowanego) w postaci przetwarzanej przez maszyny; m.in. właśnie na bazie informacji zapisanych w grafie powiązań znaczeniowych (tj. semantycznych) maszyny mogą podjąć próbę zrozumienia prezentowanej treści. Aby wspomóc proces "rozumienia" informacji zapisanej w RDF, kolejne dwie warstwy związane są z definiowaniem znaczenia pojęć wykorzystanych w opisie grafu RDF. Tak zgadliście: chodzi o okryte złą sławą ontologie (o tym w jednym z następnych odcinków serialu). RDF Schema umożliwia na definiowanie prostych ontologii za pomocą hierarchii klas (ang. class) i właściwości (ang. property); nie, tym razem nie ma to nic wspólnego z programowaniem obiektowym poza samą nazwą. Omówimy ten problem w osobnym artykule.

Kolejna warstwa, czyli reguły (ang. rules), pozwala na definiowanie (w językach formalnych, np. RIF) reguł przetwarzania wiedzy zapisanej w RDF i ontologiach. W zestawieniu z budowanymi obecnie mechanizmami struktur logicznych (ang. logic framework) umożliwią maszynom zrozumienie informacji, a nie tylko jej przetwarzanie.

Ostatnie dwie warstwy konieczne są do zapewnienia maszynom (pewnej) autonomiczności w przetwarzaniu informacji i podejmowaniu decyzji w imieniu ich właścicieli. Wymaga to jednak możliwości dostarczenia formalnych dowodów (ang. proof) na poprawność wysuniętych wniosków, oraz ustalenia poziomu zaufania do przeprowadzonego procesu wnioskowania (ang. trust).

Pozostałe dwa elementy, podpisy cyfrowe (ang. signature) i szyfrowanie (ang. encryption), zapewniają bezpieczeństwo operacji w Sieci Semantycznej.

Uff, dużo tego, a co gorsza - same suche specyfikacje, rekomendacje, standardy. Całe szczęście w ciągu ostatnich lat udało się zmienić tę wizję chociaż częściowo w rzeczywistość.

W ciągu ostatnich lat "semantyczny tort" ewoluował wraz z implementacją kolejnych jego warstw. Już dwa lata póżniej, TBL dodał dodatkową warstwę: zapytań (ang. queries) i schematów XML. Pojawiły się też pierwsze narzędzia (Annotea), słowniki (P3P, CC/PP) i standardy (Dublin Core, RSS) implementujące dolne warstwy tortu:

Kolejna wersja semantycznego tortu (rok 2004) http://www.w3.org/2004/Talks/0412-RDF-functions/slide4-0.html

Obecna wersja "semantycznego tortu" zawiera przede wszystkim specyfikacje, które stały się standardami implementującymi poszczególne warstwy: OWL (Web Ontology Language), RIF (Rule Interchange Format), SPARQL (język zapytań dla RDF). Istotne jest, że ontologie, reguły i logika stały się de facto jedną warstwą. Ograniczone też zostało znaczenie formatu XML, bo tak na prawdę w Sieci Semantycznej można radzić sobie bez ograniczeń wprowadzonych przez XML. Pojawiła się też nowa warstwa "docelowa" - interfejs użytkownika (ang. user interface) i aplikacje. Dodatkowo, wskazywanie obiektów możliwe jest teraz za pomocą standardu IRI (Internationalized Resource Identifier) rozszerzającego URI o możliwość używania znaków spoza standardu ASCII do zapisu identyfikatora obiektu.

Do niedawna cały nacisk na prace nad Siecią Semantyczną skierowany był na rozumienie znaczenia treści przez maszyny. To m.in. sukces Web 2.0 spowodował, że zrozumiano potrzebę i ogromne znaczenie interakcji użytkowników z systemami opartymi o rozwiązania semantyczne.

Obecna wersja semantycznego tortu http://www.w3.org/2007/03/layerCake.png

Na zakończenie, wisienka na torcie (ang. cherry on the cake): wersja 3D semantycznego tortu przygotowana przez Benjamina Nowacka. To co w niej istotne to najnowszy element zestawu technologii semantycznych: powiązane dane (ang. linked data). Nie ma co ukrywać, że są one niezmiernie ważne dla sukcesu Web 3.0:  bez semantycznych (czyt. powiązanych) danych, dostępnych w dużej mierze publicznie, żadne mechanizmy wnioskowania nie będą miały znaczenia.

Semantyczny tort w wersji 3D wraz z powiązanymi danymi http://bnode.org/blog/2009/07/08/the-semantic-web-not-a-piece-of-cake