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)

Image by paul+photos=moody via Flickr

„Lead Web Development Engineer” w BestBuy.com ogłosił, że wprowadzono na firmowych stronach znaczniki Schema.org. A wszystko to z okazji „Black Friday Doorbusters”.

Jak już wspominałem w jednym z pierwszych artykułów serwis BestBuy.com jest jednym z pierwszych w internecie, który postanowił wykorzystać do opisu swoich sklepów i oferowanych produktów standardy Web 3.0…

Po raz pierwszy serwis BestBuy wprowadził semantyczne znaczniki w standardzie RDFa w 2009 roku. Stopniowo zwiększał opis swoich produktów wykorzystując ontologie Good Relations a w październiku tego roku zaczął wykorzystywać Microdata  wybrany w standardzie Schema.org do opisu danych na stronach www. Przypomnę, że standard ten jest oficjalnie wspierany przez największe wyszukiwarki na świecie takie jak Google, Yahoo czy Bing.

Jay Myers z BestBuy nie raz już wypowiadał się publicznie o zaletach jakie dało wykorzystywanie semantycznych znaczników do opisu swoich sklepów i produktów. Było to min. zwiększony CTR, lepsza widocznośc w wyszukiwarkach itp.

Oto wywiad jaki przeprowadził z nim niedawno serwis semanticweb.com:

SemanticWeb.com: What led you to try schema.org and Microdata?
Jay Myers: I was fortunate enough to participate in the schema.org workshop in Mountain View last month where a bunch of really smart people were talking structured data on the web. If you know anything about the history between some of the individuals attending, you’d figure we would have several opposing viewpoints and many arguments would ensue. To my surprise, this was not the case — we had a great day of very constructive talks. And with this warm and fuzzy spirit of goodwill, I figured it was time to put the rubber to the road and release a new standard for all to test.

SW: So, what have you done to “put the rubber to the road?”
JM: We saw an opportunity to get a live working example out on our site through a Ratings and Reviews enhancement project that was already being worked on at the time of the schema.org announcement. This project was a natural fit; the [Google] Rich Snippets and [Yahoo!] Search Monkey teams had laid a very solid foundation a while back by constructing and supporting reviews vocabularies and markup examples even before schema.org. This established vocabulary was largely adopted by the new schema.org standards, so it was relatively easy to implement.

SW: What did you expect when you set out to tackle this and what did you experience?
JM: I expected there would be a slight learning curve — as a developer I have found that coding with data and presentation in mind is much different than just presentation. It’s not that the markup is more difficult, it puts me in a different mindset delivering human readable code while visualizing what a machine might get out of the rich markup.

SW: How smooth was that work compared to your earlier efforts? Were you creating new markup or modifying existing markup to make it work with schema.org?
JM: In terms of time, we spent around 2 days creating, testing and validating the code before deploying. This markup replaced a prior solution using “plain old” HTML. Rather than try to retrofit, we worked from scratch to create new code. The beauty of good data is that can be shaped into many forms. In the case of this solution, we had the raw data and simply needed to use a transformation mechanism (for us it’s NetKernel) to make it human and machine readable.

SW: You had done so much work with RDFa previously. Were you able to build on that work?
JM: One of the themes of my announcement was that this solution was about the schema, not the syntax. That being said, I did find that the Microdata syntax was straightforward to implement. I am still a massive RDFa fan, and am really excited about RDFa 1.1 Lite. I have been reading the editor’s draft and have plans to deploy it into an upcoming solution.

SW: What challenges did you encounter?
JM: I work with a number of very talented developers on an extremely large codebase. The biggest challenge is keeping the code pristine to ensure that machines can parse it and create accurate RDF triples. With a bunch of cooks in the kitchen it can be hard to maintain more stringent markup standards. In addition to experimenting with new vocabularies and syntax, I also need to continue to educate my fellow developers to be cognisant of the impact and benefits that this markup can provide.

SW: What benefit(s) do you hope/expect to see? How will you measure success?
JM: I hope that consumers will benefit from this valuable data being more visible on the web. In commerce, reviews are vital to our customers to assist in making an informed purchasing decision. I see challenges in getting this data to customers. First, there is an abundance of review data on the web for us to utilize, but so much that we humans may not be able to consume it all. Second, implementation of reviews data on the web is often inaccessible to machines. In my opinion, these challenges can be addressed by laying a foundation of rich structured data — something that can be accomplished by any dev, given they take a little extra time to be mindful of their markup. For a brief moment we have seen search engine results pages display the three latest reviews for some of our products — I feel that is very beneficial to shoppers.

Największa rosyjska wyszukiwarka internetowa Yandex ogłosiła, że wchodzi do współpracy nad projektem Schema.org…

Będzie to już czwarta po Google, Yahoo i Bing wyszukiwarka wykorzystująca znaczniki Schema.org. Jest to również bardzo dobra wiadomość dla wszystkich webmasterów stosujących najnowsze techniki optymalizacyjne na swoich stronach www.

Znaczniki Schema.org poza samą wyszukiwarka Yandex będą wyświetlane róznież na innych serwisach firmy takich jak Yandex’s Business Directory, Yandex.Images, Yandex.Video czy Yandex.Dictionaries.

Więcej o samym Schema.org pisałem już w poprzednich artykułach. Więcej o wykorzystywanych znacznikach oraz o samym projekcie można znaleźć na oficjalnej stronie.

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…

Działanie wyszukiwarki ma się opierać na wyszukiwaniu relacji między frazami. Przykładowo wpisując wyraz „samochód” otrzymamy wszystkie powiązane z nim tematy typu ubezpieczenia, wynajem, testy bezpieczeństwa, specyfikacje itp. Wpisując kod pocztowy jakiejś miejscowości otrzymujemy znajdujące się w niej szkoły, domy, informacje o społeczeństwie, współczynniku przestępstw, sklepach itp.

Wyszukiwarka WireDoo jest ciągle w budowie (od ponad 2 lat) i niedostępna dla zwykłych użytkowników internetu. Możemy dodać swój e-mail do newslettera, który poinformuje nas kiedy będziemy mogli przetestować wyszukiwarkę (na początku zapewne tylko w języku angielskim). WireDoo nie ma zamiaru konkurować z gigantami takimi jak Google czy Yahoo, ale ma nadzieje dostarczyć użytkownikom tzw. „deeper type of search„.

M.C. Hammer ogłosił wielką chęć budowania nowych technologii ”przetwarzania danych” i inwestowania w  nie, gdyż widzi w nich wielki potencjał…

Poniżej krótki film z jego przemówieniem podczas konferencji Web 2.0 Summit w San Francisco.

Od wielu lat organizacja W3C zajmująca się tworzeniem i ustalaniem standardów używanych w sieci www zabiegała (i nadal zabiega oraz promuje) o wykorzystywanie standardu RDF (RDFa) do opisu surowych danych zarówno na stronach www jak i w innych zbiorach danych aby mogły one być jak najbardziej zrozumiałe dla maszyn a tym samym dla wyszukiwarek.

Standard RDFa został wykorzystany przez Google do tworzenia tzw. Rich Snippetów, które niosą dodatkowe informacje przy wynikach wyszukiwania tejże wyszukiwarki. W tle istniały już mikroformaty (Microformats), które nie miały tyle mozliwości co standard RDFa ale z powodzeniem były używane do opisywania niektórych danych na stronach www (np. znaczniki hCard,vCard, Geo itp.) ponieważ były banalnie łatwe w użyciu…

Standard RDFa został również wykorzystany przez Martina Heppa do stworzenia swojej ontologii dla e-commerce – Good Relations. Powstała ona w celu integracji wszystkich danych o produktach i ich sprzedaży w sieci – o zaletach tego rozwiązania można poczytać min. w artykule pt. „Semantyczny e-Commerce – wpływ na producenta, konsumenta i globalną gospodarkę„. Wszystkie te formy opisu danych zostały oficjalnie wsparte przez wyszukiwarki Google i Yahoo przez co miały się bardzo dobrze.

Należy w tym miejscu wpomnieć o kolejnym gigancie obecnej sieci www jakim jest Facebook, który po cichu wprowadził na swoim portalu coś co się tajemniczo nazywało Open Graph Protocol i które po trochu przypominało ideę semantycznych standardów W3C jakim jest tworzenie semantycznej sieci www. Open Graph Protocol ma za zadanie integrację dowolnej strony www z tzw. „grafem social web” i przystosowanie jej do wyświetlenia na stronach Facebooka. Wszystkie strony www opisujące przedmioty świata rzeczywistego np. filmy, restauracje, gwiazdy filmowe, drużyny sportowe mogą dodać przycisk „Like”, który połączy je ze światem Facebooka (to taka moja subiektywna interpretacja ideii OGP). Strona taka dodaje się w profilu innego użytkownika na portalu i ma opis dokładnie taki jaki opisaliśmy na swojej stronie za pomocą znaczników og np. og:title. Właściciel strony aktualizując ją automatycznie zmienia opis pojawiający się w profilach wszystkich osób, które ja polubiły…

I co dalej ? Google dochodzi do wniosku, że deweloperów www może wkrótce zaboleć głowa od nadmiaru formatów i mówi:

There are arguments to be made for preferring any of the existing standards, but we’ve found that microdata strikes a balance between the extensibility of RDFa and the simplicity of microformats, so this is the format that we’ve gone with.

Nawiązuje również do tworu Facebooka i twierdzi, że (tutaj też się zgodzę):

Facebook Open Graph serves its purpose well, but it doesn’t provide the detailed information search engines need to improve the user experience. A single web page may have many components, and it may talk about more than one thing. Even if you mark up your content for Facebook Open Graph, schema.org provides an additional way to provide more detail about particular entities on the page.

Wszyscy ci, którzy użyli do tej pory na swojej stronie, któregoś z „przegranych” formatów nie muszą się w zasadzie niczym przejmować gdyż póki co Google zamierza nadal je pokazywać w swoich wynikach lecz zaleca na przestrzeni czasu stopniowe przejście w stronę schema.org (Microdata).

I tutaj mała dygresja odnośnie liczących się graczy na rynku www. Moim zdaniem obecna rywalizacja w świecie portali społecznościowych między Facebook a Google+ prędzej czy później zakończy się upadłością tego pierwszego. Google mając monopol na rynku wyszukiwarek nie musi praktycznie zabiegać o użytkowników swojego dziecka Google+ (czas dostępu tylko dla zaproszonych użytkowników szybko się skończył i już każdy może się w nim zarejestrować – trudno nie zauwazyć kolorowej strzałki obok paska wpisywania zapytań). Facebook ze swoim Open Graph Protocol ma daleko do wprowadzenia w życie wizji semantycznej sieci www (nie taki jest chyba jego cel) a Google i Yahoo stosując Microdata może zrobić praktycznie wszystko w świecie Semantic Web. Bez Google trudno będzie stworzyć jedną globalną bazę danych.

Tylko dlaczego może się to wszystko odbyć kosztem RDFa stworzonym przez W3C  (Microdata jest sponsorowane przez Web Hypertext Application Technology Working Group założonym przez Apple i Mozille w 2004 roku). Może być poniekąd odebrane jako cios w dalszy rozwój Semantic Web. WHATWG powstało jako wynik powolnego rozwijania sieciowych standardów przez W3C…

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.

Obecnie w sieci web istnieje, kilka ontologii tego typu jakimi są min. ontologie eClassOWL czy unspcOWL lecz głównym ich problemem jest to, że nie posiadają one najważniejszej cechy semantycznego e-commerce jaką jest możliwość wiązania danych z różnych źródeł. Konieczna jest możliwość wyrażania relacji biznesowych pomiędzy różnymi jednostkami. Trzeba móc budować bardziej złożone wyrażenia niż „Zasób A jest instancją produktu klasy TV Set”. Bardziej złożonym wyrażeniem jest zdanie, które mówi o tym czy dana firma oferuje określony produkt na sprzedaż czy na wynajem. Dla kogo przeznaczona jest ta oferta ? Czy tylko dla ludzi z Polski czy również dla klientów z innych krajów. Czy odbiorca produktu jest osoba fizyczna,  pośrednik czy inny sprzedawca masowy ?

Sieciowa ontologia Good Relations opiera się na 26 założeniach funkcjonalnych, z których najważniejsze to:

• Możliwość rozróżniania jednostek biznesowych, ofert, produktów oraz usług

Np. URI http://www.nokia.com/nokia4563 może opisywać zarówno model telefonu jak i ofertę sprzedaży tego modelu telefonu

• Możliwość rozróżniania pomiędzy zasobami informacyjnymi czytelnymi dla człowieka  a określonymi obiektami różnych klas

Np. URI http://www.mediamarkt.pl może być zarówno stroną domową sklepu jak i opisem oferty tego sklepu możliwą do odczytania przez maszynę

• Dostarczenie słownika dla określania różnych funkcji biznesowych np. sprzedaż, wynajem czy naprawa,
• Możliwość przeprowadzania na ilościowych właściwościach produktów zapytań o przedziały np. telefon komórkowy ważący od 50 do 100 gram,
• Możliwość określania różnych jednostek miar i ich konwersji pomiędzy miarami w różnych krajach,
• Kompatybilność z podobnymi ontologiami tego typu np. eClassOWL,
• Możliwość określania rynku docelowego dla produktu i obszarów geograficznych,
• Możliwość określania metod płatności, form dostawy, warunków gwarancji itp.,
• Możliwość wyrażania cen w różnych walutach,
• Możliwość określania ważności trwania określonej oferty,
• Możliwość określania kosztów zakupu i dostawy,
• Dostarczenie informacji na temat tego czy dany produkt lub jego podzespół jest kompatybilny z innym produktem, lub też może być jego substytutem

Ontologia Good Relations składa się z 27 klas. Każda z nich charakteryzuje się właściwościami dla których dana klasa jest dziedziną (rdfs:domain) oraz właściwościami będącymi zakresem klasy (rdfs:range). Najważniejsze klasy ontologii Good Relations (ang. core classes) wymagające opisu to:

• gr:BusinessEntity,
• gr:Offering,
• gr:ProductOrServiceModel,
• gr:LocationOfSalesAndServiceProvisioning

Bazowy URI dla ontologii Good Relations to http://purl.org/goodrelations/v1. Wszystkie identyfikatory poszczególnych klas  wykorzystywane w semantycznym opisie serwisu e-Commerce muszą wykorzystać powyższy URI np. http://purl.org/goodrelations/v1#BusinessEntity.

Uproszczony diagram klas w języku UML ontologii, o której mowa zawierający 11 klas, wśród nich te najważniejsze wymienione powyżej, znajduje się na poniższym rysunku.

źródło: http://www.heppnetz.de/projects/goodrelations/

Instancja klasy gr:BusinessEntity, reprezentuje określony podmiot gospodarczy lub osobę prawną. Powinna ona zawierać przynajmniej dane kontaktowe. Adres jednostki opisywanej za pomocą właściwości tej klasy nie musi być adresem miejsca, z którego odbywa się fizyczna sprzedaż lub są świadczone jakieś usługi.

Do opisu adresu mogą być wykorzystywane np. znaczniki hCard (vCard). Właściwościami dla których ta klasa jest dziedziną to: gr:hasDUNS, gr:hasGlobalLocationNumber, gr:hasISICv4, gr:hasNAICS, gr:hasPOS, gr:legalName, gr:offers, gr:owns, gr:seeks. Właściwość, która może wskazywać na klasę tego typu jest właściwość gr:hasManufacturer.

Przykładowo za pomocą właściwości gr:legalName zapisanej w języku RDFa na stronie www można określić nazwę firmy:

<span property=”gr:legalName” content=”Microsoft Corporation” datatype=”xsd:string”/>

Właściwość gr:hasPos wskazuje miejsce sprzedaży lub świadczenia określonych ofert (gr:LocationOfSalesOrServiceProvisioning).

Klasa gr:Offering i jej właściwości reprezentują ofertę danej jednostki, a konkretnie chęć świadczenia lub szukania określonych funkcji biznesowych (gr:BusinessFunction) dla określonych produktów czy usług, w tym ofertę samych produktów czy usług. Tymi funkcjami mogą być: sprzedaż, naprawa czy wynajem. Za pomocą właściwości tej klasy można nie tylko opisywać wyżej wymienione elementy ale także wskazać na opis określonego produkty czy oferty znajdującej się na różnych stronach www, które z ekonomicznego punktu widzenia mogą podnosić ich jakość czy wartość użytkową np. „za pomocą mojego aparatu Sony 556X zrobiłem świetne zdjęcia” (gr:ActualProductOrServiceInstance).

Niektóre właściwości wchodzących w skład dziedziny opisywanej klasy to: gr:acceptedPaymentMethods, gr:availableAtOrFrom gr:availableDeliveryMethods, gr:condition, gr:eligibleCustomerTypes, gr:eligibleRegions,  gr:hasBusinessFunction, gr:hasEAN_UCC-13, gr:hasEligibleQuantity, gr:hasPriceSpecification, gr:hasWarrantyPromise, gr:includes, gr:serialNumber, gr:validFrom, gr:validThrough.

Właściwości, które mogą wskazywać na instancję klasy gr:Offering to: gr:addOn, gr:offers oraz gr:seeks. Przykładowo za pomocą właściwości gr:hasBusinessFunction klasy gr:Offering można zapisać fakt sprzedaży oprogramowania Windows XP przez dowolną firmę:
…
<div property=”rdfs:label” content=”Windows XP” xml:lang=”pl”></div>
<div property=”rdfs:comment” content=”System operacyjny Windows XP firmy Microsoft” xml:lang=”pl”></div>
<div rel=”gr:hasBusinessFunction” resource=”http://purl.org/goodrelations/v1#Sell”></div>
…

Klasa gr:ProductOrServiceModel jest klasą charakteryzujące grupy podobnych produktów będących najczęściej produktami sprzedaży masowej. Można to utożsamiać z modelem danego produktu np. Sony Ericsson W125 (nienamacalny obiekt). Klasa ta jest tak naprawdę podklasą klasy gr:ProductOrService.

W celu rozróżnienia sytuacji, w których chcemy opisać produkt o jakiejś nazwie, który jest produktem określonego modelu (np. posiada te same właściwości techniczne, ale różni się nazwą) można dany produkt z klasy gr:ActualProductOrServiceInstance powiązać właściwością gr:hasMakeAndModel.

Do opisu oferty typowych serwisów e-Commerce (np. sprzedaż jakiegoś produktu) w sieci używa się klasy gr:Offering, natomiast klasa gr:ProductOrServiceModel może opisywać model tegoż produktu. Nie jest więc ona wymagana w semantycznym opisie sklepu internetowego, gdyż opisuje ona obiekt abstrakcyjny (nienamacalny). Jej użycie może być bardziej przydatne np. w budowaniu ontologii przemysłowych gromadzących informacje o abstrakcyjnych modelach produktów.

Zapraszam do kolejnej części artykułu…

<span style="font-size: 12.0pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"><span style="mso-tab-count: 1;">               </span></span><em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US; mso-bidi-font-weight: bold;" lang="EN-US">&lt;span</span></em><em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US;" lang="EN-US"> property="gr:legalName" content="Microsoft Corporation" datatype="xsd:string"<span style="mso-bidi-font-weight: bold;">/&gt;</span></span></em>

<em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US; mso-bidi-font-weight: bold;" lang="EN-US"> </span></em>

<em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: black; mso-ansi-language: EN-US; mso-bidi-font-weight: bold;" lang="EN-US"><span style="mso-tab-count: 1;">               </span></span></em>

<em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US; mso-bidi-font-weight: bold;" lang="EN-US">…</span></em>

<em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US; mso-bidi-font-weight: bold;" lang="EN-US">&lt;div</span></em><em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US;" lang="EN-US"> property="rdfs:label" content="Windows XP" xml:lang="pl"<span style="mso-bidi-font-weight: bold;">&gt;&lt;/div&gt;</span></span></em>

<em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US; mso-bidi-font-weight: bold;" lang="EN-US"><span style="mso-tab-count: 1;">      </span>&lt;div</span></em><em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US;" lang="EN-US"> property="rdfs:comment" content="System operacyjny Windows XP firmy Microsoft" xml:lang="pl"<span style="mso-bidi-font-weight: bold;">&gt;&lt;/div&gt;</span></span></em>

<em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US; mso-bidi-font-weight: bold;" lang="EN-US">&lt;div</span></em><em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-ansi-language: EN-US;" lang="EN-US"> rel="gr:hasBusinessFunction" resource="http://purl.org/goodrelations/v1#Sell"<span style="mso-bidi-font-weight: bold;">&gt;&lt;/div&gt;</span></span></em>

<em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; color: black; mso-bidi-font-weight: bold;">…</span></em>

<em style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: black; mso-bidi-font-weight: bold;"> </span></em>

<span style="font-size: 12.0pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: black;"> </span>

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