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…

Narzędzie to posiada kilka bardzo użytecznych funkcji, za pomocą których w łatwy sposób możemy odpytywać zasoby opisane w RDF. Klasy te posiadają parsery dla: RDF/XML, Turtle, SPARQL + SPOG, Legacy XML, HTML tag soup, RSS 2.0, Google Social Graph API JSON,  umożliwiają wykorzystanie SPARQL Endpoint w bardzo szybki i prosty sposób, posiadają możliwość odczytywanie mikroformatów ze stron www (DC, eRDF, microformats, OpenID, RDFa). Pełna funkcjonalność opisana jest w dokumentacji pod adresem arc.semsol.org.

Pierwszym przykładowym zastosowaniem klas ARC jaki chce pokazać to zapytanie do serwisu DBPedia z wykorzystaniem SPARQL Endpoint. W ARC cały proces łączenia się z serwisem to parę linijek kodu:

include_once('arc/ARC2.php');
$config = array(
'remote_store_endpoint' => 'http://dbpedia.org/sparql',
);
$store = ARC2::getRemoteStore($config);

Zapytanie będzie brzmiało tak: „Wyszukaj wszystkie nazwy państw (commonName), ich waluty (currency) z oznakowaniem (currencyCode), których oficjalny język (officialLanguages) to hiszpański.”

$query = '
PREFIX countries: <http://dbpedia.org/ontology/Country>

SELECT DISTINCT ?name ?currency ?code WHERE {
?b rdf:type countries: .
?b <http://dbpedia.org/property/officialLanguages> ?c .
?b <http://dbpedia.org/property/commonName> ?name .
?b <http://dbpedia.org/ontology/currency> ?currency .
?b <http://dbpedia.org/property/currencyCode> ?code
FILTER(regex(?c, "Spanish"))
}
';
$r = '<table>';

if ($rows = $store->query($q, 'rows')) {

foreach ($rows as $row) {
$r .= '<tr><td>' . $row['name'] . '</td><td>' . $row['currency'] . '</td><td>' . $row['code'] . '</td></tr>';
}
}
$r.='</table>';
echo $r ? $r  : 'nic nie znaleziono';

Otrzymany wynik wyglądał tak:

Drugim przykładem zastosowania tego narzędzia jest odczytywanie semantycznych znaczników ze stron www. ARC umożliwia odpytywanie pobranych danych po wcześniejszym „zamontowaniu” ich w lokalnej bazie danych użytkownika. Cały proces polega na zapisie tychże danych do specjalnie oznakowanych tabel (przez dodanie prefiksu). Pisząc zapytania SPARQL ARC przekształca je na zapytania odpowiednie dla relacyjncyh baz danych np. MySQL.

Prosta strona www z paroma semantycznymi znacznikami (DC i FOAF) mogłaby wyglądać tak:

<?xml version="1.0" encoding="UTF-8"?>
<!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"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
version="XHTML+RDFa 1.0" xml:lang="en">
<head>
<title></title>
<meta property="dc:creator" content="admin" />
</head>
<body>
<p>Mój nick to <span property="foaf:nick">testowy_nick44</span><br />
Mój ulubiony gatunek filmu to
<span property="foaf:interest">Sci-Fi</span><br />
Mój blog znajdziesz ppd adresem <span property="foaf:homepage">semantictechnology.eu</span>
</p>
</body>
</html>

Skrypt w PHP odczytujący nick, stronę domową oraz zainteresowania wszystkich osób opisanych znacznikiem foaf z wykorzystaniem klas ARC mógłby wyglądać tak:

$config = array(
'db_name' => 'arc',
'db_user' => 'root',
'db_pwd' => 'password',
'store_name' => 'arc_tables',
'max_errors' => 100,
);
$store = ARC2::getStore($config);

if (!$store->isSetUp()) {
$store->setUp();
}
$store->query('LOAD <http://www.przykladowaatrona.pl/semantycznapodstrona.html>');

$q = '
PREFIX foaf: <http://xmlns.com/foaf/0.1/> .
SELECT ?nick ?interest ?homepage WHERE {
?p foaf:homepage ?homepage ; foaf:nick ?nick ; foaf:interest ?interest
}
';
$r = '';

if ($rows = $store->query($q, 'rows')) {

foreach ($rows as $row) {
$r .= '<li>' . $row['nick'] . '- '.$row['homepage'].' - '.$row['interest'].'</li>';
}
}
echo $r ? '<ul>' . $r . '</ul>' : 'nic nie znaleziono';

Otrzymany wynik:

• testowy_nick44- semantictechnology.eu – Sci-Fi

Przyglądając się stworzonym przez ARC tabelom w bazie danych widzimy, że jest ich 6. Opisane są w nich trójki s-p-o:

To tylko niektóre z oferowanych możliwości klas ARC. Więcej można znaleźć w dokumentacji.

Jedną z idei semantycznej sieci www jest opisywanie zasobów za pomocą skierowanych grafów RDF. Gdy mamy już owe grafy zapisane np. w plikach .rdf musimy mieć możliwość ich przeszukiwania wg. interesujących nas kryteriów. Językiem zapytań oraz protokołem dla plików RDF jest (uznany oficjalnie w 2008 roku przez W3C jako standard)  SPARQL (SPARQL Protocol And RDF Query Language ) przypominający w swojej składni SQL.

SPARQL udostępnia cztery formy zapytań: SELECT, DESCRIBE, ASK i CONSTRUCT. Posiada podobnie jak SQL dodatkowe warunki typu ORDER BY, UNION, OPTIONAL itp. Zapytanie SELECT pozwala na zwrot szukanej wartości. CONSTRUCT umożliwia stworzenie grafu RDF na bazie zapytania. Chcąc dowiedzieć się czy dane zapytanie zwróci jakiś wynik można użyć polecenia ASK. Zapytanie DESCRIBE poda najmniejszy możliwy graf opisujący dany zasób.

Po zapoznaniu się z jego specyfikacją na stronie w3.org/TR/rdf-sparql-query/ możemy zacząć działać. Prostym narzędziem, które możemy wykorzystać do wykonywania zapytań na stworzonym przez nas pliku .rdf jest RAP API dla PHP. RAP to biblioteki dla PHP umożliwiające przetwarzanie plików RDF.

Stworzony przeze mnie przykładowy plik  semanticemployee.rdf wygląda następująco:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:vcard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description rdf:about="http://semanticemployee.eu/employee/BillParker/">
<vcard:EMAIL>bill.p@example.eu</vcard:EMAIL>
<vcard:FN>Bill Parker</vcard:FN>
<vcard:TEL>>222555999</vcard:TEL>
</rdf:Description>
<rdf:Description rdf:about="http://semanticemployee.eu/employee/GeorgeSimpson/">
<vcard:EMAIL>george.s@example.eu</vcard:EMAIL>
<vcard:FN>George Simpson</vcard:FN>
<vcard:TEL>>999777222</vcard:TEL>
</rdf:Description>
<rdf:Description rdf:about="http://semanticemployee.eu/employee/MonicaMurphy/">
<vcard:EMAIL>monica.m@example.eu</vcard:EMAIL>
<vcard:FN>Monica Murphy</vcard:FN>
<vcard:TEL>>555777888</vcard:TEL>
</rdf:Description>
</rdf:RDF>

Pierwszym najprostszym zapytaniem na powyższym pliku będzie wyszukanie wszystkich imion pracowników. Wykorzystując język SPARQL możemy zapisać to tak:

PREFIX vcard <http://www.w3.org/2001/vcard-rdf/3.0#>
SELECT ?fullName
WHERE { ?x vcard:FN ?fullName }

Składnia zapytania jest dosyć prosta. Prefix oznacza wykorzystywaną przez nas przestrzeń nazw. W tym przykładzie wykorzystano przestrzeń nazw, która reprezentuje obiekty vCard w pliakch RDF. Wykorzystując RAP API, cały kod potrzebny do zwrócenia wyniku może wyglądać tak:

<?php
$employees = ModelFactory::getDefaultModel();
$employees->load('semanticemployee.rdf');
$querystring = '
PREFIX vcard <http://www.w3.org/2001/vcard-rdf/3.0#>
SELECT ?fullName
WHERE { ?x vcard:FN ?fullName }';
echo $employees->sparqlQuery($querystring, 'HTML');
?>

Jako wynik otrzymamy:

Zwrócimy teraz wszystkie imiona i adresy e-mail posortowane malejąco zmieniając zapytanie na takie:

PREFIX vcard <http://www.w3.org/2001/vcard-rdf/3.0#>
SELECT ?fullName ?mail
WHERE { ?x vcard:FN ?fullName . ?x vcard:EMAIL ?mail }
ORDER BY DESC(?fullName)

W efekcie otrzymamy:

I na koniec zapytanie typu CONSTRUCT. Chcemy otrzymać graf RDF taki, w którym znajdują są tylko imiona pracowników w kolejności rosnących numerów telefonów (zakładając, że są one w formie liczby takiej jak w przykładzie):

PREFIX vcard <http://www.w3.org/2001/vcard-rdf/3.0#>
CONSTRUCT   { ? vcard:FN ?name }
WHERE       { ? vcard:FN ?name ; vcard:TEL ?tel . }
ORDER BY ?tel

Otrzymany graf wygląda tak:

<!-- Generated by RdfSerializer.php from RDF RAP. # http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/index.html !-->
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:owl="http://www.w3.org/2002/07/owl#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:vcard="http://www.w3.org/2001/vcard-rdf/3.0#">
Bill Parker
Monica Murphy
George Simpson