Amit Singhal (Google search executive) mówi, że wykorzystane zostaną powiązania między obiektami takimi jak ludzie, miejsca i rzeczy, które Google zgromadziło w swojej tajemnej bazie danych przez ostatnie 2 lata. Powiązania te pozwolą na lepsze powiązanie fraz wyszukiwanych przez użytkowników. Przykładowo słowo ‘Google’ zostanie powiązane ze słowami takimi jak Larry Page czy Sergey Bryn (założyciele wyszukiwarki).

Obok tradycyjnych niebieskich wyników zapytań pojawią się powiązane atrybuty np. obok jakiegoś szukanego jeziora pojawią się dodatkowe atrybuty (parametry) takie jak temperatura, głębokość, miejsce znajdowania się itp. Przy niektórych zapytaniach już dziś pojawiają się na samej górze konkretne odpowiedzi na pytania takie jak „Kto jest prezydentem USA?”. Za niedługo będą udzielane także odpowiedzi na zapytania takie jak „10 największych jezior w USA” itp. Nie da się pomylić zamka błyskawicznego z budynkiem po przejściu do wyniku zapytania zwróconego przez Google.

Korzyści z tego typu powiązań odniesie nie tylko zwykły użytkownik ale także firmy, które będą mogły lepiej ukierunkować swoje reklamy na konkretnych odbiorców. Rozwiązanie to już jest wykorzystywane w znanych portalach społecznościowych takich jak Facebook. Jak widać stworzenie Google + miało nie tylko być kolejnym portalem społecznościowym lecz jednym ze środków wspomagających tworzenie dużej bazy wiedzy o zainteresowaniach użytkowników wykorzystywanych do stworzenia powiązań w semantycznym web.

Bardziej relewantne wyniki wyszukiwań pozwolą na dłuższe zatrzymywanie użytkowników na stronach i zwiększyć już i tak duże zaufanie do wyszukiwarki Google : – ) Pozwoli to na lepsze konkurowanie z portalami takimi jak Facebook czy Twitter. Dodatkowo oferowane będą „podpowiedzi” pod wyszukiwaniami o książki, gadżety, elektronikę itp., które jeszcze bardziej wydłużą obecność użytkownikach na stronach Google.

O semantycznych rozwiązaniach w największej wyszukiwarce świata mówiło się już od jakiegoś czasu ale ostatnio znów robi się o tym głośno i miejmy nadzieję, że za niedługo zobaczymy konkrety. Jeśli stanie się to faktem to z pewnością zawrzeje w branży SEO :- )

Chcąc wyszukać pierwszych dziesięć ofert firmy „Kowalski Enterprise” zawierające w opisie słowo „Sony” wykonujemy następujące zapytanie w język SPARQL:

PREFIX gr: <http://purl.org/goodrelations/v1#>
SELECT ?nazwafirmy, ?oferta, ?komentarz
WHERE
{
?a rdf:type gr:BusinessEntity.
?a gr:legalName ?nazwafirmy.
?a gr:offers ?oferta.
?oferta rdfs:comment ?komentarz.
FILTER(regex(?nazwa,"Kowalski Enterprise")&&regex(?comment,"Sony"))
} LIMIT 10

Potencjalny klient może mieć jednak własne preferencje co do lokalizacja poszczególnych oddziałów sklepów firmy Kowalski Enterprise i interesują go tylko sklepy w regionie „Śląsk” oferujące płatność kartą VISA.
Potrzebuje on również dane dla swojego osobistego GPS’a aby mógł szybko wybrać najbliżej niego znajdujący się oddział oraz numer telefonu.
Odpowiednio stworzona aplikacja może te dane przesłać wprost do jego telefonu komórkowego lub innego urządzenia, które ma dostęp do sieci www:

PREFIX gr: <http://purl.org/goodrelations/v1#>
SELECT DISTINCT ?label, ?comment, ?region, ?latitude, ?longitude, ?telefon WHERE
  {
?a rdf:type gr:BusinessEntity.
?a gr:legalName ?nazwa.
?a gr:offers ?co.
?co rdfs:comment ?comment.
?co gr:acceptedPaymentMethods ?r.
?co gr:availableAtOrFrom ?lokalizacja.
?lokalizacja rdfs:label ?label.
?lokalizacja v:adr ?adr.
?adr v:region ?region.
?lokalizacja v:geo ?geo.
?geo v:latitude ?latitude.
?geo v:longitude ?longitude.
?lokalizacja v:tel ?tel.
?tel rdf:value ?telefon.
FILTER(regex(?nazwa,"Kowalski Enterprise") && regex(?comment,"Sony") && regex(?region,"Śląsk") && regex(?r, ,"VISA")) } LIMIT 10

Najważniejszym kryterium wyboru oferty przez klienta staje się cena, więc szuka on ofert tylko z określonych przedziałów cenowych. W zapytaniu pojawiają się dodatkowe właściwości określające przedział cenowy produktu oraz waluta w jakiej danych przedział obowiązuje.
Jeśli sklep oferuje produkty firmy „Sony” w walucie euro to minimalną ceną będzie 10 EUR a maksymalną 20 EUR. Jeśli natomiast walutą jest złoty, to przedziałem będzie kwota od 40 zł do 80 zł.
Klient postanowił jednak, że zobaczy również oferty konkurencji więc warunek o firmie „Kowalski Enterprise” zostaje usunięty:

PREFIX v: <http://www.w3.org/2006/vcard/ns#?
PREFIX gr: <http://purl.org/goodrelations/v1#>
SELECT *
WHERE
  {
?a gr:legalName ?name.
?a gr:offers ?co.
?co gr:acceptedPaymentMethods ?r.
?co gr:availableAtOrFrom ?lokalizacja.
?lokalizacja rdfs:label ?label.
?lokalizacja v:adr ?adr.
?adr v:region ?region.
?lokalizacja v:geo ?geo.
?geo v:latitude ?latitude.
?geo v:longitude ?longitude.
?lokalizacja v:tel ?tel.
?tel rdf:value ?telefon.
    ?co rdfs:comment ?comment.
    ?co gr:hasPriceSpecification ?ps .
    ?ps gr:hasCurrencyValue ?p .
    ?ps gr:hasCurrency ?c .
    FILTER ( ( ( regex(?c, "EUR")
      && ?p >"10"^^xsd:float && ?p <"20"^^xsd:float )
    || ( regex(?c, "PLN")
      && ?p >"40"^^xsd:float && ?p <"80"^^xsd:float ) ) && regex(?comment,”Sony”) && regex(?region,”Śląsk”))
  }
LIMIT 10

Jak widać zapytania w języku SPARQL są bardzo rozbudowane i do poprawnego działania wymagają dobrze zoptymalizowanych warunków uwzględniających opcjonalność występowania poszczególnych właściwości.
Niewątpliwą zaletą tego języka jest jednak fakt, że za jego pomocą można w bardzo efektywny sposób przeszukać całą sieć www, przez co mamy pełny wgląd do ofert wszystkich witryn e-commerce w jednym miejscu, co pozwoli na wybór optymalnej oferty dla potencjalnego klienta…

Osoby, które nie łapią o co chodzi w strukturze zapytań przedstawionych powyżej zachęcam do zerknięcia na poniższe artykuły opublikowane wcześniej:

Wstęp do SPARQl z wykorzystaniem RAP API dla PHP
Semantyczny serwis e-commerce (cz.1) – podstawy ontologii Good Relations
Good Relations w praktyce – semantyczny serwis e-commerce (cz.2)

Jakiś czas temu w części pierwszej artykułu napisałem trochę o budowie sieciowej ontologii dla e-commerce – Good Relations. Szczerze powiedziawszy może wydać się on trochę nudny (widać zresztą po zainteresowaniu wg statystyk), no ale od czegoś trzeba zacząć i trochę wiedzy na temat budowy samej ontologii bez wątpienia trzeba posiadać. Pora więc na trochę praktyki. W artykule tym postaram się w prosty sposób opisać za pomocą ontologii Good Relations przykładowy serwis www sprzedający produkty. W efekcie nasz sklep firmowy będzie znacznie bardziej „search engine friendly” a nawet można by powiedzieć „semantic web friendly„…

Na wstępie trochę założeń co do naszego sklepu:

• serwis powinien zawierać podstawowe informacje co do naszej firmy takie jak adres, nazwa czy telefon kontaktowy
• nasza firma posiada kilka sklepów na terenie całego kraju i informacje na ich temat będą umieszczone w serwisie
• serwis przedstawiał będzie ofertę ogólną firmy dotycząca sprzedawanych produktów z branży elektronicznej

Istnieje kilka sposobów na umieszczenie semantycznych danych w serwisie. Jak już pisałem nie raz w starszych artykułach, możemy wykorzystać składnię RDFa i mieścić semantyczne znaczniki bezpośrednio w kodzie strony HTML. Można też wykorzystać składnię RDF/XML lub N3/Turtle i zapisać te dane w oddzielnych plikach tekstowych. Dla pierwszej opcji plik powinien mieć rozszerzenie .rdf, a dla drugiej .n3. Zazwyczaj spotkać można nazwy plików takie jak semanticweb.rdf lub goodrelations.n3. W opisywanych przykładach będzie stosowana składnia RDFa.

Przed opisem jakiegoś elementu na stronie za pomocą semantycznych znaczników powinno umieścić się wszystkie przestrzenie nazw jakie będą używane. W tym celu na początku każdego bloku <div> zawierającego semantyczny opis powinno się je wyszczególnić w następujący sposób:

<div xmlns="http://www.w3.org/1999/xhtml"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:gr="http://purl.org/goodrelations/v1#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:vcard="http://www.w3.org/2006/vcard/ns#">
miejsce na semantyczny opis zawartości strony
</div>

Wszystkie dalsze przykłady będzie się traktować tak jakby były umieszczone w powyższym bloku <div>.

Do opisu informacji na temat firmy zostanie wykorzystana klasa BusinessEntity ontologii Good Relations oraz właściwości wchodzące w jej skład. Oprócz niej zostaną wykorzystane znaczniki vcard oraz foaf.

<div typeof="gr:BusinessEntity" about<strong>="</strong>#company">
<div property="gr:legalName" content="Kowalski Enterprise"></div>
<div property="vcard:tel" content="+48 669311615"></div>
<div rel="vcard:adr">
<div typeof="vcard:Address">
<div property="vcard:country-name" content="Polska"></div>
<div property="vcard:locality" content="Rybnik"></div>
<div property="vcard:postal-code" content="44-200"></div>
<div property="vcard:street-address" content="Rudzka 67"></div>
</div>
</div>
<div rel="foaf:depiction" resource="http://www.kowalskihomepage.pl/logo.jpg"></div>
<div rel="foaf:page" resource=""></div>
</div>

W powyższym przykładzie zostały zapisane podstawowe informacje na temat firmy Kowalski Enterprise. Wykorzystaną właściwością klasy BusinessEntity jest gr:legalName.

Kolejnym krokiem tworzenia semantycznego serwisu www jest opis poszczególnych sklepów firmy znajdujących się w różnych miejscach kraju. Aby opisać ten fakt trzeba skorzystać z kolejnej klasy ontologii Good Relations jaką jest LocationOfSalesOrServiceProvisioning.

Cały blok informacji dotyczący pojedynczego sklepu firmy Kowalski Enterprise powinien znajdować się w następującym bloku:

<div typeof="gr:LocationOfSalesOrServiceProvisioning" about="#store"></div>

W nim znajdują się informacje dotyczące nazwy sklepu i adresu, oraz godzin otwarcia w poszczególne dni tygodnia oraz weekendu (gr:hasOpeningHoursSpecification).

Najważniejszy element opisu, który wiąże informacje dotyczące właśnie tego sklepu z firmą jest właściwość gr:hasPOS, która wskazuje na URI miejsca, w którym znajdują się informacje dotyczące firmy macierzystej.

Fragment semantycznego opisu serwisu www dotyczący informacji na temat firmy nie jest duży i został on zaprezentowany w całości. Jako, że pełny fragment kodu potrzebnego do opisu informacji na temat poszczególnych sklepów jest zbyt rozbudowany zostaną zaprezentowane tylko jego najważniejsze fragmenty:

<div typeof="gr:LocationOfSalesOrServiceProvisioning" about="#store">
...
<div rev="gr:hasPOS" resource="http://www.kowalskienterprise.pl#company"></div>
<div property="rdfs:label" content="Kowalski Shop 1"></div>
…
<div rel="vcard:adr">
…
</div>
<div rel="vcard:geo">
…
</div>
<div rel="gr:hasOpeningHoursSpecification">
<div typeof="gr:OpeningHoursSpecification" about="#mon_fri">
…
</div>
</div>
<div rel="gr:hasOpeningHoursSpecification">
<div typeof="gr:OpeningHoursSpecification" about="#sat">
…
</div>
</div>
<div rel="gr:hasOpeningHoursSpecification">
<div typeof="gr:OpeningHoursSpecification" about="#sun">
…
</div>
</div>
…
</div>

Do opisu oferty firmy Kowalski Enterprise wykorzystana zostanie klasa Offering. Zaprezentowany zostanie skrócony opis oferty w, której pojawia się opis jednego produktu firmy jakim jest konsola Sony Playstation 3 SLIM:

<div typeof="gr:Offering" about="#offering">
<div rev="gr:offers" resource="http://www.kowalskienterprise.pl#company"></div>
<div property="rdfs:label" content="Sony Playstation 3 SLIM" xml:lang="pl"></div>
…
<div rel="gr:hasBusinessFunction" resource="http://purl.org/goodrelations/v1#Sell"></div>
<div rel="gr:hasPriceSpecification">
<div typeof="gr:UnitPriceSpecification">
…
</div>
</div>
<div rel="gr:acceptedPaymentMethods" resource="http://purl.org/goodrelations/v1#PayPal"></div>
…
</div>

Za pomocą właściwoci gr:haspriceSpecification wiążemy dany produkt z klasą UnitPriceSpecification, w której można zamieścić dokładne informacje dotyczące ceny produkty oraz waluty w jakiej sprzedajemy produkt np.

<div typeof="gr:UnitPriceSpecification">
<div property="gr:hasCurrency" content="EUR" datatype="xsd:string"></div>
<div property="gr:hasCurrencyValue" content="300.00" datatype="xsd:float"></div>
</div>

Dzieki właściwości gr:acceptedPaymentMethods można określić wszystkie możliwe metody płatności za produkt. W wybranym fragmencie została zapisana tylko jedna forma płatności jaką jest PayPal. Gdyby zaistniała potrzeba odzwierciedlenia faktu, że firma oferuje usługę naprawy tegoż produktu wystarczy dodać następujący blok:

<div rel="gr:hasBusinessFunction" resource="http://purl.org/goodrelations/v1#Repair"></div>

Good Relations posiada kilka właściwości funkcji biznesowych, które można dodać w opisie produktu. Niektóre z nich to:

• gr:ConstructionInstallation,
• gr:Dispose,
• gr:LeaseOut,
• gr:Maintain,
• gr:ProvideService,
• gr:Repair,
• gr:Sell,
• gr:Buy

W powyższych fragmentach kodu HTML i RDFa została zaprezentowana następująca struktura powiązań pomiędzy firmą, jej jednym sklepem oraz ofertą firmy dotycząca sprzedaży produktu:

źródło: opracowanie własne

Całą ofertę sklepu należy opisać w podobny sposób jak pokazany powyżej. Gdy wszystkie dane, które chcemy opisać wykorzystując składnię RDFa zostaną zamieszczone należy się upewnić czy nagłówek DOCTYPE strony www wygląda następująco:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" version="XHTML+RDFa 1.0" xml:lang="en">

Nagłówek DOCTYPE XHTML+RDFa mówi robotom, że strona zawiera semantyczne dane w języku RDFa. Do opisu danych za pomocą elementów ontologii Good Relations można wykorzystać odpowiednie generatory, które przekształcają dane wprowadzane do zwykłego formularza w odpowiednią składnię RDFa gotową do umieszczenia na stronie www. Innym rozwiązaniem jest wybór systemów zarządzania treścią strony takich jak np. Drupal, czy typowych rozwiązań typu e-Commerce jakimi są np. Magento, Joomla/Virtuemart, osCommerce czy WordPress z odpowiednimi pluginami. Posiadają one odpowiednie generatory, które są wiele z tych czynności zautomatyzować.

W kolejnej części artykułu postaram się przedstawić parę zapytań w języku SPARQL jakie można wykonać na tak skonstruowanym opisie semantycznego serwisu www…

Jakby ktoś nie wiedział, każdy z nas może do tego diagramu dodać swoje „surowe dane”  na stronie CKAN (oczywiście po spełnieniu kilku ważnych warunków zgodności owych dancyh z teorią semantyczności : ))

Zostały również uaktualnione statystyki dotyczące całej Chmury LOD.
Najpopularniejszym słownikiem opisu danych okazuje się DC (http://purl.org/dc/elements/1.1/) oraz FOAF (http://xmlns.com/foaf/0.1/):

Udział użytych słowników opisu danych w Chmurze LOD

Najwięcej wychodzących linków do innych zbiorów to linki dotyczące publikacji oraz nauki:

Udział wychodzących linków

Co ciekawe aż 68,14% zbiorów udostępnia swoje dane na zewnątrz przez SPARQL Endpoint. Pozostała część to tzw. RDF dumps.

Więcej ciekawych statystyk dostępnych jest na stronie twórców tutaj.

Przypominam również o zeszłorocznym „potworze” jaki zawitał do Chmury LOD, a o którym pisałem w poście pt. Linked Open Numbers.

Na BOF”ie rozmawiano na temat „Format RDFa vs Microformats vs Microdata” oraz inicjatywy schema.org. Jednym z pytań było to czy zapis w formacie RDFa oraz Microformats będzie tak samo traktowany przez wyszukiwarki jak Microdata?. Zapis prawie wszystkich wypowiedzi wykonał współorganizator Ivan Herman.

Zapraszam tutaj: http://www.w3.org/2011/06/semtech-bof-notes-smaller.html

Image via Wikipedia

Jak zapewnie każdy zainteresowany branżą SEO dobrze wie, wyszukiwarka Google wprowadz(ił)a najnowszy algorytm o nazwie „Panda„.  W sieci można znaleźć wiele artykułów głoszących wszem i wobec o tym co niedobrego może spotkać posiadaczy witryn pozycjonowanych przez „nieudolne” firmy nastawione na szybkie rezultaty i zyski, o tym jak wiele może stracić firma, którą wspiera tysiące (najczęściej kiepskiej jakości) „precli” itp, o tym, że pozycjonowanie stanie się luksusem, na który stać będzie tylko najdroższe firmy..

W tym artykule postaram się spojrzeć na to wszystko z innej strony – semantycznej :- )

Znalazłem ostatnio artykuł na stronie bankier.pl o nazwie „Czy firmy powinny uważać na Pandę?„. Słowem komentarzu muszę powiedzieć, że trochę się zdziwiłem w miejscu, w którym autor pisze następująca tresć:

TOP10 na zdecydowaną większość fraz będzie okupowane przez bogatsze firmy, które dysponują olbrzymimi środkami.
Jak Google postrzega Polskę?
Wśród nich będzie się toczyła ciągła rozgrywka o kluczowe pozycje. Pozostałe pozycje będą dostępne głównie dla firm, które ograniczają wydatki na tę formę reklamy.

i dalej:

Podsumowując, uczciwe i rzetelne pozycjonowanie w niedalekiej perspektywie, będzie bardzo kosztowną usługą, w niektórych przypadkach porównywalną do kosztów reklamy w TV czy w radiu.

Czyżby Google całkowicie chciało wyeliminować małe firmy z widoczności w swojej wyszukiwarce ? Osobiście twierdzę, ze autor tego tekstu trochę przesadził. O ile mi wiadomo celem nowego algorytmu jest podniesienie jakości, obiektywności wyników oraz sprawieniu aby były one jak najbardziej relewantne do zapytań użytkowników. Wszyscy tylko piszą, że sieć jest zapełniona bezużetycznymi, wymuszonymi na siłę artykułami na potrzeby szybkiego zdobycia hiperłącza z tematycznej witryny, a nikt nie zastanowi się jak postawić na jakość rozpowszechnianej w nim treści. Analizując technologie semantyczne i to do czego mają służyć, samo nasuwa się na myśl stwierdzenie, że pozwolą one pomóc wielu witrynom aby ich treść stała się jak najbardziej przyjazna srogiej pandzie : -)…

Można by powiedzieć, że na semantycznych technologiach skorzystać mogą małe firmy, które nie muszą wydawać olbrzymich nakładów finansowych na „pozycjonowanie” swojej witryny. Co prawda unikalność i jakość artykułów na witrynie będzie zapewne kluczowym znaczeniem do zdobycia zaufania przez wyszukiwarki to jej semantyka zacznie nabierać coraz większego znaczenia.

Język RDF, a konkretnie znaczniki RDFa zostały stworzone po to aby przedstawić wyszukiwarce znaczenie treści na niej znajdującej się. Surowe dane mogą być przedstawione w postaci zrozumiałej zarówno dla ludzi jak i maszyn. Różne elementy witryny zostają połączone w taki sposób aby aplikacje mogły je lepiej pogrupować a nawet zinterpretować. Tworzą one niejako element zaufania dla naszej witryny. Dzięki znacznikom RDFa robot wyszukiwarki dobrze wie co jest na stronie, kiedy została ona stworzona i co elementy na niej znajdujące się tak naprawdę przedstawiają. Robot wyszukiwarki mając do porównania stronę, na której znajduje się przysłowiowy spam np. napisany w 5 minut precel, a stronę zoptymalizowaną od strony semantycznej (znaczeniowej) na pewno postawi w rankingu wyżej tą drugą…

Kolejna sprawa to tzw. mikroformaty. Znaczniki geo oraz hCard – w najdokładniejszy sposób określają dane kontaktowe firmy. Lokalny rynek stanie się coraz bardziej „promowany” przez wyszukiwarki. Dokładne oznaczenie lokalizacji stanie się sporym atutem. Mała rzecz, a często pomijana przez wielu webmasterów. Małe firmy skupiające się na lokalnym rynku nie muszą pozycjonować się na globalne frazy w stylu „wynajem rowerów” lecz „wynajem rowerów śląsk”.

Trzeba mieć również na uwadze wprowadzenie swojej witryny do tzw. social graph. O ile sam open graph protocol z popularnego portalu o skrócie fb, nie może być wprost nazwany technologią semantyczną to jest to rozwiązanie mające poniekąd niektóre z przesłanek web 3.0. W nowym algorytmie Google ma się pojawić tzw. przycisk „block this site”, który ma służyć uzytkownikom do wyrażania opinii na temat witryny. Opinie te mają być w niewielkim stopniu pomocne przy ocenie witryny przez nowy algorytm. Warto więc zadbać o to aby zaistnieć w społeczności „social media”, gdyż na pewno nie straci się na tym, a można jedynie sporo zyskać :- )

Czy aby więc na pewno pozycjonowanie w najbliższych latach stanie się luksusem tylko dla bogaczy ? Na pewno pisanie, że TOP10 będzie przeznaczone dla bogaczy jest kompletną bzdurą. Nie uważam, że zatrudnienie w dziale IT webmastera, który dobrze zoptymalizuje witrynę pod względem smentycznym, wynajęcie dobrego copywritera oraz człowieka od reklamy w wyszukiwarce będzie kosztem porównywalnym z reklamą w TV, na który stać tylko duże przedsiębiorstwa…

Ostatnia sprawa to termin kiedy w Polsce zagości Panda. Ponoć ma to nastąpić lada moment. W USA już jest. Czy aby niektóre z jej założeń nie są już zauważalne w Polsce ? – na to pytanie odpowiedzcie sobie sami :- )

Każdy wie, że szukając informacji na temat jakiegoś produktu w sieci, na który mamy akurat ochotę, przyprawić się można o ból głowy. Serwisów typu e-Commerce jest cala masa, nie mówiąc już o serwisach aukcyjnych typu allegro czy inne. Wizja semantycznego handlu elektronicznego to wcale nie utopia lecz całkiem bliska rzeczywistość…

Podstawowym problemem dzisiejszego handlu w sieci to zarówno nadmiar informacji jak i ich brak. Co z tego, że dostępnych jest cała masa sklepów internetowych, skoro nie można wybrać najlepszej oferty dostępnej na rynku ? Potencjalny klient ograniczony jest tylko i wyłącznie do tych ofert dostępnych w serwisie www, których właściciel był w stanie do nich dodać. Oferty takich sklepów były, są i póki co będą ograniczone do określonego procentu wszystkich ofert dostępnych na globalnym rynku. Dostawca produktów czy usług nie może dodać swojej oferty do wszystkich możliwych sklepów w sieci. Z praktycznego punktu widzenia jest to wręcz niemożliwe. Podobnie konsument nie jest w stanie dokonać najlepszego wyboru, gdyż nie jest w stanie przejrzeć wszystkich ofert nawet gdyby mógł je odnaleźć – zabrakło by mu czasu. Może udać się na serwis aukcyjny i się licytować licząc na to, że akurat ktoś zaoferuje mu produkt po niskiej cenie.

Obecne serwisy typu e-Commerce nie są w żaden sposób ze sobą powiązane. Dane, które dostarczają są w bezmyślny sposób „marnowane”. Nie można ich w żaden sposób wykorzystać przez inne podmioty. Dane raz wprowadzone do bazy danych w postaci np. relacyjnej nie są w żaden sposób przystosowane do ponownego użycia. Zakładając, że jakaś firma chce wykorzystać dane o produktach innej firmy z jej serwisu www, musi je ręcznie wydłubać , a następnie marnując spore ilości godzin wklepać do swojej bazy danych albo np. klienta poczty elektronicznej. Kolejną wartą uwagi sprawą jest fakt, iż przenosząc takie dane z jednego miejsca do drugiego można je zniekształcić na wiele różnych sposobów.

Niewiele serwisów e-Commerce umożliwia porównanie produktów różnych producentów pod względem określonych parametrów. Sposób ich działania każdy może sprawdzić. Czy nie lepiej było by mieć możliwość znalezienia szybko odpowiedzi na pytanie typu „gdzie i za ile mogę kupić laptopa z 6 wejściami USB” ?, albo „gdzie w Polsce można wymienić opony za mniej niż 30 PLN” ?.

Wizja semantycznej sieci, a raczej jej początek, który już następuje pozwala usunąć wszystkie opisane wyżej niedogodności. Opisując serwis www za pomocą mikroformatów, znaczników ontologii Good Relations pozwalamy na zrozumienie serwisowi e-Commerce danych, które udostępnia. Podobnie inne serwisy mogą z tych danych wywnioskować, że produkty na ich stronie są powiązane z produktami innego serwisu www. Inny sposób, który to umożliwia to umieszczenie całej swojej ofert w postaci ontologii OWL zapisanej w odrębnym pliku umieszczonym na tym samym serwerze co dany serwis e-Commerce.

To, że maszyny będą mogły wykorzystać w znacznie lepszy sposób dane z wszystkich tego typu serwisów to tylko jedna z kilku, a może nawet kilkunastu zalet jakie niesie ze sobą semantyczny e-Commerce…

Konsument

Jakie korzyści niesie semantyczny e-Commerce dla konsumenta ?

Konsument ma szybki dostęp nie do określonego procentu wszystkich ofert dostępnych na rynku, lecz do wszystkich ofert umieszczonych w sieci. Dostawcy nie muszą już płacić scentralizowanym platformom e-Commerce za umieszczenie w nich danej ofert, lecz w darmowy sposób mają możliwość bycia znalezionym przez wszystkich użytkowników internetu. Semantyczne wyszukiwarki internetowe za pomocą „wyrafinowanych” zapytań odnajdą każdy produkt opisany za pomocą semantycznych technologii takich jak RDF czy OWL. Konsument może dokładnie określić model oraz parametry produktu, który go interesuje lub zlecić to zadanie odpowiedniemu programowi – asystentowi (agentowi), który automatycznie wyszukiwał będzie produkty odpowiadające preferencją określonego konsumenta.

Producent (dostawca usług)

Lepszy dostęp do konsumenta. Mniejsze koszty. Większa transparentność rynku. Niszowe przedsiębiorstwa mają większe szanse dotarcia do określonego odbiorcy. Powoduje to jednak zmniejszanie się łańcucha wartości poszczególnych firm co powoduje zwiększanie się konkurencyjności w branży.

Gospodarka

Większa transparentność rynku, tańsza i szybsza możliwość dotarcia do konsumenta przez producentów pozwala na zmniejszenie nakładów finansowych przeznaczonych na reklamę. Powoduje to zwiększenie szans dla małych i średnich firm w walce o konsumenta. Lepsza sytuacja niszowych firm pozwoli im na zwiększenie ich marży handlowej, a tym samym na wzrost zatrudnienia w poszczególnych sektorach gospodarki.

Kolejna ważna sprawa to istniejący obecnie w sieci rozrzut informacji (dysproporcja cen w sklepach internetowych). Poniższy rysunek pokazuje jak zmienia się oczekiwany zysk krańcowy w zależności od czasu wyszukiwania informacji. Semantyczny e-Commerce pozwoli zmniejszyć czas wyszukiwania informacji o produktach, a tym samym zwiększy zysk całkowity, który zwiększa się wraz ze zmniejszanie zysku krańcowego.

Przez zmniejszenie dysproporcji cenowej (asymetryczności informacji) zmniejszy się również ilość osób, którzy wolą zapłacić więcej znanemu serwisowi za produkt, tylko dlatego by mieć pewność, że pochodzi on z markowego źródła. W konsekwencji powinna zwiększyć się wydajność sklepów internetowych oraz ich użyteczność dla konsumentów czy firm.

źródło: opracowanie własne na podstawie "Reduction of price dispersion through Semantic E-commerce : A Position Paper"

Zwiększenie dochodu rozporządzalnego przez konsumentów spowodowane zmniejszeniem nietrafionych zakupów pozwoli im na lepsze inwestowanie zgromadzonych oszczędności w przyszłości.

Opisane wyżej korzyści nie pozostawiają żadnych wątpliwości, czy zastosowanie semantycznych technologii w serwisach typu e-Commerce ma rację bytu. techniczne podstawy do zrealizowania tej wizji już istnieją. Wystarczy tylko „trochę” chęci i promocji technologii takich jak RDF, OWL, SPARQL i pokrewnych…

Na początku artykułu (czyli w części pierwszej) przedstawię tzw. Knowledge Extraction Framework czyli opis tego w jaki sposób DBpedia „dobiera” się do danych Wikipedii i co z nimi robi. W kolejnych częściach opisane zostaną tzw. Infoboxy, czyli szablony zapisu danych Wikipedii, trochę o zapisie danych w bazie wiedzy DBpedii, aplikacjach korzystających z jej dobrodziejstw oraz kilku innych ciekawostkach…


Najważniejsza część mechanizmu składa się z 4 komponentów (ilustracja na końcu artykułu!):

• PageCollections
• Extractors
• Parsers
• Destinations

PageCollections to lokalne lub zdalne źródła artykułów Wikipedii. To tutaj zaczyna się cały przebieg pracy (work-flow). Ekstraktor danych pobiera nowe informacje na 2 różne sposoby: Dump-based extraction oraz Live Extraction.
Wydobywanie typu „Dump-based” polega na comiesięcznym przetwarzaniu zrzutów bazy danych Wikipedii. Przetworzone dane są umieszczane w tzw. N-Triples Serializers. Zapisane w postaci trójek RDF dostępne są jako Lined Data oraz możliwe do przetwarzania przez endpointy SPARQL.
Wydobywanie typu „Live Extraction” polega na tym, że fundacja Wikimedia udostępnia projektowi DBpedia dostęp do Wikipedia OAI-PMH live feed (protokół OAI-PMH), który na bieżąco informuje o zmianach jakie zachodzą na wszystkich stronach Wikipedii. Gdy wystąpi jakaś zmiana w istniejącym już artykule Wikipedii, istniejący graf RDF zostaje zaktualizowany (SPARQL-Update Destination).
Według danych DBpedii z maja 2009 roku, co 1 sekundę około 1.4 stron Wikipedii zostaje zaktualizowanych. Knowledge Extraction Framework DBpedii był w stanie w tym czasie (1 sekundy) przetworzyć około 8.8 stron, włączając w to wszystkie etapy, o których w dalszej części artykułu.
Pomiędzy miejscami docelowymi (Destinations), a źródłami (PageCollections) istnieje najważniejszy etap tzw. Extraction Job, który składa się z 2 elementów: Extractors oraz Parsers.
Extractors (ekstraktory) mają za zadanie zmienić dane odpowiedniego typu (znaczniki) w trójki RDF. Wspierają ich w tym parsery (Parsers), które określają typy danych oraz dzielą wszystkie znaczniki Wikipedii w uporządkowane listy.
Istnieje około 11 ekstraktorów, z których każdy odpowiedzialny jest za inny typ danych:

• Labels – tytuły artykułów Wikipedii zapisywane są za pomocą znacznika rdfs:label w przetworzonych grafach
• Abstract – krótki opis oraz długi opis, który zapisywany jest za pomocą znaczników rdfs:comment oraz dbpedia:abstract
• Interlanguage links - linki pomiędzy tymi samymi artykułami w różnych wersjach językowych Wikipedii
• Images – właściwość foaf:depiction
• Recirects – linki do artykułów „synonimów”
• Disambiguation - oznaczenie dwuznaczności pomiędzy artykułami za pomocą właściwości dbpedia:disambiguates
• External links - linki zewnętrzne – dbpedia:reference
• Pagelinks - wszystkie linki pomiędzy artykułami Wikipedii oznaczone predykatem dbpedia:wikilink
• Homepages - za pomocą właściwości foaf:homepage oznaczane są linki w artykułach do stron domowych encji w nich znajdujących się
• Categories – artykuły Wikipedii podzielone są na kategorie według słownika ontologii SKOS (predykaty skos:concepts oraz skos:broader)
• Geo-coordinates – współrzędne geograficzne (WGS84 lat/long)

źródło: dbpedia.org

W wydaniu z lutego tego roku pojawił się artykuł pt. „SPARQL – język zapytań dla semantycznych baz danych„. Przeczytałem i powiem szczerze, że nic nowego się nie dowiedziałem, co w tamtej chwili już wiedziałem na ten temat. Dla kogoś kto nie ma żadnego pojęcia na temat języka SPARQL, informacje tam zawarte pozwolą na całkiem wartościowe zapoznanie się z tematyką (biorąc pod uwagę, że autorem tego artykułu jest człowiek będący z wykształcenia filozofem).

Drugim artykułem dotyczącym Web 3.0 pojawił się znowu we wspomnianym magazynie w lipcowym wydaniu. Temat artykułu to „Web 3.0 – czyli semantyczny Internet„.

Ten sam autor co poprzedno opisuje na początku artykułu wizję semantycznej sieci www i … od razu przechodzi do punktu o nazwie Mikroformaty – czyli znaczników microformats – hCard, hCalendar itd. Jak dla mnie to trochę nie na miejscu, gdyż ja bym napisał na początku o samym formacie RDF następnie o RDFa, a dopiero później o mikroformatach, nie wspominając już o samym OWL czyli języku zapisu ontologii. Być może autor pomyślał, że potencjalny czytelnik nie ma ochoty „meczyć się” ontologiami, a prosty zapis semantycznych znaczników w kodzie strony sprawi, ze temat stanie się łatwiejszy, lżejszy i przyjemniejszy…

Dalej autor pisze (a raczej wspomina) o wnioskowaniu w semantycznej sieci www. Podaje przykład strony trueknowledge.com jako serwisu udzielającego odpowiedzi na zapytania w języku naturalnym… i kończy artykuł.

Cieszy mnie sam fakt pisania o tej tematyce w tego typu magazynach, ale dlaczego tylko tyle ? Jeśli ktoś znalazł coś ciekawego na temat semantycznej sieci www w innych podobnych magazynach to niech da znać!

Zainteresowanych wspomnianymi artykułami zapraszam na stronę http://lpmagazine.org/pl, na której można je znaleźć i za darmo pobrać.

Jest to jedna z ciekawszych semantycznych aplikacji, pożyteczna np. w dużych miastach gdzie potrzebujemy natychmiastowej informacji o otaczających nas obiektach.
W przeciwieństwie do zwykłej mapy nawigacyjnej znanej z popularnych GPS’ów dostajemy pełny opis obiektów wraz ze zdjęciami i innymi ciekawymi opcjami przeglądu. Widok mapy może być w dowolny sposób filtrowany a nawet edytowany przez użytkownika w czasie rzeczywistym. Wygenerowane linki powiązane z innymi stronami ułatwiają nam poszukiwanie dalszych informacji. Całość informacji pochodzi z dobrze znanej miłośnikom semantycznej sieci www – chmury Linked Open Data…

Istota działania DBpedia Mobile:

Źródło: http://www.wiwiss.fu-berlin.de/en/institute/pwo/bizer/research/publications/Bizer-Becker-DBpediaMobile.pdf

Jak widać na powyższym rysunku calość opiera sie na trzech głównych elementach:

1. LOD (Linked Open Data)
2. Semantyczne wyszukiwarki takie jak Sindice, Falcons
3. Aplikacja Marbles

O chmurze Linked Open Data już kilka razy wspominałem. O semantycznych wyszukiwarkach napisałem trochę w przed ostatnim poście, lecz o aplikacji Marbles jeszcze nie pisałem, więc pare słów wyjaśnień.

Marbles to aplikacja działająca po stronie serwera, która formatuje dane z semantycznej sieci www dla klientów XHTML wykorzystując „słownik” Fresnel. Fresnel mówi o tym, które właściwości z poszczególnego grafu RDF lub grupy grafów i w jakiej kolejności mają zostać wyświetlone oraz o tym w jaki sposób to wyświetlanie ma się odbywać. Więcej informacji na temat samej aplikacji Marbles oraz Fresnel lenses anf romats można znaleźć na na stronie http://marbles.sourceforge.net/ oraz http://www.w3.org/2005/04/fresnel-info/

Jak widać istota działania jest prosta… dane pochodzą z chmury LOD (semantycznej sieci), która jest przeszukiwana przez semantyczne wyszukiwarki a następnie apliakcja Marbles dostarcza te dane do urządzenia przenośnego.

Przeglądanie mapy:

źródło: http://wiki.dbpedia.org/DBpediaMobile

DBpedia Mobile pobiera naszą aktualną pozycję (współrzędne GPS) i generuje widok otoczenia. Istniejące zasoby w rejonie współrzędnych są przedstawiane za pomocą kolorowych ikon z odpowiednimi etykietami. Wykorzystywane są do tego kategorie ontologii YAGO. Całość prezentowana jest w 14 językach w tym polski.

Po kliknięciu na dany obiekt (zasób) dostajemy tzw. summary view, czyli krótki opis obiektu pochodzący z bazy DBpedia z ewentualnym zdjęciem dostarczanym przez flickr i opiniach z bazy Revyu. Otrzymamy także listę użytkowników profili FOAF, którzy w swych opisach użyli właściwości foaf:based near - czyli ludzi, którzy mieszkają w okolicy. Istnieją dodatkowe dwa widoki: photo view oraz full view. Pierwszy z nich dostarcza dodatkowe zdjęcia a drugi pokazuje kompletna listę właściwości skojarzonych z wybranym obiektem.

Filtrowanie mapy:

Istnieją dwie możliwości zmiany widoku mapy. Pierwsza z nich – Simple Filter – umożliwia wybranie jednego lub kilku typów wyświetlanych obiektów na mapie. Drugi z nich SPARQL Filter umożliwia za pomocą polecenia CONSTRUCT stworzyć odpowiedni graf, na podstawie którego zostanie wygenerowana mapa (opcja dla użytkowników bardziej zaawansowanych : ) ).

źródło: http://wiki.dbpedia.org/DBpediaMobile

Publikacja własnych danych:

źródło: http://wiki.dbpedia.org/DBpediaMobile

Aplikacja umożliwia edycję danych znajdujących się na mapie. Każdy zalogowany użytkownik edytuje swój własny graf, który wykorzystywany jest później przy wyświetlaniu mapy. Można dodawać zdjęcia, recenzje oraz własne lokalizacje.
Przetestowałem wersje demonstracyjną (jakkolwiek to nazwać) i niestety po kliknięciu w wybrany obiekt informacji praktycznie nie ma. W opcji full view dostajemy kilka właściwości lecz są one trochę bezużyteczne. Nie miałem okazji przetestować opisywanej aplikacji na urządzeniu, więc jeśli ktokolwiek taki by się znalazł i miał jakieś ciekawe doświadczenia, zachęcam do napisania o tym w komentarzach poniżej!

Zapraszam na stronę aplikacji gdzie można skorzystać opcji Try it! : ) – http://wiki.dbpedia.org/DBpediaMobile