Jak dogadać się w e-handlu – ontologie w ebXML

XVI Konferencja PLOUG
Kościelisko
Październik 2010
Jak dogadać się w e-handlu – ontologie
w ebXML
Tomasz Traczyk
Politechnika Warszawska
[email protected]
Abstrakt. We wszelkiej działalności handlowej jednym z podstawowych problemów jest „dogadywanie się” co do towaru i warunków
wymiany. By precyzyjne ustalenie transakcji było możliwe, strony muszą się nawzajem dobrze rozumieć. Problem ten dotyczy oczywiście także transakcji elektronicznych.
Referat stanowi uzupełnienie zeszłorocznego referatu o ebXML [Traczyk09]. Pokazuje możliwości użycia ontologii zapisanych w języku OWL do dokładnego zdefiniowania semantyki pojęć używanych w e-handlu oraz prezentuje istniejące standardy.
Informacja o autorze. dr inż. Tomasz Traczyk jest docentem w Instytucie Automatyki i Informatyki Stosowanej Politechniki Warszawskiej, gdzie pełni funkcję zastępcy dyrektora ds. dydaktycznych, kieruje także studiami podyplomowymi „Inżynieria systemów
informatycznych zarządzania i wspomagania decyzji”.
Jak dogadać się w e-handlu – ontologie w ebXML
89
1. Wprowadzenie
Podobnie jak w handlu tradycyjnym, tak i w elektronicznym, kluczem do sukcesu i do zadowolenia stron z zawartej transakcji jest precyzyjne porozumienie co do przedmiotu handlu i warunków kupna/sprzedaży. Gdy handlują między sobą ludzie, precyzja porozumienia może być
ograniczona, gdyż wiele szczegółów domniemuje się lub uważa za ustalone na mocy obowiązujących zwyczajów. Podobnie jest w handlu elektronicznym B2C (Business to Customer) – przynajmniej jedna strona jest tu człowiekiem i powinna wykazywać się przytomnością umysłu. Jednak pojawia się tu istotnie nowy aspekt: zanim klient coś kupi, musi wyszukać odpowiedni towar
wśród tysięcy e-sklepów i milionów oferowanych dóbr. Takie wyszukanie bywa bardzo trudne,
jeśli nazwa produktu nie jest dokładnie znana lub jest niejednoznaczna.
Znacznie trudniejsza jest sytuacja w handlu B2C (Business to Business), gdyż w tym przypadku oczekujemy możliwości przynajmniej częściowej automatyzacji zawierania transakcji. Rynek
elektroniczny jest trudny, gdyż zwykle jest otwarty – mogą do niego dołączać nowi uczestnicy,
jest dynamiczny – podjęte współprace mogą się często zmieniać, oraz jest heterogeniczny –
uczestnicy różnią się co do swej natury, używanych standardów, języka, systemów pojęć/
terminów itd. Mamy tu także do czynienia z wymianą formalnych dokumentów, których treść
musi być jednoznacznie interpretowalna: strony muszą mieć gwarancję, że tę treść rozumieją tak
samo. Wszelkie niejednoznaczności w rozumieniu pojęć lub rozbieżności w stosowanej terminologii mogą doprowadzić do poważnych trudności i sporów. Poprzeczkę trzeba podnieść jeszcze
wyżej, jeśli w handlu mają uczestniczyć automatyczne agenty. W tym przypadku wymiana informacji handlowych musi być zorganizowana tak, by programy komputerowe bez pomocy ludzkiej
mogły jednoznacznie interpretować oferty i dokumenty, i bez ryzyka związanego z rozbieżnością
interpretacji zawierać transakcje handlowe. Muszą zatem istnieć odpowiednie metody i narzędzia
pozwalające operować informacją na poziomie jej semantyki, a nie tylko składni.
1.1. Problemy z semantyką w e-biznesie
Jak się okazuje, takie zorganizowanie wymiany informacji handlowej, które eliminuje ryzyko
niejednoznacznej interpretacji pojęć i dokumentów, jest trudne. Nie wystarczają tu metody stosowane w tradycyjnym handlu, gdyż – jak wspomniano – tam wiele trudności rozwiązuje się
w oparciu o doświadczenie człowieka, tymczasem w e-handlu oczekujemy możliwości przynajmniej częściowej automatyzacji, np. procesu wyszukiwania i kojarzenia ofert.
Typowy problem semantyczny, na jaki natrafia się w wymianie handlowej, nazwać można
„dystansem semantycznym” (semantic distance). Polega on na tym, że strony, potencjalnie mogące ze sobą handlować, opisują swoje oferty kupna/sprzedaży za pomocą odmiennej terminologii
(kupię auto / sprzedam samochód), na innym poziomie specjalizacji/generalizacji (kupię auto /
sprzedam Opla) czy też nawet używając różnych systemów pojęciowych (kupię limuzynę z odliczeniem VAT / sprzedam samochód ciężarowy w karoserii samochodu osobowego – sic!). Proste
składniowe metody dopasowywania ofert są w takich przypadkach bezradne; by móc skojarzyć
oferty niezbędne jest sięgnięcie do metod semantycznych.
Inny problem to potrzeba kojarzenia ofert kupna/sprzedaży nie tylko wg nazwy czy rodzaju
towaru, ale także wg jego cech (własności) szczegółowych. By ten proces móc zautomatyzować,
trzeba dysponować modelem opisującym towary i rynek w sposób dokładniejszy niż tylko na poziomie słowników.
Najbardziej typowe jest występowanie problemów semantycznych przy wyszukiwaniu towarów i ofert, ale właśnie takie wyszukiwanie rozpoczyna większość transakcji elektronicznych;
możliwość znalezienia precyzyjnie pasującej oferty na szerokim rynku to przecież jedna z największych przewag e-handlu nad handlem tradycyjnym.
90
Tomasz Traczyk
1.2. Rozwiązanie – ontologie
Te i inne problemy wymagają rozwiązań sięgających do warstwy znaczeniowej wymienianej
informacji – do semantyki, by w procesie, który nazwać można semantic resolution [Peng02],
identyfikować znaczenia użytych terminów i uzgadniać je.
By móc rozwiązywać wyżej opisane problemy w sposób zautomatyzowany, trzeba sformalizować wiedzę na temat dziedziny, której pojęciami operuje się na danym rynku, w celu sprecyzowania terminologii, ustalenia relacji między pojęciami, opisania właściwości charakteryzujących pojęcia itp. Współcześnie uważa się, że odpowiednim narzędziem do takiej formalizacji są
ontologie.
2. Ontologie – przypomnienie
Choć zagadnienia związane z semantyką stały się ostatnio dość modne, nie jest to wciąż dziedzina powszechnie znana, dlatego zamieszczamy krótkie przypomnienie podstawowych zagadnień związanych z ontologiami i językiem OWL.
2.1. Taksonomie i ontologie
Najprostszą formalizację terminologii stanowią oczywiście słowniki. Podają one spis terminów
oraz ich znaczenie, jednak nie określają w sposób formalny relacji między pojęciami reprezentowanymi przez owe terminy. Dlatego nadają się raczej do użycia przez ludzi, a nie przez programy.
Taksonomie reprezentują terminologię dziedzinową w sposób silniej sformalizowany, gdyż
terminy zorganizowane są w hierarchie, zwykle reprezentujące relacje specjalizacji-generalizacji.
Sprecyzowanie terminologii w formie taksonomii bywa wystarczające do automatyzacji niektórych działań związanych z semantyką, np. do realizacji zapytań uwzględniających uogólnienia.
Taksonomie nie pozwalają jednak modelować wielu różnych relacji między pojęciami, ani nie
dają możliwości zdefiniowania własności obiektów odpowiadających zdefiniowanym pojęciom.
W taksonomiach nie można też opisać indywiduów – wystąpień (instancji) owych pojęć.
Ontologie nie mają tych ograniczeń. Ontologia jest opisem pewnej dziedziny zainteresowań,
wyszczególniającym podział tej dziedziny na pojęcia. Pozwala modelować pojęcia i przypisaną im
terminologię, określać związki między pojęciami, oraz indywidua będące instancjami pojęć i
związki między nimi. Zapisywana jest zwykle w sformalizowanym języku; współcześnie używane
są zwykle otwarte standardy, głównie te tworzone przez W3C (World Wide Web Consortium).
Daje możliwość wyrażenia złożonych opisów obiektów oraz wykorzystania ontologii utworzonych wcześniej, np. zbudowania ontologii bardziej szczegółowej na bazie ontologii ogólniejszej.
2.2. RDF i RDF Schema
Współczesne języki opisu semantycznego zwykle w mniejszym lub większym stopniu korzystają z idei RDF (Resource Description Framework). Intencją twórców RDF było stworzenie uniwersalnego sposobu semantycznego opisu wszelkiego rodzaju zasobów, zwłaszcza zasobów sieci
Web. Sama idea RDF pochodzi z czasów przed powstaniem XML, istnieje jednak – obok kilku
innych – notacja RDF w XML (tzw. RDF/XML).
Wiedza o zasobach jest w RDF reprezentowana przez tzw. trójki składające się z:
• podmiotu (subject), czyli zasobu którego cechy chcemy opisać,
• predykatu (predicate), inaczej zwanego własnością (property), określającego cechę zasobu,
• dopełnienia (object), czyli wartości (value), określającej wartość tej cechy.
Jak dogadać się w e-handlu – ontologie w ebXML
91
Taki sposób opisu jest wprawdzie bardzo elastyczny, ale nie ogranicza zbioru pojęć, którymi
można się posługiwać, co może czynić zapisaną wiedzę bezużyteczną, bo niezrozumiałą. Konieczne jest więc uporządkowanie używanego systemu pojęć i terminologii. Służyć do tego ma
standard RDF Schema – dialekt XML, mający służyć do definiowania i wymiany słowników.
Wprowadza on pojęcie klasy (class), mającej własności (properties). Własności umożliwiają
określenie relacji między klasami, pozwalając np. na budowanie hierarchii klas. W RDF Schema
można w ograniczony sposób zapisywać ontologie, ma on jednak poważne wady (por. [Morzy09]).
2.3. OWL
Na bazie RDF i RDF Schema stworzono zatem język OWL (Web Ontology Language). Ma on
dużą siłę wyrazu, a na podstawie zapisanej w nim wiedzy można także prowadzić automatyczne
wnioskowanie. Zdefiniowano trzy wersje tego języka:
• OWL Full ma największą siłę wyrazu, ale nie można gwarantować, że będzie możliwe
wnioskowanie na podstawie wszystkich zapisów w tym języku;
• OWL DL ma zapewne najlepsze własności użytkowe, gdyż dysponuje dużą siłą wyrazu,
jednocześnie gwarantując możliwości wnioskowania; jako podstawę teoretyczną ma tzw.
logiki opisowe (description logics);
• OWL Lite jest wersją najprostszą, o ograniczonej liczbie konstrukcji, ale za to stosunkowo
łatwą w użyciu, a zapewniającą możliwość definiowania hierarchii pojęć i prostych ograniczeń, z siłą wyrazu znacznie wykraczającą poza proste taksonomie.
Tak jak w logikach opisowych, tak i w OWL opis dziedziny składa się z:
• terminologii, określającej pojęcia (koncepty), odpowiadające im terminy i związki między
pojęciami,
• opisu świata, zawierającego asercje opisujące obiekty-indywidua, przyporządkowując je
pojęciom i podając związki między indywiduami.
Terminologię buduje się z tzw. klas (class). Klasa określa terminy oraz właściwości opisujące
zbiór indywiduów odpowiadających danemu pojęciu. Klasy tworzą struktury specjalizacji/generalizacji; np. klasa Samochód jest podklasą klasy PojazdMechaniczny, a ta z kolei podklasą
klasy Pojazd. Podklasa dziedziczy oczywiście charakterystykę nadklasy. Klasa może być podklasą wielu klas, co jest powszechnie używane; np. klasa PojazdMechaniczny jest jednocześnie podklasą klasy UrządzenieMechaniczne1. Do tworzenia struktur nadklas-podklas służy
konstruktor rdfs:subClassOf. Wszystkie klasy w OWL wywodzą się od klasy owl:Thing,
reprezentującej całe uniwersum, jest też określona pusta klasa owl:Nothing.
Definicja klasy może zawierać etykiety (labels), czyli odpowiadające pojęciu terminy w różnych językach; np. klasa Samochód może mieć etykiety samochód, auto, car, automobile, voiture, vettura, Kraftfahrzeug itd. Może też zawierać tzw. restrykcje, dokładniej określające pojęcie.
Przynależność do nadklasy jest rodzajem takiej restrykcji, inne restrykcje mogą dotyczyć wartości
przybieranych przez własności klasy, co dokładniej opisano dalej.
Własności (properties) mogą dotyczyć klas oraz indywiduów. W OWL mogą mieć wartości
literalne (tzw. Datatype Properties), a typ danych można określić za pomocą XML Schema; np.
własność rokProdukcji może być typu xsd:gYear. Mogą też być relacjami między instancjami dwóch klas (tzw. Object Properties).
1
Jest to element innego drzewa hierarchii niż Pojazd, gdyż można sobie wyobrazić pojazd nie będący wytworem mechanicznym, np. lektykę, balon lub latający dywan.
92
Tomasz Traczyk
Dla własności można podać dziedzinę (domain), określającą klasy mogące mieć daną własność, oraz zakres (range), określający wartości jakie własność może przybierać; np. dziedziną
własności jestMarki jest klasa Produkt, zaś zakresem jest klasa Marka. Własności mogą
być określone jako przechodnie (transitive), symetryczne (symmetric), odwrotne (inverse), funkcyjne (functional) lub odwrotnie funkcyjne (inverse functional). Wszystkie te cechy są przydatne
w procesie wnioskowania z ontologii: np. jeśli pewne indywiduum ma własność jestMarki,
można wnioskować, że jest ono produktem; jeśli własność produkowanaPrzez jest odwrotna
w stosunku do własności produkujeMarkę i dla marki Opel znana jest wartość własności produkowanaPrzez, będąca wskazaniem instancji General Motors klasy ProducenciSamochodów, wynika z tego, że własność produkujeMarkę dla General Motors przyjmuje
wartość Opel. Szczególne znaczenie mają własności odwrotnie funkcyjne: ich wartości stanowią
unikalne identyfikatory charakteryzowanych indywiduów2; zatem dwa indywidua mające tę samą
wartość takiej własności muszą być uznane za tożsame. Własności, podobnie jak klasy, mogą
tworzyć struktury generalizacji/specjalizacji; do ich tworzenia służy konstruktor
rdfs:subPropertyOf.
Własności mogą także mieć podane ograniczenia liczności (cardinality), czyli liczby wartości,
które może przybrać dana własność w stosunku do jednego indywiduum. Domyślnie nie ma ograniczeń; np. własność produkujeMarkę dla General Motors przyjmuje jednocześnie wartości
Opel, Buick, Cadillac, Chevrolet itd. W OWL Lite dopuszczone są jedynie ograniczenia liczności
„przynajmniej 1”, „najwyżej 1” lub „dokładnie 1”; np. własność rokProdukcji ma liczność
„dokładnie 1”. Ograniczenia tego typu mogą być użyte jako konstytutywne cechy klasy, np. klasa
PojazdSilnikowy może być określona jako podklasa klasy Pojazd, która ma własność maSilnik o liczności „przynajmniej 1”.
Jak wspomniano wcześniej, restrykcje określające klasę mogą dotyczyć wartości przybieranych przez własności klasy. Ograniczenie allValuesFrom oznacza, że dla instancji danej klasy wszystkie wartości danej własności muszą należeć do konkretnej klasy; np. dla klasy MarkaSamochodu wszystkie wartości własności produkowanaPrzez muszą należeć do klasy
ProducenciSamochodów3. Ograniczenie someValuesFrom oznacza, że dla każdej instancji danej klasy przynajmniej jedna z wartości danej własności musi należeć do konkretnej klasy.
W OWL DL ograniczenie hasValue może narzucać konkretną wartość danej własności dla
wszystkich instancji danej klasy; np. klasę PojazdDwukołowy można by zdefiniować jako
podklasę klasy Pojazd, mającą wartość własności liczbaKół równą 2.
Opis świata składa się z indywiduów; w OWL są one instancjami klas i dziedziczą po nich
własności, które w stosunku do indywiduów pełnią rolę atrybutów.
O indywiduach można w OWL zapisać, że są tożsame (sameAs) lub różne od siebie (nietożsame, differentFrom), można też określić cały zbiór indywiduów jako wzajemnie nietożsamych (mutually distinct – konstruktory AllDifferent + distinctMembers); np. dla instancji klasy Marki można byłoby określić, że wszystkie są wzajemnie nietożsame. W OWL DL klasę można też zdefiniować enumeratywnie – przez wyliczenie jej instancji (konstruktor oneOf).
Ponieważ jednym z założeń OWL jest możliwość budowania nowych ontologii jako rozszerzenia ontologii istniejących, także w rozproszonym środowisku sieciowym, istnieje możliwość
importu jednej ontologii (adresowanej jako zasób sieci Web) do innej. Klasy oraz własności moż2
3
Niestety, w OWL Lite i OWL DL nie jest dozwolone deklarowanie własności o wartościach literalnych
jako odwrotnie funkcyjnych, można tak określić tylko własności typu Object Property.
Nie jest to tożsame z podaniem zakresu (range) własności, zakres ma bowiem znaczenie globalne (dla
wszystkich klas), zaś ta restrykcja działa tylko lokalnie – dla definiowanej klasy; w przypadku własności
produkowanaPrzez zakresem może być klasa Producenci, nie ograniczona do producentów samochodów;
przykładowa restrykcja dotyczy tylko klasy MarkaSamochodów.
Jak dogadać się w e-handlu – ontologie w ebXML
93
na oznaczyć jako równoważne sobie (equivalentClass, equivalentProperty); przydaje się to szczególnie przy łączeniu ontologii pochodzących z różnych źródeł. W OWL istnieją
także konstruktory umożliwiające konstruowanie nowych klas z klas zdefiniowanych wcześniej,
jako przecięcie (intersectionOf), a w OWL DL także suma (union) oraz dopełnienie
(complementOf) oraz określenia klas jako rozłączne (disjointWith).
Wszystkie te konstrukcje języka OWL sprawiają, że jest to język o dużej sile wyrazu, pozwalający w dość wyczerpujący sposób opisać dziedzinę zainteresowań.
3. Ontologie w ebXML
By poradzić sobie z problemami semantycznymi wynikającymi z różnic terminologicznych
i różnych systemów pojęć stosowanych przez strony uczestniczące w handlu, trzeba precyzyjnie
i w sposób sformalizowany opisać owe systemy pojęć i terminologii oraz określić odwzorowania
między nimi. Ontologie wydają się najbardziej obiecującym narzędziem umożliwiającym taki
opis.
W handlu B2B opierającym się na ebXML problemy semantyczne są oczywiście obecne,
a standardowe rozwiązania nie dostarczają narzędzi umożliwiających skuteczne radzenie sobie
z nimi. Standard zapewnia jedynie rozwiązania wspierające wyszukiwanie z użyciem taksonomii,
co nie rozwiązuje wszystkich problemów.
Dlatego podjęto wysiłki zmierzające do rozszerzenia rozwiązań bazujących na ebXML o możliwość wykorzystania ontologii. Wynikiem tych prac jest ebXML Registry Profile for Web Ontology Language [RPOWL06, RPOWL09] – opracowywana przez OASIS propozycja zapisu i sposobów użycia ontologii zgodnych z OWL w rejestrze ebXML.
3.1. Rejestr/repozytorium ebXML – przypomnienie
Jednym z kluczowych elementów infrastruktury ebXML jest rejestr/repozytorium. W ebXML
zakłada się bowiem, że w handlu B2B istnieją pewne znane uczestnikom rynku lokalizacje sieciowe, które pełnią rolę „centrów informacyjnych”, przechowując i udostępniając informacje i dokumenty niezbędne do nawiązania kontaktów handlowych i prowadzenia handlu (patrz np.
[Chiu02, Traczyk09]).
Repozytorium ebXML jest właśnie składnicą przechowującą dokumenty potrzebne w handlu,
takie jak profile uczestników, kontrakty itp. Jest to struktura otwarta w tym sensie, że oprócz dokumentów określonych w standardzie ebXML może przechowywać także dowolne inne, np. opisy
semantyczne w OWL. Rejestr ebXML zawiera metadane, m.in. opisujące dokumenty składowane
w repozytorium, oraz dostarcza usług dostępu do tych metadanych i do zawartości repozytorium.
Rejestr ebXML udostępnia informacje za pośrednictwem dwóch interfejsów:
• Lifecycle Manager umożliwia manipulowanie informacjami w rejestrze/repozytorium, tj.
ich umieszczanie, modyfikację i kasowanie;
• Query Manager pozwala pozyskiwać informacje przez zadawanie zapytań.
Zapytania do rejestru/repozytorium mogą być zapisane w specjalnym dialekcie XML – są to
tzw. Filter Queries. W wyniku zwracają one zbiór identyfikatorów obiektów rejestru/repozytorium, które spełniają warunki zapytania. Za pomocą innych rodzajów zapytań można pobrać
dokumenty o znalezionych identyfikatorach. Ponieważ implementacje rejestru są zwykle zbudowane w oparciu o relacyjne bazy danych, standard ebXML zakłada także możliwość zadawania
zapytań w SQL. Rejestr i repozytorium ebXML są dostępne dla zapytań SQL w postaci prostego
modelu składającego się z kilku tabel/perspektyw relacyjnych. Standard ebXML zakłada także
94
Tomasz Traczyk
możliwość tworzenia „procedur składowanych” (stored procedures), które są w istocie nazwanymi sparametryzowanymi zapytaniami SQL.
Model informacji przechowywanej w rejestrze [RIM] jest dość elastyczny. Informacja jest podzielona na obiekty, istnieje zbiór domyślnych klas tych obiektów, można też tworzyć własne
klasy. Obiekty rejestru reprezentują zarówno zdefiniowane w rejestrze pojęcia/klasy jak i instancje – przechowywane w rejestrze metadane dokumentów itp., a także wszelkie struktury samego
rejestru. Każdy obiekt rejestru jest identyfikowany przez globalnie unikalny identyfikator (UUID)
oraz przez nazwę. Obiekty mogą mieć tzw. sloty – dowolnie dodawane atrybuty. Obiekty predefiniowanej klasy ExtrinsicObject reprezentują w rejestrze dokumenty dowolnych nieznanych
rejestrowi typów, przechowywane w związanym z nim repozytorium, zaś obiekty klasy ExternalLink służą do wskazywania zasobów, które są przechowywane poza danym rejestrem/repozytorium.
Między obiektami można ustanowić asocjacje. Model rejestru dostarcza zbioru predefiniowanych typów asocjacji, m.in. określających zawieranie się obiektów w innych obiektach (Contains), równoważność obiektów (EquivalentTo), relację specjalizacji/dziedziczenia
(Extends), bycie przez pewien obiekt instancją innego (InstanceOf). Możliwe jest też tworzenie nowych typów asocjacji. Obiekty rejestru mogą być pogrupowane w pakiety (za pomocą
predefiniowanej klasy RegistryPackage i asocjacji HasMember); dzięki pakietom obiekty
można zorganizować np. w struktury podobne do katalogów.
Rejestr ebXML z założenia dostarcza możliwości klasyfikacji wszystkich przechowywanych
w nim obiektów. Klasyfikacja opiera się na tzw. schematach klasyfikacji (predefiniowana klasa
ClassificationScheme), będących taksonomiami o postaci drzew, złożonych z tzw.
ClassificationNodes. Każdy obiekt w rejestrze może być zaklasyfikowany wielokrotnie,
tj. przypisany do węzłów wielu schematów klasyfikacji; do tworzenia takich wielokrotnych powiązań służą obiekty predefiniowanej klasy Classification.
3.2. Reprezentacja ontologii w rejestrze/repozytorium ebXML
Ponieważ repozytorium ebXML jest tworem bardzo elastycznym, nic nie stoi na przeszkodzie,
by przechowywać w nim ontologie czy semantyczne opisy poszczególnych obiektów (dokumentów, partnerów itp.) wprost w postaci dokumentów OWL. Jednak taka reprezentacja nie umożliwia wykorzystania wiedzy zawartej w OWL wprost z poziomu usług oferowanych przez rejestr/repozytorium.
By informacja semantyczna mogła być wykorzystana w usługach oferowanych przez rejestr,
np. w zapytaniach, musi ona zostać zapisana wprost w rejestrze. Dokumenty OWL powinny zatem, oprócz zapisania ich w repozytorium, być także przekształcone do postaci odpowiednich
zapisów w strukturze danych rejestru ebXML. Sposób takiego zapisu zaproponowano w pracach
[Dogac04, Dogac05]. Ponieważ spodziewano się, że informacja semantyczna będzie używana
głównie do wyszukiwania obiektów w repozytorium, zdecydowano się na ograniczenie reprezentowanych ontologii do zakresu OWL Lite. Prace te zyskały akceptację organizacji OASIS, stając
się podstawą propozycji ebXML Registry Profile for Web Ontology Language w wersji 1.5
[RPOWL06].
Głównym założeniem proponowanego podejścia jest wykorzystanie istniejących mechanizmów rejestru ebXML, bez konieczności ich modyfikacji, czyli bez zmiany standardów ebXML,
np. [RIM]. Założono zatem, że ontologie zostaną zapisane jako obiekty rejestru typu ClassificationScheme, a klasy z języka OWL – jako ClassificationNodes. W ebXMLowych drzewach taksonomii nie przewidziano jednak wielokrotnego dziedziczenia, co w OWL
jest normą; do tworzenia struktur specjalizacji/generalizacji nie można zatem było wykorzystać
wbudowanego typu asocjacji Extends, zdecydowano się powołać nowy typ asocjacji o nazwie
Jak dogadać się w e-handlu – ontologie w ebXML
95
subClassOf i używać go do łączenia klas podrzędnych z nadrzędnymi. Hierarchię własności
reprezentuje się podobnie – przez nowy typ asocjacji subPropertyOf.
Własności reprezentuje się w rejestrze także jako nowe typy asocjacji; odpowiednio definiując
klasę źródłową (sourceObject) i docelową (targetObject) tych typów asocjacji określa
się dziedzinę i zasięg własności. W przypadku własności typu Data Property jako obiektów docelowych używa się specjalnie zdefiniowanych tzw. ExternalLinks, wskazujących przez
adresy URI na typy danych XML Schema. Takie cechy własności jak transitive, symmetric, inverse, functional i inverse functional reprezentuje się w rejestrze ebXML jako osobne typy asocjacji.
W OWL można oznaczyć klasy, własności oraz indywidua jako równoważne; w rejestrze
ebXML istnieje predefiniowany typ asocjacji EquivalentTo, który wykorzystuje się do reprezentowania tej równoważności.
Restrykcje w OWL służą do ograniczenia globalnie zdefiniowanych własności w kontekście
danej klasy. W rejestrze ebXML mogą być one reprezentowane jako dodatkowe atrybuty
(slots) asocjacji, ponieważ typ asocjacji reprezentujący własność jest od razu definiowany lokalnie, jako łączący konkretne klasy. Operator przecięcia klas reprezentowany jest przez nowy typ
asocjacji łączącej obiekt wynikowy z pakietem (w sensie RegistryPackage), zawierającym
klasy – argumenty operacji przecięcia.
Indywidua zapisywane są w rejestrze jako ExtrinsicObjects, czyli odnośniki do obiektów zawartych z repozytorium. Inne szczegóły odwzorowania konstrukcji OWL Lite na struktury
rejestru ebXML omówiono dokładnie w [Dogac05, RPOWL06].
Odwzorowując ontologie zapisane w OWL w strukturach rejestru ebXML uzyskano możliwość tworzenia zapytań do rejestru, wykorzystujących informację semantyczną zawartą w ontologiach. Oprócz prostych zapytań, korzystających z zależności specjalizacji/generalizacji, można
realizować także zapytania bardziej złożone. Autorzy odwzorowania [Dogac05] proponują, by
takie złożone a typowe zapytania zdefiniować w rejestrze jako procedury składowane o odpowiednich parametrach. W propozycji profilu [RPOWL06] zaproponowano konkretne zapytania,
jakie powinny być dostępne w rejestrze; są to m.in. zapytania o:
• klasy/własności nadrzędne (w sensie specjalizacji/generalizacji) w stosunku do danej kla-
sy/własności;
• klasy bezpośrednio nadrzędne/podrzędne (w sensie specjalizacji/generalizacji) w stosunku
do danej klasy;
• klasy/własności równoważne w stosunku do danej klasy/własności;
• indywidua tożsame/nietożsame (w sensie sameAs) z danym indywiduum;
• własności danej klasy (z różnymi ograniczeniami, np. tylko własności konkretnego typu);
• indywidua danej klasy.
Przekształcanie ontologii zapisanych w OWL w struktury rejestru ebXML jest oczywiście procesem żmudnym, dlatego w [Dogac04, Dogac05, Bechini08] zaproponowano narzędzia, które
analizują dokumenty OWL, tworzą struktury rejestru i zapisują je za pomocą instrukcji SubmitObjectsRequest interfejsu Lifecycle Manager rejestru ebXML.
Zaproponowane rozwiązanie pozwala zapisywać ontologie w rejestrze ebXML i użyć ich do
usprawnienia wyszukiwania obiektów w rejestrze. Nie daje jednak możliwości wnioskowania
z ontologii bezpośrednio w rejestrze; do tego konieczny jest odpowiedni zewnętrzny reasoner,
który może wnioskować na podstawie ontologii odczytywanych z rejestrów.
96
Tomasz Traczyk
3.3. Nowa wizja użycia ontologii w rejestrze/repozytorium ebXML
Stworzona w roku 2009 wersja 2 propozycji ebXML Registry Profile for Web Ontology Language [RPOWL09] znacząco różni się od poprzednich propozycji. Odchodzi ona całkowicie od proponowania konkretnych sposobów implementacji, w tym reprezentacji konstrukcji OWL
w strukturach rejestru ebXML. Zamiast tego specyfikuje właściwości rejestru oraz jego sposoby
użycia, które powinny być zrealizowane, by rejestr ebXML mógł być używany do przechowywania i wykorzystywania ontologii w OWL. Wersja 2 zakłada także użycie do opisu semantycznego
konstrukcji języka OWL DL, nie ograniczając się do OWL Lite.
• Wyspecyfikowano procedury publikowania opisów semantycznych w OWL w rejestrze/re-
pozytorium ebXML oraz zarządzania wersjami ontologii. Zachowano tu koncepcję zapisu
dokumentów OWL w repozytorium i ich reprezentacji w rejestrze jako ExtrinsicObjects, ale nie podano konkretnego sposobu reprezentacji w rejestrze metadanych reprezentujących informację semantyczną zawartą w tych dokumentach OWL.
• Podano sposób odwoływania się do kontekstu semantycznego (rozumianego jako zbiór
ontologii w OWL) w zapytaniach oraz zbiór tzw. funkcji kanonicznych, służących do użycia w zapytaniach, które powinien udostępniać rejestr ebXML – są one podobne do zapytań
zaproponowanych w wersji 1.5.
• Postuluje się, by serwer implementujący funkcje rejestru realizował zapytania w języku
SPARQL – zdefiniowanym przez W3C języku semantycznych zapytań do struktur bazujących na RDF.
• Zaproponowano procedury zarządzania ontologiami składowanymi w rejestrze ebXML,
uwzględniające różne role organizacji uczestniczących w procesie tworzenia ontologii oraz
różne stadia „życia” tworzonej ontologii.
Jak widać, ta nowa wizja jest znacznie ogólniejsza i nie narzuca żadnej konkretnej metody implementacji, ale wydaje się też trudniejsza do realizacji. O ile w literaturze [Dogac06, Bechini08,
Hioual08] podawane są przykłady zastosowań podejścia z wersji 1.5 profilu [RPOWL06], o tyle
podejście prezentowane w wersji 2 [RPOWL09] wydaje się póki co tylko pewną wizją przyszłości.
3.4. Potencjalne zastosowania
Najbardziej naturalnym zastosowaniem informacji semantycznej zgromadzonej w rejestrze
ebXML jest oczywiście użycie jej do wyszukiwania obiektów w rejestrze/repozytorium (np. towarów lub partnerów); informacja zgromadzona w ontologiach może być w tym przypadku wykorzystana np. do przezwyciężenia „dystansu semantycznego” między zapytaniem a ofertą.
Inna ważna dziedzina zastosowań to użycie opublikowanych w rejestrach ebXML ontologii do
jednoznacznej interpretacji dokumentów wymienianych między stronami handlu lub do automatycznego tłumaczenia dokumentów między systemami posługującymi się innymi systemami pojęć/terminów.
W literaturze znaleźć też można inne ciekawe zastosowania rejestru ebXML rozszerzonego
o możliwości przechowywania ontologii. W pracy [Bechini08] zaproponowano wykorzystanie
wzbogaconego o ontologie rejestru ebXML do realizacji zaawansowanego systemu zarządzania
dokumentami (DMS – Document Management System). [Dogac06] podaje zastosowanie takiego
rejestru do przechowywania informacji medycznej, z użyciem ontologii do uzgadniania terminologii medycznej i wyszukiwania. [Hioual08] omawia użycie rejestru ebXML z zapisaną w nim
ontologią OWL-S, dotyczącą usług sieciowych (Web Services), do automatyzacji tzw. service
composition – składania w architekturze SOA usług złożonych z usług prostszych; zastosowania
Jak dogadać się w e-handlu – ontologie w ebXML
97
ontologii w kontekście usług sieciowych i automatycznej integracji systemów są zresztą tematem
wielu prac badawczych.
4. Podsumowanie
W dobie powszechnej „internetyzacji” coraz jaśniejsze staje się, że jedynie przejście od metod
składniowych do semantycznych pozwoli poradzić sobie z nadmiarem i niejednoznacznością informacji. Zauważono to dość dawno w stosunku do zasobów sieci Web; podobne zjawisko ma
miejsce w handlu elektronicznym.
Uznaną obecnie za wiodącą metodą semantycznego opisu świata jest zastosowanie ontologii.
Prace dotyczące użycia ontologii do opisu i przeszukiwania Weba są prowadzone od lat i dość zaawansowane. Podobne prace zaczęto prowadzić także w stosunku do metod handlu elektronicznego – ten referat opisuje jeden z bardziej znanych wątków tych prac.
Opisane tu rozwiązania nie są jeszcze bardzo zaawansowane, należy je raczej uznać za pierwsze próby. Zresztą w ogóle formalne podejścia do handlu elektronicznego typu B2B są jeszcze
dość nowe i wciąż niezbyt silnie umocowane w praktyce. Wydaje się jednak, że od takiej formalizacji i od użycia metod semantycznych nie ma odwrotu – eksplozja informacji z którą mamy do
czynienia w Internecie nie da się inaczej okiełznać.
Przestawione propozycje rozwiązań bazujących na rejestrze ebXML są o tyle obiecujące, iż
stanowią rozszerzenie standardów stosunkowo – jak na tę dziedzinę – okrzepłych i wspieranych
przez ważne ciała międzynarodowe. O ile koncepcyjnie są to rozwiązania dość ciekawe, zapewne
jeszcze sporo czasu minie zanim staną się one w miarę powszechnie używane4. Należy się jednak
spodziewać, że przedstawione tu idee, albo idee bardzo podobne, staną się w niedługim czasie
jednym z filarów rozwoju handlu elektronicznego, zwłaszcza handlu zautomatyzowanego, prowadzonego przez programowe agenty.
Bibliografia
[Bechini08]
Bechini, A., Tomasi, A., and Viotto, J.: Enabling ontology-based document classification
and management in ebXML registries. Proceedings of the 2008 ACM Symposium on Applied Computing (SAC '08), 2008.
[Chiu02]
Chiu E.: ebXML Simplified, Wiley 2002.
[Dogac04]
Dogac A., Kabak Y., Laleci G.B.: Enriching ebXML Registries with OWL Ontologies for
Efficient Service Discovery. Proceedings of the 14th International Workshop on Research
Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE'04), 2004.
[Dogac05]
Dogac A., Kabak Y., Laleci G.B., Mattocks C., Najmi F., Pollock J.: Enhancing ebXML
Registries to Make them OWL Aware. Distributed and Parallel Databases archive, Volume
18, Issue 1 (July 2005).
[Dogac06]
Dogac, A., Laleci, G. B., Kabak, Y., Unal, S., Heard, S., Beale, T., Elkin, P. L., Najmi, F.,
Mattocks, C., Webber, D., and Kernberg, M.: Exploiting ebXML registry semantic constructs for handling archetype metadata in healthcare informatics. Int. J. Metadata Semant.
Ontologies 1, 1 (Jan. 2006).
[ebXML]
ebXML – Enabling a global electronic market, http://www.ebxml.org/
[Hioual08]
Hioual, O. Boufaida, Z.: Towards a semantic composition of ebXML business processes.
International Conference on Innovations in Information Technology (IIT 2008), 2008.
4
A pewien zamęt wprowadzony przez znaczącą zmianę koncepcji profilu ebXML Registry Profile for Web
Ontology Language zapewne utrudni jego przyswojenie przez użytkowników.
98
Tomasz Traczyk
[Morzy09]
Morzy M.: Semantic Technologies, czyli Oracle i Web 3.0. Materiały XV Konferencji użytkowników i deweloperów Oracle. Kościelisko, październik 2009.
[OWL]
OWL Web Ontology
http://www.w3.org/
[Peng02]
Peng, Y., Zou, Y., Luan, X., Ivezic, N., Gruninger, M., and Jones, A.: Semantic resolution
for e-commerce. Proceedings of the 1st international Joint Conference on Autonomous
Agents and Multiagent Systems (AAMAS '02), 2002.
[RIM]
ebXML Registry Information Model (RIM) Standard Version 3.0, OASIS 2005.
http://www.oasis-open.org/
[RPOWL06]
ebXML Registry Profile for Web Ontology Language (OWL) Version 1.5, OASIS 2006.
[RPOWL09]
ebXML Registry Profile for Web Ontology Language (OWL) Version 2, OASIS 2009.
[Traczyk09]
Traczyk T.: ebXML – XML w służbie handlu. Materiały XV Konferencji użytkowników i deweloperów Oracle. Kościelisko, październik 2009.
Language,
W3C
Recommendation
10
February
2004.