Jak dogadać się w e-handlu ontologie w ebxml

Transkrypt

1 XVI Konferencja PLOUG Kościelisko Październik 2010 Jak dogadać się w e-handlu ontologie w ebxml Tomasz Traczyk Politechnika Warszawska ttraczyk@ia.pw.edu.pl 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.

2

3 Jak dogadać się w e-handlu ontologie w ebxml 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 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.

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

5 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]) 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ądzenieMechaniczne 1. 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.

6 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 Producenci- Samochodó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ów 2 ; 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ść ma- Silnik 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 Marka- Samochodu wszystkie wartości własności produkowanaprzez muszą należeć do klasy ProducenciSamochodów 3. 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 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. 3 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.

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

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

9 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 klasy/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 Submit- ObjectsRequest 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.

10 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/repozytorium ebxml oraz zarządzania wersjami ontologii. Zachowano tu koncepcję zapisu dokumentów OWL w repozytorium i ich reprezentacji w rejestrze jako Extrinsic- Objects, 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 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

11 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żywane 4. 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), [Chiu02] Chiu E.: ebxml Simplified, Wiley [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), [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, [Hioual08] Hioual, O. Boufaida, Z.: Towards a semantic composition of ebxml business processes. International Conference on Innovations in Information Technology (IIT 2008), 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.

12 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 [OWL] OWL Web Ontology Language, W3C Recommendation 10 February [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), [RIM] ebxml Registry Information Model (RIM) Standard Version 3.0, OASIS [RPOWL06] ebxml Registry Profile for Web Ontology Language (OWL) Version 1.5, OASIS [RPOWL09] ebxml Registry Profile for Web Ontology Language (OWL) Version 2, OASIS [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.